> -----Original Message----- > From: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > Sent: Thursday, February 8, 2024 8:09 AM > Subject: RE: [PATCH net-next 4/5] net: ravb: Do not apply RX checksum > settings to hardware if the interface is down > > Hi Sergey, > > > -----Original Message----- > > From: Sergey Shtylyov <s.shtylyov@xxxxxx> > > Sent: Wednesday, February 7, 2024 8:50 PM > > Subject: Re: [PATCH net-next 4/5] net: ravb: Do not apply RX checksum > > settings to hardware if the interface is down > > > > On 2/7/24 3:07 PM, Claudiu wrote: > > > > > From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> > > > > > > Do not apply the RX checksum settings to hardware if the interface > > > is > > down. > > > In case runtime PM is enabled, and while the interface is down, the > > > IP will be in reset mode (as for some platforms disabling the clocks > > > will switch the IP to reset mode, which will lead to losing > > > registers > > > content) and > > > > The register contents? I thought I'd pointed out all of these... > > > > > applying settings in reset mode is not an option. Instead, cache the > > > RX checksum settings and apply them in ravb_open() through > > ravb_emac_init(). > > > This has been solved by introducing pm_runtime_active() check. The > > > device runtime PM usage counter has been incremented to avoid > > > disabling the device clocks while the check is in progress (if any). > > > > > > Commit prepares for the addition of runtime PM. > > > > > > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> > > > > Reviewed-by: Sergey Shtylyov <s.shtylyov@xxxxxx> > > > > I'm afraid such check now needs to be added to > > ravb_set_features_gbeth() that's populated by Biju Das' checksum > > patches (which I've already ACKed)... > > You mean this check to be moved to ravb_set_features_rcar() instead of > ravb_set_rx_csum() as ravb_set_rx_csum() is called in receive path as well > which is interface up case. > ON reset mode, anyway we don't get any interrupts so there is no rx. > Then possibility is through set_features?? Or are you suggesting to have a common code to avoid code duplication? On interface down case, just cache the feature and return? Active cases, call the family specific callback()? Cheers, Biju