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:   Mon, 23 Nov 2020 15:41:47 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
        alsa-devel@...a-project.org, Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Shengjiu Wang <shengjiu.wang@....com>
Subject: Re: [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id
 table

On Mon, Nov 23, 2020 at 12:37:31PM +0000, Mark Brown wrote:
> On Mon, Nov 23, 2020 at 12:48:32PM +0200, Andy Shevchenko wrote:
> > On Sun, Nov 22, 2020 at 11:59:20AM +0100, Krzysztof Kozlowski wrote:
> > > On Fri, Nov 20, 2020 at 08:04:29PM +0000, Mark Brown wrote:
> 
> > > > Surely if that's the desired outcome the fix is to change the definition
> > > > of of_match_ptr() such that it leaves the reference with CONFIG_ACPI,
> > > > perhaps hidden behind a config option for PRP0001?  That seems better
> > > > than going through the entire tree like this.
> 
> > > That could be indeed an easier way to achieve this.
> 
> > ...easier and wrong in my opinion. Not all drivers need that.
> > What the point to touch it in the driver which is OF-only?
> > (For IP which will quite unlikely to be present in ACPI world)
> > Or if the device will get the correct ACPI ID?
> 
> That feels like something that should be done with Kconfig dependencies
> like a direct OF dependency (possibly a !PRP0001 dependency?) for the
> driver or possibly with having a variant of_match_ptr() for things that
> really don't want to support PRP0001.  Just removing all the use of
> of_match_ptr() is both noisy and confusing in that it looks like it's
> creating issues to fix, it makes it hard to understand when and why one
> should use the macro.

My personal opinion is that in 99% using that macro (as well as ACPI_PTR() one)
is kinda mistake. We save dozen of bytes here and there by adding macro,
necessary ifdeferry, and dropping user to know that the driver might serve for
other device IDs as provided by OF / ACPI.

But I'm not the one who makes a decision here and I could see some want to have
a possibility to reduce their kernel memory footprint as much as possible.

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ