Messages in this thread | | | Date | Fri, 23 May 2014 11:16:08 +0300 | From | Roger Quadros <> | Subject | Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal |
| |
Ezequiel & Javier,
On 05/22/2014 05:46 PM, Ezequiel Garcia wrote: > On 22 May 01:51 PM, Javier Martinez Canillas wrote: >> On Thu, May 22, 2014 at 10:12 AM, Roger Quadros <rogerq@ti.com> wrote: >>>> On 21 May 02:20 PM, Roger Quadros wrote: >>>>> >>>>> For DT boot: >>>>> - The GPMC controller node should have a chip select (CS) node for each used >>>>> chip select. The CS node must have a child device node for each device >>>>> attached to that chip select. Properties for that child are GPMC agnostic. >>>>> >>>>> i.e. >>>>> gpmc { >>>>> cs0 { >>>>> nand0 { >>>>> } >>>>> }; >>>>> >>>>> cs1 { >>>>> nor0 { >>>>> } >>>>> } >>>>> ... >>>>> }; >>>>> >>>> >>>> While I agree that the GPMC driver is a bit messy, I'm not sure it's possible >>>> to go through such a complete devicetree binding re-design (breaking backwards >>>> compatibility) now that the binding is already in production. >>> >>> Why not? especially if the existing bindings are poorly dones. Is anyone using these >>> bindings burning the DT into ROM and can't change it when they update the kernel? >>> >> >> While I do agree that your DT bindings are much better than the >> current ones, there is a policy that DT bindings are an external API >> and once are released with a kernel are set in stone and can't be >> changed. >> > > Exactly. The DT binding is considered an ABI. Thus, invariant across kernel > versions. Users can't be coherced into a DTB update after a kernel update. > > That said, I don't really care if you break compatilibity in this case. > Rather, I'm suggesting that you make sure this change is going to be accepted > upstream, before doing any more work. The DT maintainers are reluctant to do > so.
Appreciate your concern.
Would be really nice if you can review patches 1-12. They have nothing to do with DT changes. Thanks.
cheers, -roger
> > On the other side, I guess you will also break bisectability while breaking > backward compatibility. Doesn't sound very nice. >
| |