Hi, > > -----Original Message----- > > From: Fabio Estevam [mailto:festevam@xxxxxxxxx] > > Sent: 2015年7月29日 17:11 > > To: Wang Shenwei-B38339 > > Cc: Greg Kroah-Hartman; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; > > linux-serial@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH v3 1/1] Serial: imx: add dev_pm_ops to support suspend to > > ram/disk > > > > On Wed, Jul 29, 2015 at 6:54 PM, Shenwei Wang <Shenwei.Wang@xxxxxxxxxxxxx> > > wrote: > > > > > I am very interesting to know if you could provide an example > > > condition that may cause clk_enable failed in this callback function? > > > > Let's check clk_enable definition: > > > > int clk_enable(struct clk *clk) > > { > > unsigned long flags; > > int ret; > > > > if (!clk) > > return 0; > > > > flags = clk_enable_lock(); > > ret = clk_core_enable(clk->core); > > clk_enable_unlock(flags); > > > > return ret; > > } > > > > So if I see it right it returns 'int' not 'void' ;-) > > Actually, the function shows even if it is in error status like the parameter "clk" is null the return value is zero. > Inside the function "clk_core_enable", if everything goes smooth, it still returns zero. > A NULL clk is a valid clk per definition. > Moreover, this patch does not care about the return value of clk_enable, whatever value it returns, the following codes keep > the same. > Nevertheless it would be good to inform the user of a failure, since that may affect the system's stability after returning from suspend. Even if the current implementation of a function cannot return an error code in some specific circumstance, that doesn't mean that this will be always the case. Thus, checking the return code and acting upon it is always advisable. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@xxxxxxxxxxxxxxxxxxx ___________________________________________________________ -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
