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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E5F5DC25B08 for ; Wed, 17 Aug 2022 06:45:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=W9UM92oQjBV4nAth2r/d85KEb+6C0iLJa5Y0Yzoq0ao=; b=rDrBC++V8RLgp+ GiKrBLKQJWduO8d/huCFmguLxkk7JGmTFf6D2+oT60TRzTDtPiNo7mwjN2+wUqbjUDowmVA4VRLph VJDBWRZQ2PkzuSBo7PfLtwu5u2JqHF/NDxow0n7GbG+6WD3sePA4kSoJOLm2/eYfusDKVS2uvBxNK 3IVOxBIBt4yAwqfHWmXbX8kyHtrEhxv1u1dm2+jMQdFrY5OMiaQJqGPeemNzdyzVPnoUWUHJYRggE PcxipjdD7rJ0JdNf4VAS4W+XiLXk18VhwF8oZT0cVXiPbqaQhilShGzuNWcIHKMxNLpdj7UH8zYeS ad4L8PmGUTjvWTOkRCLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOCmo-00CA9u-9M; Wed, 17 Aug 2022 06:44:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOCml-00CA8U-My for linux-arm-kernel@lists.infradead.org; Wed, 17 Aug 2022 06:44:17 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1250860CEC; Wed, 17 Aug 2022 06:44:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D298C433D6; Wed, 17 Aug 2022 06:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660718654; bh=IEC1gV3N39NMhQ3mBHUUZstUlnMF4Nl/M3D+D2V5PZ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A0yeE7NWJFfwDWUMDymU+v0vOrH/cHwVCu4ocahR+kYd7KmHGvwvfFcDR0sItdoin mRJpcZwVbm/F76zIGzeNKT2nsMEE8b49Nl7JolX8seOXpugiYaMq8B795GB0BDdqoK zTcMZTShe8kFxzTHeXIXa06upQAtZoI2HiuapC34= Date: Wed, 17 Aug 2022 08:44:09 +0200 From: Greg Kroah-Hartman To: Saravana Kannan Cc: Mark Brown , Michael Walle , Geert Uytterhoeven , Ulf Hansson , kernelci-results@groups.io, bot@kernelci.org, gtucker@collabora.com, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org Subject: Re: next/master bisection: baseline.bootrr.intel-igb-probed on kontron-pitx-imx8m Message-ID: References: <62eed399.170a0220.2503a.1c64@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220816_234415_806393_22840448 X-CRM114-Status: GOOD ( 26.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 16, 2022 at 10:48:04AM -0700, Saravana Kannan wrote: > On Tue, Aug 16, 2022 at 10:26 AM Mark Brown wrote: > > > > On Fri, Aug 12, 2022 at 04:54:25PM -0700, Saravana Kannan wrote: > > > > > While you are here, I'm working towards patches on top of [1] where > > > fw_devlink will tie the sync_state() callback to each regulator. Also, > > > i realized that if you can convert the regulator_class to a > > > regulator_bus, we could remove a lot of the "find the supply for this > > > regulator when it's registered" code and let device links handle it. > > > Let me know if that's something you'd be okay with. It would change > > > the sysfs path for /sys/class/regulator and moves it to > > > /sys/bus/regulator, but not sure if that's considered an ABI breakage > > > (sysfs paths change all the time). > > > > That *does* sound like it'd be an ABI issue TBH. I thought there was > > support for keeping class around even when converting to a bus > > Ah, this is news to me. I'll poke around to see if the path can be > maintained even after converting a class to a bus. Which specific path are you worried about? > (though > > TBH given how entirely virtual this stuff us it seems odd that we'd be > > going for a bus). > > I'm going for a bus because class doesn't have a distinction between > "device has been added" and "device is ready if these things happen". > There's nothing to say that a "bus" has to be a real hardware bus. busses are not always real hardware busses, look at the virtual bus code for examples of that. Classes are "representations of a type of device that userspace interacts with" like input, sound, tty, and so on, that are independant of the type of hardware bus or device it is. Do all regulators need to interact with userspace in a common way? If so, it's a class, if not, maybe a bus would work, but that takes more code than a class so it should only be done if you really need it for some odd reason. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel