Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 0oWZPOdQrJLDT8ajgoGBabQafcnpp+OdXzvBLMOuBSEw2HKGM4jfm3A9dn4mNlEkHpAeibzvs7
 RyLgtqgeI90wXWE/0wJXM1f9vMe1BYQVXTXyJOEjhi5l2ML5THldwubWYiz6ye2XcedG3p7OsN
 wiVWFQR+ohSx0Qh+D7ON3ehUbdToKn0sPuCt3PV7qS5/TaJtsC2bMyIk8jlN9VfHlG9bxCnQ4q
 84oGFFS5/mrHq+iPeMF0obN9XlBCrCdNcK4BwOZeJ745MA5yBMInTfcGh7MATZI5v7BTNb6bTx
 pRI=
From:   <Tudor.Ambarus@microchip.com>
To:     <jaimeliao@mxic.com.tw>, <michael@walle.cc>
CC:     <bbrezillon@kernel.org>, <esben@geanix.com>,
        <frieder.schrempf@kontron.de>, <linux@rasmusvillemoes.dk>,
        <linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
        <masonccyang@mxic.com.tw>, <p.yadav@ti.com>, <ycllin@mxic.com.tw>,
        <zhengxunli@mxic.com.tw>
Subject: =?iso-2022-jp?B?UmU6IBskQjJzPy4bKEI6IFJlOiBbUkZDIDIvM10gbXRkOiBzcGktbm9y?=
 =?iso-2022-jp?B?OiBjb3JlOiBjb21wYXJlIEpFREVDIGJ5dGVzIHRvIGFscmVhZHkgZm91?=
 =?iso-2022-jp?B?bmQgZmxhc2hfaW5mbw==?=
Thread-Topic: =?iso-2022-jp?B?GyRCMnM/LhsoQjogUmU6IFtSRkMgMi8zXSBtdGQ6IHNwaS1ub3I6IGNv?=
 =?iso-2022-jp?B?cmU6IGNvbXBhcmUgSkVERUMgYnl0ZXMgdG8gYWxyZWFkeSBmb3VuZCBm?=
 =?iso-2022-jp?B?bGFzaF9pbmZv?=
Thread-Index: AQHXaApoB34k0r+j/EGzCRMbPuTJeg==
Date:   Wed, 23 Jun 2021 08:33:15 +0000
Message-ID: <dcd4e64f-348c-fadd-1044-61c7b6fa93c8@microchip.com>
References: <20210621152320.3811194-1-linux@rasmusvillemoes.dk>
 <20210621152320.3811194-3-linux@rasmusvillemoes.dk>
 <223232ecd0865e819477f17cd464ab08@walle.cc>
 <OF7CD5328D.D33B2BE2-ON482586FD.0027BCF2-482586FD.00280249@mxic.com.tw>
In-Reply-To: <OF7CD5328D.D33B2BE2-ON482586FD.0027BCF2-482586FD.00280249@mxic.com.tw>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?alNWUlgzQWpGSWsybUFKRnpLM1dyMVZRRzIzaWdZWGNsTWpQZDVJem5F?=
 =?iso-2022-jp?B?eVJIdVRRbzhPYlVIVWJINnIwLzhHMk05M0xocU9ha0x2TlFBblhHQWVP?=
 =?iso-2022-jp?B?aURQcmVyVzdsNGFRQzBuVjN5eXBPTTN2VUNDcmRudXQvbnYzcFVuZXFN?=
 =?iso-2022-jp?B?SUNuY2t3UGdUV0pNNkNDWlQ3amlMSHVaWk5pR0FKdWhxekNwSUMwQ3J1?=
 =?iso-2022-jp?B?Unk5SWpmbnZNZkNMNXFjWWlxS21TN3ZScFdZL2JuWGk3Y0ZVcXhTR0g4?=
 =?iso-2022-jp?B?RGRDK2tOU3QzZmFUR1A2RjRUVEVCQjkxSVdsdWl2Y2pacUNXNU5GaW9Z?=
 =?iso-2022-jp?B?QjBiS2tpcU9LZlAybFJwVTkrYmJRWHpXV2FrSVM4Ykx4algzMVIxNXBM?=
 =?iso-2022-jp?B?NS8xMzkzeFFLVFhjRWlzL1lFTGNvZVFlM3ZLY2JhNGkzSEM3R1ZObVNn?=
 =?iso-2022-jp?B?Z3M2bWhhTi9JNEpSRi9WZ2NHaU12RmxxcThYTGFRNWlSVHBlbWdCVERF?=
 =?iso-2022-jp?B?eSsrd2tqcmJlRzNBUVRaOExBam04SytMbWFWN3lhcnNXMHZyM1F2UDVM?=
 =?iso-2022-jp?B?NjY1VWJJR213dFlVWks1RnU3WE4vMVM2Vm1rZ0p1Ymg3SGFvRGptVmEy?=
 =?iso-2022-jp?B?eVR2aFY5ZjZNN0xzZjl1RXJuNTNpK20zM2tab1NkZTlJandPNU9mdGps?=
 =?iso-2022-jp?B?akdCeUNGTmVibVBtMFJwN0tuVFRrNWp3MW9XQkdkSDgvd2F4eHJDNFU5?=
 =?iso-2022-jp?B?SGpkUmo3ZGZibDRpbjYyTGcrOEFpKzNPZkYxc3U4cVNZcFQxaWtvUlZN?=
 =?iso-2022-jp?B?NG5OWVpES2Urb1JybDN2d2tKeFFRVjllMENPZnhkaEVIQzFBVUlBdFdm?=
 =?iso-2022-jp?B?NUhZVEpnV2VWbnhsL085aGh0T01PQkxlYS8xS0xmY2ZxTm9KVTczMCtm?=
 =?iso-2022-jp?B?VnlzVWdBdS81enlDaUlaY0QvVERVQnRQdlNUSEdOdkx0NHNTODBJQnRQ?=
 =?iso-2022-jp?B?TE53SVlSM255bkI0a2pZTTFPT3pFOXlaRisvbDk3b1ZORCtvUU9wR2tM?=
 =?iso-2022-jp?B?d3hla0RmSXdQNWQ3SmdPUWtkeWduNXFrdW5LUmVoQ0tsdUhuQ20xMWgz?=
 =?iso-2022-jp?B?Qzh3cjVHT1pRZ2FWWVA3Q1dUaFIwSkZFSEZ6VUtnTGdnaXA4dHN5dURL?=
 =?iso-2022-jp?B?QTdtWjVabTNzaTQ2U2Q2N0pWR0lpL1Mwbk05RDR5SFlFeGM3cmpCTEFS?=
 =?iso-2022-jp?B?MG9lVkRDemJqaTFJb2xGZXh3Qk1FRnBUUStKcW5rUHpjS2xsYTdlRVg0?=
 =?iso-2022-jp?B?M2RWMmdPWnlwNXljUmk5cHpxY0d5MXU3TlArOHBxTmtoQ2Y3WGgxSnZL?=
 =?iso-2022-jp?B?OEtlVkZFUzJQMVpRalRFS2xVRGp4cXQrL3Zmc2ZIMDlNVWpCZ2tNSGFK?=
 =?iso-2022-jp?B?WjV0T0FiT1FFZy95ckJiU2FJVjhLM3NZazRCL2ZwVk1ubFZjeXREbFJ0?=
 =?iso-2022-jp?B?YVhua1hKeVdjRjU0VHlZMFg1RFBUUGNWSi9aOGpGZm16YWJvem5LOVBK?=
 =?iso-2022-jp?B?YUoxQTZDS2FGNkMxV3Z5Uit1LzFRMzNVUldMN0RSbFpjcmZidktQRnpq?=
 =?iso-2022-jp?B?NkdOWGZPY2NwaGRYRG81cnVhSFloRW5FQ3hFblJpWVBIdUlLYTRFdUo3?=
 =?iso-2022-jp?B?NG41dm16SXZHTStmWStBZHZjMFRKdXk2clBDOXA1M0ZuNWg4SWcwSmF0?=
 =?iso-2022-jp?B?RmVSNEZ3NG1VTGsvOERRam9SUUVwMGhwbCt0LzBqMjhlNzREaVNtVmhv?=
 =?iso-2022-jp?B?cFpKRG5JZk1LK1JvUG4xSi96d1JVSkR3cW50RWg3T3NWQ2lNNkhsblc2?=
 =?iso-2022-jp?B?elozUVdtU2lPZGNnakdtODhndGlVPQ==?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <1DDE4C6DC114F9469DEF87538381692F@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4869.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bf277419-52e5-47c5-bea0-08d936218ba7
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2021 08:33:15.3676
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RwdyLcvv8McRz4lMr/cmTV1piEWOCm/NhrAeiI1oldUCm86yuF45YIKmlgLRQUil4bsr0KfrMUDL42bpL3fMKLrMnVetcX5xG86TGerCIWM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4950
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 6/23/21 10:17 AM, jaimeliao@mxic.com.tw wrote:
> You don't often get email from jaimeliao@mxic.com.tw. Learn why this is i=
mportant<http://aka.ms/LearnAboutSenderIdentification>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know th=
e content is safe
> Hi Michael and Rasmus
>=20
>=20
>>
>> Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already
>> found flash_info
>>
>> [+ some people from MXIC as they are ones who posted to the ML
>> lately. Feel free to forward this mail to the corresponding people.]
>>
>> Am 2021-06-21 17:23, schrieb Rasmus Villemoes:
>>> Macronix engineers, in their infinite wisdom, have a habit of reusing
>>> JEDEC ids for different chips. There's already one
>>> workaround (MX25L25635F v MX25L25635E), but the same problem exists
>>> for MX25L3205D v MX25L3233F, the latter of which is not currently
>>> supported by linux.
>>>
>>> AFAICT, that case cannot really be handled with any of the ->fixup
>>> machinery: The correct entry for the MX25L3233F would read
>>>
>>>         { "mx25l3233f",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K |
>>> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ ) },
>>>
>>> while the existing one is
>>>
>>>    { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>>>
>>> So in spi_nor_init_params(), we won't even try reading the sfdp
>>> info (i.e. call spi_nor_sfdp_init_params), and hence
>>> spi_nor_post_sfdp_fixups() has no way of distinguishing the
>>> chips.
>>>
>>> Replacing the existing entry with the mx25l3233f one to coerce the
>>> core into issuing the SPINOR_OP_RDSFDP is also not really an option,
>>> because the data sheet for the mx25l3205d explicitly says not to issue
>>> any commands not listed ("It is not recommended to adopt any other
>>> code not in the command definition table, which will potentially enter
>>> the hidden mode.", whatever that means).
>>
>> Maybe we should ask Macronix if it is safe to send the RDSFDP command.
>> Can anyone from MXIC comment this?
>=20
> For this part, we have validate RDSFDP command on some different chips wh=
ich
> are not support SFDP mode. The conclusion is that Flash didn't reply anyt=
hing.
> But we still not suggest to using commands which are not supported on the=
 Flash.
>=20
>> This is also interesting because we are discussing reading the SFDP
>> without reading the ID first.
>=20
> I think this idea is good but I am not sure how other vendor chips will r=
eact
> after getting the commands which are not supported on the flash.

Do any of these flashed define an extended ID, i.e. more that 3 bytes of ID=
?
Rasmus, would you please try to read more bytes of ID?