On Tue, Feb 13, 2024 at 11:31 AM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Tue, 13 Feb 2024 17:08:19 +0100 > Nuno Sá <noname.nuno@xxxxxxxxx> wrote: > > > On Tue, 2024-02-13 at 09:27 -0600, David Lechner wrote: > > > On Tue, Feb 13, 2024 at 3:47 AM Nuno Sá <noname.nuno@xxxxxxxxx> wrote: > > > > ... > > > > Am I missing something? > > > > > > No, your understanding is correct for the current state of everything > > > in this series. So, we could do as you suggest, but I have a feeling > > > that future additions to this driver might require that it gets > > > changed back this way eventually. > > > > Hmm, not really sure about that as chip_info stuff is always our friend :). And > > I'm anyways of the opinion of keeping things simpler and start to evolve when > > really needed (because often we never really need to evolve). But bah, as I > > said... this is really not a big deal. > > > Oops should have read Nuno's review before replying! > > I'd rather we embedded it for now and did the optimization at probe. > Whilst it's a lot of work per transfer it's not enough to worry about delaying > it until preenable(). Easy to make that move and take it dynamic when > driver changes need it. In meantime, I don't want lots of other drivers > picking up this pattern when they may never need the complexity of > making things more dynamic. > Noted.
