All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Rob Herring <robh@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Tony Lindgren <tony@atomide.com>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	Aaro Koskinen <aaro.koskinen@iki.fi>
Subject: Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table
Date: Mon, 3 Apr 2017 18:24:39 -0400	[thread overview]
Message-ID: <a852be9e-e1f0-0975-abd0-a4a61f3a9750@osg.samsung.com> (raw)
In-Reply-To: <20170403222010.xgbf7imyieyfroqr@rob-hp-laptop>

[adding OMAP folks to cc list]

Hello Rob,

On 04/03/2017 06:20 PM, Rob Herring wrote:
> On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
>> Hello Lee,
>>
>> On 04/03/2017 07:15 AM, Lee Jones wrote:
>>
>> [snip]
>>
>>>>  
>>>> +static const struct of_device_id retu_of_match[] = {
>>>> +	{ .compatible = "nokia,retu-mfd" },
>>>> +	{ .compatible = "nokia,tahvo-mfd" },
>>>
>>> Please drop the "-mfd".
>>>
>>
>> Yes, I also didn't like it but I didn't want to change it since that would
>> mean that backward compatiblity and bisect-ability will be broken by this
>> change.
>>
>> In other words, just adding a vendor prefix won't cause an issue if patches
>> are merged independently since if DTS patches are merged before, the driver
>> will still lookup using the I2C device ID table. And if the drivers patches
>> are picked before, the DTS will match using the OF device ID table.
>>
>> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
>> pick all patches and also that the DTS and drivers changes will have to be
>> done in the same patch. If you are OK with that, then I can change in the
>> next version.
> 
> tahvo is not documented nor used in any dts (in the kernel at least). 
> retu is used by 1 board and happened to work, but was never documented. 
> So I think it is okay to change unless the N800 folks object.
>

I'm fine with changing it (in fact I just want to fix the I2C of modalias
reporting). Does this mean that backward compatibility and bisect-ability
should be preserved? Or it's OK to split the changes in different patches?
 
> Rob
> 

Best regards,
--- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

WARNING: multiple messages have this Message-ID
From: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	Linux-OMAP <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
Subject: Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table
Date: Mon, 3 Apr 2017 18:24:39 -0400	[thread overview]
Message-ID: <a852be9e-e1f0-0975-abd0-a4a61f3a9750@osg.samsung.com> (raw)
In-Reply-To: <20170403222010.xgbf7imyieyfroqr@rob-hp-laptop>

[adding OMAP folks to cc list]

Hello Rob,

On 04/03/2017 06:20 PM, Rob Herring wrote:
> On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
>> Hello Lee,
>>
>> On 04/03/2017 07:15 AM, Lee Jones wrote:
>>
>> [snip]
>>
>>>>  
>>>> +static const struct of_device_id retu_of_match[] = {
>>>> +	{ .compatible = "nokia,retu-mfd" },
>>>> +	{ .compatible = "nokia,tahvo-mfd" },
>>>
>>> Please drop the "-mfd".
>>>
>>
>> Yes, I also didn't like it but I didn't want to change it since that would
>> mean that backward compatiblity and bisect-ability will be broken by this
>> change.
>>
>> In other words, just adding a vendor prefix won't cause an issue if patches
>> are merged independently since if DTS patches are merged before, the driver
>> will still lookup using the I2C device ID table. And if the drivers patches
>> are picked before, the DTS will match using the OF device ID table.
>>
>> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
>> pick all patches and also that the DTS and drivers changes will have to be
>> done in the same patch. If you are OK with that, then I can change in the
>> next version.
> 
> tahvo is not documented nor used in any dts (in the kernel at least). 
> retu is used by 1 board and happened to work, but was never documented. 
> So I think it is okay to change unless the N800 folks object.
>

I'm fine with changing it (in fact I just want to fix the I2C of modalias
reporting). Does this mean that backward compatibility and bisect-ability
should be preserved? Or it's OK to split the changes in different patches?
 
> Rob
> 

Best regards,
--- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-04-03 22:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01  7:18 [PATCH v3 0/7] mfd: Add OF device table to I2C drivers that are missing it Javier Martinez Canillas
2017-04-01  7:18 ` Javier Martinez Canillas
2017-04-01  7:18 ` Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips Javier Martinez Canillas
2017-04-03 11:13   ` Lee Jones
2017-04-03 11:13     ` Lee Jones
2017-04-03 15:40     ` Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 2/7] mfd: retu: Add OF device ID table Javier Martinez Canillas
2017-04-03 11:15   ` Lee Jones
2017-04-03 11:15     ` Lee Jones
2017-04-03 15:45     ` Javier Martinez Canillas
2017-04-03 22:20       ` Rob Herring
2017-04-03 22:24         ` Javier Martinez Canillas [this message]
2017-04-03 22:24           ` Javier Martinez Canillas
2017-04-03 22:53           ` Aaro Koskinen
2017-04-03 22:53             ` Aaro Koskinen
2017-04-03 22:58             ` Tony Lindgren
2017-04-03 23:00               ` Javier Martinez Canillas
2017-04-03 23:00                 ` Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 3/7] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 4/7] ARM: dts: n8x0: Add vendor prefix to retu node Javier Martinez Canillas
2017-04-01  7:18   ` Javier Martinez Canillas
2017-04-01  7:18   ` Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip Javier Martinez Canillas
2017-04-01  7:18   ` Javier Martinez Canillas
2017-04-03 11:15   ` Lee Jones
2017-04-03 11:15     ` Lee Jones
2017-04-03 15:47     ` Javier Martinez Canillas
2017-04-04  8:27       ` Lee Jones
2017-04-04 11:48         ` Javier Martinez Canillas
2017-04-04 11:48           ` Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 6/7] mfd: tps6105x: Add OF device ID table Javier Martinez Canillas
2017-04-01  7:18 ` [PATCH v3 7/7] ARM: ux500: Add vendor prefix to tps61052 node Javier Martinez Canillas
2017-04-01  7:18   ` Javier Martinez Canillas

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=a852be9e-e1f0-0975-abd0-a4a61f3a9750@osg.samsung.com \
    --to=javier@osg.samsung.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=robh@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.