[PATCH] mtd: spi-nor: Add support for BoHong bh25q128as

[Tudor.Ambarus at microchip.com]

On 5/18/21 10:39 PM, David Bauer wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Michael,
> 
> Sorry for the late reply, was not feeling well past week.
> 
> On 5/10/21 1:22 PM, Michael Walle wrote:
>> Hi David,
>>
>> Am 2021-05-10 13:04, schrieb David Bauer:
>>> On 5/10/21 12:56 PM, Michael Walle wrote:
>>>> Am 2021-05-10 12:27, schrieb David Bauer:
>>>>> On 5/10/21 11:35 AM, Michael Walle wrote:
>>>>>> Am 2021-05-10 11:28, schrieb David Bauer:
>>>>>>> On 5/10/21 10:00 AM, Michael Walle wrote
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>> +static const struct flash_info bohong_parts[] = {
>>>>>>>>> +    /* BoHong Microelectronics */
>>>>>>>>> +    { "bh25q128as", INFO(0x684018, 0, 64 * 1024, 256,
>>>>>>>>
>>>>>>>> I couldn't find "BoHong" in JEP106BC. 0x68 (without continuation codes)
>>>>>>>> is "Convex Computer". So this is wrong. OTOH I'm not sure, how many
>>>>>>>> SPI flashes "convex computer" have, if any ;) This company was brought
>>>>>>>> by HP in the end.
>>>>>>>>
>>>>>>>> In any case, this patch depends on how we handle continuation codes or
>>>>>>>> if we can handle them at all. Or if this flash just lie about its
>>>>>>>> manufacturer id and don't and CC.
>>>>>>>
>>>>>>> First of all, BoHong and Boya microelectronics seems to be the same
>>>>>>> company, as their datasheets seem to copy each other. There's not much
>>>>>>> information about either of both, so I'd say that's a fair assumption.
>>>>>>>
>>>>>>> Regarding the continuation codes, Boya is listed in bank nine, however
>>>>>>> in this case I should currently read an all 0x7f ID shouldn't I?
>>>>>>
>>>>>> I'd guess so, yes.
>>>>>>
>>>>>>> The datasheet also only specifies 3 bytes as a return value for
>>>>>>> register 0x9fh :(
>>>>>>
>>>>>> Yeah. So, this flash falls into the same category "simply hijacks
>>>>>> a manuf id" as all the other flashes.
>>>>>
>>>>> From a quick check, this is also be the case for GigaDevices and XMC.
>>>>>
>>>>> My spontaneous idea would be to extend support for JEDEC IDs to read
>>>>> the up to 9 banks of the vendor ID and fix up the existing offenders.
>>>>
>>>> you mean gigadevices and xmc? I'd presume they are also lacking the
>>>> continuation bytes.
>>>
>>> Correct, same story with them.
>>>
>>>>
>>>>> To not break existing boards, we could either skip the continuation
>>>>> bytes of the kernel ID definitions for all flash chips or flag the
>>>>> already existing ones and only perform this on such flagged chips.
>>>>>
>>>>> Personally, I'd say that only performing this on existing chips would
>>>>> be better, as new vendors with this violation scheme might probably
>>>>> appear and cause conflicts.
>>>>>
>>>>> As we still lack auto detection for new chips with that, configuring
>>>>> the flash chip used with the chip name via DT would allow to set the
>>>>> exact chip used and also validate if the manufacturer / product after
>>>>> the continuation bits matches the one read from the chip.
>>>>>
>>>>> What do you think?
>>>>
>>>> If you'd ask me, unless there is a real world conflict, I'd just go
>>>> ahead and add them as is. If there is a conflict we'd need to find
>>>> a per device resolution for it.
>>>
>>> Okay, I'll resend a v2 with the removed copyright then.
>>
>> Could you also apply my SFDP patch [1] and send the dump (if there
>> is any)? Unfortunately, I can't think of a good way to do that along
>> with the patch and if this in some way regarded as copyrighted material.
>> So feel free to send it to me privately. I'm starting to build a
>> database.
> 
> Bad news, I'm not able to get a SFDP with your patches, as the SFDP extraction
> fails at the version check.
> 
> Is there anything else I can try?
> 

So no SFDP data?
Have you tried to read more of ID bytes, maybe there's an extended ID? Please
dump 15 bytes of ID.