Remove the string "(Device Tree)" after the machine name because all AT91
machines use the DT nowadays.
Also change some function names to unify following the convention:
- at91sam9xxx aren't named sam9, 9xxx but with the full name
- sama5 are the ones that don't have the at91 prefix anymore.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Move the ramc initialization to pm.c as it is the only user left.
This allows us to get rid of at91_dt_initialize() that was the only one called
by the init_early() function pointer of struct machine_desc.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
[nicolas.ferre@atmel.com: adapt patch to newer series]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
As board files are now DT only and can address all aspects of the SoC family,
we can rename them so that the mach-at91 directory looks cleaner.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
at91_boot_soc and at91_init_soc structures are not used by any SoC, remove
their use. Also remove all the now empty SoC files.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
[nicolas.ferre@atmel.com: different organization of the patches]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
For sama5d4, remove an indirection and the remaining need for at91_boot_soc
structure.
This will allow further cleanup.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Only use SOC_AT91SAM9 for all the at91sam9 SoCs. It removes all the empty
at91sam9xxx.c SoC files. It also removes the useless at91_init_soc affectation
procedure and its "init" function pointer.
Only the SoC detection and display are kept for the at91sam9:
at91_soc_is_enabled() and at91_boot_soc.map_io() function calls are also
removed.
It enables HAVE_AT91_SMD and HAVE_AT91_UTMI for all the sam9 SoCs but this only
represents 96 bytes of uncompressed kernel code.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
[nicolas.ferre@atmel.com: different organization of the patches]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Setup arm_pm_idle and arm_pm_restart function pointers from
rm9200_dt_device_init() function to simplify the at91rm9200 initialization
process.
This same move is already done for the sam9s.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
[nicolas.ferre@atmel.com: adapt patch to newer series]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Use the GPIO descriptor API instead of the deprecated legacy GPIO API to
manage the busy GPIO.
The patch updates both the jz4740 nand driver and the only user of the driver
the qi-lb60 board driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The Intel Snowfield Peak Bluetooth controllers use a strict scanning
filter policy that filters based on Bluetooth device addresses and
not on RSSI.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When using LE_SCAN_FILTER_DUP_ENABLE, some controllers would send
advertising report from each LE device only once. That means that we
don't get any updates on RSSI value, and makes Service Discovery very
slow. This patch adds restarting scan when in Service Discovery, and
device with filtered uuid is found, but it's not in RSSI range to send
event yet. This way if device moves into range, we will quickly get RSSI
update.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Currently there is no way to restart le scan, and it's needed in
service scan method. The way it work: it disable, and then enable le
scan on controller.
During the restart, we must remember when the scan was started, and
it's duration, to later re-schedule the le_scan_disable work, that was
stopped during the stop scan phase.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Add support for retrieving port level statistics from device.
Hook is added for ethtool's stats functionality. For example,
$ ethtool -S eth3
NIC statistics:
rx_packets: 12
rx_bytes: 2790
rx_dropped: 0
rx_errors: 0
tx_packets: 8
tx_bytes: 728
tx_dropped: 0
tx_errors: 0
Signed-off-by: David Ahern <dsahern@gmail.com>
Acked-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Roopa Prabhu says:
====================
switchdev offload flags
This patch series introduces new offload flags for switchdev.
Kernel network subsystems can use this flag to accelerate
network functions by offloading to hw.
I expect that there will be need for subsystem specific feature
flag in the future.
This patch series currently only addresses bridge driver link
attribute offloads to hardware.
Looking at the current state of bridge l2 offload in the kernel,
- flag 'self' is the way to directly manage the bridge device in hw via
the ndo_bridge_setlink/ndo_bridge_getlink calls
- flag 'master' is always used to manage the in kernel bridge devices
via the same ndo_bridge_setlink/ndo_bridge_getlink calls
Today these are used separately. The nic offloads use hwmode "vepa/veb" to go
directly to hw with the "self" flag.
At this point i am trying not to introduce any new user facing flags/attributes.
In the model where we want the kernel bridging to be accelerated with
hardware, we very much want the bridge driver to be involved.
In this proposal,
- The offload flag/bit helps switch asic drivers to indicate that they
accelerate the kernel networking objects/functions
- The user does not have to specify a new flag to do so. A bridge created with
switch asic ports will be accelerated if the switch driver supports it.
- The user can continue to directly manage l2 in nics (ixgbe) using the
existing hwmode/self flags
- It also does not stop users from using the 'self' flag to talk to the
switch asic driver directly
- Involving the bridge driver makes sure the add/del notifications to user
space go out after both kernel and hardware are programmed
(To selectively offload bridge port attributes,
example learning in hw only etc, we can introduce offload bits for
per bridge port flag attribute as in my previous patch
https://patchwork.ozlabs.org/patch/413211/. I have not included that in this
series)
v2
- try a different name for the offload flag/bit
- tries to solve the stacked netdev case by traversing the lowerdev
list to reach the switch port
v3 -
- Tested with bond as bridge port for the stacked device case.
Includes a bond_fix_features change to not ignore the
NETIF_F_HW_NETFUNC_OFFLOAD flag
- Some checkpatch fixes
v4 -
- rename flag to NETIF_F_HW_SWITCH_OFFLOAD
- add ndo_bridge_setlink/dellink handlers in bond and team drivers as
suggested by jiri.
- introduce default ndo_dflt_netdev_switch_port_bridge_setlink/dellink
handlers that masters can use to call offload api on lowerdevs.
====================
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Currently ndo_bridge_setlink and ndo_bridge_dellink handlers point
to the default switchdev handlers
This follows my bonding driver changes.
I have only compile tested this patch. However similar
bonding code has been tested.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We want bond to pick up the offload flag if any of its slaves have it.
NETIF_F_HW_SWITCH_OFFLOAD flag is added to the mask, so that
netdev_increment_features does not ignore it.
This also adds ndo_bridge_setlink and ndo_bridge_dellink handlers.
These currently point to the default handlers provided by the
switchdev api.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch sets the NETIF_F_HW_SWITCH_OFFLOAD feature flag on rocker ports
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support to set/del bridge port attributes in hardware from
the bridge driver.
With this, when the user sends a bridge setlink message with no flags or
master flags set,
- the bridge driver ndo_bridge_setlink handler sets settings in the kernel
- calls the swicthdev api to propagate the attrs to the switchdev
hardware
You can still use the self flag to go to the switch hw or switch port
driver directly.
With this, it also makes sure a notification goes out only after the
attributes are set both in the kernel and hw.
The patch calls switchdev api only if BRIDGE_FLAGS_SELF is not set.
This is because the offload cases with BRIDGE_FLAGS_SELF are handled in
the caller (in rtnetlink.c).
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds two new api's netdev_switch_port_bridge_setlink
and netdev_switch_port_bridge_dellink to offload bridge port attributes
to switch port
(The names of the apis look odd with 'switch_port_bridge',
but am more inclined to change the prefix of the api to something else.
Will take any suggestions).
The api's look at the NETIF_F_HW_SWITCH_OFFLOAD feature flag to
pass bridge port attributes to the port device.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bridge flags are needed inside ndo_bridge_setlink/dellink handlers to
avoid another call to parse IFLA_AF_SPEC inside these handlers
This is used later in this series
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a high level feature flag for all switch asic offloads
switch drivers set this flag on switch ports. Logical devices like
bridge, bonds, vxlans can inherit this flag from their slaves/ports.
The patch also adds the flag to NETIF_F_ONE_FOR_ALL, so that it gets
propagated to the upperdevices (bridges and bonds).
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- In tx_hard_error_bump_tc interrupt, tc should be bumped only when current
device instance is in DMA threshold mode. Check per device xstats.threshold
other than global tc.
- Set per device xstats.threshold to SF_DMA_MODE when current device
instance is set to SF mode.
v2-changes:
- fix ident style
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In commit be9f4a44e7 ("ipv4: tcp: remove per net tcp_sock")
I tried to address contention on a socket lock, but the solution
I chose was horrible :
commit 3a7c384ffd ("ipv4: tcp: unicast_sock should not land outside
of TCP stack") addressed a selinux regression.
commit 0980e56e50 ("ipv4: tcp: set unicast_sock uc_ttl to -1")
took care of another regression.
commit b5ec8eeac4 ("ipv4: fix ip_send_skb()") fixed another regression.
commit 811230cd85 ("tcp: ipv4: initialize unicast_sock sk_pacing_rate")
was another shot in the dark.
Really, just use a proper socket per cpu, and remove the skb_orphan()
call, to re-enable flow control.
This solves a serious problem with FQ packet scheduler when used in
hostile environments, as we do not want to allocate a flow structure
for every RST packet sent in response to a spoofed packet.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add the remaining gpci requests that contain counters suitable for use
by perf. Omit those that don't contain any counters (but note their
ommision).
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This adds (in req-gen/) a framework for defining gpci counter requests.
It uses macro magic similar to ftrace.
Also convert the existing hv-gpci request structures and enum values to
use the new framework (and adjust old users of the structs and enum
values to cope with changes in naming).
In exchange for this macro disaster, we get autogenerated event listing
for GPCI in sysfs, build time field offset checking, and zero
duplication of information about GPCI requests.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Retrieves and parses the 24x7 catalog on POWER systems that supply it
(right now, only POWER 8). Events are exposed via sysfs in the standard
fashion, and are all parameterized.
$ cd /sys/bus/event_source/devices/hv_24x7/events
$ cat HPM_CS_FROM_L4_LDATA__PHYS_CORE
domain=0x2,offset=0xd58,core=?,lpar=0x0
$ cat HPM_TLBIE__VCPU_HOME_CHIP
domain=0x4,offset=0x358,vcpu=?,lpar=?
where user is required to specify values for the fields with '?' (like
core, vcpu, lpar above), when specifying the event with the perf tool.
Catalog is (at the moment) only parsed on boot. It needs re-parsing
when a some hypervisor events occur. At that point we'll also need to
prevent old events from continuing to function (counter that is passed
in via spare space in the config values?).
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Define a lite version of the EVENT_DEFINE_RANGE_FORMAT() that avoids
defining helper functions for the bit-field ranges.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(struct perf_pmu_events_attr) is defined in include/linux/perf_event.h,
but the only "show" for it is in x86 and contains x86 specific stuff.
Make a generic one for those of us who are just using the event_str.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In commit dc9daab226 ("cxgb4: Added support in debugfs to dump
sge_qinfo") a preprocessor check for CONFIG_CXGB4_DCB got added, which should
have been CONFIG_CHELSIO_T4_DCB. After adding the right preprocessor, build
fails due to missing function ethqset2pinfo. Fixing that as well.
V2: Updated description since the patch also fixes build failure
Reported-by: Paul Bolle <pebolle@tiscal.nl>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8eb23b9f35
sched: Debug nested sleeps
causes false-positive warnings in RAID5 code.
This annotation removes them and adds a comment
explaining why there is no real problem.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If a non-page-aligned write is destined for a device which
is missing/faulty, we can deadlock.
As the target device is missing, a read-modify-write cycle
is not possible.
As the write is not for a full-page, a recontruct-write cycle
is not possible.
This should be handled by logic in fetch_block() which notices
there is a non-R5_OVERWRITE write to a missing device, and so
loads all blocks.
However since commit 67f455486d, that code requires
STRIPE_PREREAD_ACTIVE before it will active, and those circumstances
never set STRIPE_PREREAD_ACTIVE.
So: in handle_stripe_dirtying, if neither rmw or rcw was possible,
set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set
after a suitable delay.
Fixes: 67f455486d
Cc: stable@vger.kernel.org (v3.16+)
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Tested-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Previously, we requested that drivers pass ecc.size and ecc.bytes when
using NAND_ECC_SOFT_BCH. However, a driver is likely to only know the ECC
strength required for its NAND, so each driver would need to perform a
strength-to-bytes calculation.
Avoid duplicating this calculation in each driver by asking drivers to
pass ecc.size and ecc.strength so that the strength-to-bytes calculation
need only be implemented once.
This reverts/generalizes this commit:
mtd: nand: Base BCH ECC bytes on required strength
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
As commit 50ba08f3 ("of/fdt: Don't clear initial_boot_params
if fdt_check_header() fails") does, the device-tree pointer
"initial_boot_params" is initialized by early_init_dt_verify(),
which is called by early_init_devtree(). So we needn't explicitly
initialize that again in early_init_devtree().
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
We have code to do syscall tracing which is disabled at compile time by
default. It's not been touched since the dawn of time (ie. v2.6.12).
There are now better ways to do syscall tracing, ie. using the
raw_syscall, or syscall tracepoints.
For the specific case of tracing syscalls at boot on a system that
doesn't get to userspace, you can boot with:
trace_event=syscalls tp_printk=on
Which will trace syscalls from boot, and echo all output to the console.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Currently when we back trace something that is in a syscall we see
something like this:
[c000000000000000] [c000000000000000] SyS_read+0x6c/0x110
[c000000000000000] [c000000000000000] syscall_exit+0x0/0x98
Although it's entirely correct, seeing syscall_exit at the bottom can be
confusing - we were exiting from a syscall and then called SyS_read() ?
If we instead change syscall_exit to be a local label we get something
more intuitive:
[c0000001fa46fde0] [c00000000026719c] SyS_read+0x6c/0x110
[c0000001fa46fe30] [c000000000009264] system_call+0x38/0xd0
ie. we were handling a system call, and it was SyS_read().
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When unbinding and rebinding the driver on a system with a card in PHB0, this
error condition is reached after a few attempts:
ERROR: Bad of_node_put() on /pciex@3fffe40000000
CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe #152
Call Trace:
[c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable)
[c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0
[c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0
[c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30
[c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50
[c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0
[c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170
[c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0
[c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160
[c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60
[c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0
[c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0
[c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260
[c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100
[c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98
We are missing a call to of_node_get(). pnv_pci_to_phb_node() should
call of_node_get() otherwise np's reference count isn't incremented and
it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node()
so it's clear it calls of_node_get().
Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Rebase of main pull for 3.20. There was a mid-air collision between
the bridge changes and msm eDP support. And atomic dpms support broke
msm somewhat, due to using prepare/commit hooks in a different way.
Compared to the initial pull req, this fixes up a memory leak caused
by the bridge changes, rebases the eDP support on the bridge changes,
and migrates to the atomic dpms hooks to fix the dpms breakage.
Highlights (from original pull req):
1) YUV support for mdp4 and mdp5
2) eDP support
3) hw cursor support for mdp5[*]
4) additional hdmi support for apq8084 (snapdragon 805)
5) few bug fixes
Note that I may have a later pull to enable hdmi hpd irqs.. but
(un)fortunately I seem to have a particularly troublesome monitor.. I
managed to figure out a workaround for spurious hpd disconnect irqs
that works with some of my boards but not others, so holding off on
that patch for now. There are also patches for HDCP support, but
those are waiting on some scm patches outside of drm so I think
waiting until 3.21 at this point.
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (22 commits)
drm/msm: add moduleparam to disable fbdev
drm/msm: fix build error with W=1
drm/msm/mdp5: Fix negative SMP block allocation
drm/msm/hdmi: disallow interlaced
drm/msm/atomic: fix issue with gnome-shell wayland
drm/msm/mdp5: Add hardware cursor support
drm/msm/hdmi: rework hdmi configurations, using dt_match[]
drm/msm/hdmi: Add HDMI platform config for apq8084
drm/msm/hdmi: use dynamic allocation for hdmi resources
drm/msm/mdp5: fix parameter type for mdp5_ctl_set_intf()
drm/msm/dp: use link power helpers
drm/msm: Add the eDP connector in msm drm driver (V2)
drm/msm: Initial add eDP support in msm drm driver (v5)
drm/msm/mdp4: add YUV format support
drm/msm/mdp5: add NV12 support for MDP5
drm/msm/mdp: add common YUV information for MDP4/MDP5
drm/msm: update generated headers
drm/msm: Do not BUG_ON(!spin_is_locked()) on UP
drm/msm/hdmi: fix memory leak after bridge changes
drm/msm: fix fallout of atomic dpms changes
...
Currently, the ioctl handling code for XFS_IOC_FSSETXATTR treats all
targets as regular files: it refuses to change the extent size if
extents are allocated. This is wrong for directories, as there the
extent size is only used as a default for children.
The patch fixes this issue and improves validation of flag
combinations:
- only disallow extent size changes after extents have been allocated
for regular files
- only allow XFS_XFLAG_EXTSIZE for regular files
- only allow XFS_XFLAG_EXTSZINHERIT for directories
- automatically clear the flags if the extent size is zero
Thanks to Dave Chinner for guidance on the proper fix for this issue.
[dchinner: ported changes onto cleanup series. Makes changes clear
and obvious.]
[dchinner: added comments documenting validity checking rules.]
Signed-off-by: Iustin Pop <iustin@k1024.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The project ID change checking is one of the few remaining open
coded checks in xfs_ioctl_setattr(). Factor it into a helper
function so that the setattr code mostly becomes a flow of check
and action helpers, making it easier to read and follow.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>