Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

[Warner Losh]

On Mon, Sep 12, 2016 at 10:29 AM, Sebastian Frias <s...@laposte.net> wrote:
> Hi Warner,
>
> On 09/12/2016 04:26 PM, Warner Losh wrote:
>> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland <mark.rutl...@arm.com> wrote:
>>>> Since the question seems understood, do you have an example of other SoC's
>>>> doing something similar?
>>>
>>> I do not have an example. I know that others are using DT for data
>>> beyond what Linux or another OS requires, but it's my understanding that
>>> that is typically in a separate DTB.
>>
>> Just to clarify: FreeBSD uses, for the most part, the DTB's that the
>> 'vendor' ships, which is quite often the same ones included in Linux.
>> There's some exceptions where the bindings weren't really hardware
>> independent, or where the abstraction model was really Linux specific
>> (for things like the HDMI stack).
>>
>> However, with the advent of overlays, one would think that a vendor
>> could easily include an overlay with the DTB data for the devices they
>> don't wish to, or cannot for other reasons release. It seems like the
>> perfect mechanism to comply with the rules about inclusion of nodes in
>> the DTS. Vendors are free to document these nodes and don't require
>> the Linux kernel include them in the Documents directory to do so.
>> There have been recent efforts to move this documentation to a third
>> party to maintain.
>
> This is very interesting, do you have a more concrete example of such
> usage?

Using overlays to layer in a proprietary device blob for a proprietary driver?
No. I don't. It just seems like a natural solution. Do I have more examples
where FreeBSD has to deviate because the DT is actually Linux
specific and does a poor job of modeling the hardware and instead
reflects the Linux driver model? I have plenty of those...

Warner

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

[Warner Losh]

On Mon, Sep 12, 2016 at 10:29 AM, Sebastian Frias  wrote:
> Hi Warner,
>
> On 09/12/2016 04:26 PM, Warner Losh wrote:
>> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland  wrote:
>>>> Since the question seems understood, do you have an example of other SoC's
>>>> doing something similar?
>>>
>>> I do not have an example. I know that others are using DT for data
>>> beyond what Linux or another OS requires, but it's my understanding that
>>> that is typically in a separate DTB.
>>
>> Just to clarify: FreeBSD uses, for the most part, the DTB's that the
>> 'vendor' ships, which is quite often the same ones included in Linux.
>> There's some exceptions where the bindings weren't really hardware
>> independent, or where the abstraction model was really Linux specific
>> (for things like the HDMI stack).
>>
>> However, with the advent of overlays, one would think that a vendor
>> could easily include an overlay with the DTB data for the devices they
>> don't wish to, or cannot for other reasons release. It seems like the
>> perfect mechanism to comply with the rules about inclusion of nodes in
>> the DTS. Vendors are free to document these nodes and don't require
>> the Linux kernel include them in the Documents directory to do so.
>> There have been recent efforts to move this documentation to a third
>> party to maintain.
>
> This is very interesting, do you have a more concrete example of such
> usage?

Using overlays to layer in a proprietary device blob for a proprietary driver?
No. I don't. It just seems like a natural solution. Do I have more examples
where FreeBSD has to deviate because the DT is actually Linux
specific and does a poor job of modeling the hardware and instead
reflects the Linux driver model? I have plenty of those...

Warner

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

[Warner Losh]

On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland  wrote:
>> Since the question seems understood, do you have an example of other SoC's
>> doing something similar?
>
> I do not have an example. I know that others are using DT for data
> beyond what Linux or another OS requires, but it's my understanding that
> that is typically in a separate DTB.

Just to clarify: FreeBSD uses, for the most part, the DTB's that the
'vendor' ships, which is quite often the same ones included in Linux.
There's some exceptions where the bindings weren't really hardware
independent, or where the abstraction model was really Linux specific
(for things like the HDMI stack).

However, with the advent of overlays, one would think that a vendor
could easily include an overlay with the DTB data for the devices they
don't wish to, or cannot for other reasons release. It seems like the
perfect mechanism to comply with the rules about inclusion of nodes in
the DTS. Vendors are free to document these nodes and don't require
the Linux kernel include them in the Documents directory to do so.
There have been recent efforts to move this documentation to a third
party to maintain.

Warner

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

[Warner Losh]

On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland  wrote:
>> Since the question seems understood, do you have an example of other SoC's
>> doing something similar?
>
> I do not have an example. I know that others are using DT for data
> beyond what Linux or another OS requires, but it's my understanding that
> that is typically in a separate DTB.

Just to clarify: FreeBSD uses, for the most part, the DTB's that the
'vendor' ships, which is quite often the same ones included in Linux.
There's some exceptions where the bindings weren't really hardware
independent, or where the abstraction model was really Linux specific
(for things like the HDMI stack).

However, with the advent of overlays, one would think that a vendor
could easily include an overlay with the DTB data for the devices they
don't wish to, or cannot for other reasons release. It seems like the
perfect mechanism to comply with the rules about inclusion of nodes in
the DTS. Vendors are free to document these nodes and don't require
the Linux kernel include them in the Documents directory to do so.
There have been recent efforts to move this documentation to a third
party to maintain.

Warner

Re: Device Tree Blob (DTB) licence

[Warner Losh]

> On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes  
> wrote:
> 
>> not true, with a proprietary bios it's a clear "pay this much money and don't
>> worry about it" while with GPL there's a nagging fear that someone you never
>> heard of may sue you a decade from now claiming you need to give them the 
>> source
>> to your OS.
> 
> Not really no - the number of companies who bought proprietary products,
> resold them and then got sued because their supplier was cavalier is
> huge.

I follow the suits pretty closely, and the number is tiny. There’s a huge hue
and cry, sure. But the number is small compared to the offenses. And the 
outcomes
aren’t always what one would hope. The big guys with staying power care.
The rest are hit or miss.

>> note, this whole discussion assumes that the DTB is even copyrightable. Since
>> it's intended to be strictly a functional description of what the hardware is
>> able to do, that could be questioned
> 
> I imagine you can write a DTB that is copyrightable and one that isn't.
> 
> However this is all missing one important point. Whoever wrote their DTB
> gets to decide how they license it. It's nobody else's business.

Actually it is other people’s business. There’s no harm in asking for a license
that would help the whole ecosystem.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Device Tree Blob (DTB) licence

[Warner Losh]

 On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk 
 wrote:
 
 not true, with a proprietary bios it's a clear pay this much money and don't
 worry about it while with GPL there's a nagging fear that someone you never
 heard of may sue you a decade from now claiming you need to give them the 
 source
 to your OS.
 
 Not really no - the number of companies who bought proprietary products,
 resold them and then got sued because their supplier was cavalier is
 huge.

I follow the suits pretty closely, and the number is tiny. There’s a huge hue
and cry, sure. But the number is small compared to the offenses. And the 
outcomes
aren’t always what one would hope. The big guys with staying power care.
The rest are hit or miss.

 note, this whole discussion assumes that the DTB is even copyrightable. Since
 it's intended to be strictly a functional description of what the hardware is
 able to do, that could be questioned
 
 I imagine you can write a DTB that is copyrightable and one that isn't.
 
 However this is all missing one important point. Whoever wrote their DTB
 gets to decide how they license it. It's nobody else's business.

Actually it is other people’s business. There’s no harm in asking for a license
that would help the whole ecosystem.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Device Tree Blob (DTB) licence

[Warner Losh]

> On May 30, 2015, at 1:59 PM, Jeroen Hofstee  wrote:
> 
> Hi,
> 
> On 22-05-15 12:05, Yann Droneaud wrote:
>> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud 
>>> wrote:
 I believe Device Tree Blob (.dtb file) built from kernel's Device
 Tree
 Sources (.dts, which #include .dtsi, which #include .h) using
 Device
 Tree Compiler (dtc) are covered by GNU General Public Licence v2
 (GPLv2), but cannot find any reference.
>>> By default yes, but we've been steering people to dual license them
>>> GPL/BSD.
>>> 
>> 
> 
> obviously these files should be reusable. If there is a license issue
> with that it should be fixed. cc-ing freebsd-...@freebsd.org.

FreeBSD segregates the files that its contributors have written and
are under BSDL from those that are received from upstream and
may be under BSDL+GPL or just GPL in its source tree.

The source is shipped, the binaries are not, at least by the FreeBSD
project. The FreeBSD project used to create its own custom dts
files that were incompatible with anything except FreeBSD. However,
apart from a few stragglers, we’ve converted all our supported platforms
to using the ‘vendor supplied’ dts files, which means we follow the
documented conventions found in Linux, as well as many of the
strange Linuxisms that seep into this or that .dts file. Following the
standard here and accepting some potentially GPLd code into the
tree given its limited scope and already segregated nature.

It is an open question to what extent the mere-aggregation clause
would apply to the typical use of placing the dtb into a filesystem
that u-boot then passes along applies. And if that same reasoning
applies to a binary bundle containing both the kernel and the dtb
file. It’s also an open question the extent to which copyright applies
to the dts files since they are, in theory at least, just an expression of
facts and there’s generally only one way to correctly express those
facts in a dts file. The GPL’d files aren’t stopping anybody from creating
proprietary software. People that really care will rewrite the files
from scratch anyway. People that don’t care.. well, one need look
no further than the difficulty of getting source code to different SoC
support packages for the kernel in the Android world to see how
much some people care about GPL compliance and how much
it really stops them from doing what they want.

Than again, I’m not a lawyer, and this isn’t legal advice.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Device Tree Blob (DTB) licence

[Warner Losh]

 On May 30, 2015, at 1:59 PM, Jeroen Hofstee linux-...@myspectrum.nl wrote:
 
 Hi,
 
 On 22-05-15 12:05, Yann Droneaud wrote:
 Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
 On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud ydrone...@opteya.com
 wrote:
 I believe Device Tree Blob (.dtb file) built from kernel's Device
 Tree
 Sources (.dts, which #include .dtsi, which #include .h) using
 Device
 Tree Compiler (dtc) are covered by GNU General Public Licence v2
 (GPLv2), but cannot find any reference.
 By default yes, but we've been steering people to dual license them
 GPL/BSD.
 
 
 
 obviously these files should be reusable. If there is a license issue
 with that it should be fixed. cc-ing freebsd-...@freebsd.org.

FreeBSD segregates the files that its contributors have written and
are under BSDL from those that are received from upstream and
may be under BSDL+GPL or just GPL in its source tree.

The source is shipped, the binaries are not, at least by the FreeBSD
project. The FreeBSD project used to create its own custom dts
files that were incompatible with anything except FreeBSD. However,
apart from a few stragglers, we’ve converted all our supported platforms
to using the ‘vendor supplied’ dts files, which means we follow the
documented conventions found in Linux, as well as many of the
strange Linuxisms that seep into this or that .dts file. Following the
standard here and accepting some potentially GPLd code into the
tree given its limited scope and already segregated nature.

It is an open question to what extent the mere-aggregation clause
would apply to the typical use of placing the dtb into a filesystem
that u-boot then passes along applies. And if that same reasoning
applies to a binary bundle containing both the kernel and the dtb
file. It’s also an open question the extent to which copyright applies
to the dts files since they are, in theory at least, just an expression of
facts and there’s generally only one way to correctly express those
facts in a dts file. The GPL’d files aren’t stopping anybody from creating
proprietary software. People that really care will rewrite the files
from scratch anyway. People that don’t care.. well, one need look
no further than the difficulty of getting source code to different SoC
support packages for the kernel in the Android world to see how
much some people care about GPL compliance and how much
it really stops them from doing what they want.

Than again, I’m not a lawyer, and this isn’t legal advice.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH 2/3] mtd: davinci-nand: add dts property for NAND_NO_SUBPAGE_WRITE option

[Warner Losh]

On Mar 20, 2014, at 12:02 PM, Santosh Shilimkar  
wrote:

> On Thursday 20 March 2014 01:44 PM, Warner Losh wrote:
>> 
>> On Mar 20, 2014, at 11:37 AM, Santosh Shilimkar  
>> wrote:
>> 
>>> 
>>> 
>>> On Thursday 20 March 2014 01:29 PM, Brian Norris wrote:
>>>> On Thu, Mar 20, 2014 at 01:12:35PM -0400, Santosh Shilimkar wrote:
>>>>> Boris,
>>>> 
>>>> Who's Boris? And why should Boris be taking this patch? It's an MTD
>>>> patch.
>>>> 
>>> I got your name completely wrong. Sorry
>>> 
>>>>> On Thursday 20 March 2014 01:06 PM, Ivan Khoronzhuk wrote:
>>>>>> From: Murali Karicheri 
>>>>>> 
>>>>>> After testing NAND flash with ubifs for k2hk-emv board were committed
>>>>>> that flash doesn't support subpage writing, so we can fix it by
>>>>>> adding a property to disable subpage write.
>>>> 
>>>> What flash? We try to autodetect NAND as much as possible. Perhaps we
>>>> should be adding infrastructure support instead of hacking it with a DT
>>>> property.
>>>> 
>>> We can't auto detect it and thats why the DT approach was taken. We
>>> will double check that.
>> 
>> I though sub page writing was one of the fields in the onfi and/or 
>> jedec(toggle) meta data structures. Have you looked there?
>> 
> Am not sure if I follow you. The limitation is from the TI NAND 
> controller(AEMIF) and
> not the NAND memory. 

Then never mind. I thought it was the other side of things.

Warner--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mtd: davinci-nand: add dts property for NAND_NO_SUBPAGE_WRITE option

[Warner Losh]

On Mar 20, 2014, at 11:37 AM, Santosh Shilimkar  
wrote:

> 
> 
> On Thursday 20 March 2014 01:29 PM, Brian Norris wrote:
>> On Thu, Mar 20, 2014 at 01:12:35PM -0400, Santosh Shilimkar wrote:
>>> Boris,
>> 
>> Who's Boris? And why should Boris be taking this patch? It's an MTD
>> patch.
>> 
> I got your name completely wrong. Sorry
> 
>>> On Thursday 20 March 2014 01:06 PM, Ivan Khoronzhuk wrote:
 From: Murali Karicheri 
 
 After testing NAND flash with ubifs for k2hk-emv board were committed
 that flash doesn't support subpage writing, so we can fix it by
 adding a property to disable subpage write.
>> 
>> What flash? We try to autodetect NAND as much as possible. Perhaps we
>> should be adding infrastructure support instead of hacking it with a DT
>> property.
>> 
> We can't auto detect it and thats why the DT approach was taken. We
> will double check that.

I though sub page writing was one of the fields in the onfi and/or 
jedec(toggle) meta data structures. Have you looked there?

Warner

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mtd: davinci-nand: add dts property for NAND_NO_SUBPAGE_WRITE option

[Warner Losh]

On Mar 20, 2014, at 11:37 AM, Santosh Shilimkar santosh.shilim...@ti.com 
wrote:

 
 
 On Thursday 20 March 2014 01:29 PM, Brian Norris wrote:
 On Thu, Mar 20, 2014 at 01:12:35PM -0400, Santosh Shilimkar wrote:
 Boris,
 
 Who's Boris? And why should Boris be taking this patch? It's an MTD
 patch.
 
 I got your name completely wrong. Sorry
 
 On Thursday 20 March 2014 01:06 PM, Ivan Khoronzhuk wrote:
 From: Murali Karicheri m-kariche...@ti.com
 
 After testing NAND flash with ubifs for k2hk-emv board were committed
 that flash doesn't support subpage writing, so we can fix it by
 adding a property to disable subpage write.
 
 What flash? We try to autodetect NAND as much as possible. Perhaps we
 should be adding infrastructure support instead of hacking it with a DT
 property.
 
 We can't auto detect it and thats why the DT approach was taken. We
 will double check that.

I though sub page writing was one of the fields in the onfi and/or 
jedec(toggle) meta data structures. Have you looked there?

Warner

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mtd: davinci-nand: add dts property for NAND_NO_SUBPAGE_WRITE option

[Warner Losh]

On Mar 20, 2014, at 12:02 PM, Santosh Shilimkar santosh.shilim...@ti.com 
wrote:

 On Thursday 20 March 2014 01:44 PM, Warner Losh wrote:
 
 On Mar 20, 2014, at 11:37 AM, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 
 
 
 On Thursday 20 March 2014 01:29 PM, Brian Norris wrote:
 On Thu, Mar 20, 2014 at 01:12:35PM -0400, Santosh Shilimkar wrote:
 Boris,
 
 Who's Boris? And why should Boris be taking this patch? It's an MTD
 patch.
 
 I got your name completely wrong. Sorry
 
 On Thursday 20 March 2014 01:06 PM, Ivan Khoronzhuk wrote:
 From: Murali Karicheri m-kariche...@ti.com
 
 After testing NAND flash with ubifs for k2hk-emv board were committed
 that flash doesn't support subpage writing, so we can fix it by
 adding a property to disable subpage write.
 
 What flash? We try to autodetect NAND as much as possible. Perhaps we
 should be adding infrastructure support instead of hacking it with a DT
 property.
 
 We can't auto detect it and thats why the DT approach was taken. We
 will double check that.
 
 I though sub page writing was one of the fields in the onfi and/or 
 jedec(toggle) meta data structures. Have you looked there?
 
 Am not sure if I follow you. The limitation is from the TI NAND 
 controller(AEMIF) and
 not the NAND memory. 

Then never mind. I thought it was the other side of things.

Warner--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 04/14] mtd: nand: define struct nand_timings

[Warner Losh]

On Mar 12, 2014, at 1:07 PM, Jason Gunthorpe  
wrote:

> On Wed, Mar 12, 2014 at 05:46:53PM +0100, Boris BREZILLON wrote:
>> I'm not a big fan of this name. I think timing structs should not
>> contain onfi in their names, because these timings are also
>> available on non ONFI chips.
> 
> Explicitly defering to the ONFI spec makes it clear what the
> definition of the timing parameter actually is.

This is good, since ONFI is a very public spec.

> If JEDEC has a different model then drivers will need to configure
> their interfaces a little differently.

JEDEC’s spec is just a public as ONFI’s, but in the past at least it has been 
difficult
to get without purchase.

> So we might end up with a jedec_sdr_timings too :|

And onfi_ddr_timings and jedec_ddr_timings since those timing modes are 
appearing
on shipping parts.

Warner

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/9] of: mtd: add documentation for the ONFI NAND timing mode property

[Warner Losh]

On Mar 12, 2014, at 12:07 PM, Boris BREZILLON  wrote:

> Add documentation for the ONFI NAND timing mode property.

I don’t see a Toggle/JEDEC mode timing property. Will that be defined for 
Toshiba, Samsung
and San Disk flash? Or will this be limited to Micron, Intel and Hynix (the 
only ones
supporting ONFI)?

Warner


> Signed-off-by: Boris BREZILLON 
> ---
> Documentation/devicetree/bindings/mtd/nand.txt |8 
> 1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt 
> b/Documentation/devicetree/bindings/mtd/nand.txt
> index b53f92e..2046027 100644
> --- a/Documentation/devicetree/bindings/mtd/nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> @@ -19,3 +19,11 @@ errors per {size} bytes".
> The interpretation of these parameters is implementation-defined, so not all
> implementations must support all possible combinations. However, 
> implementations
> are encouraged to further specify the value(s) they support.
> +
> +- onfi,nand-timing-mode: an integer encoding the supported ONFI timing modes 
> of
> +  the NAND chip. Each supported mode is represented as a bit position (i.e. :
> +  mode 0 and 1 => (1 << 0) | (1 << 1) = 0x3).
> +  This is only used when the chip does not support the ONFI standard.
> +  The last bit set represent the closest mode fulfilling the NAND chip 
> timings.
> +  For a full description of the different timing modes see this document:
> +  www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/9] of: mtd: add documentation for the ONFI NAND timing mode property

[Warner Losh]

On Mar 12, 2014, at 12:07 PM, Boris BREZILLON b.brezillon@gmail.com wrote:

 Add documentation for the ONFI NAND timing mode property.

I don’t see a Toggle/JEDEC mode timing property. Will that be defined for 
Toshiba, Samsung
and San Disk flash? Or will this be limited to Micron, Intel and Hynix (the 
only ones
supporting ONFI)?

Warner


 Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
 ---
 Documentation/devicetree/bindings/mtd/nand.txt |8 
 1 file changed, 8 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/mtd/nand.txt 
 b/Documentation/devicetree/bindings/mtd/nand.txt
 index b53f92e..2046027 100644
 --- a/Documentation/devicetree/bindings/mtd/nand.txt
 +++ b/Documentation/devicetree/bindings/mtd/nand.txt
 @@ -19,3 +19,11 @@ errors per {size} bytes.
 The interpretation of these parameters is implementation-defined, so not all
 implementations must support all possible combinations. However, 
 implementations
 are encouraged to further specify the value(s) they support.
 +
 +- onfi,nand-timing-mode: an integer encoding the supported ONFI timing modes 
 of
 +  the NAND chip. Each supported mode is represented as a bit position (i.e. :
 +  mode 0 and 1 = (1  0) | (1  1) = 0x3).
 +  This is only used when the chip does not support the ONFI standard.
 +  The last bit set represent the closest mode fulfilling the NAND chip 
 timings.
 +  For a full description of the different timing modes see this document:
 +  www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf
 -- 
 1.7.9.5
 
 --
 To unsubscribe from this list: send the line unsubscribe devicetree in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 04/14] mtd: nand: define struct nand_timings

[Warner Losh]

On Mar 12, 2014, at 1:07 PM, Jason Gunthorpe jguntho...@obsidianresearch.com 
wrote:

 On Wed, Mar 12, 2014 at 05:46:53PM +0100, Boris BREZILLON wrote:
 I'm not a big fan of this name. I think timing structs should not
 contain onfi in their names, because these timings are also
 available on non ONFI chips.
 
 Explicitly defering to the ONFI spec makes it clear what the
 definition of the timing parameter actually is.

This is good, since ONFI is a very public spec.

 If JEDEC has a different model then drivers will need to configure
 their interfaces a little differently.

JEDEC’s spec is just a public as ONFI’s, but in the past at least it has been 
difficult
to get without purchase.

 So we might end up with a jedec_sdr_timings too :|

And onfi_ddr_timings and jedec_ddr_timings since those timing modes are 
appearing
on shipping parts.

Warner

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 10, 2012, at 1:24 AM, David Gibson wrote:

> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
>> 
>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
>> 
>>> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>>>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>>>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>>>>> 
>>>>>>> What more do you think needs discussion re: dtc+cpp?
>>>>>> 
>>>>>> How not to abuse the ever-loving shit out of it? :-)
>>>>> 
>>>>> Perhaps we can just handle this through the regular patch review
>>>>> process; I think it may be difficult to define and agree upon exactly
>>>>> what "abuse" means ahead of time, but it's probably going to be easy
>>>>> enough to recognize it when one sees it?
>>>> One of the ways it could get out of hand would be via "include
>>>> dependency hell".  People will be tempted to reuse existing .h files
>>>> containing pin definitions, which, if history is a guide, will end up
>>>> depending on all sorts of other .h files.
>>>> Another problem I often face with symbolic names is the difficulty of
>>>> figuring out what the numerical values really are (for debugging),
>>>> especially when .h files are in different subtrees from the files that
>>>> use the definitions, and when they use multiple macro levels and fancy
>>>> features like concatenation.  Sometimes I think it's clearer just to
>>>> write the number and use a comment to say what it is.
>>> 
>>> Both comments apply just as well to ordinary C code, and I don't think 
>>> anyone would seriously suggest just using comments instead for C code.
>> 
>> .h files include both structs and defines, which are fine for
>> ordinary C code, but problematic in this context.
> 
> Right, cpp should be invoked with similar options to the way it's done
> for asm files which have the same problem.  I'm not sure if the
> current patch does so.

I know the current dtc code is very careful to license itself in a very 
agnostic way.  Would including files, possibly from the Linux kernel, pose any 
kind of license issue?  Or does the fact that many (but not all) .dts files 
being apparently licensed GPL already make this a moot point?  Or does it not 
matter since this is an interface and declaration of information, which likely 
isn't creative enough to receive to copyright protection  Or is this a can 
of worms best avoided :)

Warner--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 10, 2012, at 1:24 AM, David Gibson wrote:

 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
 
 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
 
 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
 What more do you think needs discussion re: dtc+cpp?
 
 How not to abuse the ever-loving shit out of it? :-)
 
 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
 
 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.
 
 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.
 
 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.

I know the current dtc code is very careful to license itself in a very 
agnostic way.  Would including files, possibly from the Linux kernel, pose any 
kind of license issue?  Or does the fact that many (but not all) .dts files 
being apparently licensed GPL already make this a moot point?  Or does it not 
matter since this is an interface and declaration of information, which likely 
isn't creative enough to receive to copyright protection  Or is this a can 
of worms best avoided :)

Warner--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>> >>>
>> >>> What more do you think needs discussion re: dtc+cpp?
>> >>
>> >> How not to abuse the ever-loving shit out of it? :-)
>> >
>> > Perhaps we can just handle this through the regular patch review
>> > process; I think it may be difficult to define and agree upon exactly
>> > what "abuse" means ahead of time, but it's probably going to be easy
>> > enough to recognize it when one sees it?
>> One of the ways it could get out of hand would be via "include
>> dependency hell".  People will be tempted to reuse existing .h files
>> containing pin definitions, which, if history is a guide, will end up
>> depending on all sorts of other .h files.
>> Another problem I often face with symbolic names is the difficulty of
>> figuring out what the numerical values really are (for debugging),
>> especially when .h files are in different subtrees from the files that
>> use the definitions, and when they use multiple macro levels and fancy
>> features like concatenation.  Sometimes I think it's clearer just to
>> write the number and use a comment to say what it is.
> 
> Both comments apply just as well to ordinary C code, and I don't think anyone 
> would seriously suggest just using comments instead for C code.

.h files include both structs and defines, which are fine for ordinary C code, 
but problematic in this context.

> Is there a way to ask CPP to evaluate a macro in the context of the input 
> file, rather than produce normal output?  If not, I guess you could make a 
> tool that creates a wrapper file that includes the main file and then 
> evaluates the symbol you want.

Not in the standard CPP, but perhaps you could scan the .dts file for all the 
values you need, and have it output the right values to use.

Warner--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
  What more do you think needs discussion re: dtc+cpp?
 
  How not to abuse the ever-loving shit out of it? :-)
 
  Perhaps we can just handle this through the regular patch review
  process; I think it may be difficult to define and agree upon exactly
  what abuse means ahead of time, but it's probably going to be easy
  enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
 
 Both comments apply just as well to ordinary C code, and I don't think anyone 
 would seriously suggest just using comments instead for C code.

.h files include both structs and defines, which are fine for ordinary C code, 
but problematic in this context.

 Is there a way to ask CPP to evaluate a macro in the context of the input 
 file, rather than produce normal output?  If not, I guess you could make a 
 tool that creates a wrapper file that includes the main file and then 
 evaluates the symbol you want.

Not in the standard CPP, but perhaps you could scan the .dts file for all the 
values you need, and have it output the right values to use.

Warner--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver: misc: bmp085: remove "of_match_table" property.

[Warner Losh]

On Aug 7, 2012, at 4:52 AM, Mark Brown wrote:

> On Tue, Aug 07, 2012 at 08:43:44AM +0300, Felipe Balbi wrote:
>> On Mon, Aug 06, 2012 at 04:42:14PM +0100, Mark Brown wrote:
> 
>>> It's good practice to have an explict compatible string even if the
>>> default happens to work in order to avoid any name clashes.
> 
>> of_i2c.c makes no use whatsoever of the compatible string. See that it
>> will build an i2c_boardinfo and register a new device. That compatible
> 
> If that's all that's done it seems like a bug frankly, certainly based
> on previous discussions it ought to be.  There are collisions out there,
> they've just happened to not bite us yet

Also keep in mind that the device tree is supposed to be a description of the 
hardware, and different implementations of the device tree may use the 
compatible string.

Warner

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver: misc: bmp085: remove of_match_table property.

[Warner Losh]

On Aug 7, 2012, at 4:52 AM, Mark Brown wrote:

 On Tue, Aug 07, 2012 at 08:43:44AM +0300, Felipe Balbi wrote:
 On Mon, Aug 06, 2012 at 04:42:14PM +0100, Mark Brown wrote:
 
 It's good practice to have an explict compatible string even if the
 default happens to work in order to avoid any name clashes.
 
 of_i2c.c makes no use whatsoever of the compatible string. See that it
 will build an i2c_boardinfo and register a new device. That compatible
 
 If that's all that's done it seems like a bug frankly, certainly based
 on previous discussions it ought to be.  There are collisions out there,
 they've just happened to not bite us yet

Also keep in mind that the device tree is supposed to be a description of the 
hardware, and different implementations of the device tree may use the 
compatible string.

Warner

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/