* [PATCH v2 0/2] Add Ether DT support for R8A7790/Lager reference board
From: Sergei Shtylyov @ 2014-02-19 23:18 UTC (permalink / raw)
To: horms, linux-sh, devicetree
Cc: magnus.damm, linux, linux-arm-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak
Hello.
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-v3.14-rc3-20140218' tag. Here we add the Ether device tree
support on the R8A7790/Lager reference board. The patchset requires the
'sh_eth' driver device tree support just merged to the 'net-next.git' repo in
order to work.
[1/2] ARM: shmobile: r8a7790: add Ether DT support
[2/2] ARM: shmobile: lager: add Ether DT support
WBR, Sergei
^ permalink raw reply
* [PATCH v4 4/4] arm: zynq: Add support for cpufreq
From: Soren Brinkmann @ 2014-02-19 23:14 UTC (permalink / raw)
To: Thomas Gleixner, Daniel Lezcano, Michal Simek
Cc: linux-kernel, linux-arm-kernel, Sören Brinkmann, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
devicetree
In-Reply-To: <1392851684-29950-1-git-send-email-soren.brinkmann@xilinx.com>
The generic cpufreq-cpu0 driver can scale the CPU frequency on Zynq
SOCs. Add the required platform device to the BSP and appropriate
OPPs to the dts.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: devicetree@vger.kernel.org
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
---
v4:
- no change
v3:
- change lowest frequency to 222223 (F_max / 3)
---
arch/arm/boot/dts/zynq-7000.dtsi | 6 ++++++
arch/arm/mach-zynq/Kconfig | 2 ++
arch/arm/mach-zynq/common.c | 3 +++
3 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 8b67b19392ec..789d0bacc110 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -24,6 +24,12 @@
device_type = "cpu";
reg = <0>;
clocks = <&clkc 3>;
+ operating-points = <
+ /* kHz uV */
+ 666667 1000000
+ 333334 1000000
+ 222223 1000000
+ >;
};
cpu@1 {
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index f84fab14f0b7..f03e75bd0b2b 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -2,6 +2,8 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform" if ARCH_MULTI_V7
select ARM_AMBA
select ARM_GIC
+ select ARCH_HAS_CPUFREQ
+ select ARCH_HAS_OPP
select COMMON_CLK
select CPU_V7
select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 1db2a5ca9ab8..644468151c04 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -51,6 +51,8 @@ static struct platform_device zynq_cpuidle_device = {
*/
static void __init zynq_init_machine(void)
{
+ struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+
/*
* 64KB way size, 8-way associativity, parity disabled
*/
@@ -59,6 +61,7 @@ static void __init zynq_init_machine(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
platform_device_register(&zynq_cpuidle_device);
+ platform_device_register_full(&devinfo);
}
static void __init zynq_timer_init(void)
--
1.9.0.1.g4196000
^ permalink raw reply related
* Re: [PATCH] of: give priority to the compatible match in __of_match_node()
From: Paul Gortmaker @ 2014-02-19 22:44 UTC (permalink / raw)
To: Grant Likely, Rob Herring
Cc: Kevin Hao, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann, Chris Proctor, Stephen N Chivers, Rob Herring,
Scott Wood, linuxppc-dev, Sebastian Hesselbarth
In-Reply-To: <20140219224051.65BB7C4077A-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On 14-02-19 05:40 PM, Grant Likely wrote:
> On Wed, 19 Feb 2014 16:23:02 -0500, Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> wrote:
>> On 14-02-19 03:41 PM, Grant Likely wrote:
>>> On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> wrote:
>>>> On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> When the device node do have a compatible property, we definitely
>>>>>> prefer the compatible match besides the type and name. Only if
>>>>>> there is no such a match, we then consider the candidate which
>>>>>> doesn't have compatible entry but do match the type or name with
>>>>>> the device node.
>>>>>>
>>>>>> This is based on a patch from Sebastian Hesselbarth.
>>>>>> http://patchwork.ozlabs.org/patch/319434/
>>>>>>
>>>>>> I did some code refactoring and also fixed a bug in the original patch.
>>>>>
>>>>> I'm inclined to just revert this once again and avoid possibly
>>>>> breaking yet another platform.
>>>>
>>>> Well, for what it is worth, today's (Feb19th) linux-next tree fails to boot
>>>> on my sbc8548. It fails with:
>>>
>>> I think I've got it fixed now with the latest series. Please try the
>>> devicetree/merge branch on git://git.secretlab.ca/git/linux
>>
>> That seems to work.
>
> Great, thanks for the testing. Can I add a Tested-by line for you?
Absolutely; sorry for not thinking to explicitly indicate that.
P.
--
>
> g.
>
>>
>> libphy: Freescale PowerQUICC MII Bus: probed
>> libphy: Freescale PowerQUICC MII Bus: probed
>> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
>> fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
>> fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
>> fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
>> fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
>> fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
>> fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
>> fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
>> fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
>> fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
>> TCP: cubic registered
>> Initializing XFRM netlink socket
>> NET: Registered protocol family 17
>>
>> ...
>>
>> root@sbc8548:~# cat /proc/version
>> Linux version 3.14.0-rc3-00024-g7119f42057c6 (paul@yow-lpgnfs-02) (gcc version 4.5.2 (GCC) ) #1 Wed Feb 19 16:08:17 EST 2014
>> root@sbc8548:~#
>>
>> Paul.
>> --
>>
>>>
>>> g.
>>>
>>>> -----------------------------------------------
>>>> libphy: Freescale PowerQUICC MII Bus: probed
>>>> mdio_bus ethernet@e002400: /soc8548@e0000000/ethernet@24000/mdio@520
>>>> PHY address 1312 is too large
>>>> libphy: Freescale PowerQUICC MII Bus: probed
>>>> libphy: Freescale PowerQUICC MII Bus: probed
>>>> mdio_bus ethernet@e002500: /soc8548@e0000000/ethernet@25000/mdio@520
>>>> PHY address 1312 is too large
>>>> libphy: Freescale PowerQUICC MII Bus: probed
>>>> TCP: cubic registered
>>>> Initializing XFRM netlink socket
>>>> NET: Registered protocol family 17
>>>> <fail nfs mount>
>>>> -----------------------------------------------
>>>>
>>>> On a normal boot, we should see this:
>>>> -----------------------------------------------
>>>> libphy: Freescale PowerQUICC MII Bus: probed
>>>> libphy: Freescale PowerQUICC MII Bus: probed
>>>> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
>>>> fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
>>>> fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
>>>> fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
>>>> fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
>>>> fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
>>>> fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
>>>> fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
>>>> fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
>>>> fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
>>>> TCP: cubic registered
>>>> Initializing XFRM netlink socket
>>>> NET: Registered protocol family 17
>>>> -----------------------------------------------
>>>>
>>>>
>>>> Git bisect says:
>>>>
>>>> ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4 is the first bad commit
>>>> commit ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4
>>>> Author: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Date: Tue Feb 18 15:57:30 2014 +0800
>>>>
>>>> of: reimplement the matching method for __of_match_node()
>>>>
>>>> In the current implementation of __of_match_node(), it will compare
>>>> each given match entry against all the node's compatible strings
>>>> with of_device_is_compatible().
>>>>
>>>> To achieve multiple compatible strings per node with ordering from
>>>> specific to generic, this requires given matches to be ordered from
>>>> specific to generic. For most of the drivers this is not true and
>>>> also an alphabetical ordering is more sane there.
>>>>
>>>> Therefore, we define a following priority order for the match, and
>>>> then scan all the entries to find the best match.
>>>> 1. specific compatible && type && name
>>>> 2. specific compatible && type
>>>> 3. specific compatible && name
>>>> 4. specific compatible
>>>> 5. general compatible && type && name
>>>> 6. general compatible && type
>>>> 7. general compatible && name
>>>> 8. general compatible
>>>> 9. type && name
>>>> 10. type
>>>> 11. name
>>>>
>>>> This is based on some pseudo-codes provided by Grant Likely.
>>>>
>>>> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> [grant.likely: Changed multiplier to 4 which makes more sense]
>>>> Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>
>>>> :040000 040000 8f5dd19174417aece63b308ff299a5dbe2efa5a0
>>>> 8401b0e3903e23e973845ee75b26b04345d803d2 M drivers
>>>>
>>>> As a double check, I checked out the head of linux-next, and did a
>>>> revert of the above commit, and my sbc8548 can then boot properly.
>>>>
>>>> Not doing anything fancy ; using the defconfig exactly as-is, and
>>>> ensuring the dtb is fresh from linux-next HEAD of today.
>>>>
>>>> Thanks,
>>>> Paul.
>>>> --
>>>>
>>>>>
>>>>> However, I think I would like to see this structured differently. We
>>>>> basically have 2 ways of matching: the existing pre-3.14 way and the
>>>>> desired match on best compatible only. All new bindings should match
>>>>> with the new way and the old way needs to be kept for compatibility.
>>>>> So lets structure the code that way. Search the match table first for
>>>>> best compatible with name and type NULL, then search the table the old
>>>>> way. I realize it appears you are doing this, but it is not clear this
>>>>> is the intent of the code. I would like to see this written as a patch
>>>>> with commit 105353145eafb3ea919 reverted first and you add a new match
>>>>> function to call first and then fallback to the existing function.
>>>>>
>>>>> Rob
>>>>>
>>>>>>
>>>>>> Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>> ---
>>>>>> drivers/of/base.c | 55 +++++++++++++++++++++++++++++++++++++------------------
>>>>>> 1 file changed, 37 insertions(+), 18 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>>>>> index ff85450d5683..9d655df458bd 100644
>>>>>> --- a/drivers/of/base.c
>>>>>> +++ b/drivers/of/base.c
>>>>>> @@ -730,32 +730,45 @@ out:
>>>>>> }
>>>>>> EXPORT_SYMBOL(of_find_node_with_property);
>>>>>>
>>>>>> +static int of_match_type_or_name(const struct device_node *node,
>>>>>> + const struct of_device_id *m)
>>>>>> +{
>>>>>> + int match = 1;
>>>>>> +
>>>>>> + if (m->name[0])
>>>>>> + match &= node->name && !strcmp(m->name, node->name);
>>>>>> +
>>>>>> + if (m->type[0])
>>>>>> + match &= node->type && !strcmp(m->type, node->type);
>>>>>> +
>>>>>> + return match;
>>>>>> +}
>>>>>> +
>>>>>> static
>>>>>> const struct of_device_id *__of_match_node(const struct of_device_id *matches,
>>>>>> const struct device_node *node)
>>>>>> {
>>>>>> const char *cp;
>>>>>> int cplen, l;
>>>>>> + const struct of_device_id *m;
>>>>>> + int match;
>>>>>>
>>>>>> if (!matches)
>>>>>> return NULL;
>>>>>>
>>>>>> cp = __of_get_property(node, "compatible", &cplen);
>>>>>> - do {
>>>>>> - const struct of_device_id *m = matches;
>>>>>> + while (cp && (cplen > 0)) {
>>>>>> + m = matches;
>>>>>>
>>>>>> /* Check against matches with current compatible string */
>>>>>> while (m->name[0] || m->type[0] || m->compatible[0]) {
>>>>>> - int match = 1;
>>>>>> - if (m->name[0])
>>>>>> - match &= node->name
>>>>>> - && !strcmp(m->name, node->name);
>>>>>> - if (m->type[0])
>>>>>> - match &= node->type
>>>>>> - && !strcmp(m->type, node->type);
>>>>>> - if (m->compatible[0])
>>>>>> - match &= cp
>>>>>> - && !of_compat_cmp(m->compatible, cp,
>>>>>> + if (!m->compatible[0]) {
>>>>>> + m++;
>>>>>> + continue;
>>>>>> + }
>>>>>> +
>>>>>> + match = of_match_type_or_name(node, m);
>>>>>> + match &= cp && !of_compat_cmp(m->compatible, cp,
>>>>>> strlen(m->compatible));
>>>>>> if (match)
>>>>>> return m;
>>>>>> @@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
>>>>>> }
>>>>>>
>>>>>> /* Get node's next compatible string */
>>>>>> - if (cp) {
>>>>>> - l = strlen(cp) + 1;
>>>>>> - cp += l;
>>>>>> - cplen -= l;
>>>>>> - }
>>>>>> - } while (cp && (cplen > 0));
>>>>>> + l = strlen(cp) + 1;
>>>>>> + cp += l;
>>>>>> + cplen -= l;
>>>>>> + }
>>>>>> +
>>>>>> + m = matches;
>>>>>> + /* Check against matches without compatible string */
>>>>>> + while (m->name[0] || m->type[0] || m->compatible[0]) {
>>>>>> + if (!m->compatible[0] && of_match_type_or_name(node, m))
>>>>>> + return m;
>>>>>> + m++;
>>>>>> + }
>>>>>>
>>>>>> return NULL;
>>>>>> }
>>>>>> --
>>>>>> 1.8.5.3
>>>>>>
>>>>>> --
>>>>>> 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
>>>>> _______________________________________________
>>>>> Linuxppc-dev mailing list
>>>>> Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>
>
--
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
^ permalink raw reply
* Re: [PATCH] of: give priority to the compatible match in __of_match_node()
From: Grant Likely @ 2014-02-19 22:40 UTC (permalink / raw)
To: Paul Gortmaker, Rob Herring
Cc: Kevin Hao, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann, Chris Proctor, Stephen N Chivers, Rob Herring,
Scott Wood, linuxppc-dev, Sebastian Hesselbarth
In-Reply-To: <530520B6.8050205-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
On Wed, 19 Feb 2014 16:23:02 -0500, Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> wrote:
> On 14-02-19 03:41 PM, Grant Likely wrote:
> > On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> wrote:
> >> On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>> When the device node do have a compatible property, we definitely
> >>>> prefer the compatible match besides the type and name. Only if
> >>>> there is no such a match, we then consider the candidate which
> >>>> doesn't have compatible entry but do match the type or name with
> >>>> the device node.
> >>>>
> >>>> This is based on a patch from Sebastian Hesselbarth.
> >>>> http://patchwork.ozlabs.org/patch/319434/
> >>>>
> >>>> I did some code refactoring and also fixed a bug in the original patch.
> >>>
> >>> I'm inclined to just revert this once again and avoid possibly
> >>> breaking yet another platform.
> >>
> >> Well, for what it is worth, today's (Feb19th) linux-next tree fails to boot
> >> on my sbc8548. It fails with:
> >
> > I think I've got it fixed now with the latest series. Please try the
> > devicetree/merge branch on git://git.secretlab.ca/git/linux
>
> That seems to work.
Great, thanks for the testing. Can I add a Tested-by line for you?
g.
>
> libphy: Freescale PowerQUICC MII Bus: probed
> libphy: Freescale PowerQUICC MII Bus: probed
> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
> fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
> fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
> fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
> fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
> fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
> fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
> fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
> fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
> fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
> TCP: cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
>
> ...
>
> root@sbc8548:~# cat /proc/version
> Linux version 3.14.0-rc3-00024-g7119f42057c6 (paul@yow-lpgnfs-02) (gcc version 4.5.2 (GCC) ) #1 Wed Feb 19 16:08:17 EST 2014
> root@sbc8548:~#
>
> Paul.
> --
>
> >
> > g.
> >
> >> -----------------------------------------------
> >> libphy: Freescale PowerQUICC MII Bus: probed
> >> mdio_bus ethernet@e002400: /soc8548@e0000000/ethernet@24000/mdio@520
> >> PHY address 1312 is too large
> >> libphy: Freescale PowerQUICC MII Bus: probed
> >> libphy: Freescale PowerQUICC MII Bus: probed
> >> mdio_bus ethernet@e002500: /soc8548@e0000000/ethernet@25000/mdio@520
> >> PHY address 1312 is too large
> >> libphy: Freescale PowerQUICC MII Bus: probed
> >> TCP: cubic registered
> >> Initializing XFRM netlink socket
> >> NET: Registered protocol family 17
> >> <fail nfs mount>
> >> -----------------------------------------------
> >>
> >> On a normal boot, we should see this:
> >> -----------------------------------------------
> >> libphy: Freescale PowerQUICC MII Bus: probed
> >> libphy: Freescale PowerQUICC MII Bus: probed
> >> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
> >> fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
> >> fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
> >> fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
> >> fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
> >> fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
> >> fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
> >> fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
> >> fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
> >> fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
> >> TCP: cubic registered
> >> Initializing XFRM netlink socket
> >> NET: Registered protocol family 17
> >> -----------------------------------------------
> >>
> >>
> >> Git bisect says:
> >>
> >> ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4 is the first bad commit
> >> commit ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4
> >> Author: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Date: Tue Feb 18 15:57:30 2014 +0800
> >>
> >> of: reimplement the matching method for __of_match_node()
> >>
> >> In the current implementation of __of_match_node(), it will compare
> >> each given match entry against all the node's compatible strings
> >> with of_device_is_compatible().
> >>
> >> To achieve multiple compatible strings per node with ordering from
> >> specific to generic, this requires given matches to be ordered from
> >> specific to generic. For most of the drivers this is not true and
> >> also an alphabetical ordering is more sane there.
> >>
> >> Therefore, we define a following priority order for the match, and
> >> then scan all the entries to find the best match.
> >> 1. specific compatible && type && name
> >> 2. specific compatible && type
> >> 3. specific compatible && name
> >> 4. specific compatible
> >> 5. general compatible && type && name
> >> 6. general compatible && type
> >> 7. general compatible && name
> >> 8. general compatible
> >> 9. type && name
> >> 10. type
> >> 11. name
> >>
> >> This is based on some pseudo-codes provided by Grant Likely.
> >>
> >> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> [grant.likely: Changed multiplier to 4 which makes more sense]
> >> Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>
> >> :040000 040000 8f5dd19174417aece63b308ff299a5dbe2efa5a0
> >> 8401b0e3903e23e973845ee75b26b04345d803d2 M drivers
> >>
> >> As a double check, I checked out the head of linux-next, and did a
> >> revert of the above commit, and my sbc8548 can then boot properly.
> >>
> >> Not doing anything fancy ; using the defconfig exactly as-is, and
> >> ensuring the dtb is fresh from linux-next HEAD of today.
> >>
> >> Thanks,
> >> Paul.
> >> --
> >>
> >>>
> >>> However, I think I would like to see this structured differently. We
> >>> basically have 2 ways of matching: the existing pre-3.14 way and the
> >>> desired match on best compatible only. All new bindings should match
> >>> with the new way and the old way needs to be kept for compatibility.
> >>> So lets structure the code that way. Search the match table first for
> >>> best compatible with name and type NULL, then search the table the old
> >>> way. I realize it appears you are doing this, but it is not clear this
> >>> is the intent of the code. I would like to see this written as a patch
> >>> with commit 105353145eafb3ea919 reverted first and you add a new match
> >>> function to call first and then fallback to the existing function.
> >>>
> >>> Rob
> >>>
> >>>>
> >>>> Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>>> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>>> ---
> >>>> drivers/of/base.c | 55 +++++++++++++++++++++++++++++++++++++------------------
> >>>> 1 file changed, 37 insertions(+), 18 deletions(-)
> >>>>
> >>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
> >>>> index ff85450d5683..9d655df458bd 100644
> >>>> --- a/drivers/of/base.c
> >>>> +++ b/drivers/of/base.c
> >>>> @@ -730,32 +730,45 @@ out:
> >>>> }
> >>>> EXPORT_SYMBOL(of_find_node_with_property);
> >>>>
> >>>> +static int of_match_type_or_name(const struct device_node *node,
> >>>> + const struct of_device_id *m)
> >>>> +{
> >>>> + int match = 1;
> >>>> +
> >>>> + if (m->name[0])
> >>>> + match &= node->name && !strcmp(m->name, node->name);
> >>>> +
> >>>> + if (m->type[0])
> >>>> + match &= node->type && !strcmp(m->type, node->type);
> >>>> +
> >>>> + return match;
> >>>> +}
> >>>> +
> >>>> static
> >>>> const struct of_device_id *__of_match_node(const struct of_device_id *matches,
> >>>> const struct device_node *node)
> >>>> {
> >>>> const char *cp;
> >>>> int cplen, l;
> >>>> + const struct of_device_id *m;
> >>>> + int match;
> >>>>
> >>>> if (!matches)
> >>>> return NULL;
> >>>>
> >>>> cp = __of_get_property(node, "compatible", &cplen);
> >>>> - do {
> >>>> - const struct of_device_id *m = matches;
> >>>> + while (cp && (cplen > 0)) {
> >>>> + m = matches;
> >>>>
> >>>> /* Check against matches with current compatible string */
> >>>> while (m->name[0] || m->type[0] || m->compatible[0]) {
> >>>> - int match = 1;
> >>>> - if (m->name[0])
> >>>> - match &= node->name
> >>>> - && !strcmp(m->name, node->name);
> >>>> - if (m->type[0])
> >>>> - match &= node->type
> >>>> - && !strcmp(m->type, node->type);
> >>>> - if (m->compatible[0])
> >>>> - match &= cp
> >>>> - && !of_compat_cmp(m->compatible, cp,
> >>>> + if (!m->compatible[0]) {
> >>>> + m++;
> >>>> + continue;
> >>>> + }
> >>>> +
> >>>> + match = of_match_type_or_name(node, m);
> >>>> + match &= cp && !of_compat_cmp(m->compatible, cp,
> >>>> strlen(m->compatible));
> >>>> if (match)
> >>>> return m;
> >>>> @@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
> >>>> }
> >>>>
> >>>> /* Get node's next compatible string */
> >>>> - if (cp) {
> >>>> - l = strlen(cp) + 1;
> >>>> - cp += l;
> >>>> - cplen -= l;
> >>>> - }
> >>>> - } while (cp && (cplen > 0));
> >>>> + l = strlen(cp) + 1;
> >>>> + cp += l;
> >>>> + cplen -= l;
> >>>> + }
> >>>> +
> >>>> + m = matches;
> >>>> + /* Check against matches without compatible string */
> >>>> + while (m->name[0] || m->type[0] || m->compatible[0]) {
> >>>> + if (!m->compatible[0] && of_match_type_or_name(node, m))
> >>>> + return m;
> >>>> + m++;
> >>>> + }
> >>>>
> >>>> return NULL;
> >>>> }
> >>>> --
> >>>> 1.8.5.3
> >>>>
> >>>> --
> >>>> 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
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> >>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
--
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
^ permalink raw reply
* Re: [PATCH] gpio: document polarity flag best practices
From: Laurent Pinchart @ 2014-02-19 22:20 UTC (permalink / raw)
To: Stephen Warren
Cc: Linus Walleij, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Warren
In-Reply-To: <1392835406-9380-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Hi Stephen,
Thank you for the patch.
On Wednesday 19 February 2014 11:43:26 Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Document what we (Laurent and I, following a mailing list dicussion)
> believe are best practices for the polarity flag in a GPIO specifier.
>
> While touching the doc, I made a few minor editing changes to other
> areas.
>
> Suggested-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/gpio/gpio.txt | 60 ++++++++++++++++++----
> 1 file changed, 52 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
> b/Documentation/devicetree/bindings/gpio/gpio.txt index
> 0c85bb6e3a80..3fb8f53071b8 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -13,11 +13,11 @@ properties, each containing a 'gpio-list':
> gpio-specifier : Array of #gpio-cells specifying specific gpio
> (controller specific)
>
> -GPIO properties should be named "[<name>-]gpios". Exact
> +GPIO properties should be named "[<name>-]gpios". The exact
> meaning of each gpios property must be documented in the device tree
> binding for each device.
>
> -For example, the following could be used to describe gpios pins to use
> +For example, the following could be used to describe GPIO pins used
> as chip select lines; with chip selects 0, 1 and 3 populated, and chip
> select 2 left empty:
>
> @@ -44,35 +44,79 @@ whether pin is open-drain and whether pin is logically
> inverted. Exact meaning of each specifier cell is controller specific, and
> must be documented in the device tree binding for the device.
>
> -Example of the node using GPIOs:
> +Example of a node using GPIOs:
>
> node {
> gpios = <&qe_pio_e 18 0>;
> };
>
> In this example gpio-specifier is "18 0" and encodes GPIO pin number,
> -and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
> +and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
> +
> +1.1) GPIO specifier best practices
> +----------------------------------
> +
> +A gpio-specifier should contain a flag indicating the GPIO polarity;
> active- +high or active-low. If it does, the follow best practices should
> be followed: +
> +The gpio-specifier's polarity flag should represent the physical level at
> the +GPIO controller that achieves (or represents, for inputs) a logically
> asserted +value at the device. The exact definition of logically asserted
> should be +defined by the binding for the device. If the board inverts the
> signal between +the GPIO controller and the device, then the gpio-specifier
> will represent the +opposite physical level than the signal at the device's
> pin.
> +
> +When the device's signal polarity is configurable, the binding for the
> +device must either:
> +
> +a) Define a single static polarity for the signal, with the expectation
> that +any software using that binding would statically program the device
> to use +that signal polarity.
> +
> +The static choice of polarity may be either:
> +
> +a1) (Preferred) Dictated by a binding-specific DT property.
> +
> +or:
> +
> +a2) Defined statically by the DT binding itself.
> +
> +In particular, the polarity cannot be derived from the gpio-specifier,
> since +that would prevent the DT from separately representing the two
> orthogonal +concepts of configurable signal polarity in the device, and
> possible board- +level signal inversion.
> +
> +or:
> +
> +b) Pick a single option for device signal polarity, and document this
> choice +in the binding. The gpio-specifier should represent the polarity of
> the signal +(at the GPIO controller) assuming that the device is configured
> for this +particular signal polarity choice. If software chooses to program
> the device +to generate or receive a signal of the opposite polarity,
> software will be +responsible for correctly interpreting (inverting) the
> GPIO signal at the GPIO +controller.
>
> 2) gpio-controller nodes
> ------------------------
>
> -Every GPIO controller node must both an empty "gpio-controller"
> -property, and have #gpio-cells contain the size of the gpio-specifier.
> +Every GPIO controller node must contain both an empty "gpio-controller"
> +property, and a #gpio-cells integer property, which indicates the number of
> +cells in a gpio-specifier.
>
> Example of two SOC GPIO banks defined as gpio-controller nodes:
>
> qe_pio_a: gpio-controller@1400 {
> - #gpio-cells = <2>;
> compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> reg = <0x1400 0x18>;
> gpio-controller;
> + #gpio-cells = <2>;
> };
>
> qe_pio_e: gpio-controller@1460 {
> - #gpio-cells = <2>;
> compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> reg = <0x1460 0x18>;
> gpio-controller;
> + #gpio-cells = <2>;
> };
>
> 2.1) gpio- and pin-controller interaction
--
Regards,
Laurent Pinchart
--
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
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Allows to get the SoC ID even without PCI enabled
From: Gregory CLEMENT @ 2014-02-19 22:14 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni, Ezequiel Garcia,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Tawfik Bayouk, Nadav Haklai
In-Reply-To: <1392848096-17838-1-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The address translation of a PCI node don't require anymore the PCI
support in the kernel. This translation is mandatory to be able to
read the SoC ID which is stored in the PCI controller of the mvebu
SoCs.
This patch selects the symbol needed to get only this translation for
all the mvebu platforms.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/mach-mvebu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7263ce..df9e7d270810 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -16,6 +16,7 @@ config ARCH_MVEBU
select ARCH_REQUIRE_GPIOLIB
select MIGHT_HAVE_PCI
select PCI_QUIRKS if PCI
+ select OF_ADDRESS_PCI
if ARCH_MVEBU
--
1.8.1.2
--
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
^ permalink raw reply related
* [PATCH 1/2] of: Allows to use the PCI translator without the PCI core
From: Gregory CLEMENT @ 2014-02-19 22:14 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni, Ezequiel Garcia,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Tawfik Bayouk, Nadav Haklai
In-Reply-To: <1392848096-17838-1-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Translating an address from a PCI node of the device-tree into a CPU
physical address doesn't require the core PCI support. Those
translations are just related to the device tree itself.
The use case to translate an address from a PCI node without actually
using the PCI core support is when one needs to access the PCI
controller without accessing any PCI devices.
Marvell SoCs, such as Kirkwood, Dove or Armada XP for instance, come
with an IP of a PCI controller. In the registers of this controller
are stored the ID and the revision of a SoC. With this patch it will
be possible to read the SoC ID of a board without any PCI device and
then without the PCI core support.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/of/Kconfig | 4 ++++
drivers/of/address.c | 8 +++++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index c6973f101a3e..ffdcb11f75fb 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -44,6 +44,10 @@ config OF_DYNAMIC
config OF_ADDRESS
def_bool y
depends on !SPARC
+ select OF_ADDRESS_PCI if PCI
+
+config OF_ADDRESS_PCI
+ bool
config OF_IRQ
def_bool y
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 1a54f1ffaadb..cb4242a69cd5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -91,7 +91,7 @@ static unsigned int of_bus_default_get_flags(const __be32 *addr)
return IORESOURCE_MEM;
}
-#ifdef CONFIG_PCI
+#ifdef CONFIG_OF_ADDRESS_PCI
/*
* PCI bus specific translator
*/
@@ -166,7 +166,9 @@ static int of_bus_pci_translate(__be32 *addr, u64 offset, int na)
{
return of_bus_default_translate(addr + 1, offset, na - 1);
}
+#endif /* CONFIG_OF_ADDRESS_PCI */
+#ifdef CONFIG_PCI
const __be32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size,
unsigned int *flags)
{
@@ -356,7 +358,7 @@ static unsigned int of_bus_isa_get_flags(const __be32 *addr)
*/
static struct of_bus of_busses[] = {
-#ifdef CONFIG_PCI
+#ifdef CONFIG_OF_ADDRESS_PCI
/* PCI */
{
.name = "pci",
@@ -367,7 +369,7 @@ static struct of_bus of_busses[] = {
.translate = of_bus_pci_translate,
.get_flags = of_bus_pci_get_flags,
},
-#endif /* CONFIG_PCI */
+#endif /* CONFIG_OF_ADDRESS_PCI */
/* ISA */
{
.name = "isa",
--
1.8.1.2
--
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
^ permalink raw reply related
* [PATCH 0/2] Translate of PCI address without PCI enabled
From: Gregory CLEMENT @ 2014-02-19 22:14 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni, Ezequiel Garcia, linux-arm-kernel, Lior Amsalem,
Tawfik Bayouk, Nadav Haklai
Hello,
This patch set makes the use of the of PCI address translator less
restrictive. At the end it will allow to use the mvebu_get_soc_id
unconditionally.
The mvebu SoC (such as Kirkwood, Dove or Armada XP for instance) come
with an IP of a PCI controller. The ID and the revision of a SoC are
stored in the registers of this controller. Being able to get this
information allows to deals with errata more dynamically.
To manage to read this information, we need to map the registers, and
for this we need to use the of PCI translator which depend of the PCI
support.
However there are mvebu board without any PCI devices, and where
selecting the PCI support would be useless.
Moreover translating an address from a PCI node of the device-tree
into a CPU physical address doesn't require the core PCI
support. Those translations are just related to the device tree
itself.
The 1st patch introduces a new config symbol: OF_ADDRESS_PCI, which
will be selected as soon as PCI will be selected, so we remains in the
same situation the current code. It should go to the of tree.
The 2nd patch selects OF_ADDRESS_PCI as soon as ARCH_MVEBU will be
selected. This will make mvebu_get_soc_id available even without the
PCI support. It should go to the mvebu tree.
Thanks,
Gregory CLEMENT (2):
of: Allows to use the PCI translator without the PCI core
ARM: mvebu: Allows to get the SoC ID even without PCI enabled
arch/arm/mach-mvebu/Kconfig | 1 +
drivers/of/Kconfig | 4 ++++
drivers/of/address.c | 8 +++++---
3 files changed, 10 insertions(+), 3 deletions(-)
--
1.8.1.2
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Warner Losh @ 2014-02-19 21:43 UTC (permalink / raw)
To: Grant Likely
Cc: Jason Cooper, Sascha Hauer, Rob Herring, Ian Campbell,
Paweł Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CACxGe6vU3j4-UtUtxBkT=Mf+AeLVxBcWicGqQhcGVZXnEBUkig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Feb 19, 2014, at 2:09 PM, Grant Likely wrote:
> On Tue, Feb 18, 2014 at 6:18 PM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
>> On Tue, Feb 18, 2014 at 04:57:50PM +0100, Sascha Hauer wrote:
>>> It will be interesting to see which rules should apply for merging new
>>> bindings. I know that devicetrees should be OS agnostic, but sometimes
>>> they are modelled after how Linux currently works. What happens when the
>>> *BSD guys have different ideas how a good binding looks like? How will
>>> such conflicts be resolved?
>>
>> That's more a question for Grant. I assume we'll all put on our big-boy
>> pants and pick the best technical solution based on their merits. :)
>
> I think you've answered it pretty competently.
What, the BSDs don't get a free pass to dump junk into the process. I'm shocked :)
But we have bug-boy pants over in BSD land, so that shouldn't be a problem.
Warner
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC v1 2/3] of: Add definition of maximum length of a property name
From: Rob Herring @ 2014-02-19 21:42 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette, Russell King - ARM Linux, Rob Herring,
Grant Likely, Mark Rutland, Kumar Gala, Kyungmin Park,
sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ, Marek Szyprowski, Tomasz Figa
In-Reply-To: <1392829124-25705-3-git-send-email-s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Feb 19, 2014 at 10:58 AM, Sylwester Nawrocki
<s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Maximum length of a property name is defined by ePAPR (2.2.4.1) as
> 31 characters. Add a corresponding definition, including the trailing
> null space.
Does dtc enforce this? It would be good to add if not.
> Signed-off-by: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> include/linux/of.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 70c64ba..7f71221 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -30,6 +30,9 @@
> typedef u32 phandle;
> typedef u32 ihandle;
>
> +/* Maximum length of name of a property, including terminating null */
> +#define OF_PROP_NAME_MAXLEN 32
> +
> struct property {
> char *name;
> int length;
> --
> 1.7.9.5
>
--
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
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Frank Rowand @ 2014-02-19 21:37 UTC (permalink / raw)
To: Grant Likely
Cc: Sascha Hauer, Tim Bird, Olof Johansson, Jason Cooper, Rob Herring,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CACxGe6uhA6FMR76WJGVEt44x6bQOC=woCkDr6ZUH30hTd8f2wA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2/19/2014 1:15 PM, Grant Likely wrote:
> On Wed, Feb 19, 2014 at 8:16 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 2/19/2014 1:08 AM, Sascha Hauer wrote:
>>> On Tue, Feb 18, 2014 at 02:44:15PM -0800, Tim Bird wrote:
>>>> I'm not in favor of separating the device tree information from the kernel.
>>>>
>>>> If we switch, then whatever synchronization issues other projects
>>>> are having now with synching with the device tree info from the kernel will
>>>> just then become the problem of the kernel developers, who will then
>>>> have to sync with the device tree info from another repository. If the
>>>> sync issues can't be solved now for them, why or how would it be solved
>>>> post-separation for us? (It sounds like a zero-sum game of pain transfer
>>>> to me.)
>>>>
>>>> I'm relatively unfamiliar with the arguments. Can someone provide
>>>> a brief list of reasons this is needed, and how the inconvenience to Linux
>>>> kernel developers will be minimized, should it proceed?
>>>
>>
>>
>>> One of the reasons for doing devicetrees is to separate the hardware
>>> description from the code so that:
>>> - Other OSes (and bootloaders) can use the same description to start on
>>> a given hardware
>>> - A generic Kernel can be started on any hardware
>>> - A hardware describes itself, makes itself more introspecitve so we can
>>> go away from very specialized kernels
>>
>> Tim knows this ^^^^. He was asking for the arguments for moving dts files
>> out of the linux kernel source tree.
>
> We've made the decision that devicetree bindings need to be treated as
> ABI, but as long as the .dts files live in the kernel there will
> always be the temptation to just tweak things in lock-step and nobody
> will notice. Splitting the files out gives that extra push to think
> about whether changes to a binding will backwards compatible with a
> tree that doesn't have those changes because the chances are a lot
> higher that someone will hit that combination.
We have other ABI in the kernel. The maintainers have to develop a
spine if they are letting the supposed ABI changes occur they way
you suggest.
I thought that the actions flowing out of Edinburgh were supposed to
move us in the direction of developing the ABI mentality, and the
process to allow development and experimentation to occur (with a
clear label that they were not yet ABI) then a way to decide that
the development of a devicetree binding was complete enough to be
ABI.
>
> The other argument is shared source between
> BSD/U-Boot/Barebox/Linux/etc. Until we have a separate .dts repo there
> is no good way to share the database of hardware descriptions.
>
> g.
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] net: ethoc: document OF bindings
From: David Miller @ 2014-02-19 21:36 UTC (permalink / raw)
To: jcmvbkbc
Cc: netdev, devicetree, linux-kernel, grant.likely, robherring2,
sergei.shtylyov, f.fainelli
In-Reply-To: <1392763610-19197-1-git-send-email-jcmvbkbc@gmail.com>
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Wed, 19 Feb 2014 02:46:50 +0400
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Frank Rowand @ 2014-02-19 21:32 UTC (permalink / raw)
To: Rob Herring
Cc: Tim Bird, Olof Johansson, Jason Cooper, Sascha Hauer,
Grant Likely, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
Rob Landley, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAL_JsqJG+OXbT7sMiHV2dCx+nf--RidL8MmMd=dy6_gAa0yYcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2/19/2014 1:12 PM, Rob Herring wrote:
> On Tue, Feb 18, 2014 at 4:44 PM, Tim Bird <tbird20d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> I'm not in favor of separating the device tree information from the kernel.
>>
>> If we switch, then whatever synchronization issues other projects
>> are having now with synching with the device tree info from the kernel will
>> just then become the problem of the kernel developers, who will then
>> have to sync with the device tree info from another repository. If the
>> sync issues can't be solved now for them, why or how would it be solved
>> post-separation for us? (It sounds like a zero-sum game of pain transfer
>> to me.)
>>
>> I'm relatively unfamiliar with the arguments. Can someone provide
>> a brief list of reasons this is needed, and how the inconvenience to Linux
>> kernel developers will be minimized, should it proceed?
>
> - Primarily, other projects like u-boot, barebox, FreeBSD and possibly
> TianoCore (UEFI) are using DT now. Leaving them in the kernel will
> cause fragmentation. The statements about barebox needing to add
> barebox properties to the dtb is exactly the kind of fragmentation I'm
> worried about.
"Devicetree only describes the hardware" (paraphrasing a claim often made).
If the linux kernel dts files do not fully describe the hardware then it
is appropriate to add the missing info.
> - The need to share dts fragments across arches. This is a bit
> orthogonal, but this restructuring would be easier done outside the
> kernel tree. Restructuring everything in the kernel tree and then
> moving it out would be a lot of churn.
The churn will occur no matter what repository the files are in.
> - As we add schema checking, we need somewhere to put those.
And why does _that_ need to be in an external repository?
>
> One way to minimize the inconvenience is keep versioning and dev
> cycles in sync with the kernel. We could also start doing things to
> align the kernel workflow with how things will work when we do have a
> separate repository.
If you stay in sync with the kernel then you are still tied to the
linux kernel source repository. No gain.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: give priority to the compatible match in __of_match_node()
From: Paul Gortmaker @ 2014-02-19 21:23 UTC (permalink / raw)
To: Grant Likely, Rob Herring
Cc: Kevin Hao, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann, Chris Proctor, Stephen N Chivers, Rob Herring,
Scott Wood, linuxppc-dev, Sebastian Hesselbarth
In-Reply-To: <20140219204134.E4A2DC4088D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On 14-02-19 03:41 PM, Grant Likely wrote:
> On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> wrote:
>> On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> When the device node do have a compatible property, we definitely
>>>> prefer the compatible match besides the type and name. Only if
>>>> there is no such a match, we then consider the candidate which
>>>> doesn't have compatible entry but do match the type or name with
>>>> the device node.
>>>>
>>>> This is based on a patch from Sebastian Hesselbarth.
>>>> http://patchwork.ozlabs.org/patch/319434/
>>>>
>>>> I did some code refactoring and also fixed a bug in the original patch.
>>>
>>> I'm inclined to just revert this once again and avoid possibly
>>> breaking yet another platform.
>>
>> Well, for what it is worth, today's (Feb19th) linux-next tree fails to boot
>> on my sbc8548. It fails with:
>
> I think I've got it fixed now with the latest series. Please try the
> devicetree/merge branch on git://git.secretlab.ca/git/linux
That seems to work.
libphy: Freescale PowerQUICC MII Bus: probed
libphy: Freescale PowerQUICC MII Bus: probed
fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
TCP: cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
...
root@sbc8548:~# cat /proc/version
Linux version 3.14.0-rc3-00024-g7119f42057c6 (paul@yow-lpgnfs-02) (gcc version 4.5.2 (GCC) ) #1 Wed Feb 19 16:08:17 EST 2014
root@sbc8548:~#
Paul.
--
>
> g.
>
>> -----------------------------------------------
>> libphy: Freescale PowerQUICC MII Bus: probed
>> mdio_bus ethernet@e002400: /soc8548@e0000000/ethernet@24000/mdio@520
>> PHY address 1312 is too large
>> libphy: Freescale PowerQUICC MII Bus: probed
>> libphy: Freescale PowerQUICC MII Bus: probed
>> mdio_bus ethernet@e002500: /soc8548@e0000000/ethernet@25000/mdio@520
>> PHY address 1312 is too large
>> libphy: Freescale PowerQUICC MII Bus: probed
>> TCP: cubic registered
>> Initializing XFRM netlink socket
>> NET: Registered protocol family 17
>> <fail nfs mount>
>> -----------------------------------------------
>>
>> On a normal boot, we should see this:
>> -----------------------------------------------
>> libphy: Freescale PowerQUICC MII Bus: probed
>> libphy: Freescale PowerQUICC MII Bus: probed
>> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
>> fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
>> fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
>> fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
>> fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
>> fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
>> fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
>> fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
>> fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
>> fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
>> TCP: cubic registered
>> Initializing XFRM netlink socket
>> NET: Registered protocol family 17
>> -----------------------------------------------
>>
>>
>> Git bisect says:
>>
>> ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4 is the first bad commit
>> commit ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4
>> Author: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Tue Feb 18 15:57:30 2014 +0800
>>
>> of: reimplement the matching method for __of_match_node()
>>
>> In the current implementation of __of_match_node(), it will compare
>> each given match entry against all the node's compatible strings
>> with of_device_is_compatible().
>>
>> To achieve multiple compatible strings per node with ordering from
>> specific to generic, this requires given matches to be ordered from
>> specific to generic. For most of the drivers this is not true and
>> also an alphabetical ordering is more sane there.
>>
>> Therefore, we define a following priority order for the match, and
>> then scan all the entries to find the best match.
>> 1. specific compatible && type && name
>> 2. specific compatible && type
>> 3. specific compatible && name
>> 4. specific compatible
>> 5. general compatible && type && name
>> 6. general compatible && type
>> 7. general compatible && name
>> 8. general compatible
>> 9. type && name
>> 10. type
>> 11. name
>>
>> This is based on some pseudo-codes provided by Grant Likely.
>>
>> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> [grant.likely: Changed multiplier to 4 which makes more sense]
>> Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>
>> :040000 040000 8f5dd19174417aece63b308ff299a5dbe2efa5a0
>> 8401b0e3903e23e973845ee75b26b04345d803d2 M drivers
>>
>> As a double check, I checked out the head of linux-next, and did a
>> revert of the above commit, and my sbc8548 can then boot properly.
>>
>> Not doing anything fancy ; using the defconfig exactly as-is, and
>> ensuring the dtb is fresh from linux-next HEAD of today.
>>
>> Thanks,
>> Paul.
>> --
>>
>>>
>>> However, I think I would like to see this structured differently. We
>>> basically have 2 ways of matching: the existing pre-3.14 way and the
>>> desired match on best compatible only. All new bindings should match
>>> with the new way and the old way needs to be kept for compatibility.
>>> So lets structure the code that way. Search the match table first for
>>> best compatible with name and type NULL, then search the table the old
>>> way. I realize it appears you are doing this, but it is not clear this
>>> is the intent of the code. I would like to see this written as a patch
>>> with commit 105353145eafb3ea919 reverted first and you add a new match
>>> function to call first and then fallback to the existing function.
>>>
>>> Rob
>>>
>>>>
>>>> Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>> drivers/of/base.c | 55 +++++++++++++++++++++++++++++++++++++------------------
>>>> 1 file changed, 37 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>>> index ff85450d5683..9d655df458bd 100644
>>>> --- a/drivers/of/base.c
>>>> +++ b/drivers/of/base.c
>>>> @@ -730,32 +730,45 @@ out:
>>>> }
>>>> EXPORT_SYMBOL(of_find_node_with_property);
>>>>
>>>> +static int of_match_type_or_name(const struct device_node *node,
>>>> + const struct of_device_id *m)
>>>> +{
>>>> + int match = 1;
>>>> +
>>>> + if (m->name[0])
>>>> + match &= node->name && !strcmp(m->name, node->name);
>>>> +
>>>> + if (m->type[0])
>>>> + match &= node->type && !strcmp(m->type, node->type);
>>>> +
>>>> + return match;
>>>> +}
>>>> +
>>>> static
>>>> const struct of_device_id *__of_match_node(const struct of_device_id *matches,
>>>> const struct device_node *node)
>>>> {
>>>> const char *cp;
>>>> int cplen, l;
>>>> + const struct of_device_id *m;
>>>> + int match;
>>>>
>>>> if (!matches)
>>>> return NULL;
>>>>
>>>> cp = __of_get_property(node, "compatible", &cplen);
>>>> - do {
>>>> - const struct of_device_id *m = matches;
>>>> + while (cp && (cplen > 0)) {
>>>> + m = matches;
>>>>
>>>> /* Check against matches with current compatible string */
>>>> while (m->name[0] || m->type[0] || m->compatible[0]) {
>>>> - int match = 1;
>>>> - if (m->name[0])
>>>> - match &= node->name
>>>> - && !strcmp(m->name, node->name);
>>>> - if (m->type[0])
>>>> - match &= node->type
>>>> - && !strcmp(m->type, node->type);
>>>> - if (m->compatible[0])
>>>> - match &= cp
>>>> - && !of_compat_cmp(m->compatible, cp,
>>>> + if (!m->compatible[0]) {
>>>> + m++;
>>>> + continue;
>>>> + }
>>>> +
>>>> + match = of_match_type_or_name(node, m);
>>>> + match &= cp && !of_compat_cmp(m->compatible, cp,
>>>> strlen(m->compatible));
>>>> if (match)
>>>> return m;
>>>> @@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
>>>> }
>>>>
>>>> /* Get node's next compatible string */
>>>> - if (cp) {
>>>> - l = strlen(cp) + 1;
>>>> - cp += l;
>>>> - cplen -= l;
>>>> - }
>>>> - } while (cp && (cplen > 0));
>>>> + l = strlen(cp) + 1;
>>>> + cp += l;
>>>> + cplen -= l;
>>>> + }
>>>> +
>>>> + m = matches;
>>>> + /* Check against matches without compatible string */
>>>> + while (m->name[0] || m->type[0] || m->compatible[0]) {
>>>> + if (!m->compatible[0] && of_match_type_or_name(node, m))
>>>> + return m;
>>>> + m++;
>>>> + }
>>>>
>>>> return NULL;
>>>> }
>>>> --
>>>> 1.8.5.3
>>>>
>>>> --
>>>> 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
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
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
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Olof Johansson @ 2014-02-19 21:20 UTC (permalink / raw)
To: Rob Herring
Cc: Tim Bird, Jason Cooper, Sascha Hauer, Grant Likely, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAL_JsqJG+OXbT7sMiHV2dCx+nf--RidL8MmMd=dy6_gAa0yYcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> One way to minimize the inconvenience is keep versioning and dev
> cycles in sync with the kernel. We could also start doing things to
> align the kernel workflow with how things will work when we do have a
> separate repository.
I don't think aligning development cycles is what we want most here it
might be useful for us in Linux but it'll make things difficult for
other projects since they're not aware of our release cycles. The
device tree bindings and DT contents in that repo should be "always
stable", i.e. no merge window / rc concept. As soon as something goes
in it's live, and from then out only fixes to the DTS files (or
appending the binding).
For example, I don't want to have to track two trees to test against
-- I'll want to keep one repo of the very latest DT files and always
use those to boot any and all boards.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 1/4] DT: Vendor prefixes: Add ricoh, qnap, sii and synology
From: Rob Herring @ 2014-02-19 21:17 UTC (permalink / raw)
To: klightspeed-aslSrjg9ejhWX4hkXwHRhw
Cc: Andrew Lunn, Jason Cooper, Ian Campbell,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Pawel Moll, Mark Rutland, Kumar Gala
In-Reply-To: <1392840157-31072-2-git-send-email-klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org>
On Wed, Feb 19, 2014 at 2:02 PM, <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org> wrote:
> From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>
> The following patches make use of vendor names:
> * ricoh (Ricoh Co. Ltd.);
> * qnap (QNAP Systems, Inc.);
> * sii (Seiko Instruments, Inc.); and
> * synology (Synology, Inc.)
>
> Add them to the vendor prefix list.
>
> Signed-off-by: Ben Peddell <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org>
> Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> v2:
> Use stock ticker for Ricoh as vendor name
> s/Richoh/Ricoh/
>
> v5:
> Add vendor prefix for QNAP
>
> v6:
> Revert qnap vendor prefix change from v5
> Now properly based on -rc1
>
> v7:
> Revert ricoh vendor prefix change from v2
>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 3f900cd..4a52fa9 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -65,10 +65,12 @@ picochip Picochip Ltd
> powervr PowerVR (deprecated, use img)
> qca Qualcomm Atheros, Inc.
> qcom Qualcomm, Inc.
> +qnap QNAP Systems, Inc.
> ralink Mediatek/Ralink Technology Corp.
> ramtron Ramtron International
> realtek Realtek Semiconductor Corp.
> renesas Renesas Electronics Corporation
> +ricoh Ricoh Co. Ltd.
> rockchip Fuzhou Rockchip Electronics Co., Ltd
> samsung Samsung Semiconductor
> sbs Smart Battery System
> @@ -76,11 +78,13 @@ schindler Schindler
> sil Silicon Image
> silabs Silicon Laboratories
> simtek
> +sii Seiko Instruments, Inc.
> sirf SiRF Technology, Inc.
> snps Synopsys, Inc.
> st STMicroelectronics
> ste ST-Ericsson
> stericsson ST-Ericsson
> +synology Synology, Inc.
> ti Texas Instruments
> tlm Trusted Logic Mobility
> toshiba Toshiba Corporation
> --
> 1.8.3.2
>
--
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
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Grant Likely @ 2014-02-19 21:15 UTC (permalink / raw)
To: Frank Rowand
Cc: Sascha Hauer, Tim Bird, Olof Johansson, Jason Cooper, Rob Herring,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <53051102.8060801-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Feb 19, 2014 at 8:16 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 2/19/2014 1:08 AM, Sascha Hauer wrote:
>> On Tue, Feb 18, 2014 at 02:44:15PM -0800, Tim Bird wrote:
>>> I'm not in favor of separating the device tree information from the kernel.
>>>
>>> If we switch, then whatever synchronization issues other projects
>>> are having now with synching with the device tree info from the kernel will
>>> just then become the problem of the kernel developers, who will then
>>> have to sync with the device tree info from another repository. If the
>>> sync issues can't be solved now for them, why or how would it be solved
>>> post-separation for us? (It sounds like a zero-sum game of pain transfer
>>> to me.)
>>>
>>> I'm relatively unfamiliar with the arguments. Can someone provide
>>> a brief list of reasons this is needed, and how the inconvenience to Linux
>>> kernel developers will be minimized, should it proceed?
>>
>
>
>> One of the reasons for doing devicetrees is to separate the hardware
>> description from the code so that:
>> - Other OSes (and bootloaders) can use the same description to start on
>> a given hardware
>> - A generic Kernel can be started on any hardware
>> - A hardware describes itself, makes itself more introspecitve so we can
>> go away from very specialized kernels
>
> Tim knows this ^^^^. He was asking for the arguments for moving dts files
> out of the linux kernel source tree.
We've made the decision that devicetree bindings need to be treated as
ABI, but as long as the .dts files live in the kernel there will
always be the temptation to just tweak things in lock-step and nobody
will notice. Splitting the files out gives that extra push to think
about whether changes to a binding will backwards compatible with a
tree that doesn't have those changes because the chances are a lot
higher that someone will hit that combination.
The other argument is shared source between
BSD/U-Boot/Barebox/Linux/etc. Until we have a separate .dts repo there
is no good way to share the database of hardware descriptions.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Rob Herring @ 2014-02-19 21:12 UTC (permalink / raw)
To: Tim Bird
Cc: Olof Johansson, Jason Cooper, Sascha Hauer, Grant Likely,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+bK7J5+n2Se4cLv5WjR5B31ej7FdrGjPcjUULNrhb1UQ7=vmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Feb 18, 2014 at 4:44 PM, Tim Bird <tbird20d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I'm not in favor of separating the device tree information from the kernel.
>
> If we switch, then whatever synchronization issues other projects
> are having now with synching with the device tree info from the kernel will
> just then become the problem of the kernel developers, who will then
> have to sync with the device tree info from another repository. If the
> sync issues can't be solved now for them, why or how would it be solved
> post-separation for us? (It sounds like a zero-sum game of pain transfer
> to me.)
>
> I'm relatively unfamiliar with the arguments. Can someone provide
> a brief list of reasons this is needed, and how the inconvenience to Linux
> kernel developers will be minimized, should it proceed?
- Primarily, other projects like u-boot, barebox, FreeBSD and possibly
TianoCore (UEFI) are using DT now. Leaving them in the kernel will
cause fragmentation. The statements about barebox needing to add
barebox properties to the dtb is exactly the kind of fragmentation I'm
worried about.
- The need to share dts fragments across arches. This is a bit
orthogonal, but this restructuring would be easier done outside the
kernel tree. Restructuring everything in the kernel tree and then
moving it out would be a lot of churn.
- As we add schema checking, we need somewhere to put those.
One way to minimize the inconvenience is keep versioning and dev
cycles in sync with the kernel. We could also start doing things to
align the kernel workflow with how things will work when we do have a
separate repository.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Grant Likely @ 2014-02-19 21:09 UTC (permalink / raw)
To: Jason Cooper
Cc: Sascha Hauer, Rob Herring, Ian Campbell, Paweł Moll,
Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140218181854.GB7862-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Tue, Feb 18, 2014 at 6:18 PM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> On Tue, Feb 18, 2014 at 04:57:50PM +0100, Sascha Hauer wrote:
>> It will be interesting to see which rules should apply for merging new
>> bindings. I know that devicetrees should be OS agnostic, but sometimes
>> they are modelled after how Linux currently works. What happens when the
>> *BSD guys have different ideas how a good binding looks like? How will
>> such conflicts be resolved?
>
> That's more a question for Grant. I assume we'll all put on our big-boy
> pants and pick the best technical solution based on their merits. :)
I think you've answered it pretty competently.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: give priority to the compatible match in __of_match_node()
From: Grant Likely @ 2014-02-19 20:41 UTC (permalink / raw)
To: Paul Gortmaker, Rob Herring
Cc: Kevin Hao, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann, Chris Proctor, Stephen N Chivers, Rob Herring,
Scott Wood, linuxppc-dev, Sebastian Hesselbarth
In-Reply-To: <CAP=VYLr7hqnzW2HLS4GCMFeghCgPmrQZHYst+AUfZc_WNT-Wog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> wrote:
> On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> When the device node do have a compatible property, we definitely
> >> prefer the compatible match besides the type and name. Only if
> >> there is no such a match, we then consider the candidate which
> >> doesn't have compatible entry but do match the type or name with
> >> the device node.
> >>
> >> This is based on a patch from Sebastian Hesselbarth.
> >> http://patchwork.ozlabs.org/patch/319434/
> >>
> >> I did some code refactoring and also fixed a bug in the original patch.
> >
> > I'm inclined to just revert this once again and avoid possibly
> > breaking yet another platform.
>
> Well, for what it is worth, today's (Feb19th) linux-next tree fails to boot
> on my sbc8548. It fails with:
I think I've got it fixed now with the latest series. Please try the
devicetree/merge branch on git://git.secretlab.ca/git/linux
g.
> -----------------------------------------------
> libphy: Freescale PowerQUICC MII Bus: probed
> mdio_bus ethernet@e002400: /soc8548@e0000000/ethernet@24000/mdio@520
> PHY address 1312 is too large
> libphy: Freescale PowerQUICC MII Bus: probed
> libphy: Freescale PowerQUICC MII Bus: probed
> mdio_bus ethernet@e002500: /soc8548@e0000000/ethernet@25000/mdio@520
> PHY address 1312 is too large
> libphy: Freescale PowerQUICC MII Bus: probed
> TCP: cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
> <fail nfs mount>
> -----------------------------------------------
>
> On a normal boot, we should see this:
> -----------------------------------------------
> libphy: Freescale PowerQUICC MII Bus: probed
> libphy: Freescale PowerQUICC MII Bus: probed
> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4
> fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd
> fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled
> fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256
> fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256
> fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4
> fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd
> fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled
> fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256
> fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256
> TCP: cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
> -----------------------------------------------
>
>
> Git bisect says:
>
> ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4 is the first bad commit
> commit ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4
> Author: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Tue Feb 18 15:57:30 2014 +0800
>
> of: reimplement the matching method for __of_match_node()
>
> In the current implementation of __of_match_node(), it will compare
> each given match entry against all the node's compatible strings
> with of_device_is_compatible().
>
> To achieve multiple compatible strings per node with ordering from
> specific to generic, this requires given matches to be ordered from
> specific to generic. For most of the drivers this is not true and
> also an alphabetical ordering is more sane there.
>
> Therefore, we define a following priority order for the match, and
> then scan all the entries to find the best match.
> 1. specific compatible && type && name
> 2. specific compatible && type
> 3. specific compatible && name
> 4. specific compatible
> 5. general compatible && type && name
> 6. general compatible && type
> 7. general compatible && name
> 8. general compatible
> 9. type && name
> 10. type
> 11. name
>
> This is based on some pseudo-codes provided by Grant Likely.
>
> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> [grant.likely: Changed multiplier to 4 which makes more sense]
> Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> :040000 040000 8f5dd19174417aece63b308ff299a5dbe2efa5a0
> 8401b0e3903e23e973845ee75b26b04345d803d2 M drivers
>
> As a double check, I checked out the head of linux-next, and did a
> revert of the above commit, and my sbc8548 can then boot properly.
>
> Not doing anything fancy ; using the defconfig exactly as-is, and
> ensuring the dtb is fresh from linux-next HEAD of today.
>
> Thanks,
> Paul.
> --
>
> >
> > However, I think I would like to see this structured differently. We
> > basically have 2 ways of matching: the existing pre-3.14 way and the
> > desired match on best compatible only. All new bindings should match
> > with the new way and the old way needs to be kept for compatibility.
> > So lets structure the code that way. Search the match table first for
> > best compatible with name and type NULL, then search the table the old
> > way. I realize it appears you are doing this, but it is not clear this
> > is the intent of the code. I would like to see this written as a patch
> > with commit 105353145eafb3ea919 reverted first and you add a new match
> > function to call first and then fallback to the existing function.
> >
> > Rob
> >
> >>
> >> Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >> drivers/of/base.c | 55 +++++++++++++++++++++++++++++++++++++------------------
> >> 1 file changed, 37 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/of/base.c b/drivers/of/base.c
> >> index ff85450d5683..9d655df458bd 100644
> >> --- a/drivers/of/base.c
> >> +++ b/drivers/of/base.c
> >> @@ -730,32 +730,45 @@ out:
> >> }
> >> EXPORT_SYMBOL(of_find_node_with_property);
> >>
> >> +static int of_match_type_or_name(const struct device_node *node,
> >> + const struct of_device_id *m)
> >> +{
> >> + int match = 1;
> >> +
> >> + if (m->name[0])
> >> + match &= node->name && !strcmp(m->name, node->name);
> >> +
> >> + if (m->type[0])
> >> + match &= node->type && !strcmp(m->type, node->type);
> >> +
> >> + return match;
> >> +}
> >> +
> >> static
> >> const struct of_device_id *__of_match_node(const struct of_device_id *matches,
> >> const struct device_node *node)
> >> {
> >> const char *cp;
> >> int cplen, l;
> >> + const struct of_device_id *m;
> >> + int match;
> >>
> >> if (!matches)
> >> return NULL;
> >>
> >> cp = __of_get_property(node, "compatible", &cplen);
> >> - do {
> >> - const struct of_device_id *m = matches;
> >> + while (cp && (cplen > 0)) {
> >> + m = matches;
> >>
> >> /* Check against matches with current compatible string */
> >> while (m->name[0] || m->type[0] || m->compatible[0]) {
> >> - int match = 1;
> >> - if (m->name[0])
> >> - match &= node->name
> >> - && !strcmp(m->name, node->name);
> >> - if (m->type[0])
> >> - match &= node->type
> >> - && !strcmp(m->type, node->type);
> >> - if (m->compatible[0])
> >> - match &= cp
> >> - && !of_compat_cmp(m->compatible, cp,
> >> + if (!m->compatible[0]) {
> >> + m++;
> >> + continue;
> >> + }
> >> +
> >> + match = of_match_type_or_name(node, m);
> >> + match &= cp && !of_compat_cmp(m->compatible, cp,
> >> strlen(m->compatible));
> >> if (match)
> >> return m;
> >> @@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
> >> }
> >>
> >> /* Get node's next compatible string */
> >> - if (cp) {
> >> - l = strlen(cp) + 1;
> >> - cp += l;
> >> - cplen -= l;
> >> - }
> >> - } while (cp && (cplen > 0));
> >> + l = strlen(cp) + 1;
> >> + cp += l;
> >> + cplen -= l;
> >> + }
> >> +
> >> + m = matches;
> >> + /* Check against matches without compatible string */
> >> + while (m->name[0] || m->type[0] || m->compatible[0]) {
> >> + if (!m->compatible[0] && of_match_type_or_name(node, m))
> >> + return m;
> >> + m++;
> >> + }
> >>
> >> return NULL;
> >> }
> >> --
> >> 1.8.5.3
> >>
> >> --
> >> 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
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Warner Losh @ 2014-02-19 20:28 UTC (permalink / raw)
To: Jason Cooper
Cc: Frank Rowand, Sascha Hauer, Grant Likely, Rob Herring,
Ian Campbell, pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
galak-sgV2jX0FEOL9JmXXK+q4OQ, rob-VoJi6FS/r0vR7s880joybQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140219184626.GP7862-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Feb 19, 2014, at 11:46 AM, Jason Cooper wrote:
> I think the long term health of the devicetree would benefit greatly
> from being more detached than it currently is. It would force everyone
> to "Pay the bills".
>
> The time might not be right now, and it probably will take one of the
> more gradual forms Olof suggested. But I think it should happen at some
> point to help it grow up.
>
> And we still have the short term problem of facilitating other projects
> use of the devicetree. Which can only make it more robust and accepted
> by default.
I know it would be easier to import new device tree files into FreeBSD, and
support the latest version of the spec if there was a clean way of doing so.
Right now, with the files comingled with other files in the Linux tree it is harder
to do so than if they were stand-alone. Especially if the compiler could also
come from a near-by place.
Warner
P.S. I've been championing the use of fdt in FreeBSD for a few years now. I
am presently converting over all our Atmel support to use fdt, as well as
championing cross-SoC and cross-architecture use of fdt + gpio, fdt + i2c, etc.
Just so you know who I am, in case the name in unfamiliar to you...--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
From: Sergei Shtylyov @ 2014-02-19 20:24 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Peter Chen, Grant Likely, Rob Herring, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392824921.17130.71.camel@iivanov-dev>
Hello.
On 02/19/2014 06:48 PM, Ivan T. Ivanov wrote:
>>>>> From: "Ivan T. Ivanov" <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
>>>>> Allows controller to be specified via device tree.
>>>>> Pass PHY phandle specified in DT to core driver.
>>>>> Signed-off-by: Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
>>>>> ---
>>>>> drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++++++++++++++++++++++-
>>>>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>>> You also need to describe the binding you're creating in
>>>> Documentation/devicetree/bindings/usb/<file>.txt.
>>> Did you check "[PATCH v2 1/3]"?
>> Did you send it to 'linux-usb'?
> Opps, sorry. get_maintainer.pl did not list linux-usb and I forgot
> to add it. Would like to resend it?
I guess so, since the binding document would go in thru the USB tree
anyway, IIUC.
> Regards,
> Ivan
WBR, Sergei
--
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
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Warner Losh @ 2014-02-19 20:23 UTC (permalink / raw)
To: Jason Cooper
Cc: Olof Johansson, Sascha Hauer, Grant Likely, Rob Herring,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140219183221.GO7862-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Feb 19, 2014, at 11:32 AM, Jason Cooper wrote:
> On Tue, Feb 18, 2014 at 11:47:56AM -0800, Olof Johansson wrote:
>> On Tue, Feb 18, 2014 at 10:18 AM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
>> I think we have two options:
>>
>> 1. Bring out everything in the current kernel repo to a separate one,
>> but do it my mirroring over. Changes go into the kernel repo first and
>> then comes over to this one, but other projects can mirror the
>> standalone repo without downloading a whole kernel tree.
>
> I prefer this one. Assuming that a separate repo is mostly agreed upon,
> this allows us to provide the tree in an easily digestible way without
> impacting the current workflow.
>
> Also, if it works for the other projects, no one says we have to move
> beyond this step.
I just joined this list... What's the scope of what would move into the new
repo? The dts files with the binding docs, or also the code to implement
those bindings?
Warner
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of_mdio: fix phy interrupt passing
From: Sergei Shtylyov @ 2014-02-19 20:18 UTC (permalink / raw)
To: Florian Fainelli, Ben Dooks
Cc: Grant Likely, linux-kernel, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev, Linux-sh list
In-Reply-To: <CAGVrzcZGW05uNj75VG7w4iSGre4OzEMhHedQfaynekrbhP4NLQ@mail.gmail.com>
Hello.
On 02/17/2014 08:48 PM, Florian Fainelli wrote:
>>>> The of_mdiobus_register_phy() is not setting phy->irq this causing
>>>> some drivers to incorrectly assume that the PHY does not have an
>>>> IRQ associated with it or install an interrupt handler for the
>>>> PHY.
>>>> Simplify the code setting irq and set the phy->irq at the same
>>>> time so that the case if mdio->irq is not NULL is easier to read.
>>> The real bug fix, which is not properly explained here, is that
>>> irq_of_parse_and_map() should return values > 0 when the interrupt is
>>> valid, so this makes me wonder why we are not propagating the return
>>> value from irq_of_parse_and_map() in case the call to
>>> of_irq_parse_one() does return something non-zero?
>> No, the first issue is phy->dev never gets set, which causes the
>> issue. The cleanup was added as it seemed easier to put it in with
>> this.
> Ok, that really needs to be mentioned in the commit message, even
> being quite familiar (and possibly dumb too) with the code, I could
> not figure this out by reading your patch.
Yes, the main issue was that phy->irq wasn't overridden from the value set
by phy_device_create().
>> I think phy->irq is already initialised to PHY_POLL and thus there
>> is no need to set phy->irq if the irq_of_parse_and_map() fails.
> That is correct, the reason why I introduced 7d97637 ("net: of_mdio:
> do not overwrite PHY interrupt configuration") was that you are also
> allowed to change the irq type before calling into
> of_mdiobus_register(),
Not really: of_mdiobus_register() init's all of mdio->irq[] with IRQ_POLL,
thus wiping out all of the previous initialization, so I don't know what you
did achieve with the aforementioned commit.
> so we want to preserve other irq values being
> set here, such as PHY_IGNORE_INTERRUPT. Your patch does take care of
> that since it only overrides the irq in case we could parse it.
And it should have stayed that way. The latter change was unnecessary.
WBR, Sergei
^ permalink raw reply
* Re: devicetree repository separation/migration
From: Frank Rowand @ 2014-02-19 20:18 UTC (permalink / raw)
To: Jason Cooper
Cc: Sascha Hauer, Grant Likely, Rob Herring, Ian Campbell,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
galak-sgV2jX0FEOL9JmXXK+q4OQ, rob-VoJi6FS/r0vR7s880joybQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140219184626.GP7862-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On 2/19/2014 10:46 AM, Jason Cooper wrote:
> On Tue, Feb 18, 2014 at 02:14:51PM -0800, Frank Rowand wrote:
>> On 2/18/2014 10:18 AM, Jason Cooper wrote:
>>> On Tue, Feb 18, 2014 at 04:57:50PM +0100, Sascha Hauer wrote:
>>>> On Mon, Feb 17, 2014 at 01:05:44PM -0500, Jason Cooper wrote:
>>> ...
>>>>> - Is the Linux development workflow ready for devicetree to move out
>>>>> of the Linux Kernel?
>>>>
>>>> I hope so since keeping the devicetrees in sync with the kernel is a
>>>> pain for all external users.
>>>
>>> Well, I haven't heard any screams yet. I suspect people are waiting for
>>> details on the exact form it would take before complaining...
>>
>> < snip >
>>
>> Let me join the chorus of screams.
>>
>> I would venture that the number of linux kernel developers actively
>> touching device tree source files (and impacted by changes to them)
>> is vastly larger than any other set of developers.
>>
>> My experience in the kernel is already that finding working device
>> tree fragments that match current under development code is difficult.
>> (I am not trying to generalize for all systems, just the ones I use.)
>>
>> Moving the device tree source files out of the kernel git tree will
>> only make things worse.
>
> Having written/applied a significant portion of the arm devicetree files
> for several SoCs over the past couple of years, I share your concern.
> The reason I bring this up is because I keep seeing the little churn
> here and there because we _can_.
>
> I find it very similar to a teenager reaching adulthood. At a certain
> point, the parents have to say "Get out, get a job, get your own place."
> It's hard for all parties involved, but it's the best thing for the
> young adult in the long run. There's no substitute for living on your
> own and paying bills.
That is not exactly a technical reason (the teenager explanation).
>
> I think the long term health of the devicetree would benefit greatly
> from being more detached than it currently is. It would force everyone
> to "Pay the bills".
>
> The time might not be right now, and it probably will take one of the
> more gradual forms Olof suggested. But I think it should happen at some
> point to help it grow up.
>
> And we still have the short term problem of facilitating other projects
> use of the devicetree. Which can only make it more robust and accepted
> by default.
I am predicting increased pain for little gain if the dts files move out
of the linux kernel repository.
-Frnak
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox