linux-kernel - Re: [PATCH] regmap: Add support for 12/20 register formatting

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]

Message-ID: <CAPybu_2L5eK7SckELHxUsW72TZ8kG0TsTHbSn1Z6ohyUaPzQCg@mail.gmail.com>
Date:   Thu, 17 Sep 2020 13:38:53 +0200
From:   Ricardo Ribalda Delgado <ribalda@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regmap: Add support for 12/20 register formatting

HI Mark

On Thu, Sep 17, 2020 at 1:22 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <broonie@...nel.org> wrote:
>
> > > What exactly is the format you're trying to describe here?  It sounds
> > > like there's two blocks of padding in here (I'm assuing that's what
> > > dummy means) but what's the exact arrangement here and what are the
> > > commands?  It sounds like this might not work ideally with things like
> > > the cache code (if it makes things seems sparser than they are) and
> > > might not be obvious to someone looking at the datsheet.
>
> > The format is
>
> > XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
>
> > Where X is dont care, C is command, A is address and D is data bits. I
>
> > Shall I add this to the commit message? I want to send a V2 anyway,
> > because I screwed up the identity (ribalda.com instead of kernel.org)
>
> Yes, please.  I was fairly sure it worked, it was just a question of if
> it was ideal for the format described.  The only issue I can see with
> the above is that the users will need to left shift their data - on the
> face of it it would seem better to add a facility for padding the LSBs
> of the data field to the core so that users can just use the data field
> as documented.

I was thinking also about that, the problem is that there are many
devices on that family that are "software" compatible and it only
changes the width of the data. Eg:

DDDDDDDDDDDDDDDDXXXX
DDDDDDDDDDDDXXXXXXXX
DDDDDDDDXXXXXXXXXXXX

So if we need to make a driver, we could use the same driver for all
the chips on that family, saying to the user that the data size is
always 20 bits....

I will send v2 ASAP with the updated doc.

Thanks