From: Roger Quadros <rogerq@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
dwmw2@infradead.org, Jingoo Han <jg1.han@samsung.com>,
nsekhar@ti.com, Linux Kernel <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
linux-mtd@lists.infradead.org, "Gupta, Pekon" <pekon@ti.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Grant Likely <grant.likely@linaro.org>,
Javier Martinez Canillas <javier@dowhile0.org>,
Brian Norris <computersforpeace@gmail.com>,
Robert Nelson <robertcnelson@gmail.com>
Subject: Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Date: Mon, 26 May 2014 10:33:52 +0300 [thread overview]
Message-ID: <5382EE60.3000808@ti.com> (raw)
In-Reply-To: <20140523145354.GE2321@atomide.com>
On 05/23/2014 05:53 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [140523 01:17]:
>> 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:
>>>>>> 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.
>
> I'm mostly concerned about keeping things working. I think the
> only way we can keep things working is to keep support for
> the old binding around in addition to the new one. That way
> we can update devices one at a time.
Good to hear that you are not keen on keeping the old bindings forever. I understand
that we need to keep things working during the transition. I'll think of something to
maintain backward compatibility while supporting the new binding.
cheers,
-roger
WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Javier Martinez Canillas <javier@dowhile0.org>,
Brian Norris <computersforpeace@gmail.com>,
"Gupta, Pekon" <pekon@ti.com>,
Robert Nelson <robertcnelson@gmail.com>,
Jingoo Han <jg1.han@samsung.com>,
dwmw2@infradead.org, nsekhar@ti.com,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
linux-mtd@lists.infradead.org,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Date: Mon, 26 May 2014 10:33:52 +0300 [thread overview]
Message-ID: <5382EE60.3000808@ti.com> (raw)
In-Reply-To: <20140523145354.GE2321@atomide.com>
On 05/23/2014 05:53 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [140523 01:17]:
>> 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:
>>>>>> 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.
>
> I'm mostly concerned about keeping things working. I think the
> only way we can keep things working is to keep support for
> the old binding around in addition to the new one. That way
> we can update devices one at a time.
Good to hear that you are not keen on keeping the old bindings forever. I understand
that we need to keep things working during the transition. I'll think of something to
maintain backward compatibility while supporting the new binding.
cheers,
-roger
WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Javier Martinez Canillas <javier@dowhile0.org>,
Brian Norris <computersforpeace@gmail.com>,
"Gupta, Pekon" <pekon@ti.com>,
Robert Nelson <robertcnelson@gmail.com>,
Jingoo Han <jg1.han@samsung.com>, <dwmw2@infradead.org>,
<nsekhar@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
<linux-mtd@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Date: Mon, 26 May 2014 10:33:52 +0300 [thread overview]
Message-ID: <5382EE60.3000808@ti.com> (raw)
In-Reply-To: <20140523145354.GE2321@atomide.com>
On 05/23/2014 05:53 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [140523 01:17]:
>> 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:
>>>>>> 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.
>
> I'm mostly concerned about keeping things working. I think the
> only way we can keep things working is to keep support for
> the old binding around in addition to the new one. That way
> we can update devices one at a time.
Good to hear that you are not keen on keeping the old bindings forever. I understand
that we need to keep things working during the transition. I'll think of something to
maintain backward compatibility while supporting the new binding.
cheers,
-roger
next prev parent reply other threads:[~2014-05-26 7:34 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 11:20 [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 01/16] ARM: OMAP2+: gpmc: Add platform data Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 02/16] ARM: OMAP2+: gpmc: Add gpmc timings and settings to " Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 03/16] ARM: OMAP2+: gmpc: add gpmc_generic_init() Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 04/16] ARM: OMAP2+: gpmc: use platform data to configure CS space and poplulate device Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 05/16] ARM: OMAP2+: gpmc: Use low level read/write for context save/restore Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 06/16] ARM: OMAP2+: gpmc: add NAND specific setup Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 07/16] ARM: OMAP2+: nand: Update gpmc_nand_init() to use generic_gpmc_init() Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 08/16] mtd: nand: omap: Fix build warning Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-22 0:54 ` Jingoo Han
2014-05-22 0:54 ` Jingoo Han
2014-05-22 8:17 ` Roger Quadros
2014-05-22 8:17 ` Roger Quadros
2014-05-22 8:17 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 09/16] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 10/16] mtd: nand: omap: Move gpmc_update_nand_reg to nand driver Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` [RFC PATCH 11/16] mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:20 ` Roger Quadros
2014-05-21 11:21 ` [RFC PATCH 12/16] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` [RFC PATCH 13/16] mtd: nand: omap: True device tree support Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` [RFC PATCH 14/16] ARM: OMAP: gpmc: Update DT binding documentation Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` [RFC PATCH 15/16] mtd: nand: omap: " Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` [RFC PATCH 16/16] ARM: dts: omap3-beagle: Add NAND device Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 11:21 ` Roger Quadros
2014-05-21 16:08 ` [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) Ezequiel Garcia
2014-05-21 16:08 ` Ezequiel Garcia
2014-05-22 8:12 ` [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal Roger Quadros
2014-05-22 8:12 ` Roger Quadros
2014-05-22 8:12 ` Roger Quadros
2014-05-22 11:51 ` Javier Martinez Canillas
2014-05-22 11:51 ` Javier Martinez Canillas
2014-05-22 11:51 ` Javier Martinez Canillas
2014-05-22 14:46 ` Ezequiel Garcia
2014-05-22 14:46 ` Ezequiel Garcia
2014-05-22 14:46 ` Ezequiel Garcia
2014-05-23 8:16 ` Roger Quadros
2014-05-23 8:16 ` Roger Quadros
2014-05-23 8:16 ` Roger Quadros
2014-05-23 9:40 ` Javier Martinez Canillas
2014-05-23 9:40 ` Javier Martinez Canillas
2014-05-26 7:23 ` Roger Quadros
2014-05-26 7:23 ` Roger Quadros
2014-05-26 7:23 ` Roger Quadros
2014-05-23 14:53 ` Tony Lindgren
2014-05-23 14:53 ` Tony Lindgren
2014-05-26 7:33 ` Roger Quadros [this message]
2014-05-26 7:33 ` Roger Quadros
2014-05-26 7:33 ` Roger Quadros
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5382EE60.3000808@ti.com \
--to=rogerq@ti.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=grant.likely@linaro.org \
--cc=javier@dowhile0.org \
--cc=jg1.han@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=pekon@ti.com \
--cc=robertcnelson@gmail.com \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.