From: Marek Behun <marek.behun@nic.cz>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: Pavel Machek <pavel@ucw.cz>, Randy Dunlap <rdunlap@infradead.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-leds@vger.kernel.org
Subject: Re: linux-next: Tree for Apr 29 (drivers/leds/leds-turris-omnia)
Date: Mon, 29 Apr 2019 21:02:21 +0200 [thread overview]
Message-ID: <20190429210221.6e6c207e@nic.cz> (raw)
In-Reply-To: <ccf6596b-e645-a9b3-dfab-96ff14e8b70d@metux.net>
On Mon, 29 Apr 2019 20:49:59 +0200
"Enrico Weigelt, metux IT consult" <lkml@metux.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
prev parent reply other threads:[~2019-04-29 19:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190429190354.0d5e2e93@canb.auug.org.au>
2019-04-29 15:03 ` linux-next: Tree for Apr 29 (drivers/leds/leds-turris-omnia) Randy Dunlap
2019-04-29 15:32 ` Pavel Machek
2019-04-29 15:38 ` Marek Behun
2019-04-29 16:37 ` Pavel Machek
2019-04-29 16:44 ` Marek Behun
2019-04-29 16:53 ` Pavel Machek
2019-04-29 17:51 ` Enrico Weigelt, metux IT consult
2019-04-29 18:12 ` Pavel Machek
2019-04-29 18:49 ` Enrico Weigelt, metux IT consult
2019-04-29 19:02 ` Marek Behun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190429210221.6e6c207e@nic.cz \
--to=marek.behun@nic.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=lkml@metux.net \
--cc=pavel@ucw.cz \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).