Message ID | 20240626180031.4050226-15-cassel@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | ata,libsas: Assign the unique id used for printing earlier | expand |
On 26/06/2024 19:00, Niklas Cassel wrote: > Hello all, > > This patch series was orginally meant to simply assign a unique id used > for printing earlier (ap->print_id), but has since grown to also include > cleanups related to ata_port_alloc() (since ap->print_id is now assigned > in ata_port_alloc()). > There's no real problem statement wrt print_id, telling how and why things are like they are, how it is a problem, and how it is improved in this series. > Patch 1-3 fixes incorrect cleanups in the error paths. > Patch 4,12 removes a useless libata wrappers only used for libsas. > Patch 5 introduces a ata_port_free(), in order to avoid duplicated code. > Patch 6 removes a unused function declaration in include/linux/libata.h. > Patch 7 remove support for decreasing the number of ports, as it is never > used by any libata driver (including libsas and ipr). > Patch 8 removes a superfluous assignment in ata_sas_port_alloc(). > Patch 9 removes the unnecessary local_port_no struct member in ata_port. > Patch 10 performs the ata_port print_id assignment earlier, so that the > ata_port_* print functions can be used even before the ata_host > has been registered. > Patch 11 changes the print_id assignment to use an ida_alloc(), such that > we will reuse IDs that are no longer in use, rather than keep > increasing the print_id forever. > Patch 13 adds a debug print in case the port is marked as external, this > code runs before the ata_host has been registered, so it depends > on patch 10.
On Thu, Jun 27, 2024 at 01:26:04PM +0100, John Garry wrote: > On 26/06/2024 19:00, Niklas Cassel wrote: > > Hello all, > > > > This patch series was orginally meant to simply assign a unique id used > > for printing earlier (ap->print_id), but has since grown to also include > > cleanups related to ata_port_alloc() (since ap->print_id is now assigned > > in ata_port_alloc()). > > > > There's no real problem statement wrt print_id, telling how and why things > are like they are, how it is a problem, and how it is improved in this > series. You are right, it is missing from the cover-letter. It was there in v1: https://lore.kernel.org/linux-ide/20240618153537.2687621-7-cassel@kernel.org/ """ This series moves the assignment of ap->print_id, which is used as a unique id for each port, earlier, such that we can use the ata_port_* print functions even before the ata_host has been registered. """ Will re-add it in v3. Kind regards, Niklas
On 27/06/2024 13:32, Niklas Cassel wrote: > On Thu, Jun 27, 2024 at 01:26:04PM +0100, John Garry wrote: >> On 26/06/2024 19:00, Niklas Cassel wrote: >>> Hello all, >>> >>> This patch series was orginally meant to simply assign a unique id used >>> for printing earlier (ap->print_id), but has since grown to also include >>> cleanups related to ata_port_alloc() (since ap->print_id is now assigned >>> in ata_port_alloc()). >>> >> >> There's no real problem statement wrt print_id, telling how and why things >> are like they are, how it is a problem, and how it is improved in this >> series. > > You are right, it is missing from the cover-letter. > > It was there in v1: > https://lore.kernel.org/linux-ide/20240618153537.2687621-7-cassel@kernel.org/ > > """ > This series moves the assignment of ap->print_id, which is used as a > unique id for each port, earlier, such that we can use the ata_port_* > print functions even before the ata_host has been registered. > """ OK, fine. I see code which checks vs ap->print_id, like: static void ata_force_link_limits(struct ata_link *link) { ... if (fe->port != -1 && fe->port != link->ap->print_id) continue; Is this all ok to deal with this print_id assignment change? To me, it seems natural to assign a valid print_id from the alloc time, so I can't help but wonder it was done the current way. Thanks, John
On Thu, Jun 27, 2024 at 01:54:34PM +0100, John Garry wrote: > On 27/06/2024 13:32, Niklas Cassel wrote: > > On Thu, Jun 27, 2024 at 01:26:04PM +0100, John Garry wrote: > > > On 26/06/2024 19:00, Niklas Cassel wrote: > > > > Hello all, > > > > > > > > This patch series was orginally meant to simply assign a unique id used > > > > for printing earlier (ap->print_id), but has since grown to also include > > > > cleanups related to ata_port_alloc() (since ap->print_id is now assigned > > > > in ata_port_alloc()). > > > > > > > > > > There's no real problem statement wrt print_id, telling how and why things > > > are like they are, how it is a problem, and how it is improved in this > > > series. > > > > You are right, it is missing from the cover-letter. > > > > It was there in v1: > > https://lore.kernel.org/linux-ide/20240618153537.2687621-7-cassel@kernel.org/ > > > > """ > > This series moves the assignment of ap->print_id, which is used as a > > unique id for each port, earlier, such that we can use the ata_port_* > > print functions even before the ata_host has been registered. > > """ > > OK, fine. > > I see code which checks vs ap->print_id, like: > > static void ata_force_link_limits(struct ata_link *link) > { > ... > if (fe->port != -1 && fe->port != link->ap->print_id) > continue; > > > Is this all ok to deal with this print_id assignment change? > > To me, it seems natural to assign a valid print_id from the alloc time, so I > can't help but wonder it was done the current way. ap->print_id was assigned after calling ata_host_register(), because libata allowed a driver that did not know how many ports it had, to initially call ata_alloc_host() with a big number of ports, and then reduce the host->n_ports variable once it knew the actually number of ports, before calling ata_host_register(), which would then free the "excess" ports. This feature has actually never been used by and driver, and I remove support for this in this series: https://lore.kernel.org/linux-ide/20240626180031.4050226-22-cassel@kernel.org/ However, you do raise a good point... ap->print_id is just supposed to be used for printing, but it appears that ata_force_link_limits() and some other ata_force_*() functions make use of it for other things... sigh... Hopefully I can just change them from: if (fe->port != -1 && fe->port != link->ap->print_id) to if (fe->port != -1) but I will need to look in to this further... Thank you for noticing this (ab)use of print_id! Kind regards, Niklas
On Thu, Jun 27, 2024 at 05:07:43PM +0200, Niklas Cassel wrote: > On Thu, Jun 27, 2024 at 01:54:34PM +0100, John Garry wrote: > > On 27/06/2024 13:32, Niklas Cassel wrote: > > > On Thu, Jun 27, 2024 at 01:26:04PM +0100, John Garry wrote: > > > > On 26/06/2024 19:00, Niklas Cassel wrote: > > > > > Hello all, > > > > > > > > > > This patch series was orginally meant to simply assign a unique id used > > > > > for printing earlier (ap->print_id), but has since grown to also include > > > > > cleanups related to ata_port_alloc() (since ap->print_id is now assigned > > > > > in ata_port_alloc()). > > > > > > > > > > > > > There's no real problem statement wrt print_id, telling how and why things > > > > are like they are, how it is a problem, and how it is improved in this > > > > series. > > > > > > You are right, it is missing from the cover-letter. > > > > > > It was there in v1: > > > https://lore.kernel.org/linux-ide/20240618153537.2687621-7-cassel@kernel.org/ > > > > > > """ > > > This series moves the assignment of ap->print_id, which is used as a > > > unique id for each port, earlier, such that we can use the ata_port_* > > > print functions even before the ata_host has been registered. > > > """ > > > > OK, fine. > > > > I see code which checks vs ap->print_id, like: > > > > static void ata_force_link_limits(struct ata_link *link) > > { > > ... > > if (fe->port != -1 && fe->port != link->ap->print_id) > > continue; > > > > > > Is this all ok to deal with this print_id assignment change? > > > > To me, it seems natural to assign a valid print_id from the alloc time, so I > > can't help but wonder it was done the current way. > > ap->print_id was assigned after calling ata_host_register(), because libata > allowed a driver that did not know how many ports it had, to initially call > ata_alloc_host() with a big number of ports, and then reduce the host->n_ports > variable once it knew the actually number of ports, before calling > ata_host_register(), which would then free the "excess" ports. > > This feature has actually never been used by and driver, and I remove support > for this in this series: > https://lore.kernel.org/linux-ide/20240626180031.4050226-22-cassel@kernel.org/ > > > However, you do raise a good point... > ap->print_id is just supposed to be used for printing, but it appears that > ata_force_link_limits() and some other ata_force_*() functions make use of > it for other things... sigh... > > Hopefully I can just change them from: > if (fe->port != -1 && fe->port != link->ap->print_id) > to > if (fe->port != -1) > > but I will need to look in to this further... So, looking more closely at this, the code is actually not abusing print_id. Looking at libata.force in Documentation/admin-guide/kernel-parameters.txt: [LIBATA] Force configurations. The format is a comma- separated list of "[ID:]VAL" where ID is PORT[.DEVICE]. PORT and DEVICE are decimal numbers matching port, link or device. Basically, it matches the ATA ID string printed on console by libata. While this seems a bit fragile, since it relies on the probe ordering of the SATA controller drivers, which could change, it does still work as designed after this series: I added the following to my kernel command line: "libata.force=5:nolpm" which yielded: [ 1.811464] ata3.00: FORCE: horkage modified (nolpm) [ 1.811466] ata3.00: LPM support broken, forcing max_power [ 1.811468] ata3.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [ 1.811470] ata3.00: 2097152 sectors, multi 16: LBA48 NCQ (depth 32) [ 1.811474] ata3.00: applying bridge limits [ 1.811535] ata3.00: LPM support broken, forcing max_power [ 1.811537] ata3.00: configured for UDMA/100 And considering that all checks against ap->print_id is for libata.force related parameters, I think that we are all good. Kind regards, Niklas