linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH v5 2/4] ata: libata: Rename ata_dev_blacklisted()
Date: Thu, 25 Jul 2024 18:43:20 +0200	[thread overview]
Message-ID: <ZqKAqMqq11fO1exb@ryzen.lan> (raw)
In-Reply-To: <20240724054539.182655-3-dlemoal@kernel.org>

On Wed, Jul 24, 2024 at 02:45:37PM +0900, Damien Le Moal wrote:
> Rename the function ata_dev_blacklisted() to ata_dev_horkage() as this
> new name:
> 1) Does not use an expression that can be considered as negatively loaded.
> 2) The name does not reflect what the function actually does, which is
>    returning a set of horkage flag for the device, of which only one
>    flag will completely disable the device.
> 
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> Reviewed-by: Igor Pylypiv <ipylypiv@google.com>
> ---
>  drivers/ata/libata-core.c | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index a35bce4236d3..272770f09609 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -84,7 +84,7 @@ static unsigned int ata_dev_init_params(struct ata_device *dev,
>  					u16 heads, u16 sectors);
>  static unsigned int ata_dev_set_xfermode(struct ata_device *dev);
>  static void ata_dev_xfermask(struct ata_device *dev);
> -static unsigned long ata_dev_blacklisted(const struct ata_device *dev);
> +static unsigned long ata_dev_horkage(const struct ata_device *dev);
>  
>  static DEFINE_IDA(ata_ida);
>  
> @@ -2223,7 +2223,7 @@ static inline u8 ata_dev_knobble(struct ata_device *dev)
>  {
>  	struct ata_port *ap = dev->link->ap;
>  
> -	if (ata_dev_blacklisted(dev) & ATA_HORKAGE_BRIDGE_OK)
> +	if (ata_dev_horkage(dev) & ATA_HORKAGE_BRIDGE_OK)
>  		return 0;
>  
>  	return ((ap->cbl == ATA_CBL_SATA) && (!ata_id_is_sata(dev->id)));
> @@ -2830,7 +2830,7 @@ int ata_dev_configure(struct ata_device *dev)
>  	}
>  
>  	/* set horkage */
> -	dev->horkage |= ata_dev_blacklisted(dev);
> +	dev->horkage |= ata_dev_horkage(dev);
>  	ata_force_horkage(dev);
>  
>  	if (dev->horkage & ATA_HORKAGE_DISABLE) {
> @@ -3987,13 +3987,13 @@ int ata_dev_revalidate(struct ata_device *dev, unsigned int new_class,
>  	return rc;
>  }
>  
> -struct ata_blacklist_entry {
> +struct ata_dev_horkage_entry {
>  	const char *model_num;
>  	const char *model_rev;
>  	unsigned long horkage;
>  };
>  
> -static const struct ata_blacklist_entry ata_device_blacklist [] = {
> +static const struct ata_dev_horkage_entry ata_dev_horkages[] = {
>  	/* Devices with DMA related problems under Linux */
>  	{ "WDC AC11000H",	NULL,		ATA_HORKAGE_NODMA },
>  	{ "WDC AC22100H",	NULL,		ATA_HORKAGE_NODMA },
> @@ -4111,7 +4111,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>  
>  	/* Devices which get the IVB wrong */
>  	{ "QUANTUM FIREBALLlct10 05", "A03.0900", ATA_HORKAGE_IVB },
> -	/* Maybe we should just blacklist TSSTcorp... */
> +	/* Maybe we should just add all TSSTcorp devices... */
>  	{ "TSSTcorp CDDVDW SH-S202[HJN]", "SB0[01]",  ATA_HORKAGE_IVB },
>  
>  	/* Devices that do not need bridging limits applied */
> @@ -4266,11 +4266,11 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>  	{ }
>  };
>  
> -static unsigned long ata_dev_blacklisted(const struct ata_device *dev)
> +static unsigned long ata_dev_horkage(const struct ata_device *dev)

So it turns that the term "horkage" is only used by libata:
$ git grep -i horkage

See also:
https://unix.stackexchange.com/questions/752755/what-is-horkage

I have mixed emotions about this. In one way I want to preserve the legacy,
but in one way, the term quirk/quirks is used everywhere else in the kernel,
so it is way more intuitive for other kernel developers to understand what
this is if we just use the common terminology.

I do think that the name ata_dev_horkage() is not good because it sounds
like you can just have a single horkage, but in fact a devices can have
serveral quirks. So should the name be ata_dev_horkages() ?

Search the kernel tree gives zero results for this before your patch:
$ git grep -i horkages origin/master  | wc -l
0

So maybe the plural of horkage is horkage???

To me, this again suggests that quirk/quirks is way clearer.
(And we do also use the term quirk in libata:
$ git grep -i quirk drivers/ata
so in one way renaming would also make us more consistent...)

I do see that you have used "horkages" in this patch however.

So either migrate to quirk/quirks, or we continue to make up our own words.

I prefer the former.
dev->quirks |= ata_dev_quirks(dev);


If we choose the latter, may I suggest that we change this line:
dev->horkage |= ata_dev_horkage(dev);
to:
dev->horkages |= ata_dev_horkages(dev);

to make it clearer that we can have several *whatever the plural of horkage*.

see e.g. how nvme does it:
ctrl->quirks = quirks;
and
if (ns->ctrl->quirks & NVME_QUIRK_DEALLOCATE_ZEROES)


Kind regards,
Niklas

  reply	other threads:[~2024-07-25 16:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24  5:45 [PATCH v5 0/4] Some cleanup, renaming and horkage improvements Damien Le Moal
2024-07-24  5:45 ` [PATCH v5 1/4] ata: libata: Rename ata_dma_blacklisted() Damien Le Moal
2024-07-25 16:42   ` Niklas Cassel
2024-07-24  5:45 ` [PATCH v5 2/4] ata: libata: Rename ata_dev_blacklisted() Damien Le Moal
2024-07-25 16:43   ` Niklas Cassel [this message]
2024-07-25 22:55     ` Damien Le Moal
2024-07-24  5:45 ` [PATCH v5 3/4] ata: libata: Change ata_dev_knobble() to return a bool Damien Le Moal
2024-07-24 17:34   ` Igor Pylypiv
2024-07-25 16:43   ` Niklas Cassel
2024-07-24  5:45 ` [PATCH v5 4/4] ata: libata: Print horkages applied to devices Damien Le Moal
2024-07-24 17:32   ` Igor Pylypiv
2024-07-25 16:45   ` Niklas Cassel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZqKAqMqq11fO1exb@ryzen.lan \
    --to=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).