[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190429210221.6e6c207e@nic.cz>
Date: Mon, 29 Apr 2019 21:02:21 +0200
From: Marek Behun <marek.behun@....cz>
To: "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc: Pavel Machek <pavel@....cz>, Randy Dunlap <rdunlap@...radead.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-leds@...r.kernel.org
Subject: Re: linux-next: Tree for Apr 29 (drivers/leds/leds-turris-omnia)
On Mon, 29 Apr 2019 20:49:59 +0200
"Enrico Weigelt, metux IT consult" <lkml@...ux.net> wrote:
> On 29.04.19 20:12, Pavel Machek wrote:
>
> >> Is that controller only built-in into some SoCs, or also available
> >> as a separate chip ?
> >
> > AFAIU.. separate chip, but runs firmware not likely to be available
> > outside Turris routers.
>
> hmm, if it's a separate chip, IMHO it should be selectable, so that
> anybody who puts that chip on his board can directly use it.
>
> --mtx
>
The chip is a cortex-m3 or something like that. What makes the LEDs
work in this specific way this driver uses is the firmware on the chip,
and that firmware is specific for Omnia.
It is possible that in the future someone makes a I2C controller
compatible with the API the Omnia firmware provides, but very unlikely.
I think it is reasonable to make the driver depend on MACH_ARMADA_38X
and in the unlikely scenario that someone makes a compatible
controller, the dependency can always be removed.
Marek
situation it is possible to
Powered by blists - more mailing lists