Re: [PATCH v7 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
Kyle Hsieh <[email protected]> Fri, 12 Jun 2026 09:19:28 +0800
| Newsgroups | org.ozlabs.lists.linux-aspeed,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAF7HswOi3fPMFppPoGmh0QELiPz4Po4cyWuDrEHLY2vNMyKE9g@mail.gmail.com> |
On Thu, Jun 11, 2026 at 11:57 PM Andrew Lunn <[email protected]> wrote: > > > + /* Marvell 88E6393X EEPROM */ > > + eeprom@50 { > > + compatible = "atmel,24c64"; > > + reg = <0x50>; > > + }; > > How is this on both a host I2C bus, and the switches I2C bus? Are you > using multi-master? Is there a GPIO to hold the switch in reset while > the host access the EEPROM? > > Andrew Hi Andrew, Thanks for taking a look at this. To answer your questions: No, we are not using multi-master. The EEPROM is physically isolated by a hardware I2C multiplexer. By default, the mux connects the EEPROM directly to the Marvell switch for its routine operation and configuration loading. The BMC's I2C bus is physically disconnected from the EEPROM during this time. The BMC only gains access to this EEPROM for out-of-band firmware updates. When an update is required, the BMC or CPLD asserts a reset to the switch, toggles the I2C mux to route the EEPROM to the BMC, performs the flash, and then restores the original routing before releasing the switch from reset. Therefore, there is no runtime concurrent access or multi-master scenario between the host and the switch. Would you recommend adding a comment in the device tree to clarify this hardware isolation, or is this explanation sufficient? Best regards, Kyle Hsieh