From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 879B9C433E0 for ; Tue, 11 Aug 2020 08:00:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66A2320656 for ; Tue, 11 Aug 2020 08:00:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728204AbgHKIAo (ORCPT ); Tue, 11 Aug 2020 04:00:44 -0400 Received: from retiisi.org.uk ([95.216.213.190]:45760 "EHLO hillosipuli.retiisi.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726397AbgHKIAn (ORCPT ); Tue, 11 Aug 2020 04:00:43 -0400 Received: from valkosipuli.localdomain (valkosipuli.retiisi.org.uk [IPv6:2a01:4f9:c010:4572::80:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 256DC634C87; Tue, 11 Aug 2020 11:00:10 +0300 (EEST) Received: from sailus by valkosipuli.localdomain with local (Exim 4.92) (envelope-from ) id 1k5PCb-0001ID-Uo; Tue, 11 Aug 2020 11:00:09 +0300 Date: Tue, 11 Aug 2020 11:00:09 +0300 From: Sakari Ailus To: Bartosz Golaszewski Cc: Sakari Ailus , "Rafael J. Wysocki" , linux-i2c , Wolfram Sang , linux-acpi@vger.kernel.org, Bingbu Cao , linux-media , Chiranjeevi Rapolu , Hyungwoo Yang , Arnd Bergmann , LKML , Greg Kroah-Hartman , Rajmohan Mani , Tomasz Figa Subject: Re: [PATCH v4 5/6] at24: Support probing while off Message-ID: <20200811080009.GE840@valkosipuli.retiisi.org.uk> References: <20200121134157.20396-1-sakari.ailus@linux.intel.com> <20200121134157.20396-6-sakari.ailus@linux.intel.com> <20200311085555.GH5379@paasikivi.fi.intel.com> <20200323213101.GB21174@kekkonen.localdomain> <20200810082549.GD840@valkosipuli.retiisi.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Bartosz, On Mon, Aug 10, 2020 at 08:12:00PM +0200, Bartosz Golaszewski wrote: > On Mon, Aug 10, 2020 at 10:26 AM Sakari Ailus wrote: > > > > [snip] > > > > > > > Rafael: I think that there are two issues with patch 1/5: > > > 1. It adds a very specific boolean flag to a structure that's meant to > > > be very general. As I pointed out in the i2c patch: at the very least > > > this could be made into an int storing flag values, instead of a > > > boolean field. But rather than that - it looks to me more like a > > > device (or bus) feature than a driver feature. Is there any ACPI flag > > > we could use to pass this information to the driver model without > > > changing the driver structure? > > > > To my knowledge there isn't. The fact that I²C devices are powered on for > > probe in ACPI based systems is specific to Linux kernel and not ACPI as > > such. > > > > The reason this needs to be in a generic struct is that the device's power > > state will be changed before any interaction with the driver takes place as > > it's the I²C framework that powers on the device. > > > > I'm not sure I'm following. Looking at patch 1/6 struct device already > exists so why can't this information be conveyed "per device" as > opposed to "per driver"? It's both driver and device. Suppose there's no indication of driver support. If you add the property telling the device shouldn't be powered on for probe, it won't be. And if the driver doesn't support that, probe will fail. That could happen e.g. when running an older kernel on a system that happens to specify this property for a given device. You could view this as a driver bug of course. I still think it's better to make driver support for this explicit, and avoid making this a practical problem anywhere. -- Kind regards, Sakari Ailus