Messages in this thread | | | Date | Tue, 5 Feb 2019 19:47:23 +0100 | From | Miquel Raynal <> | Subject | Re: [PATCH net-next v3] net: dsa: mv88e6xxx: Prevent suspend to RAM |
| |
Hi Vivien,
Vivien Didelot <vivien.didelot@gmail.com> wrote on Tue, 5 Feb 2019 11:28:57 -0500:
> Hi Miquel, > > On Tue, 5 Feb 2019 12:07:28 +0100, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > +/* There is no suspend to RAM support at DSA level yet, the switch configuration > > + * would be lost after a power cycle so prevent it to be suspended. > > + */ > > +static int __maybe_unused mv88e6xxx_suspend(struct device *dev) > > +{ > > + return -EOPNOTSUPP; > > +} > > + > > +static int __maybe_unused mv88e6xxx_resume(struct device *dev) > > +{ > > + return 0; > > +} > > The code looks good but my only concern is -EOPNOTSUPP. In this > context this code is specific to callbacks targeting bridge and > switchdev, while the dev_pm_ops are completely parallel to DSA. > > It is intuitive but given Documentation/power/runtime_pm.txt, this > will default to being interpreted as a fatal error, while -EBUSY > seems to keep the device in an 'active' state in a saner way. > > I don't understand yet how to properly tell PM core that suspend to RAM > isn't supported. If an error code different from -EAGAIN or -EBUSY > is the way to go, I'm good with it:
I do share your concern and I went through the Documentation but I did not find a unified way to tell the PM core the feature is unsupported.
By grepping code, I realized returning -EOPNOTSUPP was a recurrent alternative so here we are. I also considered -EBUSY but it seems more like a "I cannot right now" and -EAGAIN which is more a "try again soon". Anyway, no matter the error code returned, I'm not sure if the PM core actually cares?
> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> > > > Thanks, > > Vivien
Thanks, Miquèl
| |