RE: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe twice
From: Elad Nachman
Date: Thu Mar 21 2024 - 13:34:11 EST
> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Thursday, March 21, 2024 2:18 AM
> To: Elad Nachman <enachman@xxxxxxxxxxx>
> Cc: Taras Chornyi <taras.chornyi@xxxxxxxxxxx>; davem@xxxxxxxxxxxxx;
> edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx; pabeni@xxxxxxxxxx;
> kory.maincent@xxxxxxxxxxx; thomas.petazzoni@xxxxxxxxxxx;
> miquel.raynal@xxxxxxxxxxx; przemyslaw.kitszel@xxxxxxxxx;
> dkirjanov@xxxxxxx; netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe twice
>
> Prioritize security for external emails: Confirm sender and content safety
> before clicking links or opening attachments
>
> ----------------------------------------------------------------------
> On Wed, Mar 20, 2024 at 07:20:03PM +0200, Elad Nachman wrote:
> > From: Elad Nachman <enachman@xxxxxxxxxxx>
> >
> > Fix issues resulting from insmod, rmmod and insmod of the prestera
> > driver:
> >
> > 1. Call of firmware switch HW reset was missing, and is required
> > in order to make the firmware loader shift to the correct state
> > needed for loading the next firmware.
> > 2. Time-out for waiting for firmware loader to be ready was too small.
> > 3. memory referencing after freeing
> > 4. MAC addresses wrapping
> > 5. Missing SFP unbind (phylink release) of a port during the port release.
>
> I don't see any problems with 3-5. Maybe post them independent of the first
> 2 and they can be merged.
>
> Are you really saying it is impossible to determine if the hardware is in the
> boot loader waiting for firmware, or is running the firmware?
>
> Andrew
Originally, the pain point for Kory was the rmmod + insmod re-probing failure,
Which is only fixed by the first two commits, so I see little point in submitting 3-5 alone,
Without fixing Kory's problem.
The problem is not with the hardware, but with the existing firmware code on the
Firmware cpu, most probably secure-boot protected, which lacks the ABIs to report to
The kernel what is loaded, what version, what state, etc.
I agree that with better original design, we could have made a better work of avoiding
This lengthy reload, but at this point, I believe my options are quite limited here, unfortunately.
Elad.