linux-kernel - Re: [PATCH 07/13] drivers: Add generic match helper by ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 13 Jun 2019 00:07:34 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     rafael@...nel.org, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org, lenb@...nel.org,
        linux-acpi@...r.kernel.org, linux-spi@...r.kernel.org,
        broonie@...nel.org
Subject: Re: [PATCH 07/13] drivers: Add generic match helper by ACPI_COMPANION device

On Wednesday, June 12, 2019 11:43:38 AM CEST Suzuki K Poulose wrote:
> Hi Rafael,
> 
> On 06/06/2019 10:57, Rafael J. Wysocki wrote:
> > On Thu, Jun 6, 2019 at 11:28 AM Suzuki K Poulose <suzuki.poulose@....com> wrote:
> >>
> >>
> >>
> >> On 06/06/2019 10:17, Rafael J. Wysocki wrote:
> >>> On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@....com> wrote:
> >>>>
> >>>> Add a generic helper to match a device by the acpi device.
> >>>
> >>> "by its ACPI companion device object", please.
> >>
> >> Sure.
> >>
> >>>
> >>> Also, it would be good to combine this patch with the patch(es) that
> >>> cause device_match_acpi_dev() to be actually used.
> >>>
> >>> Helpers without any users are arguably not useful.
> >>
> >> Sure, the helpers will be part of the part2 of the whole series,
> >> which will actually have the individual subsystems consuming the
> >> new helpers. For your reference, it is available here :
> >>
> >> http://linux-arm.org/git?p=linux-skp.git;a=shortlog;h=refs/heads/driver-cleanup/v2
> >>
> >> e.g:
> >> http://linux-arm.org/git?p=linux-skp.git;a=commit;h=59534e843e2f214f1f29659993f6e423bef16b28
> >>
> >> I could simply pull those patches into this part, if you prefer that.
> > 
> > Not really.
> > 
> > I'd rather do it the other way around: push the introduction of the
> > helpers to part 2.
> 
> Sure, I will do that.
> 
> > 
> >> However, that would be true for the other patches in the part2.
> >> I am open to suggestions, on how to split the series.
> > 
> > You can introduce each helper along with its users in one patch.
> > 
> > This way the total number of patches will be reduced and they will be
> > easier to review IMO.
> > 
> 
> Wouldn't it make the merging complicated ? I am still not clear how we plan
> to merge the part 2 ?

I wouldn't worry about it that much.  Without review, you have nothing to merge anyway.

Technically, every patch with a new helper and its users can go in via the Greg's tree
as long as it has been ACKed by the maintainers of the code touched by it.