Re: [PATCH] net: qcom/emac: don't try to claim clocks on ACPI systems

2016-12-13 Thread Timur Tabi
On 12/13/2016 04:02 PM, Florian Fainelli wrote: No strong feelings either, it just seems easier and safer to move the check down in the function and make it return success rather than potentially affecting the error path within the caller of emac_clks_phase{1,2}_init here. I suppose that makes

Re: [PATCH] net: qcom/emac: don't try to claim clocks on ACPI systems

2016-12-13 Thread Florian Fainelli
On 12/13/2016 01:54 PM, Timur Tabi wrote: > On 12/13/2016 03:46 PM, Florian Fainelli wrote: >> Is there a reason why the check is not moved down inwo >> emac_clks_phase{1,2}_init functions? Do you anticipate other >> ACPI-related changes in the future that would warrant having this check >> moved a

Re: [PATCH] net: qcom/emac: don't try to claim clocks on ACPI systems

2016-12-13 Thread Timur Tabi
On 12/13/2016 03:46 PM, Florian Fainelli wrote: Is there a reason why the check is not moved down inwo emac_clks_phase{1,2}_init functions? Do you anticipate other ACPI-related changes in the future that would warrant having this check moved at a higher level? No, this is the last ACPI-related

Re: [PATCH] net: qcom/emac: don't try to claim clocks on ACPI systems

2016-12-13 Thread Florian Fainelli
On 12/13/2016 11:55 AM, Timur Tabi wrote: > On ACPI systems, clocks are not available to drivers directly. They are > handled exclusively by ACPI and/or firmware, so there is no clock driver. > Calls to clk_get() always fail, so we should not even attempt to claim > any clocks on ACPI systems. >

[PATCH] net: qcom/emac: don't try to claim clocks on ACPI systems

2016-12-13 Thread Timur Tabi
On ACPI systems, clocks are not available to drivers directly. They are handled exclusively by ACPI and/or firmware, so there is no clock driver. Calls to clk_get() always fail, so we should not even attempt to claim any clocks on ACPI systems. Signed-off-by: Timur Tabi --- drivers/net/ethernet