From: Angus Clark <angus.clark@st.com>
To: Huang Shijie <b32955@freescale.com>
Cc: "marex@denx.de" <marex@denx.de>, Angus CLARK <angus.clark@st.com>,
"broonie@linaro.org" <broonie@linaro.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Gupta, Pekon" <pekon@ti.com>,
"Poddar, Sourav" <sourav.poddar@ti.com>,
"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/4] mtd: spi-nor: move the SPI NOR commands to a new header file
Date: Tue, 26 Nov 2013 14:48:35 +0000 [thread overview]
Message-ID: <5294B4C3.9080201@st.com> (raw)
In-Reply-To: <52946197.5050104@freescale.com>
On 11/26/2013 08:53 AM, Huang Shijie wrote:
> Hi Pekon:
>> (1)
>> It's better to take all Flash vendor specific opcodes from DT..
> firstly, some arch may does not support the DT, such as x86.
Indeed, although the 'flash_platform_data' structure could be extended to
provide similar functionality, if that were deemed the right way to go. However...
>
> second, it makes people crazy if we put the opcodes in the DT :)
I would agree. Where possible, I think it's preferable for the driver to probe
device properties at runtime. One benefit, often overlooked, is that it allows
board manufacturers to second-source parts without having to rebuild, and
possibly re-certify, binaries.
>> With new framework we should do away with macros for each vendor,
>> instead let each board file provide this information based on flash
>> device
>> which is mounted on it.
>>
>> (2)
>> And also, I suggest not to touch m25p80 in anyway, bcoz it stable driver
>> used by many. So unless spi-nor framework is accepted and is stable we
>> m25p80 should continue working as it is.
>> Thus your patches should be independent of any existing driver or other
>> frameworks. This way it might get accepted fast. Then later you can
>> provide
>> a way to attach m25p80 to spi-nor framework.
>> Thoughts ?
> the merge window is closed not long ago, and we have rc1 now.
>
> Isn't it the BEST time to change the m25p80?
>
The spi-nor framework has great potential, but I think you should allow some
time for other driver developers to comment, and the framework to mature.
Without greater support, it risks becoming another single-use framework.
Cheers,
Angus
> thanks
> Huang Shijie
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
-------------------------------------
Angus Clark
ST Microelectronics (R&D) Ltd.
1000 Aztec West, Bristol, BS32 4SQ
email: angus.clark@st.com
tel: +44 (0) 1454 462389
st-tina: 065 2389
-------------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: angus.clark@st.com (Angus Clark)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] mtd: spi-nor: move the SPI NOR commands to a new header file
Date: Tue, 26 Nov 2013 14:48:35 +0000 [thread overview]
Message-ID: <5294B4C3.9080201@st.com> (raw)
In-Reply-To: <52946197.5050104@freescale.com>
On 11/26/2013 08:53 AM, Huang Shijie wrote:
> Hi Pekon:
>> (1)
>> It's better to take all Flash vendor specific opcodes from DT..
> firstly, some arch may does not support the DT, such as x86.
Indeed, although the 'flash_platform_data' structure could be extended to
provide similar functionality, if that were deemed the right way to go. However...
>
> second, it makes people crazy if we put the opcodes in the DT :)
I would agree. Where possible, I think it's preferable for the driver to probe
device properties at runtime. One benefit, often overlooked, is that it allows
board manufacturers to second-source parts without having to rebuild, and
possibly re-certify, binaries.
>> With new framework we should do away with macros for each vendor,
>> instead let each board file provide this information based on flash
>> device
>> which is mounted on it.
>>
>> (2)
>> And also, I suggest not to touch m25p80 in anyway, bcoz it stable driver
>> used by many. So unless spi-nor framework is accepted and is stable we
>> m25p80 should continue working as it is.
>> Thus your patches should be independent of any existing driver or other
>> frameworks. This way it might get accepted fast. Then later you can
>> provide
>> a way to attach m25p80 to spi-nor framework.
>> Thoughts ?
> the merge window is closed not long ago, and we have rc1 now.
>
> Isn't it the BEST time to change the m25p80?
>
The spi-nor framework has great potential, but I think you should allow some
time for other driver developers to comment, and the framework to mature.
Without greater support, it risks becoming another single-use framework.
Cheers,
Angus
> thanks
> Huang Shijie
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
-------------------------------------
Angus Clark
ST Microelectronics (R&D) Ltd.
1000 Aztec West, Bristol, BS32 4SQ
email: angus.clark at st.com
tel: +44 (0) 1454 462389
st-tina: 065 2389
-------------------------------------
next prev parent reply other threads:[~2013-11-26 14:48 UTC|newest]
Thread overview: 157+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 6:32 [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 6:32 ` [PATCH 1/4] mtd: spi-nor: move the SPI NOR commands to a new header file Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 7:42 ` Gupta, Pekon
2013-11-26 7:42 ` Gupta, Pekon
2013-11-26 8:53 ` Huang Shijie
2013-11-26 8:53 ` Huang Shijie
2013-11-26 14:48 ` Angus Clark [this message]
2013-11-26 14:48 ` Angus Clark
2013-11-26 6:32 ` [PATCH 2/4] mtd: spi-nor: add a new data structrue spi_nor{} Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 11:42 ` Gupta, Pekon
2013-11-26 11:42 ` Gupta, Pekon
2013-11-27 4:35 ` Huang Shijie
2013-11-27 4:35 ` Huang Shijie
2013-11-27 9:32 ` Marek Vasut
2013-11-27 9:32 ` Marek Vasut
2013-11-27 10:24 ` Huang Shijie
2013-11-27 10:24 ` Huang Shijie
2013-11-27 10:27 ` Marek Vasut
2013-11-27 10:27 ` Marek Vasut
2013-11-26 6:32 ` [PATCH 3/4] mtd: spi-nor: add the framework for SPI NOR Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 10:03 ` Gupta, Pekon
2013-11-26 10:03 ` Gupta, Pekon
2013-11-27 9:39 ` Marek Vasut
2013-11-27 9:39 ` Marek Vasut
2013-11-26 6:32 ` [PATCH 4/4] mtd: m25p80: use the new spi-nor APIs Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 12:57 ` [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR Angus Clark
2013-11-26 12:57 ` Angus Clark
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:39 ` Huang Shijie
2013-11-27 4:39 ` Huang Shijie
2013-11-27 4:39 ` Huang Shijie
2013-11-29 14:52 ` Angus Clark
2013-11-29 14:52 ` Angus Clark
2013-11-29 14:52 ` Angus Clark
2013-12-02 10:06 ` Huang Shijie
2013-12-02 10:06 ` Huang Shijie
2013-12-02 10:06 ` Huang Shijie
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:19 ` Angus Clark
2013-12-02 11:19 ` Angus Clark
2013-12-03 6:20 ` Huang Shijie
2013-12-03 6:20 ` Huang Shijie
2013-12-03 6:20 ` Huang Shijie
2013-12-03 8:23 ` Lee Jones
2013-12-03 8:23 ` Lee Jones
2013-12-03 8:23 ` Lee Jones
2013-12-10 8:25 ` Brian Norris
2013-12-10 8:25 ` Brian Norris
2013-12-10 8:25 ` Brian Norris
2013-12-10 10:00 ` Lee Jones
2013-12-10 10:00 ` Lee Jones
2013-12-10 10:00 ` Lee Jones
2013-12-03 0:32 ` Marek Vasut
2013-12-03 0:32 ` Marek Vasut
2013-12-03 0:32 ` Marek Vasut
2013-12-03 10:36 ` Huang Shijie
2013-12-03 10:36 ` Huang Shijie
2013-12-03 10:36 ` Huang Shijie
2013-12-03 14:51 ` David Woodhouse
2013-12-03 14:51 ` David Woodhouse
2013-12-03 14:51 ` David Woodhouse
2013-12-04 18:44 ` Brian Norris
2013-12-04 18:44 ` Brian Norris
2013-12-04 18:44 ` Brian Norris
2013-12-05 7:12 ` Huang Shijie
2013-12-05 7:12 ` Huang Shijie
2013-12-05 7:12 ` Huang Shijie
2013-12-05 8:11 ` Brian Norris
2013-12-05 8:11 ` Brian Norris
2013-12-05 8:11 ` Brian Norris
2013-12-05 7:59 ` Huang Shijie
2013-12-05 7:59 ` Huang Shijie
2013-12-05 7:59 ` Huang Shijie
2013-12-05 9:20 ` Brian Norris
2013-12-05 9:20 ` Brian Norris
2013-12-05 9:20 ` Brian Norris
2013-12-06 3:07 ` Huang Shijie
2013-12-06 3:07 ` Huang Shijie
2013-12-06 3:07 ` Huang Shijie
2013-12-05 14:35 ` Angus Clark
2013-12-05 14:35 ` Angus Clark
2013-12-05 14:35 ` Angus Clark
2013-12-06 8:18 ` Huang Shijie
2013-12-06 8:18 ` Huang Shijie
2013-12-06 8:18 ` Huang Shijie
2013-12-10 9:08 ` Brian Norris
2013-12-10 9:08 ` Brian Norris
2013-12-10 9:08 ` Brian Norris
2013-12-04 2:46 ` Huang Shijie
2013-12-04 2:46 ` Huang Shijie
2013-12-04 2:46 ` Huang Shijie
2013-12-04 6:58 ` Angus Clark
2013-12-04 6:58 ` Angus Clark
2013-12-04 6:58 ` Angus Clark
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 8:21 ` Angus Clark
2013-12-04 8:21 ` Angus Clark
2013-12-04 8:21 ` Angus Clark
2013-12-04 15:36 ` Marek Vasut
2013-12-04 15:36 ` Marek Vasut
2013-12-04 15:36 ` Marek Vasut
2013-12-05 2:42 ` Huang Shijie
2013-12-05 2:42 ` Huang Shijie
2013-12-05 2:42 ` Huang Shijie
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 7:33 ` Huang Shijie
2013-12-05 7:33 ` Huang Shijie
2013-12-05 7:33 ` Huang Shijie
2013-11-27 9:27 ` Marek Vasut
2013-11-27 9:27 ` Marek Vasut
2013-11-27 9:47 ` Sourav Poddar
2013-11-27 9:47 ` Sourav Poddar
2013-11-27 10:06 ` Marek Vasut
2013-11-27 10:06 ` Marek Vasut
2013-11-27 10:56 ` Sourav Poddar
2013-11-27 10:56 ` Sourav Poddar
2013-12-02 23:59 ` Marek Vasut
2013-12-02 23:59 ` Marek Vasut
2013-12-03 10:01 ` Sourav Poddar
2013-12-03 10:01 ` Sourav Poddar
2013-12-03 13:42 ` Marek Vasut
2013-12-03 13:42 ` Marek Vasut
2013-12-03 13:50 ` Sourav Poddar
2013-12-03 13:50 ` Sourav Poddar
2013-12-03 14:19 ` Marek Vasut
2013-12-03 14:19 ` Marek Vasut
2013-12-03 14:31 ` Sourav Poddar
2013-12-03 14:31 ` Sourav Poddar
2013-12-03 15:09 ` Marek Vasut
2013-12-03 15:09 ` Marek Vasut
2013-12-03 15:16 ` Sourav Poddar
2013-12-03 15:16 ` Sourav Poddar
2013-12-03 15:35 ` Marek Vasut
2013-12-03 15:35 ` Marek Vasut
2013-12-03 15:23 ` David Woodhouse
2013-12-03 15:23 ` David Woodhouse
2013-12-03 18:28 ` Brian Norris
2013-12-03 18:28 ` Brian Norris
2013-12-03 23:41 ` Marek Vasut
2013-12-03 23:41 ` Marek Vasut
2013-11-27 10:19 ` Huang Shijie
2013-11-27 10:19 ` Huang Shijie
2013-12-03 0:00 ` Marek Vasut
2013-12-03 0:00 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5294B4C3.9080201@st.com \
--to=angus.clark@st.com \
--cc=b32955@freescale.com \
--cc=broonie@linaro.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=pekon@ti.com \
--cc=sourav.poddar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.