Openembedded Core Discussions
 help / color / mirror / Atom feed
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.
> 
> 
> 



  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