From: Greg K-H <gregkh@linuxfoundation.org>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Firmware files removal for 4.14-rc1
Date: Sat, 16 Sep 2017 10:53:52 -0700 [thread overview]
Message-ID: <0F296E69-5784-43AF-9970-7C1E5B44C6AC@linuxfoundation.org> (raw)
In-Reply-To: <20170916172051.GB1846@x4>
On September 16, 2017 10:20:51 AM PDT, Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
>On 2017.09.16 at 09:55 -0700, Greg KH wrote:
>> On Sat, Sep 16, 2017 at 08:25:03AM +0200, Markus Trippelsdorf wrote:
>> > On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote:
>> > > On 2017.09.15 at 11:56 -0700, Greg KH wrote:
>> > > > The following changes since commit
>569dbb88e80deb68974ef6fdd6a13edb9d686261:
>> > > >
>> > > > Linux 4.13 (2017-09-03 13:56:17 -0700)
>> > > >
>> > > > are available in the git repository at:
>> > > >
>> > > >
>git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/
>tags/firmware_removal-4.14-rc1
>> > > >
>> > > > for you to fetch changes up to
>5620a0d1aacd554ebebcff373e31107bb1ef7769:
>> > > >
>> > > > firmware: delete in-kernel firmware (2017-09-14 14:49:41
>-0700)
>> > > >
>> > > >
>----------------------------------------------------------------
>> > > > Firmware removal patch for 4.14-rc1
>> > > >
>> > > > Many many years ago (at the kernel summit in Boston), we all
>came to the
>> > > > agreement that the firmware/ tree should be dropped from the
>kernel, and
>> > > > everyone use the linux-firmware package instead. For some
>minor reason,
>> > > > David Woodhouse didn't send the pull request at that point in
>time, and
>> > > > everyone forgot about this.
>> > > >
>> > > > The topic came up in the hallway track at the Plumbers
>conference this
>> > > > week, so here's a single patch that drops the whole firmware
>tree. The
>> > > > last firmware update was back in 2013, and all distros have
>been using
>> > > > linux-firmware instead since at least that year, if not before.
> The
>> > > > only commits to that directory since 2013 was some kbuild
>fixups for
>> > > > various build tool issues.
>> > > >
>> > > > So lets finally drop this, we don't need to lug them around in
>the
>> > > > kernel source tree anymore, especially as no one wants or uses
>them.
>> > >
>> > > Well, it is one thing to drop the redundant binary blobs. But is
>another
>> > > to break perfectly fine setups that worked for years, e.g.:
>> > >
>> > > CONFIG_FW_LOADER=y
>> > > CONFIG_FIRMWARE_IN_KERNEL=y
>> > > CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin
>radeon/R600_rlc.bin"
>> > > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>> > >
>> > > Please restore the support for built-in firmware.
>>
>> How did that break anything? You are still using external firmware,
>> right?
>>
>> That just adds an empty Makefile that doesn't actually build anything
>> into the kernel. What error is this fixing? I did a bunch of build
>> tests with the patch that I submitted, and nothing failed.
>
>The external firmware has to be packaged before it can be included into
>the kernel. And this is what the Makefile in firmware/ does. It
>generates a *.gen.S for every firmware file in the
>CONFIG_EXTRA_FIRMWARE
>list. For example:
>
>markus@x4 linux % cat firmware/amd-ucode/microcode_amd.bin.gen.S
>/* Generated by firmware/Makefile */
> .section .rodata
> .p2align 3
>_fw_amd_ucode_microcode_amd_bin_bin:
> .incbin "/lib/firmware/amd-ucode/microcode_amd.bin"
>_fw_end:
> .section .rodata.str,"aMS",@progbits,1
> .p2align 3
>_fw_amd_ucode_microcode_amd_bin_name:
> .string "amd-ucode/microcode_amd.bin"
> .section .builtin_fw,"a",@progbits
> .p2align 3
> .quad _fw_amd_ucode_microcode_amd_bin_name
> .quad _fw_amd_ucode_microcode_amd_bin_bin
> .quad _fw_end - _fw_amd_ucode_microcode_amd_bin_bin
>
>This is then used to assemble *.bin.gen.o object files and finally
>firmware/built-in.o, that includes all firmware blobs.
>
>Without the firmware/Makefile nothing gets build and therefore no
>firmware gets included into the kernel. This may lead for example to a
>failure to start X11, because the firmware for the graphic card doesn't
>get loaded.
Ah doh, you are so right, sorry about that. I'm getting onto a flight right now but will send this on to Linus when I land in the morning.
thanks,
greg k-h
next prev parent reply other threads:[~2017-09-16 17:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 18:56 Greg KH
2017-09-16 4:51 ` Markus Trippelsdorf
2017-09-16 6:25 ` Markus Trippelsdorf
2017-09-16 16:55 ` Greg KH
2017-09-16 17:20 ` Markus Trippelsdorf
2017-09-16 17:53 ` Greg K-H [this message]
2017-09-16 17:56 ` Linus Torvalds
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=0F296E69-5784-43AF-9970-7C1E5B44C6AC@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®