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
>
> Thanks,
>
> Jonathan
> > Best Regards,
> > Emil
> >
>
