[U-Boot] [PATCH 00/12] Introduce layout aware eeprom commands

[Nikita Kiryanov]

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?

> 
> > 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).

> 
> > 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
>