[U-Boot] [PATCH v1 1/2] cmd_sf: Add command "sf info" to show current device info

[Jagan Teki]

On 20 July 2015 at 11:25, Wang Haikun <Haikun.Wang at freescale.com> wrote:
> On 5/11/2015 10:59 AM, Simon Glass wrote:
>> Hi,
>>
>> On 10 May 2015 at 07:04, Jagan Teki <jteki at openedev.com> wrote:
>>> On 8 May 2015 at 13:51, Haikun.Wang at freescale.com
>>> <Haikun.Wang at freescale.com> wrote:
>>>> On 5/8/2015 1:53 PM, Jagan Teki wrote:
>>>>> On 8 May 2015 at 08:14, Haikun.Wang at freescale.com
>>>>> <Haikun.Wang at freescale.com> wrote:
>>>>>> On 5/7/2015 7:44 PM, Jagan Teki wrote:
>>>>>>> On 6 May 2015 at 02:30, Simon Glass <sjg at chromium.org> wrote:
>>>>>>>> On 5 May 2015 at 05:37, Haikun.Wang at freescale.com
>>>>>>>> <Haikun.Wang at freescale.com> wrote:
>>>>>>>>> On 5/1/2015 9:54 AM, Simon Glass wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 29 April 2015 at 04:40, Haikun Wang <haikun.wang at freescale.com> wrote:
>>>>>>>>>>> Add command "sf info" to show the information of the current SPI flash device.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Haikun Wang <haikun.wang at freescale.com>
>>>>>>>>>>> ---
>>>>>>>>>>> In current sf driver, we show the debug information during the flash probe
>>>>>>>>>>> period.
>>>>>>>>>>>
>>>>>>>>>>> In case of without DM SPI, we need to run command "sf probe" to get the debug
>>>>>>>>>>> information of the current SPI flash device. "sf probe" will re-identify the
>>>>>>>>>>> device every time and it reduce the efficiency. We can get the debug information
>>>>>>>>>>> without any re-identify process using "sf info".
>>>>>>>
>>>>>>> So for non-dm case, sf probe and sf info does same?
>>>>>> For non-dm case, sf info only show the information store in the current
>>>>>> struct spi_flash, sf_probe will re-probe the SPI flash and create a new
>>>>>> struct spi-flash.
>>>>>
>>>>> How could it be, in non-dm case sf probe will detect the flash and
>>>>> print the info
>>>>> from drivers/mtd/spi/sf_probe.c So sf probe every-time will
>>>>> re-identify the device
>>>>> and print the info.
>>>> I approve of what you said.
>>>> We don't have divergence about the difference between "sf probe" and "sf
>>>> info".
>>>> I just want to emphasize that "sf probe" re-identify the device, create
>>>> a new "spi_flash" and print the info, "sf info" only print the current info.
>>>>>
>>>>> BTW: regarding this patch, unlike any command in u-boot (for my understanding)
>>>>> sf probe has a run-time capable detection option based on  bus:cs hz mode
>>>>> from user. So it better to skip the re-identify the same fitlash if
>>>>> the flash is identified before
>>>>> in sf probe logic and try to print the info in it instead of going
>>>>> another stale command just
>>>>> by doing print using earlier commands settings (sf probe).
>>>>>
>>>> I think we get to a common view that it is unnecessary to re-identify
>>>> the device if it has been identified.
>>>> Divergence is that you think this should be completed through updating
>>>> the sf probe logic and I think we should add the new command "sf info".
>>>> "sf info" resolves the problem in a more simpler way.
>>>> User will be more clearly about the functions of the sf commands if we
>>>> add a new command "sf info".
>>>>   From the literal meaning of the command "sf probe" should identify the
>>>> device and the command "sf info" show the information of current device.
>>>
>>> Yes, I agree that 'sf info' simply show the current device info in a
>>> simpler way.
>>> But, being with my previous statement it simply print the info which
>>> is derived from
>>> 'sf probe' So why should we go and do the same thing in 'sf probe'
>>> with increasing
>>> one more command which does part of same as before.
>>>
>>> Yes, 'sf probe' is doing unnecessary re-identify the device so may be we can
>>> fix that, ie going to be a real fix other than adding new command.
>>>
>>> Please think in that direction, adding new command in u-boot is really a big
>>> step to think in whole u-boot development point of view.
>>
>> We have an 'info' command for usb, mmc, scsi, etc. and they don't have
>> side-effects like re-probing the device. I think it makes sense to
>> support something like this for sf, at least for driver model.
>>
>> Also, with driver model it would be good if the sf could automatically
>> probe when used, rather than needing to probe it explicitly. We could
>> also support more than one active flash, and a command to switch
>> between them (like mmc dev and the like). Even better if we could
>> specific the device in the 'sf read/write/erase' commands.
>>
>> [snip]
>>
>> Regards,
>> Simon
>>
> Update my email address.

Pls- send the next version by add some text on commit message.

thanks!
-- 
Jagan | openedev.