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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 6 Jun 2019 11:57:33 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH 07/13] drivers: Add generic match helper by ACPI_COMPANION device

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.

> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ