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 >