Add ADE9000 driver to staging:iio:meter?

Add ADE9000 driver to staging:iio:meter?

[Pollak, Leonard]

Hi,

I have written a driver for the ADE9000. It has enough functionality to 
calibrate the device
and use it for energy metering. This was tested on a Raspberry Pi 3 
which i also have
a dts for if anyone is interested.

There are some quirks though since the ABI doesn't really make it easy 
on this kind of device.
For example: my driver (ab)uses the iio modifiers x and y to distinguish 
between Wh and VAh.
There are other issues with the driver I can think of (especially the 
channel definitions).
I think if you would want a more complete implementation of this IC as 
an iio device one would
need to start adding modifiers/types to the iio chan spec which would 
probably need a lot
of discussion. Since this is the first driver I have written for the 
linux kernel don't
expect too much, but I am commited to learn and happy to implement any 
suggestions for
making this a nice driver in the future :)

For now, I have forked the kernel tree from GKH made a patch and cleaned 
it up with checkpatch.pl
should I just send the driver as a patch is there anything else I need 
to do beforehand?

Regards,
Leo

Re: Add ADE9000 driver to staging:iio:meter?

[Jonathan Cameron]

On Tue, 13 Aug 2019 11:25:14 +0200
"Pollak, Leonard" <pollak@tr-host.de> wrote:

> Hi,

Hi Leo,

Welcome to IIO :)

> 
> I have written a driver for the ADE9000. It has enough functionality to 
> calibrate the device
> and use it for energy metering. This was tested on a Raspberry Pi 3 
> which i also have
> a dts for if anyone is interested.

Cool.

> 
> There are some quirks though since the ABI doesn't really make it easy 
> on this kind of device.
> For example: my driver (ab)uses the iio modifiers x and y to distinguish 
> between Wh and VAh.

IIRC we discussed this in the thread I linked to from the driver review.
The IIO interface as it stands is not quite descriptive enough to
cover these devices.  That's fine - just means we need to work out how
to extend it without breaking corners.  The problem normally when doing
this is events as the even codes are our most constrained space.

> There are other issues with the driver I can think of (especially the 
> channel definitions).
> I think if you would want a more complete implementation of this IC as 
> an iio device one would
> need to start adding modifiers/types to the iio chan spec which would 
> probably need a lot
> of discussion. 

Agreed.  Dive in there and propose something.  Might take a little while
but that's the only way to expand our ABI to support new classes of
devices.  Though we've had meter drivers in IIO staging for a long
long time, we've all been aware they weren't suitable for moving out
and this type of device needed revisiting.  

> Since this is the first driver I have written for the 
> linux kernel don't
> expect too much, but I am commited to learn and happy to implement any 
> suggestions for
> making this a nice driver in the future :)

Cool. Certainly not an easy one to start with.  The problem is that we
need to think through the whole ABI even if we initially only implement
a subset so that we ensure it will generalize if the fancy features
are added in future.

> 
> For now, I have forked the kernel tree from GKH made a patch and cleaned 
> it up with checkpatch.pl
> should I just send the driver as a patch is there anything else I need 
> to do beforehand?
> 
> Regards,
> Leo

I now understand a little more why you posted it under staging.  I'd
suggest we don't do that for now, but rather just assume this may take
a few rounds of patches to get it right.  Mostly the only reason we
would take a driver into staging now for IIO is that it comes from some
vendor tree and we want to clean it up in a clear way that keeps it's
history etc.  For a new driver like yours, where the history is on
the mailing list, there is limited benefit in doing so.

Thanks,

Jonathan