summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-04nvme: improve NVME_HOST_AUTH and NVME_TARGET_AUTH config descriptionsShin'ichiro Kawasaki2-4/+6
Currently two similar config options NVME_HOST_AUTH and NVME_TARGET_AUTH have almost same descriptions. It is confusing to choose them in menuconfig. Improve the descriptions to distinguish them. Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2023-12-04nvme-ioctl: move capable() admin check to the endKeith Busch1-10/+11
This can be an expensive call on some kernel configs. Move it to the end after checking the cheaper ways to determine if the command is allowed. Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2023-12-04nvme: ensure reset state check orderingKeith Busch5-49/+63
A different CPU may be setting the ctrl->state value, so ensure proper barriers to prevent optimizing to a stale state. Normally it isn't a problem to observe the wrong state as it is merely advisory to take a quicker path during initialization and error recovery, but seeing an old state can report unexpected ENETRESET errors when a reset request was in fact successful. Reported-by: Minh Hoang <mh2022@meta.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Hannes Reinecke <hare@suse.de>
2023-12-04nvme: introduce helper function to get ctrl stateKeith Busch1-0/+5
The controller state is typically written by another CPU, so reading it should ensure no optimizations are taken. This is a repeated pattern in the driver, so start with adding a convenience function that returns the controller state with READ_ONCE(). Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org>
2023-12-04ASoC: qcom: sc8280xp: Limit speaker digital volumesSrinivas Kandagatla1-0/+17
Limit the speaker digital gains to 0dB so that the users will not damage them. Currently there is a limit in UCM, but this does not stop the user form changing the digital gains from command line. So limit this in driver which makes the speakers more safer without active speaker protection in place. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20231204124736.132185-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04ASoC: ops: add correct range check for limiting volumeSrinivas Kandagatla1-1/+1
Volume can have ranges that start with negative values, ex: -84dB to +40dB. Apply correct range check in snd_soc_limit_volume before setting the platform_max. Without this patch, for example setting a 0dB limit on a volume range of -84dB to +40dB would fail. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20231204124736.132185-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04ALSA: hda/realtek: Enable headset on Lenovo M90 Gen5Bin Li1-0/+1
Lenovo M90 Gen5 is equipped with ALC897, and it needs ALC897_FIXUP_HEADSET_MIC_PIN quirk to make its headset mic work. Signed-off-by: Bin Li <bin.li@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20231204100450.642783-1-bin.li@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-12-04ALSA: hda/realtek: fix speakers on XPS 9530 (2023)Aleksandrs Vinarskis1-0/+1
XPS 9530 has 2 tweeters and 2 subwoofers powered by CS35L41 amplifier, SPI connected. For subwoofers to work, it requires both to enable amplifier support, and to enable output to subwoofers via 0x17 quirk (similalry to XPS 9510/9520). Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20231203233006.100558-1-alex.vinarskis@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-12-04ALSA: usb-audio: Add Pioneer DJM-450 mixer controlsSarah Grant1-0/+30
These values mirror those of the Pioneer DJM-250MK2 as the channel layout appears identical based on my observations. This duplication could be removed in later contributions if desired. Signed-off-by: Sarah Grant <s@srd.tw> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20231201181654.5058-1-s@srd.tw Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-12-04usb: typec: tcpci: add vconn over current fault handling to maxim_coreRD Babiera2-2/+23
Add TCPC_FAULT_STATUS_VCONN_OC constant and corresponding mask definition. Maxim TCPC is capable of detecting VConn over current faults, so add fault to alert mask. When a Vconn over current fault is triggered, put the port in an error recovery state via tcpm_port_error_recovery. Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231121203845.170234-6-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: typec: tcpm: add tcpm_port_error_recovery symbolRD Babiera2-0/+15
Add tcpm_port_error_recovery symbol and corresponding event that runs in tcpm_pd_event handler to set the port to the ERROR_RECOVERY state. tcpci drivers can use the symbol to reset the port when tcpc faults affect port functionality. Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20231121203845.170234-5-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04dt-bindings: usb: tps6598x: add reset-gpios propertyJavier Carrasco1-0/+6
The TPS6598x device family provides a high-level reset pin. It can be either grounded or used to reinitialize all device settings. Document the reset GPIO as an optional property and add it to the existing example. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230912-topic-tps6598x_reset-v3-2-0c2873070a77@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: typec: tps6598x: add reset gpio supportJavier Carrasco1-0/+20
The TPS6598x PD controller provides an active-high hardware reset input that reinitializes all device settings. If it is not grounded by design, the driver must be able to de-assert it in order to initialize the device. The PD controller is not ready for registration right after the reset de-assertion and a delay must be introduced in that case. According to TI, the delay can reach up to 1000 ms [1], which is in line with the experimental results obtained with a TPS65987D. Add a GPIO descriptor for the reset signal and basic reset management for initialization and suspend/resume. [1] https://e2e.ti.com/support/power-management-group/power-management/ f/power-management-forum/1269856/tps65987d-tps65987d-reset-de-assert- to-normal-operation/4809389#4809389 Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230912-topic-tps6598x_reset-v3-1-0c2873070a77@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04r8152: Choose our USB config with choose_configuration() rather than probe()Douglas Anderson1-11/+5
If you deauthorize the r8152 device (by writing 0 to the "authorized" field in sysfs) and then reauthorize it (by writing a 1) then it no longer works. This is because when you do the above we lose the special configuration that we set in rtl8152_cfgselector_probe(). Deauthorizing causes the config to be set to -1 and then reauthorizing runs the default logic for choosing the best config. I made an attempt to fix it so that the config is kept across deauthorizing / reauthorizing [1] but it was a bit ugly. Let's instead use the new USB core feature to override choose_configuration(). This patch relies upon the patches ("usb: core: Don't force USB generic_subclass drivers to define probe()") and ("usb: core: Allow subclassed USB drivers to override usb_choose_configuration()") [1] https://lore.kernel.org/r/20231130154337.1.Ie00e07f07f87149c9ce0b27ae4e26991d307e14b@changeid Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection") Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Link: https://lore.kernel.org/r/20231201102946.v2.3.Ie00e07f07f87149c9ce0b27ae4e26991d307e14b@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: core: Allow subclassed USB drivers to override usb_choose_configuration()Douglas Anderson2-0/+13
For some USB devices we might want to do something different for usb_choose_configuration(). One example here is the r8152 driver where we want to end up using the vendor driver with the preferred interface. The r8152 driver tried to make things work by implementing a USB generic_subclass driver and then overriding the normal config selection after it happened. This is less than ideal and also caused breakage if someone deauthorized and re-authorized the USB device because the USB core ended up going back to it's default logic for choosing the best config. I made an attempt to fix this [1] but it was a bit ugly. Let's do this better and allow USB generic_subclass drivers to override usb_choose_configuration(). [1] https://lore.kernel.org/r/20231130154337.1.Ie00e07f07f87149c9ce0b27ae4e26991d307e14b@changeid Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231201102946.v2.2.Iade5fa31997f1a0ca3e1dec0591633b02471df12@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: core: Don't force USB generic_subclass drivers to define probe()Douglas Anderson1-1/+4
There's no real reason that subclassed USB drivers _need_ to define probe() since they might want to subclass for some other reason. Make it optional to define probe() if we're a generic_subclass. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231201102946.v2.1.I7ea0dd55ee2acdb48b0e6d28c1a704ab2c29206f@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: gadget: f_tcm: Remove snprintf() from sysfs call-backs and replace with ↵Lee Jones1-2/+2
sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces just one use of snprintf() found in the sysfs .show() call-back with the new sysfs_emit() helper. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Dmitry Bogdanov <d.bogdanov@yadro.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-6-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: gadget: Remove snprintf() from sysfs call-backs and replace with ↵Lee Jones1-1/+1
sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces just one use of snprintf() found in the sysfs .show() call-back with the new sysfs_emit() helper. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-5-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: fotg210-hcd: Replace snprintf() with the safer scnprintf() variantLee Jones1-8/+4
There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. The uses in this file both seem to assume that data *has been* written! Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com> Cc: Feng-Hsin Chiang <john453@faraday-tech.com> Cc: Po-Yu Chuang <ratbert.chuang@gmail.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231130105459.3208986-4-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: cdnsp: Replace snprintf() with the safer scnprintf() variantLee Jones1-177/+177
There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. The uses in this file all seem to assume that data *has been* written! Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Pawel Laszczak <pawell@cadence.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-3-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: atm: Remove snprintf() from sysfs call-backs and replace with sysfs_emit()Lee Jones1-8/+8
Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces the 2 uses of snprintf() found in the sysfs .show() call-backs with the new sysfs_emit() helpers. Whist we're at it, let's replace the sprintf()s as well. For no other reason than consistency. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Matthieu CASTET <castet.matthieu@free.fr> Cc: Stanislaw Gruszka <stf_xl@wp.pl> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Damien Bergamini <damien.bergamini@free.fr> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-2-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04usb: typec: class: fix typec_altmode_put_partner to put plugsRD Babiera1-2/+3
When typec_altmode_put_partner is called by a plug altmode upon release, the port altmode the plug belongs to will not remove its reference to the plug. The check to see if the altmode being released evaluates against the released altmode's partner instead of the calling altmode itself, so change adev in typec_altmode_put_partner to properly refer to the altmode being released. typec_altmode_set_partner is not run for port altmodes, so also add a check in typec_altmode_release to prevent typec_altmode_put_partner() calls on port altmode release. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable@vger.kernel.org Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231129192349.1773623-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04USB: gadget: core: adjust uevent timing on gadget unbindRoy Luo1-2/+2
The KOBJ_CHANGE uevent is sent before gadget unbind is actually executed, resulting in inaccurate uevent emitted at incorrect timing (the uevent would have USB_UDC_DRIVER variable set while it would soon be removed). Move the KOBJ_CHANGE uevent to the end of the unbind function so that uevent is sent only after the change has been made. Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class") Cc: stable@vger.kernel.org Signed-off-by: Roy Luo <royluo@google.com> Link: https://lore.kernel.org/r/20231128221756.2591158-1-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04platform/mellanox: Check devm_hwmon_device_register_with_groups() return valueKunwu Chan1-0/+2
devm_hwmon_device_register_with_groups() returns an error pointer upon failure. Check its return value for errors. Compile-tested only. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Suggested-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20231201055447.2356001-1-chentao@kylinos.cn [ij: split the change into two] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-12-04platform/mellanox: Add null pointer checks for devm_kasprintf()Kunwu Chan1-0/+12
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Compile-tested only. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Suggested-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20231201055447.2356001-1-chentao@kylinos.cn [ij: split the change into two] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-12-04ASoC: wm_adsp: fix memleak in wm_adsp_buffer_populateDinghao Liu1-2/+6
When wm_adsp_buffer_read() fails, we should free buf->regions. Otherwise, the callers of wm_adsp_buffer_populate() will directly free buf on failure, which makes buf->regions a leaked memory. Fixes: a792af69b08f ("ASoC: wm_adsp: Refactor compress stream initialisation") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20231204074158.12026-1-dinghao.liu@zju.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04ASoC: da7219: Support low DC impedance headsetDavid Rau1-1/+1
Change the default MIC detection impedance threshold to 200ohm to support low mic DC impedance headset. Signed-off-by: David Rau <David.Rau.opensource@dm.renesas.com> Link: https://lore.kernel.org/r/20231201042933.26392-1-David.Rau.opensource@dm.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04ASoC: amd: acp: Add support for a new Huawei Matebook laptopMarian Postevca1-0/+14
This commit adds support for Huawei MateBook D16 2021 with Ryzen 4600H in driver acp3x-es83xx. Signed-off-by: Marian Postevca <posteuca@mutex.one> Link: https://lore.kernel.org/r/20231202223001.8025-1-posteuca@mutex.one Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04mlxbf-bootctl: correctly identify secure boot with development keysDavid Thompson1-13/+26
The secure boot state of the BlueField SoC is represented by two bits: 0 = production state 1 = secure boot enabled 2 = non-secure (secure boot disabled) 3 = RMA state There is also a single bit to indicate whether production keys or development keys are being used when secure boot is enabled. This single bit (specified by MLXBF_BOOTCTL_SB_DEV_MASK) only has meaning if secure boot state equals 1 (secure boot enabled). The secure boot states are as follows: - “GA secured” is when secure boot is enabled with official production keys. - “Secured (development)” is when secure boot is enabled with development keys. Without this fix “GA Secured” is displayed on development cards which is misleading. This patch updates the logic in "lifecycle_state_show()" to handle the case where the SoC is configured for secure boot and is using development keys. Fixes: 79e29cb8fbc5c ("platform/mellanox: Add bootctl driver for Mellanox BlueField Soc") Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/20231130183515.17214-1-davthompson@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-12-04regmap: fix bogus error on regcache_sync successMatthias Reichl1-2/+1
Since commit 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") opening pcm512x based soundcards fail with EINVAL and dmesg shows sync cache and pm_runtime_get errors: [ 228.794676] pcm512x 1-004c: Failed to sync cache: -22 [ 228.794740] pcm512x 1-004c: ASoC: error at snd_soc_pcm_component_pm_runtime_get on pcm512x.1-004c: -22 This is caused by the cache check result leaking out into the regcache_sync return value. Fix this by making the check local-only, as the comment above the regcache_read call states a non-zero return value means there's nothing to do so the return value should not be altered. Fixes: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") Cc: stable@vger.kernel.org Signed-off-by: Matthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20231203222216.96547-1-hias@horus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04firmware: arm_scmi: Fix possible frequency truncation when using level ↵Sudeep Holla1-5/+7
indexing mode The multiplier is already promoted to unsigned long, however the frequency calculations done when using level indexing mode doesn't use the multiplier computed. It instead hardcodes the multiplier value of 1000 at all the usage sites. Clean that up by assigning the multiplier value of 1000 when using the perf level indexing mode and update the frequency calculations to use the multiplier instead. It should fix the possible frequency truncation for all the values greater than or equal to 4GHz on 64-bit machines. Fixes: 31c7c1397a33 ("firmware: arm_scmi: Add v3.2 perf level indexing mode support") Reported-by: Sibi Sankar <quic_sibis@quicinc.com> Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ Cc: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231130204343.503076-2-sudeep.holla@arm.com Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-12-04firmware: arm_scmi: Fix frequency truncation by promoting multiplier typeSudeep Holla1-3/+3
Fix the possible frequency truncation for all values equal to or greater 4GHz on 64bit machines by updating the multiplier 'mult_factor' to 'unsigned long' type. It is also possible that the multiplier itself can be greater than or equal to 2^32. So we need to also fix the equation computing the value of the multiplier. Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") Reported-by: Sibi Sankar <quic_sibis@quicinc.com> Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ Cc: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231130204343.503076-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson1-0/+2
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8153_aldps_en(). Fixes: 4214cc550bf9 ("r8152: check if disabling ALDPS is finished") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Douglas Anderson1-0/+2
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8153_pre_firmware_1(). Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson1-0/+2
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8156b_wait_loading_flash(). Fixes: 195aae321c82 ("r8152: support new chips") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE checks to more loopsDouglas Anderson1-0/+8
Previous commits added checks for RTL8152_INACCESSIBLE in the loops in the driver. There are still a few more that keep tripping the driver up in error cases and make things take longer than they should. Add those in. All the loops that are part of this commit existed in some form or another since the r8152 driver was first introduced, though RTL8152_INACCESSIBLE was known as RTL8152_UNPLUG before commit 715f67f33af4 ("r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE") Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Hold the rtnl_lock for all of resetDouglas Anderson1-6/+7
As of commit d9962b0d4202 ("r8152: Block future register access if register access fails") there is a race condition that can happen between the USB device reset thread and napi_enable() (not) getting called during rtl8152_open(). Specifically: * While rtl8152_open() is running we get a register access error that's _not_ -ENODEV and queue up a USB reset. * rtl8152_open() exits before calling napi_enable() due to any reason (including usb_submit_urb() returning an error). In that case: * Since the USB reset is perform in a separate thread asynchronously, it can run at anytime USB device lock is not held - even before rtl8152_open() has exited with an error and caused __dev_open() to clear the __LINK_STATE_START bit. * The rtl8152_pre_reset() will notice that the netif_running() returns true (since __LINK_STATE_START wasn't cleared) so it won't exit early. * rtl8152_pre_reset() will then hang in napi_disable() because napi_enable() was never called. We can fix the race by making sure that the r8152 reset routines don't run at the same time as we're opening the device. Specifically we need the reset routines in their entirety rely on the return value of netif_running(). The only way to reliably depend on that is for them to hold the rntl_lock() mutex for the duration of reset. Grabbing the rntl_lock() mutex for the duration of reset seems like a long time, but reset is not expected to be common and the rtnl_lock() mutex is already held for long durations since the core grabs it around the open/close calls. Fixes: d9962b0d4202 ("r8152: Block future register access if register access fails") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04greybus: gb-beagleplay: Ensure le for values in transportAyush Singh1-4/+5
Ensure that the following values are little-endian: - header->pad (which is used for cport_id) - header->size Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Reported-by: kernel test robot <yujie.liu@intel.com> Closes: https://lore.kernel.org/r/202311072329.Xogj7hGW-lkp@intel.com/ Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com> Link: https://lore.kernel.org/r/20231203075312.255233-1-ayushdevel1325@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04greybus: BeaglePlay driver needs CRC_CCITTRandy Dunlap1-0/+1
The gb-beagleplay driver uses crc_ccitt(), so it should select CRC_CCITT to make sure that the function is available. Fixes these build errors: s390-linux-ld: drivers/greybus/gb-beagleplay.o: in function `hdlc_append_tx_u8': gb-beagleplay.c:(.text+0x2c0): undefined reference to `crc_ccitt' s390-linux-ld: drivers/greybus/gb-beagleplay.o: in function `hdlc_rx_frame': gb-beagleplay.c:(.text+0x6a0): undefined reference to `crc_ccitt' Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Ayush Singh <ayushdevel1325@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: greybus-dev@lists.linaro.org Link: https://lore.kernel.org/r/20231031040909.21201-1-rdunlap@infradead.org Reviewed-by: Ayush Singh <ayushdevel1325@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: fix possible null pointer deref during xhci urb enqueueMathias Nyman1-17/+23
There is a short gap between urb being submitted and actually added to the endpoint queue (linked). If the device is disconnected during this time then usb core is not yet aware of the pending urb, and device may be freed just before xhci_urq_enqueue() continues, dereferencing the freed device. Freeing the device is protected by the xhci spinlock, so make sure we take and keep the lock while checking that device exists, dereference it, and add the urb to the queue. Remove the unnecessary URB check, usb core checks it before calling xhci_urb_enqueue() Suggested-by: Kuen-Han Tsai <khtsai@google.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-20-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: Reconfigure endpoint 0 max packet size only during endpoint resetMathias Nyman1-43/+42
The max packet size for full speed control endpoint 0 may vary. It is defined in the device descriptor, which is read using the same endpoint. Usb core sets a temporary max packet size value until the real value is read. xhci driver needs to reconfigure the endpoint context seen by the controller if the max packet size changes. It makes more sense to do this reconfiguration in xhci_endpoint_reset() instead of urb enqueue as usb core will call endpoint reset during enumeration if the max packet values differ. Max packet size adjustment for endpoint 0 can only happen once per device enumeration. Previously the max packet size was checked during every urb enqueue. This is an additional check for every enqueued urb, and also turned out to have locking issues as urbs may be queued in any context while xhci max packet size reconfiguration requires memory allocation, locking, and sleeping. Tested with a full speed device using both old and new scheme enumeration and an intentionally incorrect preliminary max packet size value. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-19-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: minor coding style cleanup in 'xhci_try_enable_msi()'Niklas Neronin1-5/+3
Remove extra spaces/indentation and add spaces where required. This commit does not change any functionality. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: rework 'xhci_try_enable_msi()' MSI and MSI-X setup codeNiklas Neronin1-29/+15
Simplify 'xhci_try_enable_msi()' and reduce unnecessary function calls. xHCI driver first tries to allocate 'num_online_cpu()' number of MSI-X vectors, if that fails it falls back to a single MSI vector. There is no good reason for this, we currently only support a primary interrupter. However, we are still interested in knowing if there are more vectors available, which will be utilized once we get secondary interrupter support. Call 'pci_alloc_irq_vectors()' once (with MSI-X and MSI flag), instead of separately for MSI-X and MSI. And accept any number of MSI-X or MSI vectors between 1 and 'num_online_cpu()'. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: change 'msix_count' to encompass MSI or MSI-X vectorsNiklas Neronin2-9/+9
Instead of variable 'msix_count' containing the number of MSI-X vectors, now it can contains MSI or MSI-X vector amount. Because both interrupt methods allow several vectors. Thus, 'msix_count' is renamed to 'nvecs'. Additionally, instead of storing the maximum possible vector amount, now it stores the amount of successfully allocated vectors, or negative integer on allocation failure. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: refactor static MSI functionNiklas Neronin1-34/+15
The current way the xhci driver sets up MSI interrupts is overly complex and messy. The whole MSI setup can be done in one simple function. Continue refactoring MSI/MSI-X setup by incorporating 'xhci_setup_msi()' into 'xhci_try_enable_msi()'. Now all interrupt enabling is contained in one function, which should make it easier to rework. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: refactor static MSI-X functionNiklas Neronin1-40/+28
The current way the xhci driver sets up MSI/MSI-X interrupts is overly complex and messy. The whole MSI/MSI-X setup can be done in one simple function. Start refactoring this by incorporating 'xhci_setup_msix()' into 'xhci_try_enable_msi()'. 'xhci_setup_msix()' is a static function which is only called by 'xhci_try_enable_msi()'. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: add handler for only one interrupt lineNiklas Neronin1-25/+10
Current xHCI driver only supports one "interrupter", meaning we will only use one MSI/MSI-X interrupt line. Thus, add handler only to the first interrupt line. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: check if legacy irq is available before using it as fallbackNiklas Neronin1-1/+1
Move the error check "No MSI-X/MSI found and no IRQ in BIOS" inside 'goto legacy'. It is better to check if the IRQ interrupt is available, before trying to add a handler. Additionally the aforementioned error message is much more clear. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: dbc: Add missing headersAndy Shevchenko1-1/+16
Don't inherit headers "by chances" from asm/bug.h, asm/io.h, etc... Include the needed headers explicitly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04xhci: dbc: Use sizeof(*pointer) instead of sizeof(type)Andy Shevchenko1-3/+3
It is preferred to use sizeof(*pointer) instead of sizeof(type). The type of the variable can change and one needs not change the former (unlike the latter). No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>