lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54255692.8020402@st.com>
Date:	Fri, 26 Sep 2014 14:05:38 +0200
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
	David Miller <davem@...emloft.net>
Cc:	"rayagond@...avyalabs.com" <rayagond@...avyalabs.com>,
	"vbridgers2013@...il.com" <vbridgers2013@...il.com>,
	"wens@...e.org" <wens@...e.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	"tobias.johannes.klausmann@....thm.de" 
	<tobias.johannes.klausmann@....thm.de>
Subject: Re: [PATCH] net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK
 is selected

On 9/24/2014 12:48 PM, Kweh, Hock Leong wrote:
>> -----Original Message-----
>> From: Giuseppe CAVALLARO [mailto:peppe.cavallaro@...com]
>> Sent: Wednesday, September 24, 2014 2:10 PM
>>>
>>> Hi peppe,
>>>
>>> Appreciate for the explanation. Just to clarify that I am not asking not to
>> pass in the priv->stmmac_clk.
>>> In fact, the fix will fail at case 2 if driver cannot obtain the priv->stmmac_clk,
>> but just not the case 1.
>>> For case 1, seem like it does not require the stmmac_clk then I think
>>> it should be OK not to fail it when driver did not get stmmac_clk but have
>> the clk_csr set.
>>
>> ok we can do that but this clock is also managed when the iface is down.
>> Maybe it could be convenient to manage it for power consumption.
>> What do you think?
>
> Hi peppe,
>
> I don't really get what you mean here. Are you telling that you are OK with the fix?
> Or you are referring to the bottom idea which introduce clock registration APIs to
> stmmac_pci driver?

I just meant that if no clock is passed then the probe doesn't fail and
we can keep a dev_warn. Pls surround the code with a comment and repost
the patch. Let me know and sorry for the delay on replying.

peppe

>
> Regarding the power management, isn't this taking care by the PCI framework itself
> for the PCI devices / PCI cards?
>
> Sorry, may be would need you to provide a big picture to this. Thanks. :)
>
>>
>>> Anyway, I can change the fix by adding the clock registration APIs
>>> being call at the stmmac_pci.c probe there before calling
>>> stmmac_dvr_probe. By doing this, it created a dependency to the pci
>>> driver that must have CONFIG_HAVE_CLK to be turned on. Besides, I
>> would need you guys to provide me information on other platforms about
>> what is the best value to set? Can I just set to zero since the stmmac_pci
>> driver is always using the priv->plat->clk_csr?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ