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

[Nikita Kiryanov <nikita@compulab.co.il>]

Hi Tom, Marek,
 
For the time being I do not wish to make additional refactoring to the
code as I think it is better to wait until an alternative to the bus
number is found. My changes follow the current implementation of the
eeprom command, so if there are no additional comments, can this be
applied?

On Mon, Apr 18, 2016 at 01:21:30PM +0200, Marek Vasut wrote:
> 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
>