On 2019-02-24 15:57, Andrew Lunn wrote:
>> +static int mdio_mux_multiplexer_remove(struct platform_device *pdev)
>> +{
>> +struct mdio_mux_multiplexer_state *s = platform_get_drvdata(pdev);
>> +
>> +mdio_mux_uninit(s->mux_handle);
>
> I've never used the multiplexer framework before. But i
On 2019-02-21 16:17, Andrew Lunn wrote:
config MDIO_BUS_MUX
tristate
depends on OF_MDIO
+ select MULTIPLEXER
help
This module provides a driver framework for MDIO bus
multiplexers which connect one of several child MDIO busses
>>>
>>> Hi Panka
automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++
include
Signed-off-by: Peter Rosin
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 5 ++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++---
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850
second patch simplifies one of these platform drivers, since it
can now rely on the SSC to register itself with ASoC. However, this
may not be a possible simplification for other, older, drivers since
it also requires device tree changes.
Cheers,
Peter
Peter Rosin (2):
misc: atmel-ssc: register as
On 2016-10-10 21:54, Rob Herring wrote:
> On Fri, Oct 07, 2016 at 06:18:32PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev
>>
>> Add binding document for the i2c driver of SAM FPGA.
>>
>> Signed-off-by: Georgi Vlaev
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou
>> -
On 2016-10-07 17:18, Pantelis Antoniou wrote:
> From: Georgi Vlaev
>
> Add device tree bindings document for the SAM MDIO block
> present in Juniper's SAM FPGA.
>
> Signed-off-by: Georgi Vlaev
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou
> ---
> Documentation/devicetree/b
On 2016-09-21 09:56, Alexander Shiyan wrote:
>> Среда, 21 сентября 2016, 9:57 +03:00 от Yangbo Lu :
>>
>> From: Arnd Bergmann < a...@arndb.de >
>>
>> We keep running into cases where device drivers want to know the exact
>> version of the a SoC they are currently running on. In the past, this has
>
