linux-stable.git/drivers/pci/switch, branch linux-5.10.y Linux kernel stable tree PCI: switchtec: Fix an error handling path in switchtec_pci_probe() 2024-03-26T22:21:56+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2023-12-24T14:30:01+00:00 38e61b751113e5dc3a317abb85158df85176e716 [ Upstream commit dec529b0b0572b32f9eb91c882dd1f08ca657efb ] The commit in Fixes changed the logic on how resources are released and introduced a new switchtec_exit_pci() that need to be called explicitly in order to undo a corresponding switchtec_init_pci(). This was done in the remove function, but not in the probe. Fix the probe now. Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surprise hot remove") Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.1703428183.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit dec529b0b0572b32f9eb91c882dd1f08ca657efb ]

The commit in Fixes changed the logic on how resources are released and
introduced a new switchtec_exit_pci() that need to be called explicitly in
order to undo a corresponding switchtec_init_pci().

This was done in the remove function, but not in the probe.

Fix the probe now.

Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surprise hot remove")
Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.1703428183.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PCI: switchtec: Fix stdev_release() crash after surprise hot remove 2024-02-23T07:42:14+00:00 Daniel Stodden dns@arista.com 2023-11-22T04:23:16+00:00 4a5d0528cf19dbf060313dffbe047bc11c90c24c [ Upstream commit df25461119d987b8c81d232cfe4411e91dcabe66 ] A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com Link: https://lore.kernel.org/r/20231122042316.91208-2-dns@arista.com Signed-off-by: Daniel Stodden <dns@arista.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Reviewed-by: Dmitry Safonov <dima@arista.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit df25461119d987b8c81d232cfe4411e91dcabe66 ]

A PCI device hot removal may occur while stdev->cdev is held open. The call
to stdev_release() then happens during close or exit, at a point way past
switchtec_pci_remove(). Otherwise the last ref would vanish with the
trailing put_device(), just before return.

At that later point in time, the devm cleanup has already removed the
stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
a fatal page fault, and the subsequent dma_free_coherent(), if reached,
would pass a stale &stdev->pdev->dev pointer.

Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
future accidents.

Reproducible via the script at
https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com

Link: https://lore.kernel.org/r/20231122042316.91208-2-dns@arista.com
Signed-off-by: Daniel Stodden <dns@arista.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PCI: switchtec: Add missing __iomem tag to fix sparse warnings 2020-07-31T16:23:45+00:00 Logan Gunthorpe logang@deltatee.com 2020-07-28T19:24:34+00:00 42dae8937406c98ce0cb6ff0d683765c854098d9 Fix a missing __iomem tag in the init_pfn() function. This fixes a sparse warning of the form: $ make C=2 drivers/pci/switch/ drivers/pci/switch/switchtec.c:... incorrect type assignment(different address spaces) Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver") Link: https://lore.kernel.org/r/20200728192434.18993-2-logang@deltatee.com Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Fix a missing __iomem tag in the init_pfn() function. This fixes a sparse
warning of the form:

  $ make C=2 drivers/pci/switch/
  drivers/pci/switch/switchtec.c:... incorrect type assignment(different address spaces)

Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")
Link: https://lore.kernel.org/r/20200728192434.18993-2-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI: switchtec: Add missing __iomem and __user tags to fix sparse warnings 2020-07-31T16:23:34+00:00 Logan Gunthorpe logang@deltatee.com 2020-07-28T19:24:33+00:00 5f11723b204aaf461e7a5242fc732222d2f0aa17 Fix a number of missing __iomem and __user tags in the ioctl functions of the switchtec driver. This fixes a number of sparse warnings of the form: $ make C=2 drivers/pci/switch/ drivers/pci/switch/switchtec.c:... incorrect type in ... (different address spaces) Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver") Link: https://lore.kernel.org/r/20200728192434.18993-1-logang@deltatee.com Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Fix a number of missing __iomem and __user tags in the ioctl functions of
the switchtec driver. This fixes a number of sparse warnings of the form:

  $ make C=2 drivers/pci/switch/
  drivers/pci/switch/switchtec.c:... incorrect type in ... (different address spaces)

Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Link: https://lore.kernel.org/r/20200728192434.18993-1-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI/switchtec: Correct bool variable type assignment 2020-05-21T20:21:53+00:00 Krzysztof Wilczynski kw@linux.com 2020-05-21T20:04:39+00:00 b8af85492fbf1acfb63b1f83e4faafbaa11c73eb Use "true" instead of 1 to initialize "bool use_dma_mrpc". This resolves the following Coccinelle warning: drivers/pci/switch/switchtec.c:28:12-24: WARNING: Assignment of 0/1 to bool variable Link: https://lore.kernel.org/r/20200521200439.1076672-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> 
Use "true" instead of 1 to initialize "bool use_dma_mrpc".  This resolves
the following Coccinelle warning:

  drivers/pci/switch/switchtec.c:28:12-24: WARNING: Assignment of 0/1 to bool variable

Link: https://lore.kernel.org/r/20200521200439.1076672-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
pci/switchtec: Replace completion wait queue usage for poll 2020-03-21T15:00:20+00:00 Sebastian Andrzej Siewior bigeasy@linutronix.de 2020-03-21T11:25:46+00:00 deaa0a8a74d86573f190e21ae9a444ea5e3bceee The poll callback is using the completion wait queue and sticks it into poll_wait() to wake up pollers after a command has completed. This works to some extent, but cannot provide EPOLLEXCLUSIVE support because the waker side uses complete_all() which unconditionally wakes up all waiters. complete_all() is required because completions internally use exclusive wait and complete() only wakes up one waiter by default. This mixes conceptually different mechanisms and relies on internal implementation details of completions, which in turn puts contraints on changing the internal implementation of completions. Replace it with a regular wait queue and store the state in struct switchtec_user. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200321113240.936097534@linutronix.de 
The poll callback is using the completion wait queue and sticks it into
poll_wait() to wake up pollers after a command has completed.

This works to some extent, but cannot provide EPOLLEXCLUSIVE support
because the waker side uses complete_all() which unconditionally wakes up
all waiters. complete_all() is required because completions internally use
exclusive wait and complete() only wakes up one waiter by default.

This mixes conceptually different mechanisms and relies on internal
implementation details of completions, which in turn puts contraints on
changing the internal implementation of completions.

Replace it with a regular wait queue and store the state in struct
switchtec_user.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200321113240.936097534@linutronix.de
PCI/switchtec: Fix init_completion race condition with poll_wait() 2020-03-21T15:00:20+00:00 Logan Gunthorpe logang@deltatee.com 2020-03-21T11:25:45+00:00 efbdc769601f4d50018bf7ca50fc9f7c67392ece The call to init_completion() in mrpc_queue_cmd() can theoretically race with the call to poll_wait() in switchtec_dev_poll(). poll() write() switchtec_dev_poll() switchtec_dev_write() poll_wait(&s->comp.wait); mrpc_queue_cmd() init_completion(&s->comp) init_waitqueue_head(&s->comp.wait) To my knowledge, no one has hit this bug. Fix this by using reinit_completion() instead of init_completion() in mrpc_queue_cmd(). Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver") Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com 
The call to init_completion() in mrpc_queue_cmd() can theoretically
race with the call to poll_wait() in switchtec_dev_poll().

  poll()			write()
    switchtec_dev_poll()   	  switchtec_dev_write()
      poll_wait(&s->comp.wait);      mrpc_queue_cmd()
			               init_completion(&s->comp)
				         init_waitqueue_head(&s->comp.wait)

To my knowledge, no one has hit this bug.

Fix this by using reinit_completion() instead of init_completion() in
mrpc_queue_cmd().

Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com
PCI/switchtec: Add Gen4 device IDs 2020-01-15T17:00:40+00:00 Kelvin Cao kelvin.cao@microchip.com 2020-01-15T03:56:48+00:00 7a30ebb9f2a253eae908cc3e1ba7daaa3bfe2bba Now that Gen4 is properly supported, advertise support in the module's device ID table and add the same IDs to the list of switchtec quirks. [logang@deltatee.com: add commit message and quirk IDs] Link: https://lore.kernel.org/r/20200115035648.2578-8-logang@deltatee.com Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com> Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Now that Gen4 is properly supported, advertise support in the module's
device ID table and add the same IDs to the list of switchtec quirks.

[logang@deltatee.com: add commit message and quirk IDs]
Link: https://lore.kernel.org/r/20200115035648.2578-8-logang@deltatee.com
Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI/switchtec: Add Gen4 MRPC GAS access permission check 2020-01-15T17:00:39+00:00 Kelvin Cao kelvin.cao@microchip.com 2020-01-06T19:03:35+00:00 ce7c88600bf8ec0d12cf8e147907f96cd58eeb2e Gen4 hardware provides new MRPC commands to read and write directly from any address in the PCI BAR (which Microsemi refers to as GAS). Since accessing BARs can be dangerous and break the driver, we don't want unprivileged users to have this ability. Therefore, require CAP_SYS_ADMIN for the local and remote GAS access MRPC commands. Privileged processes will already have access to the BAR through the sysfs resource file so this doesn't give userspace any capabilities it didn't already have. [logang@deltatee.com: rework commit message] Link: https://lore.kernel.org/r/20200106190337.2428-11-logang@deltatee.com Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com> Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Gen4 hardware provides new MRPC commands to read and write directly from
any address in the PCI BAR (which Microsemi refers to as GAS). Since
accessing BARs can be dangerous and break the driver, we don't want
unprivileged users to have this ability.

Therefore, require CAP_SYS_ADMIN for the local and remote GAS access MRPC
commands. Privileged processes will already have access to the BAR through
the sysfs resource file so this doesn't give userspace any capabilities it
didn't already have.

[logang@deltatee.com: rework commit message]
Link: https://lore.kernel.org/r/20200106190337.2428-11-logang@deltatee.com
Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI/switchtec: Add Gen4 flash information interface support 2020-01-15T17:00:39+00:00 Kelvin Cao kelvin.cao@microchip.com 2020-01-15T03:56:47+00:00 4efa1d2e36976d7b26f2e67f4c838330fbc91299 Add the new flash_info registers struct and the implementation of ioctl_flash_part_info() for the new Gen4 hardware. [logang@deltatee.com: rewrote commit message] Link: https://lore.kernel.org/r/20200115035648.2578-7-logang@deltatee.com Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com> Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Add the new flash_info registers struct and the implementation of
ioctl_flash_part_info() for the new Gen4 hardware.

[logang@deltatee.com: rewrote commit message]
Link: https://lore.kernel.org/r/20200115035648.2578-7-logang@deltatee.com
Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>