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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 14 Oct 2024 06:18:29 +0000
Emil Gedenryd <Emil.Gedenryd@xxxxxxxx> wrote:

> On Sat, 2024-10-12 at 16:10 +0100, Jonathan Cameron wrote:
> > On Fri, 11 Oct 2024 07:12:05 +0000
> > Emil Gedenryd <Emil.Gedenryd@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx/
> > > > > 
> > > > > 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.  
> 
> Great, thank you!
> 
> > > 
> > > 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  
> 
> Thank you for the information and for the help during the review process for this patch.
> Best regards,
> Emil

Applied to the togreg branch of iio.git and pushed out initially as testing to
let the build bots see if they can find anything we missed.

I'll push it out for linux-next to pick up in a few days.

Jonathan

> > 
> > Thanks,
> > 
> > Jonathan  
> > > Best Regards,
> > > Emil 
> > >   
> >   
> 






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux