Fix the following fallthrough warnings seen after building sh
architecture with sh7763rdp_defconfig configuration:
drivers/video/fbdev/sh7760fb.c: In function 'sh7760fb_get_color_info':
drivers/video/fbdev/sh7760fb.c:138:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
138 | lgray = 1;
| ~~~~~~^~~
drivers/video/fbdev/sh7760fb.c:139:9: note: here
139 | case LDDFR_4BPP:
| ^~~~
drivers/video/fbdev/sh7760fb.c:143:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
143 | lgray = 1;
| ~~~~~~^~~
drivers/video/fbdev/sh7760fb.c:144:9: note: here
144 | case LDDFR_8BPP:
| ^~~~
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
When configurating a CHn Source Image Format Register (LDBBSIFR), one
should use the corresponding LDBBSIFR_RPKF_* definition for overlay
planes, not the DDFR_PKF_* definition for the primary plane.
Fortunately both definitions resolve to the same value, so this bug did
not cause any harm.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Helge Deller <deller@gmx.de>
We all know they are redundant.
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Michal Wilczynski <michal.wilczynski@intel.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The check for existing VFs was redundant since very
inception of SR-IOV sysfs interface in the kernel,
see commit 1789382a72 ("PCI: SRIOV control and status via sysfs").
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Currently ice driver's .ndo_bpf callback brings interface down and up
independently of XDP resources' presence. This is only needed when
either these resources have to be configured or removed. It means that
if one is switching XDP programs on-the-fly with running traffic,
packets will be dropped.
To avoid this, compare early on ice_xdp_setup_prog() state of incoming
bpf_prog pointer vs the bpf_prog pointer that is already assigned to
VSI. Do the swap in case VSI has bpf_prog and incoming one are non-NULL.
Lastly, while at it, put old bpf_prog *after* the update of Rx ring's
bpf_prog pointer. In theory previous code could expose us to a state
where Rx ring's bpf_prog would still be referring to old_prog that got
released with earlier bpf_prog_put().
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The ice_sq_send_cmd() function is used to send messages to the control
queues used to communicate with firmware, virtual functions, and even some
hardware.
When sending a control queue message, the driver is designed to
synchronously wait for a response from the queue. Currently it waits
between checks for 100 to 150 microseconds.
Commit f86d6f9c49 ("ice: sleep, don't busy-wait, for
ICE_CTL_Q_SQ_CMD_TIMEOUT") did recently change the behavior from an
unnecessary delay into a sleep which is a significant improvement over the
old behavior of polling using udelay.
Because of the nature of PCIe transactions, the hardware won't be informed
about a new message until the write to the tail register posts. This is
only guaranteed to occur at the next register read. In ice_sq_send_cmd(),
this happens at the ice_sq_done() call. Because of this, the driver
essentially forces a minimum of one full wait time regardless of how fast
the response is.
For the hardware-based sideband queue, this is especially slow. It is
expected that the hardware will respond within 2 or 3 microseconds, an
order of magnitude faster than the 100-150 microsecond sleep.
Allow such fast completions to occur without delay by introducing a small 5
microsecond delay first before entering the sleeping timeout loop. Ensure
the tail write has been posted by using ice_flush(hw) first.
While at it, lets also remove the ICE_CTL_Q_SQ_CMD_USEC macro as it
obscures the sleep time in the inner loop. It was likely introduced to
avoid "magic numbers", but in practice sleep and delay values are easier to
read and understand when using actual numbers instead of a named constant.
This change should allow the fast hardware based control queue messages to
complete quickly without delay, while slower firmware queue response times
will sleep while waiting for the response.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Schmidt <mschmidt@redhat.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
KVM_ARM_VCPU_POWER_OFF is as bit index, _not_ a literal bitmask.
Nonetheless, commit e3c1c0cae3 ("KVM: arm64: Relax invariance
of KVM_ARM_VCPU_POWER_OFF") started using it that way, meaning that
powering off a vCPU with the KVM_ARM_VCPU_INIT ioctl is completely
broken.
Fix it by using a shifted bit for the bitwise operations instead.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: e3c1c0cae3 ("KVM: arm64: Relax invariance of KVM_ARM_VCPU_POWER_OFF")
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230622160922.1925530-1-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
STM32F4-F7 are, from hardware point of view, capable to handle device mode.
So this property should not be forced at false in dt-bindings.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/Message-Id: <20230621115523.923176-3-valentin.caron@foss.st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If the soundcard does not specify the dapm pins, let the common
code add these pins for jack.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/Message-Id: <20230302120327.10823-1-srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The i2s driver uses the mapped __iomem address of the FIFO as the DMA
address for the device. This apparently works on loongarch because of
the way it handles __iomem pointers as aliases of physical addresses,
but this is not portable to other architectures and causes a compiler
warning when dma addresses are not the same size as pointers:
sound/soc/loongson/loongson_i2s_pci.c: In function 'loongson_i2s_pci_probe':
sound/soc/loongson/loongson_i2s_pci.c:110:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
110 | tx_data->dev_addr = (dma_addr_t)i2s->reg_base + LS_I2S_TX_DATA;
| ^
sound/soc/loongson/loongson_i2s_pci.c:113:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
113 | rx_data->dev_addr = (dma_addr_t)i2s->reg_base + LS_I2S_RX_DATA;
| ^
Change the driver to instead use the physical address as stored in the
PCI BAR resource directly. Since 'dev_addr' is a 32-bit address, I think
this results in the same truncated address on loongarch but is otherwise
closer to portable code and avoids the warning.
Fixes: d84881e068 ("ASoC: Add support for Loongson I2S controller")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/Message-Id: <20230622101235.3230941-1-arnd@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
"enum" values should be integers or strings, not arrays (though json-schema
does allow arrays, we do not). In this case, all possible combinations are
allowed anyways, so there's little point in expressing as an array.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/Message-Id: <20230621231044.3816914-1-robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove stale comments in AHUB driver which is related to DAPM
widgets and routes. This is misleading otherwise.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/Message-Id: <1687433656-7892-7-git-send-email-spujar@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Align with other AHUB module drivers and use normal system
sleep for ASRC as well.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/Message-Id: <1687433656-7892-6-git-send-email-spujar@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make all possible functions static.
Move iavf_force_wb() up to avoid forward declaration.
Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Defer removal of current primary MAC until a replacement is successfully
added. Previous implementation would left filter list with no primary MAC.
This was found while reading the code.
The patch takes advantage of the fact that there can only be a single primary
MAC filter at any time ([1] by Piotr)
Piotr has also applied some review suggestions during our internal patch
submittal process.
[1] https://lore.kernel.org/netdev/20230614145302.902301-2-piotrx.gardocki@intel.com/
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Piotr Gardocki <piotrx.gardocki@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The Dell Studio 1569 predates Windows 8, so it defaults to using
acpi_video# for backlight control, but this is non functional on
this model.
Add a DMI quirk to use the native intel_backlight interface which
does work properly.
Reported-by: raycekarneal <raycekarneal@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
1. Renesas RPC IF: correct the Strobe Timing Adjustment.
2. Broadcom DPFE: fix smatch warning for testing array offset after use.
3. Atmel SDRAMC: drop driver because it was just a wrapper over enabling
clock which is not handled by its clock controller.
4. Minor bindings cleanup.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmSHW7MQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD12azD/0b7k0T02IRlfIQLPfzJAVT85ax0SJNFZrV
3SmGu1EJMK7n8vBQJh4Jos7ImqI6zoSdK66d7QjsdI7sUTf1yuM78YWAyuvaUcnM
kln2X5GM6HQo65g8WgwmIVvfV1Ty3kLl2eiBYYuBd5Mf6qwPz2AZ7QrFVzCL3fg3
FI+JqyVWUaRHNPgPFHTND+M6TK2n6r+t0/FYxQuN6vj96fN3W3jx79Owjf6lSB6x
LWS5BFC5yRqXBKXWeTC8Llp8Q6vYhy7qwjuVxV9ERVJSA/R6NhjiLZQX8tB/NKRH
JyZEFjnL/fKVQrti25GZIkyD/w4wjsEECHeTwMtzORhOedkW5fpoiVQQP5xzPBie
Wkjdd0xPC7t4HxPxyFGDUrnllNbdAqNTRLpBPLiOvfoe/FBYNHp6AjDCh33feNMD
lbON+2E4j0KY0nrLTsZuID+h0dtaAYTSVubrTQiCoRoVT8vANy57eyCaet6feqyK
HFK+V8QN18X4jG5Me5SkrMOcihZWV2qZK/uTBe17EsJPsz4r0C/jlSy4HCcgl57e
0KuFpZUu2Y87Ssx7PFBCF144U+A6aWz0S+PbWD+rcK4WGEGn4c/514PtFa7KfLg2
U+KvadDIYBXZ+T95bAjqY75Ci4kqWpIAwP/J3Qcfb5URD/ZYkaxi+EsOkZvZoEsE
f+zZ/ahUYg==
=Q7+J
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSUaeoACgkQYKtH/8kJ
UifUvw/8Cb6UG88BJeQG3PS4B1ZiJ5Dd35u26o80ReUmFTLCcUUgUDHjXHHUbW+9
B/oooX6cOB6U3eiW5HVpWcq+5jOz2NhrPiQqXx49M5D80jvA1WgNUYeI9tma8F/m
ThMCWc1O0xTHzN4N1TtUdOg52Wh17Ynww8pLBTissxYqurhzuMIVtve72dpSaKsC
E891yZ3yz0S/tK1FjfP7Hgixlyc0Pbwg5F2JESPYXDPIpefaA5oLQC+5nV870MxJ
B32MWjQpSveUHgchFDPOuC9y7GMbzQCB580WezNtAns9rn1zn1hCVfmBXYt0tt6l
XW46+nd+a1G5T+0Z6KQxr86a/5ckkPxEEIfTcPCznonYFZTwxa2No4w16dmBARYW
SCsQ9JKI8pYve6k7/hk20lWFakn/A+VshbIjuR/MI/jLUNMrR4q6NXuRlcyO2WbK
MYvopJd6oHsfSDxqGHiH5QuAXyOngdd7CZdKYCIHPatrh2cTPgeGmX1e6eYeHJmv
ByO2vsaR/ijnXdsrq+mzL+oaAy6rGGFOYWKuNFov6MI+SnP7ijW9hAOwpGxnY8rz
Odh7Mbe7VoiHlWLfKCgCcjudHCFnG9ctVmNw6h2pPmY+guFnBp8+6dtlR/icENlI
h/nNoOLIt1zachOXOMbQFXDs2e0z7i1YLaz+2+OH7AR10s54EsY=
=stpo
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v6.5
1. Renesas RPC IF: correct the Strobe Timing Adjustment.
2. Broadcom DPFE: fix smatch warning for testing array offset after use.
3. Atmel SDRAMC: drop driver because it was just a wrapper over enabling
clock which is not handled by its clock controller.
4. Minor bindings cleanup.
* tag 'memory-controller-drv-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
dt-bindings: memory-controllers: drop unneeded quotes
memory: atmel-sdramc: remove the driver
memory: brcmstb_dpfe: fix testing array offset after use
memory: renesas-rpc-if: Fix PHYCNT.STRTIM setting
Link: https://lore.kernel.org/r/20230612175508.288775-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Couple of main additions :-
1. Support for multiple SMC/HVC transports for SCMI:
Some platforms need to support multiple SCMI instances within
a platform(more commonly in a VM). The same SMC/HVC FID is used with
all the instances. The platform or the hypervisor needs a way to
distinguish among SMC/HVC calls made from different instances.
This change adds support for passing shmem channel address as the
parameters in the SMC/HVC call. The address is split into 4KB-page
and offset for simiplicity.
2. Addition od SCMI v3.2 explicit powercap enable/disable support:
SCMI v3.2 specification introduces support to disable powercapping
as a whole on the desired zones.
This change adds the needed support to the core SCMI powercap protocol,
exposing enable/disable protocol operations and then wiring up the new
operartions in the related powercap framework helpers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmSHCbQACgkQAEG6vDF+
4phj9hAAjYYoJ9HvIqxJ68jRRh7BFnsdeCVqsGUzopeXbiWwr+uc0hko+oP8+hjz
R/tHvqhKuUiKC+ROOVHSx0VdU5721v2Uhvn5gtp2ZzKN/Iw7Mm/6dMlGDF790MSw
gkxJ5dog9H04HSGG1LvQIPKKY/BNUh7xvPkwoKlCO7DyNG+WQ5yyQT0v9DiZH8gg
j5eKX29gDZJEuzr8TlkpYHATyDlzMNVD0/pX97DedhqEqzVnms/yAa1R6zu+M0sn
8xyR2gy0UJ0w3unT8KxEbbxdJcykYxTbyVqJIc28xtVYA1EOGkFwZLYcVvy4z0LC
xny3PJSeL8g/pbrilbYNbYcqz9Qjb9eNU9XdDFa+Oy09skwnYr2uYje6XPBk/KFu
cQ5xs9ChJezcIRPBq/iV4Aqe5WK05IPZ0Q0HKsuTmdOOMaCsPui5nMkkybrm3KOU
uZ6z90Br854FI/pQqAqpwYY1Wqa1g6I4DFUwOtd04qD1V19s0CEDrx8uPtoKcSaP
0W+BeSv56Ukvn2rYPbu0teIzbk3s00kGqHcy1YKyq1rGmZSYrBf1bfmZkIJgfN/2
0cyzJAch4j4ggvnJQJPybWYjbmKfxE+A9hk3hjZ1mrew2wWeIsjevclu4wtNUCjc
qT3wa8SOtjaUGTQmvEWBKeYrkMcOhx+vxSo8SjemW/X3WjYswdw=
=uVB0
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSUabgACgkQYKtH/8kJ
UieE8A//Rvcl3hDpZgNa6pCvX7dH3m2JttmBgBmGbH4mVffjqhstYknp8Fb8Faxq
91cGvAJ0QTn0Kaox7ycHQQVxLK5u7UfTmCe6pGGIDWZqXQDj6TETZoeWmiBgnTeS
510Id9S/CsSnjErO1D575fogSx2AohgBzIIk4r0YxZ0HcQiGteS7fAFjd4JMoheF
ZhUUmAu8Kp//grgeujvgQ59bCP4w6dqJ7KT/wnBZCy0CACpECA+LmYS1N/bnfPB2
rzxMo1GgUfSNEKxNx6T8UC9+LfUkitHNwfPyoe3av9GAGhozaTbGD9xll0DTj2iz
yFyhbgyY9aCxNMAwzq6hnveZi90X/bC1hnIidH5oyQkqTNTgE1X1y7SA6+SSfBzF
UlFafLq2xw+ENmDYOV6Lz4JREPhC2gFwjYqjn8teLQBriaCBIdtaedbGDnUVN0Ht
Iiv4baGtrIqbwosO2o/mfCLAveY/zh5aINv3rY1bkdfdFUQqS8gDlNGTuKDN+H+3
v80eyP8XPU2pZ7NTzSxcnz5SHSZWagVcugnzDEdeX2ZBeSKY50PzFZEY7OSU5k9o
iYjRyChHTTab/rG51GyhthVvszU9iKSQzmGco6OnaHd/vfCeXUfNKey98zVLbjUO
V8xJOAIZ9NNU9SzIfupfe9vjfIPOTxEqbWV3M4pvkgyKjNEddr4=
=Ze5+
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates for v6.5
Couple of main additions :-
1. Support for multiple SMC/HVC transports for SCMI:
Some platforms need to support multiple SCMI instances within
a platform(more commonly in a VM). The same SMC/HVC FID is used with
all the instances. The platform or the hypervisor needs a way to
distinguish among SMC/HVC calls made from different instances.
This change adds support for passing shmem channel address as the
parameters in the SMC/HVC call. The address is split into 4KB-page
and offset for simiplicity.
2. Addition od SCMI v3.2 explicit powercap enable/disable support:
SCMI v3.2 specification introduces support to disable powercapping
as a whole on the desired zones.
This change adds the needed support to the core SCMI powercap protocol,
exposing enable/disable protocol operations and then wiring up the new
operartions in the related powercap framework helpers.
* tag 'scmi-updates-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
powercap: arm_scmi: Add support for disabling powercaps on a zone
firmware: arm_scmi: Add Powercap protocol enable support
firmware: arm_scmi: Refactor the internal powercap get/set helpers
firmware: arm_scmi: Augment SMC/HVC to allow optional parameters
dt-bindings: firmware: arm,scmi: support for parameter in smc/hvc call
Link: https://lore.kernel.org/r/20230612121017.4108104-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
rk3588-based "General-register-files" register areas and a move to
C99 array inits for the dtpm driver to fix sparse warnings.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmSGMvYQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgVtnB/9Mm4ppU1GRJiK8TSZIVFfM5YZRoNyGgRXF
oGtF8LvMq7/v0Ep1G+NgvbwdwCpzlIM0Z9Uo/3AfVqft9rFN8TpKbYDLRGryuIbC
L+8kqk4pmBo/U6ZApwylUcBGNymyliHdsOYqMqbWqRvwK2tXbgMlO6c3Yna0VXD7
l8fvn9/jtHBQwVniF9iIGbQbAS+avJcyCamh8Wn/Hs5Ke60NRNUhLuvHs4mom82R
26IuO9QkkRQCU/hC22NydPnBmK7dSQMqiInI9XgoMYOZi9TJ8+OrTExc0kkUZVAL
i4Vg+XGmDXmTtAd11C6NjsLhMuzhsR1znk3ndQjsjUnw0QlhNSHP
=rrNf
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSUaYQACgkQYKtH/8kJ
UicjvQ/+KRFMBrgNgpylHsVDrOIEVCyBhxk7duMmOGEEljJwVM1MPsqRqBXr3Eck
4B8ZlKNDYw0V7+2mSdbwHWYsGmHd2srpJfXxTHQiCXNAxDXEIoJnDoTtIOYoY8ZD
CeTWEkPmavTT0AvkLPI4Es/2e/AbRbehp/SkNMfmN/d4UXL5lIqsNNZ7eqsqKCPU
VuR7vwvcB0+rJdjU/84eYdjPag2//r3+0qN6LzWNLLOO0Za7FAJ34WUZDiYM3db7
vHvvgbJo7YXuOueAmpv/wGB7NwZfXw8lYPPj230M1wH1cPqy4Dpo8Drj377HWPkk
90BxSkTnT2kN+dhjx3afzlIgemil3C8u60/QmdkwhY2MiFqB5TOClswI9oQZBTyY
1OiU8MxfXsprV2eFQqiTvf1XaDSVlVyUdQDgSVzxoTSd2WIxEnreKJZt7mxm97rW
w4D2ujbBuu9yfyMdAdWei2s/hFJdXIAJvXZjMgOu40nZdfL9myohdbaAVPe+fGV+
wZsvdUJJbAgEYSewvgFIjNTlA5/ATicr53DtPzcjslJT0C14Yp3jAGJJQao1ZJXP
A0h/BeW+VyNr/UYUPccJFL1hi83XXJqdndl/JOHyrZUbVZD7QA9AqT2gnquisWPA
2akMZ6mxdwN9ZgbMUIUOsv7DiSw6zctRe16whFljbynRDW0NzVg=
=R3D1
-----END PGP SIGNATURE-----
Merge tag 'v6.5-rockchip-drivers1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/drivers
An addition to the rk3588 power-domains, some new syscon compatibles for
rk3588-based "General-register-files" register areas and a move to
C99 array inits for the dtpm driver to fix sparse warnings.
* tag 'v6.5-rockchip-drivers1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
soc: rockchip: dtpm: use C99 array init syntax
dt-bindings: soc: rockchip: add rk3588 pipe-phy syscon
dt-bindings: soc: rockchip: add rk3588 usb2phy syscon
soc: rockchip: power-domain: add rk3588 mem module support
Link: https://lore.kernel.org/r/10286366.nUPlyArG6x@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I mistyped one of the SD/MMC GPIO lines on the Nokia n810 which
was supposed to be "vio" as "vsd".
Fix it up.
Reported-by: Peter Vasil <petervasil@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230614093032.403982-1-linus.walleij@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
the following:
- Justin, Kamal and Florian update their email to use their corporate
Broadcom email address
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmSQXLkACgkQh9CWnEQH
BwQR3hAAyjeBR1iMAgk64EhLOgtZ0YEoVxcfic3XOWMnR5vK+FuQBPZ06xF6vgBr
yK3Qx7TW5zIRaHijzYUKhaEInhfakuGKHwe71kDR2rs85SOG19aGIbkYzgIjTGam
EXVuTj01+r6B0ps6WDkhgBec+C70bZZt59WTWWL4bWPOSkYZ2dAanBWaMRSADoZq
DAJDT23qswhQJueRhTDoFBm0ujP5r0mGXnh8faRfDBSbAv6vV08Ij2wheZmn09HO
BhOflmqlymbaxN4iJs5rgQfSVtOT6C9F1Oy/v3+svDUGEXcal9jFa2gavFGMZd9r
bNKgD7pX5wL36EHdgUd0DXK4XXG/br5QVKT/a9TvlUIDLmWcqoK0CCv1fbFt+4oK
2yhEQyn0Y+uiFLqNYMCS3yglSLp1DinRnIo1SIMZFTKcXMAXL4TzvJpXSZZTZDZN
yIzntKGQkhEknF/dwC/3EoRIm8+vHVKknhBGjOK0/ZErFp+EfBnFV33N1ljqcslN
/RBo83Tc9etLwolaq8yyT3ORElOJxDSDwimFRUhcbCGA1qGnNKRfUSndfbmDfn10
vCRCKp3LM/AGu2auJoN961FL2mAKeM9W4gtWHpsEPi129kW0IiWcnGUhct+wB+u7
pK6AVpNPrd5OBZMniMJ+C6ttyEpDrfBQXbK6LPufdhKzWNQkD14=
=dkkm
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSUaJ4ACgkQYKtH/8kJ
Uid3vhAAyBXpTO9x1TwJqsr8zUCJmEKanw5EO0rRqYxq+O1qFomI5j7olBWmM20r
cxTziqCRIZwJW3rRk3g6KEuK8RCvxOPH6BmJyqiVGImdk9SwDmkvweJkhBvhxeUa
K1CYbTarw28ARtXIjzbs6IpJ2dKgULVC+lQUz8WdQ0e5HWmbuZzHouVI4l0XJih0
PQCrO32+ZimDT85Sj7VoAILdoQ2CfertyiMHTlODb5LnSNYL4/sGdSaCxWpidt/U
tOxWJXg/YPn+hcNW4ddR99Pzp+qOivW47yZPE78pEx2Z+tixwuBVVsDqexf3OBK2
edxqCpAYho6vHkpgFDy6A+V+4gbB6SDLjCj9mAbyEVhB6acujrpcOWmt4eOEkmLY
5v/O2q9hRh4jtt8uLQ73dfyJTyYJ5Pbjdkr5t5vk40opEbpN/D9qz5Xl0Przb9oE
sqBI0SR/QcyJZpUoMOlPEZSM2Lz5wT3qh1CKDciDfKStODj+8tPXx+f3Hte+Dqsk
QtO3+OmnEp0ezvcV14KdiY+q4vofPiHLECGGgYt76gf/RG4iGOvtwbvpG6I8zs8B
imNSqejk6O8cjdCYan4z2zuj5h0trCpGUUgIgkILi1CfqTgB6G3/n880bvGzM5lG
gZ7V+yS8ODt2PqyMlyGvmATZM894vrNqh9YAexuGVNDxCN/Di3g=
=a+MV
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.5/maintainers' of https://github.com/Broadcom/stblinux into soc/arm
This pull request contains MAINTAINERS file updates for 6.5, please pull
the following:
- Justin, Kamal and Florian update their email to use their corporate
Broadcom email address
* tag 'arm-soc/for-6.5/maintainers' of https://github.com/Broadcom/stblinux:
MAINTAINERS: Replace my email address
MAINTAINERS: Replace my email address
MAINTAINERS: Replace my email address
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There's an hardware issue that can cause missing timestamps. The bug
is that the interrupt is only cleared if the IGC_TXSTMPH_0 register is
read.
The bug can cause a race condition if a timestamp is captured at the
wrong time, and we will miss that timestamp. To reduce the time window
that the problem is able to happen, in case no timestamp was ready, we
read the "previous" value of the timestamp registers, and we compare
with the "current" one, if it didn't change we can be reasonably sure
that no timestamp was captured. If they are different, we use the new
value as the captured timestamp.
The HW bug is not easy to reproduce, got to reproduce it when smashing
the NIC with timestamping requests from multiple applications (e.g.
multiple ntpperf instances + ptp4l), after 10s of minutes.
This workaround has more impact when multiple timestamp registers are
used, and the IGC_TXSTMPH_0 register always need to be read, so the
interrupt is cleared.
Fixes: 2c344ae245 ("igc: Add support for TX timestamping")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Before requesting a packet transmission to be hardware timestamped,
check if the user has TX timestamping enabled. Fixes an issue that if
a packet was internally forwarded to the NIC, and it had the
SKBTX_HW_TSTAMP flag set, the driver would mark that timestamp as
skipped.
In reality, that timestamp was "not for us", as TX timestamp could
never be enabled in the NIC.
Checking if the TX timestamping is enabled earlier has a secondary
effect that when TX timestamping is disabled, there's no need to check
for timestamp timeouts.
We should only take care to free any pending timestamp when TX
timestamping is disabled, as that skb would never be released
otherwise.
Fixes: 2c344ae245 ("igc: Add support for TX timestamping")
Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae245 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Source file locations for syscall definitions can change over a period
of time. File paths in comments get stale and are hard to maintain long
term. Also, their usefulness is questionable since it would be easier to
locate a syscall definition using the SYSCALL_DEFINEx() macro.
Remove all source file path comments from the syscall headers. Also,
equalize the uneven line spacing (some of which is introduced due to the
deletions).
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When we didn't find a device and didn't guess it might be a partition,
it might still show up later, so don't disable rootwait for it by
returning -EINVAL.
Fixes: 079caa35f7 ("init: clear root_wait on all invalid root= strings")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230622150644.600327-1-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
After the following two commits:
commit 872e24d5c6 ("hexagon: remove asm/bitsperlong.h")
commit 83f0124ad8 ("microblaze: remove asm-generic wrapper headers")
the arch-specific headers of hexagon and microblaze have been removed,
the tools arch uapi headers are useless too, remove them.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0
in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are
usable, it is probably fine to unify the definition of __BITS_PER_LONG as
(__CHAR_BIT__ * __SIZEOF_LONG__) in asm-generic uapi bitsperlong.h.
In order to keep safe and avoid regression, only unify uapi bitsperlong.h
for some archs such as arm64, riscv and loongarch which are using newer
toolchains that have the definitions of __CHAR_BIT__ and __SIZEOF_LONG__.
Suggested-by: Xi Ruoyao <xry111@xry111.site>
Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.camel@xry111.site/
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/linux-arch/a3a4f48a-07d4-4ed9-bc53-5d383428bdd2@app.fastmail.com/
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There was regression caused by a97699d1d6 ("btrfs: replace
map_lookup->stripe_len by BTRFS_STRIPE_LEN") and supposedly fixed by
a7299a18a1 ("btrfs: fix u32 overflows when left shifting stripe_nr").
To avoid code churn the fix was open coding the type casts but
unfortunately missed one which was still possible to hit [1].
The missing place was assignment of bioc->full_stripe_logical inside
btrfs_map_block().
Fix it by adding a helper that does the safe calculation of the offset
and use it everywhere even though it may not be strictly necessary due
to already using u64 types. This replaces all remaining
"<< BTRFS_STRIPE_LEN_SHIFT" calls.
[1] https://lore.kernel.org/linux-btrfs/20230622065438.86402-1-wqu@suse.com/
Fixes: a7299a18a1 ("btrfs: fix u32 overflows when left shifting stripe_nr")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
For the declaration of parent clocks, use struct clk_parent_data instead
of a string. Due to the change in the passed arguments, replace the usage
of devm_clk_hw_register_mux() with clk_hw_register_mux_parent_data() for
all cases.
Signed-off-by: Jacky Huang <ychuang3@nuvoton.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The constant hex values used to define register offsets were written
in uppercase. This patch update all these constant hex values to
be lowercase.
Signed-off-by: Jacky Huang <ychuang3@nuvoton.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Moved the declaration of extern functions ma35d1_reg_clk_pll() and
ma35d1_reg_adc_clkdiv() from the .c files to the newly created header
file clk-ma35d1.h.
Signed-off-by: Jacky Huang <ychuang3@nuvoton.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When the resource is the first in the bulk_move range, adding it again
(thus moving it to the tail) will corrupt the list since the first
pointer is not moved. This eventually lead to null pointer deref in
ttm_lru_bulk_move_del()
Fixes: fee2ede155 ("drm/ttm: rework bulk move handling v5")
Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20230622141902.28718-3-Yunxiang.Li@amd.com
Signed-off-by: Christian König <christian.koenig@amd.com>
The previous patch ("function_graph: Support recording and printing
the return value of function") has laid the groundwork for the for
the funcgraph-retval, and this modification makes it available on
the RISC-V platform.
We introduce a new structure called fgraph_ret_regs for the RISC-V
platform to hold return registers and the frame pointer. We then
fill its content in the return_to_handler and pass its address to
the function ftrace_return_to_handler to record the return value.
Link: https://lore.kernel.org/linux-trace-kernel/a8d71b12259f90e7e63d0ea654fcac95b0232bbc.1680954589.git.pengdonglin@sangfor.com.cn
Signed-off-by: Donglin Peng <pengdonglin@sangfor.com.cn>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
Direct replacement is safe here since return value of -E2BIG
is used to check for truncation instead of sizeof(dest).
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
[2] https://github.com/KSPP/linux/issues/89
Link: https://lore.kernel.org/linux-trace-kernel/20230613004125.3539934-1-azeemshaikh38@gmail.com
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Going a step further, we propose a way to use any user-space
workload as the task waiting for the timerlat timer. This is done
via a per-CPU file named osnoise/cpu$id/timerlat_fd file.
The tracef_fd allows a task to open at a time. When a task reads
the file, the timerlat timer is armed for future osnoise/timerlat_period_us
time. When the timer fires, it prints the IRQ latency and
wakes up the user-space thread waiting in the timerlat_fd.
The thread then starts to run, executes the timerlat measurement, prints
the thread scheduling latency and returns to user-space.
When the thread rereads the timerlat_fd, the tracer will print the
user-ret(urn) latency, which is an additional metric.
This additional metric is also traced by the tracer and can be used, for
example of measuring the context switch overhead from kernel-to-user and
user-to-kernel, or the response time for an arbitrary execution in
user-space.
The tracer supports one thread per CPU, the thread must be pinned to
the CPU, and it cannot migrate while holding the timerlat_fd. The reason
is that the tracer is per CPU (nothing prohibits the tracer from
allowing migrations in the future). The tracer monitors the migration
of the thread and disables the tracer if detected.
The timerlat_fd is only available for opening/reading when timerlat
tracer is enabled, and NO_OSNOISE_WORKLOAD is set.
The simplest way to activate this feature from user-space is:
-------------------------------- %< -----------------------------------
int main(void)
{
char buffer[1024];
int timerlat_fd;
int retval;
long cpu = 0; /* place in CPU 0 */
cpu_set_t set;
CPU_ZERO(&set);
CPU_SET(cpu, &set);
if (sched_setaffinity(gettid(), sizeof(set), &set) == -1)
return 1;
snprintf(buffer, sizeof(buffer),
"/sys/kernel/tracing/osnoise/per_cpu/cpu%ld/timerlat_fd",
cpu);
timerlat_fd = open(buffer, O_RDONLY);
if (timerlat_fd < 0) {
printf("error opening %s: %s\n", buffer, strerror(errno));
exit(1);
}
for (;;) {
retval = read(timerlat_fd, buffer, 1024);
if (retval < 0)
break;
}
close(timerlat_fd);
exit(0);
}
-------------------------------- >% -----------------------------------
When disabling timerlat, if there is a workload holding the timerlat_fd,
the SIGKILL will be sent to the thread.
Link: https://lkml.kernel.org/r/69fe66a863d2792ff4c3a149bf9e32e26468bb3a.1686063934.git.bristot@kernel.org
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: William White <chwhite@redhat.com>
Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
In the case of all tracing instances being off, sleep for the entire
period.
Q: Why not kill all threads so?
A: It is valid and useful to start the threads with tracing off.
For example, rtla disables tracing, starts the tracer, applies the
scheduling setup to the threads, e.g., sched priority and cgroup,
and then begin tracing with all set.
Skipping the period helps to speed up rtla setup and save the
trace after a stop tracing.
Link: https://lkml.kernel.org/r/aa4dd9b7e76fcb63901fe5407e15ec002b318599.1686063934.git.bristot@kernel.org
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: William White <chwhite@redhat.com>
Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Currently, osnoise/timerlat threads run with PF_NO_SETAFFINITY set.
It works well, however, cgroups do not allow PF_NO_SETAFFINITY threads
to be accepted, and this creates a limitation to osnoise/timerlat.
To avoid this limitation, disable migration of the threads as soon
as they start to run, and then clean the PF_NO_SETAFFINITY flag (still)
used during thread creation.
If for some reason a thread migration is requested, e.g., via
sched_settafinity, the tracer thread will notice and exit.
Link: https://lkml.kernel.org/r/8ba8bc9c15b3ea40cf73cf67a9bc061a264609f0.1686063934.git.bristot@kernel.org
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: William White <chwhite@redhat.com>
Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Adding new available_filter_functions_addrs file that shows all available
functions (same as available_filter_functions) together with addresses,
like:
# cat available_filter_functions_addrs | head
ffffffff81000770 __traceiter_initcall_level
ffffffff810007c0 __traceiter_initcall_start
ffffffff81000810 __traceiter_initcall_finish
ffffffff81000860 trace_initcall_finish_cb
...
Note displayed address is the patch-site address and can differ from
/proc/kallsyms address.
It's useful to have address avilable for traceable symbols, so we don't
need to allways cross check kallsyms with available_filter_functions
(or the other way around) and have all the data in single file.
For backwards compatibility reasons we can't change the existing
available_filter_functions file output, but we need to add new file.
The problem is that we need to do 2 passes:
- through available_filter_functions and find out if the function is traceable
- through /proc/kallsyms to get the address for traceable function
Having available_filter_functions symbols together with addresses allow
us to skip the kallsyms step and we are ok with the address in
available_filter_functions_addr not being the function entry, because
kprobe_multi uses fprobe and that handles both entry and patch-site
address properly.
We have 2 interfaces how to create kprobe_multi link:
a) passing symbols to kernel
1) user gathers symbols and need to ensure that they are
trace-able -> pass through available_filter_functions file
2) kernel takes those symbols and translates them to addresses
through kallsyms api
3) addresses are passed to fprobe/ftrace through:
register_fprobe_ips
-> ftrace_set_filter_ips
b) passing addresses to kernel
1) user gathers symbols and needs to ensure that they are
trace-able -> pass through available_filter_functions file
2) user takes those symbols and translates them to addresses
through /proc/kallsyms
3) addresses are passed to the kernel and kernel calls:
register_fprobe_ips
-> ftrace_set_filter_ips
The new available_filter_functions_addrs file helps us with option b),
because we can make 'b 1' and 'b 2' in one step - while filtering traceable
functions, we get the address directly.
Link: https://lore.kernel.org/linux-trace-kernel/20230611130029.1202298-1-jolsa@kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Tested-by: Jackie Liu <liuyun01@kylinos.cn> # x86
Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Big transfers might take a bit of time, too constraining timeouts might
lead to false positives. In order to simplify the drivers work and with
the goal of factorizing code in mind, let's add a helper that can be
used by any spi controller driver to derive a relevant per-transfer
timeout value.
The logic is simple: we know how much time it would take to transfer a
byte, we can easily derive the total theoretical amount of time involved
for each transfer. We multiply it by two to have a bit of margin and
enforce a minimum of 500ms.
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/Message-Id: <20230622090634.3411468-2-miquel.raynal@bootlin.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When __blkcg_rstat_flush() is called from cgroup_rstat_flush*() code
path, interrupt is always disabled.
When we start to flush blkcg per-cpu stats list in __blkg_release()
for avoiding to leak blkcg_gq's reference in commit 20cb1c2fb7
("blk-cgroup: Flush stats before releasing blkcg_gq"), local irq
isn't disabled yet, then lockdep warning may be triggered because
the dependent cgroup locks may be acquired from irq(soft irq) handler.
Fix the issue by disabling local irq always.
Fixes: 20cb1c2fb7 ("blk-cgroup: Flush stats before releasing blkcg_gq")
Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Closes: https://lore.kernel.org/linux-block/pz2wzwnmn5tk3pwpskmjhli6g3qly7eoknilb26of376c7kwxy@qydzpvt6zpis/T/#u
Cc: stable@vger.kernel.org
Cc: Jay Shin <jaeshin@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Waiman Long <longman@redhat.com>
Link: https://lore.kernel.org/r/20230622084249.1208005-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Several trivial cleanups which aren't quite necessary to split:
- Rename lcluster load functions as well as justify full indexes
since they are typically used for global deduplication for
compressed data;
- Avoid unnecessary lines, comments for simplicity.
No logic changes.
Reviewed-by: Guo Xuenan <guoxuenan@huaweicloud.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230615064421.103178-1-hsiangkao@linux.alibaba.com
