<div dir="auto">Hi James,<div>I have eeprom on board, how can I enable the i2c bus driver to access it? right now I can find the dev under /sys/bus/i2c..., could you guide me how to sync FRU data into eeprom?</div><div>If I want to use i2c raw access, how to define the i2c bus driver?</div><div>thanks a lot in advance for your help</div><div><br>Jeff</div></div><div style="line-height:1.5"><br><br>-------- 原始郵件 --------<br>寄件者： James Feist <james.feist@linux.intel.com><br>日期： 2019年8月7日 週三 01:15<br>收件人： Patrick Venture <venture@google.com><br>副本： OpenBMC Maillist <openbmc@lists.ozlabs.org><br>主旨： Re: Supporting eeproms from device-tree in FruDevice<br><blockquote>On 8/5/19 5:31 PM, Patrick Venture wrote:<br>> I'm nearly done adapting FruDevice to handle FRUs that have drivers<br>> ready, and raw i2c FRUs.  Before I push the code for review, I wanted<br>> to get early feedback on the design change.  I wanted to keep it small<br>> and surgical.<br>> <br>> Basically, for each bus, before it scans for FRUs raw, it searches for<br>> eeprom files for that bus.  And validates, and adds those devices.<br>> Those addresses go into a skip list, and another list (used elsewhere<br>> for writes).  The normal get frus code is then run but it'll skip the<br>> addresses already handled.  Elsewhere, the code that handles writes to<br>> the FRUs will check to see if the bus/address is in the list of<br>> "driver handled" ones, and if so it'll call to write via the eeprom<br>> file instead of the raw i2c commands.<br>> <br>> Basically, the new code wouldn't interfere with normal operations, but<br>> just extend it to leverage a driver when it's available.<br><br>Sounds great to me.<br><br>-James<br><br><br>> <br>> Patrick<br>> <br></blockquote></div>