LinuxLists.cc - Re: crypto-rockchip patches queued for 6.1

2022-12-28 11:08:26

Subject: Re: crypto-rockchip patches queued for 6.1

On Wed, Dec 28, 2022 at 11:37:16AM +0100, Diederik de Haas wrote:
> Hi,
>
> I couldn't find an existing mail with "[PATCH AUTOSEL 6.1 N/M] XYZ" to reply
> to, so I'm just sending an email like this. Hope that's ok.
>
> In https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/
> tree/queue-6.1 there are a number of patches which start with:
> crypto-rockchip- like crypto-rockchip-add-fallback-for-ahash.patch
>
> I guess they were (auto) selected as they contain a "Fixes: <commitid>" line.
> Those 7 patches are actually part of a larger patch set, see here:
> https://lore.kernel.org/all/[email protected]/
>
> All those patches have been merged into Linus' tree for 6.2 and there's a
> hotfix planned to be submitted for 6.2 here:
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/
> commit/?h=v6.2-armsoc/dtsfixes&id=53e8e1e6e9c1653095211a8edf17912f2374bb03
>
> Wouldn't it make more sense to queue the whole patch set for 6.1?
> Or (at least) the whole crypto rockchip part as mentioned here:
> https://lore.kernel.org/all/[email protected]/
> under the "Corentin Labbe (32):" label?

Please provide us a list of the specific git commits and in the order in
which you wish to see them applied and we will be glad to review them.

Looking at random links (that are wrapped and not able to be easily
used) is not going to work well.

thanks,

greg k-h

2022-12-28 12:01:54

by Diederik de Haas

[permalink] [raw]

Subject: Re: crypto-rockchip patches queued for 6.1

Attachments:

signature.asc (235.00 B)
This is a digitally signed message part.

2022-12-28 13:13:59

by Greg Kroah-Hartman

[permalink] [raw]

Subject: Re: crypto-rockchip patches queued for 6.1

2022-12-28 16:26:03

by Diederik de Haas

[permalink] [raw]

Subject: Re: crypto-rockchip patches queued for 6.1

On Wednesday, 28 December 2022 14:06:03 CET Greg KH wrote:
> > These commands will show them too:
> > git log --oneline -25 d1b5749687618d969c0be6428174a18a7e94ebd2 --reverse
> > git log --oneline -1 b136468a0024ea90c1259767c732eed12ce6edba
> > git log --oneline -2 8c701fa6e38c43dba75282e4d919298a5cfc5b05 --reverse
> > git log --oneline -5 9dcd71c863a6f6476378d076d3e9189c854d49fd --reverse
> >
> That's a lot, I'll look at them in a week or so after catching up with
> the rest of the stable queue.

Ok.

> Any reason why you all didn't properly mark these for the stable tree
> beforehand?

Insofar as this was (also) directed at me: I don't know how this works (yet).

I'm an interested 'bystander' who is interested in kernel 6.1 as that'll likely
be Debian Bookworm's kernel and rockchip/Pine64 devices.

As such I regularly look at the (6.1) queue and found those rockchip crypto
patches. I also tested this whole patch set to see whether it does what it
claimed; which it does.

> > And this is the hotfix, planned for 6.2 (unwrapped):
> > https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/c
> > ommit?id=53e8e1e6e9c1653095211a8edf17912f2374bb03
> fix for what?

Rob Herring noted a mismatch between the dt-bindings of the "reset-names"
property and the implementation in rk3399.dtsi in commit 8c701fa6e38c here:
https://lore.kernel.org/all/CAL_JsqJkHR+iccEf=5SU40Qq+cQpGZRq26TLzec-_Nr-Buu2KQ@mail.gmail.com/
("lave" -> "slave" and "crypto" -> "crypto-rst")

I may have used the word 'hotfix' incorrectly.

> When will it be sent to Linus?

I don't know, but I've seen several "Merge tag 'vX.Y-rockchip-dtsfixes' ..."
commits by Arnd Bergmann around rc6 or rc7 in the past.

Attachments:

signature.asc (235.00 B)
This is a digitally signed message part.

2023-02-03 09:33:30

by Greg Kroah-Hartman

[permalink] [raw]

Subject: Re: crypto-rockchip patches queued for 6.1

2023-02-03 11:09:19

by Diederik de Haas

[permalink] [raw]

Subject: Re: crypto-rockchip patches queued for 6.1

On Friday, 3 February 2023 10:33:16 CET Greg KH wrote:
> > That's a lot, I'll look at them in a week or so after catching up with
> > the rest of the stable queue.
>
> I looked at this now, and some of the more obvious "fixes" are already
> in the 6.1.y tree (and older kernels).
>
> So this series does not apply as-is, and it seems like there is a lot of
> extra stuff in this series that is not needed (like a MAINTAINER entry?)
>
> Can you provide a patch series, that has been tested and with your
> signed-off-by for whatever you feel still needs to be applied to the
> 6.1.y tree to resolve any existing bugs in 6.1.y for this driver (note,
> that does NOT mean that you can add new functionality that was never
> there...)

I don't feel confident (enough) that I could 'pull that off', especially since
it would effectively be a new patch set, which would likely not get the same
level of review/testing as the original one got.
It would also (effectively) add new functionality as the crypto engine (at
least on rk3328 and rk3399) did not work previously as among others they don't
have the crypto node in the dts files.

So I think it's better that the (new) patch set does not get applied to the
6.1 Stable release (series).

The reason I raised my initial question was because I did test (and provided
my Tested-By to) the patch set as a whole, not any single patch in isolation.

Regards,
Diederik

Attachments:

signature.asc (228.00 B)
This is a digitally signed message part.