Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp225441pxa; Tue, 11 Aug 2020 01:01:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/cngfJUZ+0VjuctBAylfBbLvkVRQHlI1pidF7gVW7sbbIfnQdqduix8NBwDvHRKvJS7jG X-Received: by 2002:a17:906:364e:: with SMTP id r14mr23979289ejb.295.1597132897559; Tue, 11 Aug 2020 01:01:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597132897; cv=none; d=google.com; s=arc-20160816; b=F+wXdPnE1vbOxvc2wb0FVJhYHY+EgO8H6qFsWpW5Uf8N8qNOgSa4M/33u8lPZL2TJ4 Txfw5rCm3mmRQrlw06fZTVsPqycpcACHzZ4iqwywT8avTp1NTmCUKBqvQgKj4L/Xj7Nl +AB/kFbt8J5Momxz7Okv4kBJTBQNdWKfilrdgG5wPVAbzef4HpTFrmjFbOH9CTzM9gN3 TQZI33s4uQeE0+sn1UEz59iUvNQ6WdsrGvY0DIsQJjRSQLY76OTQ7iTu4Gqo46Ef8/5P vi5yQ8MjU4Lr53xi8UZ5alg+XJS9LV+VxukunsklIVeoisTIka6IRGv03mBbQcJBW8NK BUiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=++FmaV0miWsY23KH91xbEXWWGAG8us/M5TNJevDjhP0=; b=kSFZrzTrcRfY7Nyo8zO9g8GfAKX2RcCAGOYZSCM4FAkIu9ByQZxeV2bfui3e+3OZ6J /AjVRkI1E+C/kz/kKLhvn2wNuM3oRBtcKj9Z1EgWxAyqcN5nTlPZiJ4J161auxmQT2hI pG/44MJiBoajwF4vyF3utBufFry4dQeapT1sPEmFNrh/PooKIfTvx/HDiHYSq20yYQg1 FdDGGb/UIHhBrejAS7lxdNiq/qb8Y7G8dRt/4+rCc4McCY/7bOz7rQdjjJgyGtEiqnuu ZDMYOZoE1TpKS1Umb0fwRtmCEEtPncE5cUZBuhs1NPQAFrPNsmpapyfzQt9xLec6MUBp 9JTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a18si13497509ejr.616.2020.08.11.01.01.14; Tue, 11 Aug 2020 01:01:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728239AbgHKIAo (ORCPT + 99 others); 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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