linux-kernel - Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180325175430.3f60741f@archlinux>
Date:   Sun, 25 Mar 2018 17:54:30 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     John Syne <john3909@...il.com>
Cc:     Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>,
        devel@...verdev.osuosl.org, Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Hartmut Knaack <knaack.h@....de>, daniel.baluta@....com,
        Mark Brown <broonie@...nel.org>
Subject: Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces
 IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sun, 25 Mar 2018 01:29:41 -0700
John Syne <john3909@...il.com> wrote:

> Hi Jonathan,
Hi John,

Please wrap your normal emails (excepting tables) to 80 chars.

> 
> I was speaking with Rodrigo and here is what I think must be done to move
> ADE7878 out of staging
> 
> Here are the steps as I see them:
> 
> 1) Define the IIO Attributes so they are consistent with the IIO ABI. This
>    should be pretty simple given agreement on the naming convention.
Please don't go just changing attribute names - the driver needs to
use the standard approach of iio_chan_spec and create the vast
majority of attributes automatically via that.  There 'may' be
a few corner cases wee don't want to make generic and they 'might'
be exposed as attributes.

I suspect this change is the 'big' job.  The core support necessary
for RMS and MAV (computedtype or whatever we call it) will need adding
as well.  That is a separate patch set with support for some examples
in the dummy driver.
 
> 2) Map the ADE7854 interrupt status to IIO events. This requires an
>    interrupt processing section.
> 3) Add DeviceTree support.
> 4) Create DeviceTree overlay for the ADE7854.
More a case of bindings for now.  If those are used via an overlay
fine but given we don't have any boards with one one in mainline,
this is an implementation detail for the user rather than part
of moving this driver out of staging.

> 5) Update ADE7854 probe to read in the DeviceTree register settings.
> 6) Add support for power modes (PM1, PM2).
This isn't necessary for a move out of staging (nice to have though).

> 7) Not sure if we will support measurement streaming on the ADE7854.
>    The problem is ADE7854 is designed as an SPI master, which means
>    it controls the SPI clock, so the driver must support SPI slave
>    mode. However, the Linux Kernel does not currently support SPI
>    slave mode. We have three choices to make this work and they
>    are all a lot of work: 1) Add support for SPI Slave mode to the
>    kernel,  2) Use hardware to convert SPI signals to I2S signals
>    and with the use of a custom codec, use the ALSA framework to
>    stream the samples (this is an approach I used, but I don’t like
>    it), 3) Move the I2S driver out of the sound subsystem and use it
>    together with DMA to stream samples directly into the ADE7854 driver
>    (my preferred solutions). Perhaps Mark Brown has some ideas on how
>     to make this work. 
I'll be honest, this is an end of line part and frankly more than
a little crazy. I would go with simply not supporting the measurement
streaming at all for this part.  If you really need it we can then
move onto the how part, but from what you have said I'm guessing you
don't care except in an abstract 'it would be nice' sort of a way?

> 
> The ADE9000 will be much easier because it uses an SPI Slave interface. 
> 
> I hope I have captured everything, but let me know if I have missed anything.
> 

That will do for now ;)  I'm sure there will be details that need
tidying up once we have the above done, but that's true for any new
driver (and this will be nearly a new driver before things are done).

Jonathan