On 07.01.2024 20:24, Sergey Shtylyov wrote: > On 1/5/24 11:23 AM, Claudiu wrote: > >> From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> >> >> The runtime PM implementation will disable clocks at the end of >> ravb_probe(). As some IP variants switch to reset mode as a result of >> setting module standby through clock disable APIs, to implement runtime PM >> the resource parsing and requesting are moved in the probe function and IP >> settings are moved in the open function. This is done because at the end of >> the probe some IP variants will switch anyway to reset mode and the >> registers content is lost. Also keeping only register specific operations >> in the ravb_open()/ravb_close() functions will make them faster. >> >> Commit moves IRQ requests to ravb_probe() to have all the IRQs ready when >> the interface is open. As now IRQs gets and requests are in a single place >> there is no need to keep intermediary data (like ravb_rx_irqs[] and >> ravb_tx_irqs[] arrays or IRQs in struct ravb_private). > > There's one thing that you probably didn't take into account: after > you call request_irq(), you should be able to handle your IRQ as it's > automatically unmasked, unless you pass IRQF_NO_AUTOEN to request_irq(). > Your device may be held i reset or even powered off but if you pass IRQF_SHARED to request_irq() (you do in a single IRQ config), you must > be prepared to get your device's registers read (in order to ascertain > whether it's your IRQ or not). And you can't even pass IRQF_NO_AUTOEN > along with IRQF_SHARED, according to my reading of the IRQ code... Good point! > >> This is a preparatory change to add runtime PM support for all IP variants. > > I don't readily see why this is necessary for the full-fledged RPM > support... I tried to speed up the ravb_open()/ravb_close() but missed the IRQF_SHARED IRQ. As there is only one IRQ requested w/ IRQF_SHARED, are you OK with still keeping the rest of IRQs handled as proposed by this patch? > >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> > > Unfortunately, I have to NAK this patch, at least in its current > form... > > [...] > > MBR, Sergey
