From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 00/12] Introduce layout aware eeprom commands
Date: Mon, 18 Apr 2016 13:21:30 +0200 [thread overview]
Message-ID: <5714C33A.6090808@denx.de> (raw)
In-Reply-To: <20160418082211.GA12514@skynet>
On 04/18/2016 10:22 AM, Nikita Kiryanov wrote:
> On Sun, Apr 17, 2016 at 11:00:09PM +0200, Marek Vasut wrote:
>> On 04/17/2016 12:33 PM, Nikita Kiryanov wrote:
>>> Hi Marek,
>>>
>>> On Sun, Apr 17, 2016 at 11:47:23AM +0200, Marek Vasut wrote:
>>>> On 04/16/2016 04:55 PM, Nikita Kiryanov wrote:
>>>>> This series introduces eeprom layout aware capabilities to the existing eeprom
>>>>> command, and then enables this feature on Compulab boards. It is an import of
>>>>> the Compulab eeprom-utility (https://github.com/compulab/eeprom-util), and it
>>>>> introduces 2 new options to the eeprom command:
>>>>>
>>>>> eeprom print [-l <layout_version>] bus_num device_addr
>>>>
>>>> The bus number starts to become a problem, esp. when used with DM and
>>>> where the bus number can change between boots.
>>>
>>> Are you referring to the fact that the command allows the user to not specify
>>> the bus number (relying on a default value instead)?
>>
>> No, just using the bus number and device address doesn't seem right anymore.
>
> How so? Both are properties of the hardware, and they should be
> addressable as such. I feel like I'm missing something, can you
> elaborate on what you think the problem is?
The bus number is not really an exact identifier in the system anymore
because the number changes depending on the number and order of
registered buses in DM case. This works for now and is backwards
compatible, but I am tempted to push for user API which would be more
exact. You might want Simon's opinion on this too.
>>> If so, I agree with you
>>> that it is problematic. If I had my way I would've made it a mendatory
>>> parameter along with the device address, but that will hurt backwards
>>> compatibility.
>>
>> But this is new feature, there is no backward compatibility.
>
> I meant making this change for the eeprom read and write commands as well, not
> just the new commands. I think that the new commands should follow the
> conventions of the original commands for consistency, I just wish the current
> conventions were less ambiguous than they are now (it's not possible to figure
> out what ommision of these parameters does without looking at the source code).
The EEPROM code is in horrible state, indeed. If you want to clean it up
some more, I'd be real happy.
>>
>>> I'll be more than happy to redo the last 3 patches if we
>>> agree that we are willing to pay that price.
>>>
>>>>
>>>> Best regards,
>>>> Marek Vasut
>>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut
>>
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2016-04-18 11:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-16 14:55 [U-Boot] [PATCH 00/12] Introduce layout aware eeprom commands Nikita Kiryanov
2016-04-16 14:55 ` [U-Boot] [PATCH 01/12] cmd: eeprom: add bus switching support for all i2c drivers Nikita Kiryanov
2016-05-23 22:12 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 02/12] cmd: eeprom: add support for layout aware commands Nikita Kiryanov
2016-05-23 22:12 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 03/12] compulab: add support for layout aware eeprom commands Nikita Kiryanov
2016-05-23 22:12 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 04/12] arm: cm-fx6: add support for eeprom layout comands Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 05/12] arm: cm-t335: " Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 06/12] arm: cm-t54: " Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 07/12] arm: cm-t3517: " Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 08/12] arm: cm-t35: " Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 09/12] arm: cm-t43: " Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 10/12] eeprom: refactor i2c bus and devaddr parsing Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 11/12] eeprom: use eeprom_execute_command for all eeprom functions Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-16 14:55 ` [U-Boot] [PATCH 12/12] eeprom: merge cmdline parsing of eeprom commands Nikita Kiryanov
2016-05-23 22:13 ` Tom Rini
2016-04-17 9:47 ` [U-Boot] [PATCH 00/12] Introduce layout aware " Marek Vasut
2016-04-17 10:33 ` Nikita Kiryanov
2016-04-17 21:00 ` Marek Vasut
2016-04-18 8:22 ` Nikita Kiryanov
2016-04-18 11:21 ` Marek Vasut [this message]
2016-05-11 9:56 ` Nikita Kiryanov
2016-05-13 20:46 ` Tom Rini
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=5714C33A.6090808@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox