The declaration was necessary until commit cc2d224777 ("pwm: Drop
per-chip dbg_show callback").
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no cyclic dependency, so by reordering the forward declaration
can be dropped.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Spelling mistake (triple letters) in comment. Detected with the help of
Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There are no drivers left providing the legacy callbacks. So drop
support for these.
If this commit breaks your out-of-tree pwm driver, look at e.g. commit
ec00cd5e63 ("pwm: renesas-tpu: Implement .apply() callback") for an
example of the needed conversion for your driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This contains a couple of fixes:
- fid refcounting was incorrect in some corner cases and would
leak resources, only freed at umount time. The first three commits
fix three such cases
- cache=loose or fscache was broken when trying to write a partial
page to a file with no read permission since the rework a few releases
ago. The fix taken here is just to restore old behavior of using the
special 'writeback_fid' for such reads, which is open as root/RDWR
and such not get complains that we try to read on a WRONLY fid.
Long-term it'd be nice to get rid of this and not issue the read at
all (skip cache?) in such cases, but that direction hasn't progressed
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE/IPbcYBuWt0zoYhOq06b7GqY5nAFAmKynEUACgkQq06b7GqY
5nBOwQ//c1AoCuzt8gXefaBy9dDvaq/Cg5a339bUGmsvRJS8dHWTx2/HO7ncf3wE
59uRh+ipLxXmHTkkLz13JtaVAFQ2HYlxKwmyvakBIjGVgDC+IYm9vkPHb2Z2yIBY
D6XTuNufnb+/lrqekrmHiT2+eJOi2MhxPNyjXUAML7KKny6LpzdwymF/KIEsCbR8
EbRrSf+KTnCssIfJlrZUbbk2UkbW18uG/V1MgThN3rgj+bgG/oB+lU6BELCIOQc2
+0io2dg+ZgfJIK2fpBKF64vK2ILMSNEJ8obkfWgqOyI/LBOya38Z/cSbuzPMBwZd
P2A2zQmjp8oYSbXM8EGaSFTXix28Lxljk5vvT/xbEipzyUU3UZAPJJE6UX9M66UF
d/FHA8ljDVuRrknM0yDv5sqBYRB8uuEBtUiKGBO6k5zPTn0A7oEzEviryMCiEUF5
1fbe/PWrFLnZMB2hWZ1aiY0tyopivp67zo6mRY/qehCihb/QlpiVNLGCC1e3eMdu
FHPR3pSD1B5jFurOB8Wn1zUMjsZsnIjvpOET4WiP9pU9SJpOCd2fsAo69POHZVfA
NIJxZ9MqW+3/eK+7CDmwnJLhTNRvvrQmTH55Ex61HTcn+2KFIqizCr/I6sQUl/g0
teAB8T5UlS6+nDDWfZouUiXcm0He2C56RyJOCYlagHD1qYm//Gg=
=2yZw
-----END PGP SIGNATURE-----
Merge tag '9p-for-5.19-rc4' of https://github.com/martinetd/linux
Pull 9pfs fixes from Dominique Martinet:
"A couple of fid refcount and fscache fixes:
- fid refcounting was incorrect in some corner cases and would leak
resources, only freed at umount time. The first three commits fix
three such cases
- 'cache=loose' or fscache was broken when trying to write a partial
page to a file with no read permission since the rework a few
releases ago.
The fix taken here is just to restore old behavior of using the
special 'writeback_fid' for such reads, which is open as root/RDWR
and such not get complains that we try to read on a WRONLY fid.
Long-term it'd be nice to get rid of this and not issue the read at
all (skip cache?) in such cases, but that direction hasn't
progressed"
* tag '9p-for-5.19-rc4' of https://github.com/martinetd/linux:
9p: fix EBADF errors in cached mode
9p: Fix refcounting during full path walks for fid lookups
9p: fix fid refcount leak in v9fs_vfs_get_link
9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl
For devices stuck behind a conventional PCI bus, saving extra cycles at
33MHz is probably fairly significant. However since native PCI Express
is now the norm for high-performance devices, the optimisation to always
prefer 32-bit addresses for the sake of avoiding DAC is starting to look
rather anachronistic. Technically 32-bit addresses do have shorter TLPs
on PCIe, but unless the device is saturating its link bandwidth with
small transfers it seems unlikely that the difference is appreciable.
What definitely is appreciable, however, is that the IOVA allocator
doesn't behave all that well once the 32-bit space starts getting full.
As DMA working sets get bigger, this optimisation increasingly backfires
and adds considerable overhead to the dma_map path for use-cases like
high-bandwidth networking. We've increasingly bandaged the allocator
in attempts to mitigate this, but it remains fundamentally at odds with
other valid requirements to try as hard as possible to satisfy a request
within the given limit; what we really need is to just avoid this odd
notion of a speculative allocation when it isn't beneficial anyway.
Unfortunately that's where things get awkward... Having been present on
x86 for 15 years or so now, it turns out there are systems which fail to
properly define the upper limit of usable IOVA space for certain devices
and this trick was the only thing letting them work OK. I had a similar
ulterior motive for a couple of early arm64 systems when originally
adding it to iommu-dma, but those really should be fixed with proper
firmware bindings by now. Let's be brave and default it to off in the
hope that CI systems and developers will find and fix those bugs, but
expect that desktop-focused distro configs are likely to want to turn
it back on for maximum compatibility.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/3f06994f9f370f9d35b2630ab75171ecd2065621.1654782107.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Use ida_alloc()/ida_free() instead of deprecated
ida_simple_get()/ida_simple_remove().
Signed-off-by: Ke Liu <liuke94@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20220608021655.1538087-1-liuke94@huawei.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Commit 44f362c2cc ("ASoC: rockchip: i2s: switch BCLK to GPIO") added
pinctrl lookups, but did not skip the lookup if there was no pinctrl
device tied to the I2S controller. As a result, the lookup was done
on an invalid pointer in such cases, causing a kernel panic.
Only do the subsequent pinctrl state lookups and switch if a pinctrl
device was found.
i2s_pinctrl_select_bclk_{on,off} already guard against missing pinctrl
device or pinctrl state, so those two functions aren't touched.
Fixes: 44f362c2cc ("ASoC: rockchip: i2s: switch BCLK to GPIO")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20220621185747.2782-1-wens@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Even in the presence of problems (here: rn_acp_deinit() might fail), it's
important to unregister all resources acquired during .probe() because
even if .remove() returns an error code, the device is removed.
As .remove() is only called after .probe() returned success, platdata
must be valid, so the first check in .remove() can just be dropped.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220622061739.225966-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The function snd_soc_unregister_card() returned 0 unconditionally and most
callers don't care to check the return value. Make it return void and
adapt the callers that didn't ignore the return value before.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220621145834.198519-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds mt8186 dsp document. The dsp is used for Sound Open
Firmware driver node. It includes registers, clocks, memory regions,
and mailbox for dsp.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220622062245.21021-4-tinghan.shen@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rename mbox according to actions instead of 'mbox0' and 'mbox1'.
The 8195 dsp node, which uses this binding, has not yet been added to
the 8195 devicetree.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220622062245.21021-2-tinghan.shen@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit 8fc74d1863.
BAR0 is the main (only?) register bank for this device. We most
obviously can't unmap it before the netdev is unregistered.
This was pointed out in review but the patch got reposted and
merged, anyway.
The author of the patch was only testing it with a QEMU model,
which I presume does not emulate enough for the netdev to be brought
up (author's replies are not visible in lore because they kept sending
their emails in HTML).
Link: https://lore.kernel.org/all/20220616085059.680dc215@kernel.org/
Fixes: 8fc74d1863 ("drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kuniyuki Iwashima says:
====================
af_unix: Introduce per-netns socket hash table.
This series replaces unix_socket_table with a per-netns hash table and
reduces lock contention and time on iterating over the list.
Note the 3rd-6th patches can be a single patch, but for ease of review,
they are split into small changes without breakage.
Changes:
v3:
6th:
* Remove unix_table_locks from comments.
* Remove missed spin_unlock(&unix_table_locks) in
unix_lookup_by_ino() (kernel test robot)
v2: https://lore.kernel.org/netdev/20220620185151.65294-1-kuniyu@amazon.com/
3rd:
* Update changelog
* Remove holes from per-netns hash table structure
* Use kvmalloc_array() instead of kmalloc() (Eric Dumazet)
* Remove unnecessary parts in af_unix_init() (Eric Dumazet)
* Move `err_sysctl` label into ifdef block (kernel test robot)
* Remove struct netns_unix from struct net if CONFIG_UNIX is disabled
4th:
* Use spin_lock_nested() (kernel test robot)
v1: https://lore.kernel.org/netdev/20220616234714.4291-1-kuniyu@amazon.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
unix_table_locks are to protect the global hash table, unix_socket_table.
The previous commit removed it, so let's clean up the unnecessary locks.
Here is a test result on EC2 c5.9xlarge where 10 processes run concurrently
in different netns and bind 100,000 sockets for each.
without this series : 1m 38s
with this series : 11s
It is ~10x faster because the global hash table is split into 10 netns in
this case.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit replaces the global hash table with a per-netns one and removes
the global one.
We now link a socket in each netns's hash table so we can save some netns
comparisons when iterating through a hash bucket.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit adds extra spin_lock/spin_unlock() for a per-netns
hash table inside the existing ones for unix_table_locks.
As of this commit, sockets are still linked in the global hash
table. After putting sockets in a per-netns hash table and
removing the old one in the next patch, we remove the global
locks in the last patch.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit adds a per netns hash table for AF_UNIX, which size is fixed
as UNIX_HASH_SIZE for now.
The first implementation defines a per-netns hash table as a single array
of lock and list:
struct unix_hashbucket {
spinlock_t lock;
struct hlist_head head;
};
struct netns_unix {
struct unix_hashbucket *hash;
...
};
But, Eric pointed out memory cost that the structure has holes because of
sizeof(spinlock_t), which is 4 (or more if LOCKDEP is enabled). [0] It
could be expensive on a host with thousands of netns and few AF_UNIX
sockets. For this reason, a per-netns hash table uses two dense arrays.
struct unix_table {
spinlock_t *locks;
struct hlist_head *buckets;
};
struct netns_unix {
struct unix_table table;
...
};
Note the length of the list has a significant impact rather than lock
contention, so having shared locks can be an option. But, per-netns
locks and lists still perform better than the global locks and per-netns
lists. [1]
Also, this patch adds a change so that struct netns_unix disappears from
struct net if CONFIG_UNIX is disabled.
[0]: https://lore.kernel.org/netdev/CANn89iLVxO5aqx16azNU7p7Z-nz5NrnM5QTqOzueVxEnkVTxyg@mail.gmail.com/
[1]: https://lore.kernel.org/netdev/20220617175215.1769-1-kuniyu@amazon.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the size of AF_UNIX hash table is UNIX_HASH_SIZE * 2,
the first half for bind()ed sockets and the second half for unbound
ones. UNIX_HASH_SIZE * 2 is used to define the table and iterate
over it.
In some places, we use ARRAY_SIZE(unix_socket_table) instead of
UNIX_HASH_SIZE * 2. However, we cannot use it anymore because we
will allocate the hash table dynamically. Then, we would have to
add UNIX_HASH_SIZE * 2 in many places, which would be troublesome.
This patch adapts the UNIX_HASH_SIZE definition to include bound
and unbound sockets and defines a new UNIX_HASH_MOD macro to ease
calculations.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some functions define a net pointer only for one-shot use. Others call
sock_net() redundantly even when a net pointer is available. Let's fix
these and make the code simpler.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add common LED properties - the function and color - to aat1290 flash
LED node in Galaxy S3, so we can drop deprecated label property.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220620175033.130468-4-krzysztof.kozlowski@linaro.org
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Ido Schimmel says:
====================
mlxsw: Unified bridge conversion - part 2/6
This is the second part of the conversion of mlxsw to the unified bridge
model. Part 1 was merged in commit 4336487e30 ("Merge branch
'mlxsw-unified-bridge-conversion-part-1'") which includes details about
the new model and the motivation behind the conversion.
This patchset does not begin the conversion, but rather prepares the code
base for it.
Patchset overview:
Patch #1 removes an unnecessary field from one of the FID families.
Patches #2-#7 make various improvements in the layer 2 multicast code,
making it more receptive towards upcoming changes.
Patches #8-#10 prepare the CONFIG_PROFILE command for the unified bridge
model. This command will be used to enable the new model in the last
patchset.
Patches #11-#13 perform small changes in the FID code, preparing it for
upcoming changes.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
rFID and dummy FID do not support FID->VNI mapping. Currently, these
families do not implement the vni_{set, clear}() operations. Instead, there
is a check if these functions are implemented.
Similarly, 'SFMR.nve_tunnel_flood_ptr' is not relevant for rFID and dummy
FID, therefore, these families do not implement
nve_flood_index_{set, clear}().
Align the behavior to other unsupported operations, implement the functions
and just return an error or warn. Then, checks like '!ops->vni_set' can be
removed.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The previous patch added 'fid_offset' field to FID structure. Now, this
field can be used when VNI is set using SFMR register. Currently
'fid_offset' is set to zero, instead, use the new field which is now set
to zero and in the future will be changed.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
SFMR register contains a 'fid_offset' field which is used when flooding
tables of type FID offset are used.
Currently, the driver sets this field to zero, as flooding tables of type
FID are used.
Using unified bridge model, the driver will use FID offset flooding
tables. As preparation, add 'fid_offset' to 'struct mlxsw_sp_fid'. Then,
use this field instead of passing zero to the function that configures
SFMR.
Set the new field as part of 'ops->setup()', for that, implement this
function for dummy FID and rFID.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, as part of mlxsw_pci_init(), resources are queried from firmware
before issuing the 'CONFIG_PROFILE' command.
There are resources whose size depend on the enablement of the unified
bridge model that is performed via 'CONFIG_PROFILE' command. As a
preparation for unified bridge model, add an additional query after issuing
this command. Both queries are required as KVD sizes are read from
firmware and then are configured as part of 'CONFIG_PROFILE' command.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the length of 'config_profile.flood_mode' is defined as 2
bits, while the correct length is 3 bits.
As preparation for unified bridge model, which will use the whole field
length, fix it and increase the field to the correct size.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently magic constant is used for setting 'flood_mode' as part of
config profile.
As preparation for unified bridge model, which will require different
'flood_mode', add a dedicated enumerator for this field and use it as
part of 'struct mlxsw_config_profile'.
Add the relevant value for unified bridge model.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The above mentioned function calls two functions which return values, but
it ignores them.
Check if the return value is an error, handle it in such case and return
an error back to the caller.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The function returns 'false' upon failure and 'true' upon success.
Convert it to the usual scheme of returning integer error codes and
align the callers.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The above mentioned function just returns an error in case that
mlxsw_sp_bridge_ports_flood_table_set() fails. That means that the previous
configurations are not cleaned.
Fix it by adding error path to clean the configurations in case of error.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The above mentioned function is called for each port in bridge when the
multicast behavior is changed. Currently, it updates all the relevant
MID entries only for the first call, but the update of flooding per port
is done only for the port that it was called for it.
To simplify this behavior, it is possible to handle flooding for all the
ports in the first call, then, the other calls will do nothing. For
that, new functions are required to set flooding for all ports, no
'struct mlxsw_sp_port' is required.
This issue was found while extending this function for unified bridge
model, the above mentioned change will ease the extending later.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The function mlxsw_sp_port_mc_disabled_set() sets
'bridge_device->multicast_enabled' twice. Remove the unnecessary setting.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently the above mentioned function gets 'struct mlxsw_sp_port',
while the only use of this structure is to get 'mlxsw_sp_port->mlxsw_sp'.
Instead, pass 'struct mlxsw_sp'.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently 'struct mlxsw_sp_fid_family' has a field which indicates if
'lag_vid' is valid for use in SFD register.
This is a leftover from using .1Q FIDs instead of emulating them using
.1D FIDs.
Currently when .1Q FIDs are emulated using .1D FIDs, this field is true
for both families, so there is no reason to maintain it.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We will use mediatek clock reset as infracfg_ao reset instead of
ti-syscon. To support this, remove property of ti reset and add
property of #reset-cells for mediatek clock reset.
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220503093856.22250-17-rex-bc.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
To support reset of infra, we add property of #reset-cells.
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220503093856.22250-16-rex-bc.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
We need to divide the sub-irq status register offset by register
stride to get an index for the status buffer to avoid an out of
bounds write when the register stride is greater than 1.
Fixes: a2d21848d9 ("regmap: regmap-irq: Add main status register support")
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Link: https://lore.kernel.org/r/20220620200644.1961936-3-aidanmacdonald.0x0@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
