Re: [PATCH v4 2/2] iio: light: opt3001: add support for TI's opt3002 light sensor

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 11 Oct 2024 07:12:05 +0000
Emil Gedenryd <Emil.Gedenryd@axis.com> wrote:

> On Thu, 2024-10-10 at 18:47 +0100, Jonathan Cameron wrote:
> > On Mon, 7 Oct 2024 07:19:06 +0000
> > Emil Gedenryd <Emil.Gedenryd@axis.com> wrote:
> >   
> > > On Sun, 2024-10-06 at 14:16 +0100, Jonathan Cameron wrote:  
> > > > On Thu, 3 Oct 2024 14:22:17 +0200
> > > > Emil Gedenryd <emil.gedenryd@axis.com> wrote:    
> > > > > 
> > > > > +struct opt3001_chip_info {
> > > > > +	const struct iio_chan_spec (*channels)[2];
> > > > > +	enum iio_chan_type chan_type;
> > > > > +	int num_channels;
> > > > > +
> > > > > +	const struct opt3001_scale (*scales)[12];    
> > > > This doesn't compile for me as one of the two options only
> > > > has 11 entries.  You could either force them to be 12
> > > > entries each or use a pointer without the size and
> > > > add a num_scales entry in here.
> > > > 
> > > > Jonathan    
> > > 
> > > Hi Jonathan,
> > > 
> > > Are you building on top of the patch that was accepted in earlier versions of this
> > > patch set? That patch adds the twelfth missing scale value for the opt3001.
> > > See: https://lore.kernel.org/all/20240916-add_opt3002-v3-1-984b190cd68c@axis.com/
> > > 
> > > Should I have added some tag to highlight the dependency for this version of the
> > > patch set?  
> > Ah.  Yes, I was half asleep.
> > They are going via different branches (slow and fast) so I'll have to
> > sit on this series until after that fix is in the upstream for the togreg
> > branch of iio.git.
> > 
> > If I seem to have lost it after that is the case feel free to give me a poke.
> > 
> > Jonathan
> >   
> Hi,
> 
> No worries. Just to clarify, do you mean sit on it as that you will continue reviewing
> the code after the fix is in upstream, or should I consider this patch to be approved?
Assuming not other review comes in, I consider this ready to go.
> 
> Also, do you have an approximation of what time frame we're talking about?
2 weeks most likely.

I've just sent Greg KH a pull request with the fix in it. He will hopefully
pick that up and then send a pull request on to Linus.  Then we wait for the
next rc after that at which point Greg will probably pull it into char-misc-next or
I can always merge it into my togreg branch once it is in a release candidate of
Linus' tree.

In parallel with that I'll probably do a pull request for what is already in the
togreg tree to get a lot of stuff in char-misc-next for the next cycle. That makes
the history a little cleaner as I can fast forward my tree and end up with
whatever is in char-misc-next (hopefully including this).

Anyhow, a bit of tree juggling for me, but we have plenty of time as rc3 will probably
be out tomorrow and it normally goes to rc7 at one rc a week

Thanks,

Jonathan
> Best Regards,
> Emil 
>