Re: [PATCH v5 28/28] mtd: rawnand: Allocate the best data interface structure dynamically

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

 



Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Wed, 27 May
2020 10:35:19 +0200:

> On Wed, 27 May 2020 09:57:32 +0200
> Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> 
> > Maybe I misunderstood your request, you were saying that allocating a
> > "best data interface object" would be good, so I interpreted it as:
> > rename it, and allocated it dynamically. I'm fine keeping
> > data_interface and just declaring it as a pointer.  
> 
> Correct, renaming it into best_iface_cfg is probably good, but then,
> maybe we should have a current_iface_cfg, so the core/drivers always
> have a pointer to the currently applied config (which after a reset
> can be the reset config for a short period of time).

That's why I created an indirection on chip->data_interface.
nand_get_interface_cfg() is here for that -> the drivers do not care
about which one is applied. I don't think we need more than I already
proposed:
-> there is one default reset configuration object that can be used by
   anyone
-> there is a best configuration

If the best configuration has been derived, then it will be used.
Otherwise, the helper will fallback to the default slower one, and this
covers all the cases :)

> 
> > 
> > Anyway, I like talking about the "interface" rather than the "interface
> > configuration" which is implied in my mind, I saw you were asking to
> > add "configuration" sometimes, do you have something in mind that I
> > don't?  
> 
> Well, to me a configuration is something that you can manipulate without
> necessarily implying it's the current state the HW operates in. For a
> configuration to be active, you have to apply it. And that's pretty
> much what the nand_data_interface describes, a configuration, that can
> be retrieved, tweaked, and finally applied. Hence the renaming I
> suggest.

Fine.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux