On Mon, Mar 18, 2019 at 04:45:19PM +0800, Chen-Yu Tsai wrote: > On Mon, Mar 18, 2019 at 4:42 PM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > > > Hi, > > > > On Mon, Mar 18, 2019 at 03:33:52PM +0800, Chen-Yu Tsai wrote: > > > From: Chen-Yu Tsai <wens@xxxxxxxx> > > > > > > Originally the SID e-fuses were thought to be in big-endian format. > > > Later sources show that they are in fact native or little-endian. > > > The most compelling evidence is the thermal sensor calibration data, > > > which is a set of one to three 16-bit values. In native-endian they > > > are in 16-bit cells with increasing offsets, whereas with big-endian > > > they are in the wrong order, and a gap with no data will show if there > > > are one or three cells. > > > > > > Switch to a native endian representation for the nvmem device. For the > > > H3, the register read-out method was already returning data in native > > > endian. This only affects the other SoCs. > > > > > > Signed-off-by: Chen-Yu Tsai <wens@xxxxxxxx> > > > > I thought only the newer SoCs were impacted by this issue? > > It is noticable on the newer SoCs. The old ones only have the 128-bit SID, > which could be read either way, as AFAIK it's just a serial number. > > If you think we should leave the old ones alone I can factor that in. IIRC, there was also the SoC ID in the SID on those SoCs as well, which we might have to use in the future so we'll want to make sure it is correct. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
