From: Mike Looijmans <mike.looijmans@topic.nl>
To: Martin Jansa <martin.jansa@gmail.com>,
Andre McCurdy <armccurdy@gmail.com>
Cc: daiane.angolini@nxp.com, patches@linaro.org,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM
Date: Fri, 24 Aug 2018 12:43:36 +0200 [thread overview]
Message-ID: <75f6f971-cc25-4828-d17d-aa3d04b259cc@topic.nl> (raw)
In-Reply-To: <CA+chaQeR5fARUq_y+SKU+YBg1psK-aV4efXbq7+aY+-FaLRcig@mail.gmail.com>
I think this should be solved in the driver actually. It probably "knows"
which variant is there (or could be taught using devicetree or so).
On 24-08-18 11:04, Martin Jansa wrote:
> One way to keep it allarch would be to package
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
> in 2 separate packages and handle
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
> symlink with update-alternatives
>
> most MACHINEs won't install either of these packages and those which need it
> will pull the right one (e.g. through MACHINE_EXTRA_RRECOMMENDS).
>
> In worst case someone will try to install both packages and based on u-a
> priority one of them will win (use higher priority for the more common version).
>
> Cheers,
>
> On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy <armccurdy@gmail.com
> <mailto:armccurdy@gmail.com>> wrote:
>
> On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin <ryan.harkin@linaro.org
> <mailto:ryan.harkin@linaro.org>> wrote:
> >
> > So now the ln issue is resolved, I'm not convinced my MACHINEOVERRIDES is
> > the correct approach. Does anyone have any feedback on how I can improve
> > that?
>
> If you want to make a configurable symlink then perhaps the more usual
> approach would be to just use a variable in the linux-firmware recipe
> to weakly define a default target for the symlink. Machine config
> files could then either do nothing (ie use the default) or provide
> their own value. For example, in the linux-firmware recipe:
>
> BCM43430_NVRAM_SYMLINK ?= "brcmfmac43430-sdio.AP6212.txt"
>
> FILES_${PN}-bcm43430-nvram = " \
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt \
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt \
> "
>
> do_install() {
> ...
> ln -sf ${BCM43430_NVRAM_SYMLINK}
> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
> }
>
> And then in the machine config files of machines which need the MUR1DX
> firmware instead of the default, add:
>
> BCM43430_NVRAM_SYMLINK = "brcmfmac43430-sdio.MUR1DX.txt"
>
> However... note that currently the linux-firmware recipe is
> architecture independent (ie it won't be rebuilt if the target is
> changed). Adding a machine specific symlink is going to cause problems
> with that, so the above is still not a full solution.
>
>
>
next prev parent reply other threads:[~2018-08-25 9:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-22 16:30 [RFC 0/3] Adding BCM43430 NVRAM files Ryan Harkin
2018-08-22 16:30 ` [RFC 1/3] linux-firmware: upgrade to 1d17c18 revision Ryan Harkin
2018-08-22 16:30 ` [RFC 2/3] linux-firmware: add BCM43430 nvram files Ryan Harkin
2018-08-22 16:30 ` [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM Ryan Harkin
2018-08-22 16:41 ` Martin Jansa
2018-08-22 16:47 ` Ryan Harkin
2018-08-22 16:56 ` Martin Jansa
2018-08-22 17:11 ` Ryan Harkin
2018-08-22 19:02 ` Martin Jansa
2018-08-22 20:10 ` Ryan Harkin
2018-08-22 20:36 ` Khem Raj
2018-08-22 21:52 ` Ryan Harkin
2018-08-22 20:42 ` Andre McCurdy
2018-08-22 21:56 ` Ryan Harkin
2018-08-22 22:55 ` Andre McCurdy
2018-08-23 6:12 ` Ryan Harkin
2018-08-23 6:39 ` Martin Hundebøll
2018-08-23 7:08 ` Ryan Harkin
2018-08-23 7:19 ` Andre McCurdy
2018-08-23 15:58 ` Khem Raj
2018-08-23 7:06 ` Andre McCurdy
2018-08-23 7:17 ` Ryan Harkin
2018-08-23 7:34 ` Andre McCurdy
2018-08-23 7:36 ` Ryan Harkin
2018-08-23 8:15 ` Ryan Harkin
2018-08-24 2:53 ` Andre McCurdy
2018-08-24 9:04 ` Martin Jansa
2018-08-24 10:43 ` Mike Looijmans [this message]
2018-08-28 10:54 ` Ryan Harkin
2018-08-24 10:50 ` Ryan Harkin
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=75f6f971-cc25-4828-d17d-aa3d04b259cc@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=armccurdy@gmail.com \
--cc=daiane.angolini@nxp.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patches@linaro.org \
/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