[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r3fimb7l.fsf@dell.be.48ers.dk>
Date: Thu, 10 Mar 2016 19:36:46 +0100
From: Peter Korsgaard <peter@...sgaard.com>
To: Joseph CHANG <josright123@...il.com>
Cc: Peter Korsgaard <jacmet@...site.dk>, netdev@...r.kernel.org,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
Joseph Chang <joseph_chang@...icom.com.tw>
Subject: Re: [PATCH 2/3] dm9601: manage eeprom to assure the chip for correct operation
>>>>> "Joseph" == Joseph CHANG <josright123@...il.com> writes:
> Add to maintain variant eeprom adapters which may have not right
> dm962x's format.
> Signed-off-by: Joseph CHANG <josright123@...il.com>
> +static void dm_render_begin(struct usbnet *dev)
> +{
> + /* Render eeprom if need, WORD3 render, set D[15:14] 01b */
> + dm_eeprom_render(dev, 3, 0x4000, 0xc000);
> + /* Render eeprom if need, WORD7 render, clear D[10] */
> + dm_eeprom_render(dev, 7, 0x0000, 0x0400);
> + /* Render eeprom if need, WORD11 render, need 0x005a */
> + dm_eeprom_render(dev, 11, 0x005a, 0xffff);
> + /* Render eeprom if need, WORD12 render, need 0x0007 */
> + dm_eeprom_render(dev, 12, DM_EP3I_VAL, 0xffff);
With render I guess you mean something like fixup? I'm not sure we want
to do this automatically without an explicit action from the user.
How common are these adapters without valid eeprom? What happens if the
eeprom content isn't fixed?
Do we need to reset the device once the eeprom is updated?
--
Bye, Peter Korsgaard
Powered by blists - more mailing lists