All of lore.kernel.org
 help / color / mirror / Atom feed
* Supporting eeproms from device-tree in FruDevice
@ 2019-08-06  0:31 Patrick Venture
  2019-08-06 17:15 ` James Feist
  0 siblings, 1 reply; 3+ messages in thread
From: Patrick Venture @ 2019-08-06  0:31 UTC (permalink / raw)
  To: James Feist; +Cc: OpenBMC Maillist

I'm nearly done adapting FruDevice to handle FRUs that have drivers
ready, and raw i2c FRUs.  Before I push the code for review, I wanted
to get early feedback on the design change.  I wanted to keep it small
and surgical.

Basically, for each bus, before it scans for FRUs raw, it searches for
eeprom files for that bus.  And validates, and adds those devices.
Those addresses go into a skip list, and another list (used elsewhere
for writes).  The normal get frus code is then run but it'll skip the
addresses already handled.  Elsewhere, the code that handles writes to
the FRUs will check to see if the bus/address is in the list of
"driver handled" ones, and if so it'll call to write via the eeprom
file instead of the raw i2c commands.

Basically, the new code wouldn't interfere with normal operations, but
just extend it to leverage a driver when it's available.

Patrick

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Supporting eeproms from device-tree in FruDevice
  2019-08-06  0:31 Supporting eeproms from device-tree in FruDevice Patrick Venture
@ 2019-08-06 17:15 ` James Feist
  2019-12-25 14:17   ` 回覆:Supporting " ‪‪‪‪Jeff Chan‬‬‬‬
  0 siblings, 1 reply; 3+ messages in thread
From: James Feist @ 2019-08-06 17:15 UTC (permalink / raw)
  To: Patrick Venture; +Cc: OpenBMC Maillist

On 8/5/19 5:31 PM, Patrick Venture wrote:
> I'm nearly done adapting FruDevice to handle FRUs that have drivers
> ready, and raw i2c FRUs.  Before I push the code for review, I wanted
> to get early feedback on the design change.  I wanted to keep it small
> and surgical.
> 
> Basically, for each bus, before it scans for FRUs raw, it searches for
> eeprom files for that bus.  And validates, and adds those devices.
> Those addresses go into a skip list, and another list (used elsewhere
> for writes).  The normal get frus code is then run but it'll skip the
> addresses already handled.  Elsewhere, the code that handles writes to
> the FRUs will check to see if the bus/address is in the list of
> "driver handled" ones, and if so it'll call to write via the eeprom
> file instead of the raw i2c commands.
> 
> Basically, the new code wouldn't interfere with normal operations, but
> just extend it to leverage a driver when it's available.

Sounds great to me.

-James


> 
> Patrick
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* 回覆:Supporting eeproms from device-tree in FruDevice
  2019-08-06 17:15 ` James Feist
@ 2019-12-25 14:17   ` ‪‪‪‪Jeff Chan‬‬‬‬
  0 siblings, 0 replies; 3+ messages in thread
From: ‪‪‪‪Jeff Chan‬‬‬‬ @ 2019-12-25 14:17 UTC (permalink / raw)
  To: James Feist, Patrick Venture; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/html, Size: 1913 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-12-25 14:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-06  0:31 Supporting eeproms from device-tree in FruDevice Patrick Venture
2019-08-06 17:15 ` James Feist
2019-12-25 14:17   ` 回覆:Supporting " ‪‪‪‪Jeff Chan‬‬‬‬

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.