linux-kernel - Re: [PATCH 12/21] ata: libahci: Discard redundant force_port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 12 Apr 2022 15:29:31 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Damien Le Moal <damien.lemoal@...nsource.wdc.com>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Hans de Goede <hdegoede@...hat.com>,
        Jens Axboe <axboe@...nel.dk>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Rob Herring <robh+dt@...nel.org>, linux-ide@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 12/21] ata: libahci: Discard redundant force_port_map
 parameter

On Tue, Apr 12, 2022 at 07:48:50AM +0900, Damien Le Moal wrote:
> On 4/12/22 05:52, Serge Semin wrote:
> > On Mon, Apr 11, 2022 at 09:25:03PM +0900, Damien Le Moal wrote:
> >> On 4/11/22 21:11, Serge Semin wrote:
> >>> On Thu, Mar 24, 2022 at 11:05:58AM +0900, Damien Le Moal wrote:
> >>>> On 3/24/22 09:16, Serge Semin wrote:
> >>>>> Currently there are four port-map-related fields declared in the
> >>>>> ahci_host_priv structure and used to setup the HBA ports mapping. First
> >>>>> the ports-mapping is read from the PI register and immediately stored in
> >>>>> the saved_port_map field. If forced_port_map is initialized with non-zero
> >>>>> value then its value will have greater priority over the value read from
> >>>>> PI, thus it will override the saved_port_map field. That value will be then
> >>>>> masked by a non-zero mask_port_map field and after some sanity checks it
> >>>>> will be stored in the ahci_host_priv.port_map field as a final port
> >>>>> mapping.
> >>>>>
> >>>>> As you can see the logic is a bit too complicated for such a simple task.
> >>>>> We can freely get rid from at least one of the fields with no change to
> >>>>> the implemented semantic. The force_port_map field can be replaced with
> >>>>> taking non-zero saved_port_map value into account. So if saved_port_map is
> >>>>> pre-initialized by the glue-driver/platform-specific code then it will
> >>>>
> >>>
> >>>> glue-driver == LLDD (low level device driver), for the entire series please.
> >>>
> >>> Why? It's a normal term and well known amongst developers. I've used it
> >>> in a plenty of my patches before and none of them has been questioned in that
> >>> part so far.
> >>
> > 
> >> This term is not used in libata, nor do I remember seeing it used in SCSI
> >> or block subsystem either. We always talk about mid-layer (ahci platform)
> >> and LLDD (adapter driver).
> > 
> > Great, do we need to learn the subsystem-specific dictionary now
> > before submitting the patches for it? =)
> > Really, you are asking me to change one term to its synonym just
> > because it's mainly unused here. Now you know what it means, the
> > others can easily google it and get to learn something new. Win-win.)
> 

> I already knew what it meant, but it was unclear if my idea of what you
> meant was actually the same as yours. Sticking with the vocabulary already
> used since *a long time ago* makes life easier for reviewers and avoids
> confusion.

I believe there can't be too many possible meaning of that term to
have much doubts. Especially when we refer to the kernel drivers. One
more time requesting to settle some implicit subsystem-specific
conventions, not having them described in some kernel documents seems
very much wrong. The ahci_ prefixing and the specific vocabulary
concerns each driver in very many aspects. Seeing there are not a few
drivers which don't follow those conventions, you give no chance for
the developers to get their code accepted with no requests to fix the
corresponding parts. So to speak you need to thoroughly describe these
and the others conventions in the kernel documentation otherwise
you'll always end up requesting the same fixes wasting your and
developers time again and again.

Really if you had that document available, you could have used as a
reference and just said something like "please, follow the coding
style convention described here..." and no question would have raised.
Meanwhile currently both ahci_-prefix change and using the LLDD term
seem more like a personal desire to me.

-Sergey

> 
> -- 
> Damien Le Moal
> Western Digital Research