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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 0002AC433FF for ; Thu, 1 Aug 2019 19:36:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CC1F320B7C for ; Thu, 1 Aug 2019 19:36:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564688219; bh=lypMJbkrxUynjgnSEFuwofVmlVKCWiCa3c8E0G4VfEA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=pztTghMLoTPUA1e0vAVSEzCQklDSn4ySmPQabXd50EHbNa3Qqu/Yamd1HQPD1m16I Z5ncZ629UHWsZk9OKWWiNxXMZIOrg9wngj/pETCQ8rAoIYcjMlPmelT2cPzCh9se6S Sp01UdzD0XbyoPi38uqOYy1hlyWC54HRxQKgFpmE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388684AbfHATg7 (ORCPT ); Thu, 1 Aug 2019 15:36:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:36362 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388609AbfHATg7 (ORCPT ); Thu, 1 Aug 2019 15:36:59 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2139520838; Thu, 1 Aug 2019 19:36:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564688218; bh=lypMJbkrxUynjgnSEFuwofVmlVKCWiCa3c8E0G4VfEA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Hqnd451LmueSlcqobyaOj3Px3+5vctxxTbMIf2bZbHq6v8Cv8r4odS8S+vPi3lOtu bON5FfervHBjLsYYb+LSR3gwalIPBmPD2hwq9XZI1PVyx4pvgWMBb88KXBaDYJD1To whsURxIydlhyNIENR6hf6JH7TGu6ZUDx6DEbE96A= Date: Thu, 1 Aug 2019 21:36:56 +0200 From: Greg Kroah-Hartman To: Stephen Boyd Cc: "Rafael J. Wysocki" , Tri Vo , "Rafael J. Wysocki" , Viresh Kumar , Hridya Valsaraju , Sandeep Patil , Kalesh Singh , Ravi Chandra Sadineni , LKML , Linux PM , "Cc: Android Kernel" Subject: Re: [PATCH v6] PM / wakeup: show wakeup sources stats in sysfs Message-ID: <20190801193656.GB24916@kroah.com> References: <6987393.M0uybTKmdI@kreacher> <5d42281c.1c69fb81.bcda1.71f5@mx.google.com> <5d423637.1c69fb81.62114.ca6f@mx.google.com> <5d4305df.1c69fb81.c4013.1950@mx.google.com> <5d433c91.1c69fb81.93f13.febc@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d433c91.1c69fb81.93f13.febc@mx.google.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Thu, Aug 01, 2019 at 12:25:04PM -0700, Stephen Boyd wrote: > Quoting Rafael J. Wysocki (2019-08-01 10:21:44) > > On Thu, Aug 1, 2019 at 5:31 PM Stephen Boyd wrote: > > > > > > BTW, paths in /sys/devices aren't supposed to matter too much. In this > > > case, I'd expect to see userspace looking at the /sys/class/wakeup path > > > to follow the symlink to figure out what device triggered a wakeup. It > > > can look at the 'device' symlink inside the directory for the wakeup > > > device to figure out which one it is. > > > > But if you go from the device, it would be good to be able to figure > > out which wakeup sources are associated with it and in the alarmtimer > > example you don't even see that it is a wakeup source without > > following the link. > > Userspace shouldn't go from the device path (/sys/devices/.../rtc0 in > this example). That's incorrect. Instead, userspace should go from the > /sys/class/wakeup/... path. It should iterate over all the devices in > the class path and look at the device pointers instead. > > # ls /sys/class/wakeup/*/device -l > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/alarmtimer/device -> ../../rtc0 > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup0/device -> ../../../a6f8800.usb > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup1/device -> ../../../a8f8800.usb > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup2/device -> ../../../cros-ec-rtc.1.auto > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup3/device -> ../../sbs-16-000b > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup4/device -> ../../../a88000.spi:ec@0:keyboard-controller > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup5/device -> ../../../spi10.0 > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup6/device -> ../../../gpio-keys > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup7/device -> ../../../1-1.1 > lrwxrwxrwx. 1 root root 0 Aug 1 12:13 /sys/class/wakeup/wakeup8/device -> ../../../1-1.2.4.1 > > > > > So the "wakeupN" virtual dev names for all wakeup source objects are > > less confusing IMO. > > > > It would be good to avoid the glue dir creation in all cases somehow too. > > I recall some differences between a bus_type and a class. Are you > suggesting to use a bus_type for the wakeup sources? I like the class > approach taken here to use different device names because it avoids the > name collisions, avoids making another attribute to express the name of > the wakeup source, and doesn't make a more heavyweight driver > abstraction on top of wakeup sources. This should be a class, as-is, not a bus type as these are all the same type of "interface" for many different individual devices. The difference between bus type and class is: - class is almost always how userspace sees the device, and cuts across types of devices. For example, a keyboard is a type of an input device, and it can be a serial, PS/2, bluetooth, or USB type of device. - a bus is a common type of devices usually at the hardware level, where a driver is needed to send class-specific commands down to a specific hardware device. Busses have drivers that bind a specific class to a specific device. For example, there is a USB bus, and it has USB drivers for things like a keyboard. That USB keyboard driver knows how to talk to the specific USB commands for the hardware and translate them into specific input calls for the input class. Hope this helps explain things better. thanks, greg k-h