> > Hello Chloe, > > On Tue, Mar 19, 2024 at 05:13:22PM +0800, Szuying Chen wrote: > > Signed-off-by: Szuying Chen <Chloe_Chen@xxxxxxxxxxxxxx> > > --- > > > > On 3/18/24 19:32, Niklas Cassel wrote: > > > A user plugging in an external PMP (so not a PMP embedded on the PCIe card). > > > We need to be able to read the PMP device and vendor ID, in order to apply > > > the correct PMP quirks, see sata_pmp_quirks(). So trying to hide which PMP > > > that is connected is bad, not only because it violates the specs, but also > > > because it stops us from providing the proper quirks for the connected PMP. > > > > > > Could you please tell us how we can communicate with the PMPs directly? > > > (Regardless if they are external PMPs or PMPs embedded on the PCIe card.) > > > > > Hello Niklas, > > > > Unfortunately, our design does not provide interface to communicate with > > the PMPs directly. > > When ASM1064 plugging in an external PMP, we will hide the PMP and map to > > the virtual port to run. > > Thank you for your reply! > > If you have any idea on how those users with a ASM1064 card that does not > have any PMPs on the PCIe cards, e.g. Delock 90073, can avoid the extra > 2-3 minutes delay during boot, we are open to suggestions. > > I guess you could send a new firmware to Delock that sets the PI register > (Ports Implemented) register to 0xf. > > However, from what I've understood from how you have decided to implement > PMP support on your HBAs, I assume that setting the PI register to 0xf > would also stop Delock 90073 from working with an externally connected > port multiplier, so that it probably not a good approach after all. > > > Kind regards, > Niklas So, I guess the current conclusion is that there's no optimal solution due to hardware not following the standards? I also thought about the option to use override parameters like setting the port mask. But then I also thought about: How to handle a system with different HBAs? Like a system using one card with a pci-e multiplexer but also a card like mine with port multipliers. The result would be either the current behaviour - all ports working but long timeouts - or like with the change - no timeouts but not all ports working. An optimal solution would requite a per-HBA setting. To keep a consistent order the address path could be used, like "the first HBA is on pci-e_3, the second on pci-e_5". It would still be up to the user to correctly identify the correct ports and set up a working kernel command but at least it would be an option for mixed systems to set parameters per controller instead of applying the same setting global. I searched for both host controllers as well as port multipliers. Although most solutions end up with controllers from ASMedia, JMicron or even SLI there seem also way more lesser known chips out there. I also searched for more details around all that topic - and was able to find older forum threads from 2008 to 2013. So this seem to already going on for several years (hence I not really understood the initial report about the long boot timeout as I thought "well, people deal with it for over a decade now"). Aside from the revert is in my favour I also see that there're some deeper issues that either have to be ignored potentially breaking hardware, tried to worked around with (would a separate driver be possible?) or to get in contact with major controller manufactures to get them to come up with changes for newer chips/firmware - this way at least new hardware can have a chance to work out of the box by following the standards. Quite a complicated topic. Matt
