From: John Garry <john.garry@huawei.com>
To: Niklas Cassel <niklas.cassel@wdc.com>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: <linux-ide@vger.kernel.org>
Subject: Re: [PATCH 1/4] ata: add ata_port_is_frozen() helper
Date: Mon, 10 Oct 2022 08:00:09 +0100 [thread overview]
Message-ID: <2d3253f5-c14a-67b2-0ce3-68ba1e332664@huawei.com> (raw)
In-Reply-To: <20221007132342.1590367-2-niklas.cassel@wdc.com>
On 07/10/2022 14:23, Niklas Cassel wrote:
> At the request of the libata maintainer, introduce a ata_port_is_frozen()
> helper function.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> ---
> include/linux/libata.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/libata.h b/include/linux/libata.h
> index a505cfb92ab3..d5ac52654b42 100644
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -1043,6 +1043,11 @@ static inline int ata_port_is_dummy(struct ata_port *ap)
> return ap->ops == &ata_dummy_port_ops;
> }
Hi Niklas,
>
> +static inline bool ata_port_is_frozen(const struct ata_port *ap)
The majority of libata APIs don't use const in this way, so I think that
consistency is better.
Indeed, this is not const data which you're pointing at, so maybe it's
better to be honest with the compiler. And since this is inlined, could
the compiler optimise out multiple reads on ap->flags in a caller
function since we tell it it's const?
Thanks,
John
> +{
> + return ap->pflags & ATA_PFLAG_FROZEN;
> +}
> +
> extern int ata_std_prereset(struct ata_link *link, unsigned long deadline);
> extern int ata_wait_after_reset(struct ata_link *link, unsigned long deadline,
> int (*check_ready)(struct ata_link *link));
next prev parent reply other threads:[~2022-10-10 7:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 13:23 [PATCH 0/4] libata: misc frozen port cleanups Niklas Cassel
2022-10-07 13:23 ` [PATCH 1/4] ata: add ata_port_is_frozen() helper Niklas Cassel
2022-10-10 7:00 ` John Garry [this message]
2022-10-10 10:17 ` Niklas Cassel
2022-10-10 11:22 ` John Garry
2022-10-11 0:32 ` Damien Le Moal
2022-10-07 13:23 ` [PATCH 2/4] ata: make use of " Niklas Cassel
2022-10-07 22:31 ` Damien Le Moal
2022-10-07 23:50 ` Niklas Cassel
2022-10-07 23:56 ` Damien Le Moal
2022-10-08 0:09 ` Niklas Cassel
2022-10-07 13:23 ` [PATCH 4/4] ata: libata-core: do not retry reading the log on timeout Niklas Cassel
2022-10-07 22:33 ` Damien Le Moal
2022-10-07 23:47 ` Niklas Cassel
2022-10-07 23:52 ` Damien Le Moal
2022-10-10 17:10 ` Niklas Cassel
2022-10-18 4:59 ` [PATCH 0/4] libata: misc frozen port cleanups Damien Le Moal
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=2d3253f5-c14a-67b2-0ce3-68ba1e332664@huawei.com \
--to=john.garry@huawei.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=linux-ide@vger.kernel.org \
--cc=niklas.cassel@wdc.com \
/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