RE: [PATCH v2 2/2] pci: Support "removable" attribute for PCI devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Oliver Neukum
> Sent: 27 April 2021 13:00
> 
> Am Montag, den 26.04.2021, 13:01 +0000 schrieb David Laight:
> > From: Rafael J. Wysocki
> > > Sent: 26 April 2021 12:49
> > >
> > > On Mon, Apr 26, 2021 at 11:17 AM Oliver Neukum <oneukum@xxxxxxxx> wrote:
> > > > Am Freitag, den 23.04.2021, 19:16 -0700 schrieb Rajat Jain:
> > > > > Export the already available info, to the userspace via the
> > > > > device core, so that userspace can implement whatever policies it
> > > > > wants to, for external removable devices.
> > > >
> > > > Hi,
> > > >
> > > > is there a way to tell apart whether a device can undergo regular
> > > > surprise removal?
> > >
> > > PCI devices located under a removable parent can undergo surprise
> > > removal.  The ones on a Thunderbolt chain too.
> > >
> > > > Do we want that?
> > >
> > > Do you mean surprise removal?  Yes, we do.
> >
> > Always been true - think of cardbus (PCI pcmcia) cards with
> > PCI bridges to external PCI expansion chassis containing
> > additional PCI slots.
> > The cardbus card is hot removable.
> 
> Hi,
> 
> that is true for those options, but not for the style
> of PCI hotplug which requires you to push a button and wait
> for the blinking light.

True, I remember some of those PCI hotplug chassis from 25 years ago.
ISTR we did get the removal events working (SVR4/Unixware) but I
don't remember the relevant chassis ever being sold.
In spite of the marketing hype I suspect it was only ever possible
to remove a completely working board and replace it with an
exactly equivalent one.

In any case those chassis are not 'surprise removal'.

More modern drivers are less likely to crash (and burn?) when
a PCI read returns ~0u.
But I suspect an awful lot really don't handle surprise removal
very well at all.

How many ensure that a ~0u response from every PCI(e) wont
cause some kind of grief?
(We've been there due to a buggy fpga not responding to non-config
cycles.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux