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]
Message-ID: <20200831093109.GA4632@kunai>
Date:   Mon, 31 Aug 2020 11:31:09 +0200
From:   Wolfram Sang <wsa@...nel.org>
To:     Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc:     linux-i2c@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-acpi@...r.kernel.org, Bingbu Cao <bingbu.cao@...el.com>,
        linux-media@...r.kernel.org,
        Chiranjeevi Rapolu <chiranjeevi.rapolu@...el.com>,
        Hyungwoo Yang <hyungwoo.yang@...el.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rajmohan.mani@...el.com, Tomasz Figa <tfiga@...omium.org>,
        "Qiu, Tian Shu" <tian.shu.qiu@...el.com>
Subject: Re: [PATCH v6 1/6] i2c: Allow an ACPI driver to manage the device's
 power state during probe


> This patchset is really about changing the default of ACPI powering up I²C
> devices. On OF the drivers are indeed responsible for that.

So, maybe it makes sense then to move from 'device_property_present()'
to 'acpi_dev_get_property()' or something alike? To clearly tell this
binding is expected to be used with ACPI only. Then, we can skip this
discussion now and postpone it to when someone wants to use it with DT.
Which is hopefully never. Or does this approach have drawbacks?

> My original series had a field in struct device_driver for this purpose but
> Greg K-H suggested moving it to I²C instead:
> 
> <URL:https://lore.kernel.org/linux-acpi/20190826084343.GA1095@kroah.com/>

Ok, we can still factor it out in the unlikely case it needs to be done
again.

I still have the question via which tree this should go upstream?
It is probably more I2C than ACPI?


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ