On Mon, Apr 19, 2021 at 5:45 PM David Miller wrote:
>
> From: Adam Ford
> Date: Sat, 17 Apr 2021 08:23:29 -0500
>
> > The call to clk_disable_unprepare() can happen before priv is
> > initialized. This means moving clk_disable_unprepare out of
> > out_release i
On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven wrote:
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford wrote:
> > The AVB refererence clock assumes an external clock that runs
>
> reference
>
> > automatically. Because the Versaclock is wired to provide the
> &
The call to clk_disable_unprepare() can happen before priv is
initialized. This means moving clk_disable_unprepare out of
out_release into a new label.
Fixes: 8ef7adc6beb2("net: ethernet: ravb: Enable optional refclk")
Signed-off-by: Adam Ford
diff --git a/drivers/net/ethern
On Tue, Apr 13, 2021 at 2:33 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Mon, Apr 12, 2021 at 3:27 PM Adam Ford wrote:
> > For devices that use a programmable clock for the AVB reference clock,
> > the driver may need to enable them. Add code to find the optional
add the additional optional clock, and explicitly
name both of them.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Acked-by: Rob Herring
Reviewed-by: Sergei Shtylyov
---
V4: No Change
V3: No Change
V2: No Change
diff --git a/Documentation/devicetree/bindings/net/renesas
For devices that use a programmable clock for the AVB reference clock,
the driver may need to enable them. Add code to find the optional clock
and enable it when available.
Signed-off-by: Adam Ford
Reviewed-by: Andrew Lunn
---
V4: Eliminate the NULL check when disabling refclk, and add a
On Thu, Mar 4, 2021 at 2:08 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford wrote:
> > For devices that use a programmable clock for the AVB reference clock,
> > the driver may need to enable them. Add code to find the optional
On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven wrote:
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford wrote:
> > The AVB refererence clock assumes an external clock that runs
>
> reference
>
> > automatically. Because the Versaclock is wired to provide the
> &
The AVB refererence clock assumes an external clock that runs
automatically. Because the Versaclock is wired to provide the
AVB refclock, the device tree needs to reference it in order for the
driver to start the clock.
Signed-off-by: Adam Ford
---
V3: New to series
diff --git a/arch/arm64
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
V3: No Change
V2: No Change
diff --git a/arch/arm/boot/dts/r8a7742
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
V3: No Change
V2: No Change
diff --git a/arch/arm64/boot/dts/renesas
add the additional optional clock, and explicitly
name both of them.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Acked-by: Rob Herring
---
V3: No Change
V2: No Change
diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
b/Documentation/devicetree/bindings/net
For devices that use a programmable clock for the AVB reference clock,
the driver may need to enable them. Add code to find the optional clock
and enable it when available.
Signed-off-by: Adam Ford
---
V3: Change 'avb' to 'AVB'
Remove unnessary else statement and p
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1 +
arch/arm64/boot/dts
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7742.dtsi | 1 +
arch/arm/boot/dts/r8a7743.dtsi
For devices that use a programmable clock for the avb reference clock,
the driver may need to enable them. Add code to find the optional clock
and enable it when available.
Signed-off-by: Adam Ford
---
drivers/net/ethernet/renesas/ravb.h | 1 +
drivers/net/ethernet/renesas/ravb_main.c | 8
add the additional optional clock, and explicitly
name both of them.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Acked-by: Rob Herring
---
.../devicetree/bindings/net/renesas,etheravb.yaml | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
V2: Change name from
On Mon, Jan 4, 2021 at 4:41 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> > The bindings have been updated to support two clocks, but the
> > original clock now requires the name fck to distinguish it
> > from th
The bindings have been updated to support two clocks, but the
original clock now requires the name fck to distinguish it
from the other.
Signed-off-by: Adam Ford
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet
to add the additional optional clock, and explicitly
name both of them.
Signed-off-by: Adam Ford
---
.../devicetree/bindings/net/renesas,etheravb.yaml | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
b
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
---
arch/arm/boot/dts/r8a7742.dtsi | 1 +
arch/arm/boot/dts/r8a7743.dtsi | 1 +
arch/arm/boot/dts/r8a7744
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 1 +
arch
On Mon, Dec 14, 2020 at 4:05 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Sun, Dec 13, 2020 at 5:18 PM Adam Ford wrote:
> > The SoC expects the txv_refclk is provided, but if it is provided
> > by a programmable clock, there needs to be a way to get and enable
> &
On Sat, Dec 12, 2020 at 11:55 AM Sergei Shtylyov
wrote:
>
> Hello!
>
> On 12.12.2020 19:56, Adam Ford wrote:
>
> > The SoC expects the txv_refclk is provided, but if it is provided
> > by a programmable clock, there needs to be a way to get and enable
> > this
The SoC expects the txv_refclk is provided, but if it is provided
by a programmable clock, there needs to be a way to get and enable
this clock to operate. It needs to be optional since it's only
necessary for those with programmable clocks.
Signed-off-by: Adam Ford
diff --git a/driver
I am not sure if anyone else has seen this. If not, I'll bisect, but
the AM3517 ethernet seems to have died, and it's throwing some errors
[2.708933] davinci_mdio davinci_mdio.0: failed to get device clock
[2.715363] davinci_mdio: probe of davinci_mdio.0 failed with error -2
[snip]
[
On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford wrote:
> On Tue, May 9, 2017 at 9:14 AM, Rob Herring wrote:
>> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach wrote:
>>> Hi Rob,
>>>
>>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>>>
On Tue, May 9, 2017 at 9:14 AM, Rob Herring wrote:
> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach wrote:
>> Hi Rob,
>>
>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford wrote:
>>> > On Sun, A
On Thu, Sep 7, 2017 at 3:36 AM, Sekhar Nori wrote:
> On Thursday 07 September 2017 03:11 AM, Adam Ford wrote:
>> On Mon, Sep 4, 2017 at 11:42 PM, Sekhar Nori wrote:
>>> Hi Adam,
>>>
>>> On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote:
>>>>
On Mon, Sep 4, 2017 at 11:42 PM, Sekhar Nori wrote:
> Hi Adam,
>
> On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote:
>>> I wonder if U-Boot isn't pushing something to Linux because it doesn't
>>> appear to be running some of the da850 specific code even when I run
>>> linux-next. Can you t
On Tue, Aug 29, 2017 at 10:20 AM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori wrote:
>> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori wrote:
>>>> On Tuesday 29 August 2017 03:53 PM, Adam
On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori wrote:
> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori wrote:
>>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar
On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori wrote:
> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori wrote:
>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>> * Adam Ford [170828 13:33]:
>>
On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori wrote:
> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>> * Adam Ford [170828 13:33]:
>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>> wrote:
>>>> Cc: Sekhar
>>>>
>>&g
On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
wrote:
> Cc: Sekhar
>
> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>
>> The davinvi_emac MAC address seems to attempt a call to
>> ti_cm_get_macid in cpsw-common.c but it returns the message
>> 'davinci_ema
The davinvi_emac MAC address seems to attempt a call to
ti_cm_get_macid in cpsw-common.c but it returns the message
'davinci_emac davinci_emac.1: incompatible machine/device type for
reading mac address ' and then generates a random MAC address.
The function appears to lookup varions boards using
On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel wrote:
> Hi,
>
> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring wrote:
>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> &g
On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring wrote:
> This series adds serdev support to the HCI LL protocol used on TI BT
> modules and enables support on HiKey board with with the WL1835 module.
> With this the custom TI UIM daemon and btattach are no longer needed.
Without UIM daemon, what inst
On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring wrote:
> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed for
> BT. This mirrors other d
39 matches
Mail list logo
