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.
>
> 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
>
