Re: Question for AMD patches

2020-12-17 Thread Greg K-H
On Fri, Dec 18, 2020 at 05:18:16AM +0800, Young Hsieh wrote:
> Hi Greg,
> 
> Thanks.  I am looking for the Essential, RAS & Perf patches for AMD Milan as 
> follows:
> 

I don't see anything here :(


> I am not familiar the rules for stable kernel patches, can you help to 
> elaborate ?  Thanks for your assistance! :) 

Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

for what stable kernels are all about.

thanks,

greg k-h


Re: Question for AMD patches

2020-12-17 Thread Greg K-H
What exact commits are you referring to?

And you do know about the rules for stable kernel patches, right?

greg k-h

On December 17, 2020 9:05:45 PM GMT+01:00, Young Hsieh  wrote:
>Hello, 
>
>This is Young Hsieh from Uber and currently I am in Uber infra team and in 
>charge of server system design. Nice to e-meet you!  :)
>
>We are working on AMD Milan platform with Debian, and notice there are some 
>patches for performance and security improvements, which are not implemented 
>in LTS kernels (4.14/4.19/5.4) yet. On our side, we prefer to use the general 
>LTS kernel release instead of a customized kernel, in case we will not align 
>on major fixes down the road. So would like to know if there is any plan to 
>backport these patches and if so, what is the timeline?  Thanks a lot again 
>for any advice.  
>
>Cheers,
>
>Young Hsieh
>Uber Hardware Engineer
>


Re: Linux 4.17.12

2018-08-04 Thread Greg K-H
On August 4, 2018 12:56:23 PM GMT+02:00, "Kai Wasserbäch" 
 wrote:
>Hey Greg,
>as with the 4.17.11 release, there is no signature file for the patch
>(. Could
>you
>please add a signature for that patch?
>
>Thanks,
>Kai

https://www.kernel.org/minor-changes-to-tarball-release-format.html


Re: Linux 4.17.12

2018-08-04 Thread Greg K-H
On August 4, 2018 12:56:23 PM GMT+02:00, "Kai Wasserbäch" 
 wrote:
>Hey Greg,
>as with the 4.17.11 release, there is no signature file for the patch
>(. Could
>you
>please add a signature for that patch?
>
>Thanks,
>Kai

https://www.kernel.org/minor-changes-to-tarball-release-format.html


Re: Linux 4.17.11

2018-07-29 Thread Greg K-H
On July 29, 2018 12:47:16 PM GMT+02:00, "Jörg-Volker Peetz"  
wrote:
>Greg KH wrote on 07/28/18 08:27:
>> I'm announcing the release of the 4.17.11 kernel.
>> 
>> All users of the 4.17 kernel series must upgrade.
>> 
>> The updated 4.17.y git tree can be found at:
>>
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>linux-4.17.y
>> and can be browsed at the normal kernel.org git web browser:
>>
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>> 
>> thanks,
>> 
>> greg k-h
>> 
>
>
>Hi Greg,
>
>your signature files did not yet appear on
>https://www.kernel.org/pub/linux/kernel/v4.x/ .
>Any idea?
>
>Regards,
>Jörg.

https://www.kernel.org/minor-changes-to-tarball-release-format.html


Re: Linux 4.17.11

2018-07-29 Thread Greg K-H
On July 29, 2018 12:47:16 PM GMT+02:00, "Jörg-Volker Peetz"  
wrote:
>Greg KH wrote on 07/28/18 08:27:
>> I'm announcing the release of the 4.17.11 kernel.
>> 
>> All users of the 4.17 kernel series must upgrade.
>> 
>> The updated 4.17.y git tree can be found at:
>>
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>linux-4.17.y
>> and can be browsed at the normal kernel.org git web browser:
>>
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>> 
>> thanks,
>> 
>> greg k-h
>> 
>
>
>Hi Greg,
>
>your signature files did not yet appear on
>https://www.kernel.org/pub/linux/kernel/v4.x/ .
>Any idea?
>
>Regards,
>Jörg.

https://www.kernel.org/minor-changes-to-tarball-release-format.html


Re: [PATCH] kbuild: rpm-pkg: delete firmware_install to fix build error

2017-09-18 Thread Greg K-H
On Mon, Sep 18, 2017 at 06:12:36PM +0900, Masahiro Yamada wrote:
> Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
> in-kernel firmware support, including "make firmware_install".
> 
> Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
> the error:
> 
>   make[2]: *** No rule to make target `firmware_install'.  Stop.
> 
> Commit df85b2d767aa ("firmware: Restore support for built-in firmware")
> restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
> is out of the scope of "make firmware_install".  So, the right thing to
> do is to kill the use of "make firmware_install".
> 
> Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
> Signed-off-by: Masahiro Yamada 

Acked-by: Greg Kroah-Hartman 


Re: [PATCH] kbuild: rpm-pkg: delete firmware_install to fix build error

2017-09-18 Thread Greg K-H
On Mon, Sep 18, 2017 at 06:12:36PM +0900, Masahiro Yamada wrote:
> Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
> in-kernel firmware support, including "make firmware_install".
> 
> Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
> the error:
> 
>   make[2]: *** No rule to make target `firmware_install'.  Stop.
> 
> Commit df85b2d767aa ("firmware: Restore support for built-in firmware")
> restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
> is out of the scope of "make firmware_install".  So, the right thing to
> do is to kill the use of "make firmware_install".
> 
> Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> ---
> 
>  scripts/package/mkspec | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)

Nice find, what's the odds the debian package "script" also needs this
fix?

thanks,

greg k-h


Re: [PATCH] kbuild: rpm-pkg: delete firmware_install to fix build error

2017-09-18 Thread Greg K-H
On Mon, Sep 18, 2017 at 06:12:36PM +0900, Masahiro Yamada wrote:
> Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
> in-kernel firmware support, including "make firmware_install".
> 
> Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
> the error:
> 
>   make[2]: *** No rule to make target `firmware_install'.  Stop.
> 
> Commit df85b2d767aa ("firmware: Restore support for built-in firmware")
> restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
> is out of the scope of "make firmware_install".  So, the right thing to
> do is to kill the use of "make firmware_install".
> 
> Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  scripts/package/mkspec | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)

Nice find, what's the odds the debian package "script" also needs this
fix?

thanks,

greg k-h


Re: [PATCH] kbuild: rpm-pkg: delete firmware_install to fix build error

2017-09-18 Thread Greg K-H
On Mon, Sep 18, 2017 at 06:12:36PM +0900, Masahiro Yamada wrote:
> Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
> in-kernel firmware support, including "make firmware_install".
> 
> Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
> the error:
> 
>   make[2]: *** No rule to make target `firmware_install'.  Stop.
> 
> Commit df85b2d767aa ("firmware: Restore support for built-in firmware")
> restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
> is out of the scope of "make firmware_install".  So, the right thing to
> do is to kill the use of "make firmware_install".
> 
> Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
> Signed-off-by: Masahiro Yamada 

Acked-by: Greg Kroah-Hartman 


Re: [GIT PULL] Firmware files removal for 4.14-rc1

2017-09-16 Thread Greg K-H
On September 16, 2017 10:20:51 AM PDT, Markus Trippelsdorf 
<mar...@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


Re: [GIT PULL] Firmware files removal for 4.14-rc1

2017-09-16 Thread Greg K-H
On September 16, 2017 10:20:51 AM PDT, Markus Trippelsdorf 
 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


Re: Bad signatures on recent stable releases

2017-05-14 Thread Greg K-H
On Sun, May 14, 2017 at 05:07:04PM +0200, Greg K-H wrote:
> Hi all,
> 
> The stable kernels I just released have bad signatures due to a mixup
> using pixz in the new kernel.org backend. It will be fixed soon...
> 
> Thanks to Konstantin for the quick response and to Brad and Michael
> for reporting the issue to me.

And this should all now be fixed up, if not, can someone please let us
know?

thanks,

greg k-h


Re: Bad signatures on recent stable releases

2017-05-14 Thread Greg K-H
On Sun, May 14, 2017 at 05:07:04PM +0200, Greg K-H wrote:
> Hi all,
> 
> The stable kernels I just released have bad signatures due to a mixup
> using pixz in the new kernel.org backend. It will be fixed soon...
> 
> Thanks to Konstantin for the quick response and to Brad and Michael
> for reporting the issue to me.

And this should all now be fixed up, if not, can someone please let us
know?

thanks,

greg k-h


Bad signatures on recent stable releases

2017-05-14 Thread Greg K-H
Hi all,

The stable kernels I just released have bad signatures due to a mixup using 
pixz in the new kernel.org backend. It will be fixed soon...

Thanks to Konstantin for the quick response and to Brad and Michael for 
reporting the issue to me.

thanks,

greg k-h


Bad signatures on recent stable releases

2017-05-14 Thread Greg K-H
Hi all,

The stable kernels I just released have bad signatures due to a mixup using 
pixz in the new kernel.org backend. It will be fixed soon...

Thanks to Konstantin for the quick response and to Brad and Michael for 
reporting the issue to me.

thanks,

greg k-h