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

2016-09-12 Thread 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

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

2016-09-12 Thread 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 >>>>

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

2016-09-12 Thread 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,

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

2016-09-12 Thread 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

Re: Device Tree Blob (DTB) licence

2015-06-01 Thread 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

Re: Device Tree Blob (DTB) licence

2015-06-01 Thread 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

Re: Device Tree Blob (DTB) licence

2015-05-31 Thread 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

Re: Device Tree Blob (DTB) licence

2015-05-31 Thread 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

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

2014-03-20 Thread 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

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

2014-03-20 Thread 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

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

2014-03-20 Thread 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.

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

2014-03-20 Thread 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

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

2014-03-12 Thread 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. > >

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

2014-03-12 Thread 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

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

2014-03-12 Thread 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

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

2014-03-12 Thread 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

Re: dtc: import latest upstream dtc

2012-10-10 Thread 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, Steph

Re: dtc: import latest upstream dtc

2012-10-10 Thread 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

Re: dtc: import latest upstream dtc

2012-10-09 Thread 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

Re: dtc: import latest upstream dtc

2012-10-09 Thread 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?

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

2012-08-07 Thread 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

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

2012-08-07 Thread 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