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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 E425EC4360F for ; Thu, 4 Apr 2019 20:13:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B0F5120651 for ; Thu, 4 Apr 2019 20:13:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KdeOJ7Zk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729964AbfDDUNs (ORCPT ); Thu, 4 Apr 2019 16:13:48 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:35522 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729712AbfDDUNs (ORCPT ); Thu, 4 Apr 2019 16:13:48 -0400 Received: by mail-lj1-f196.google.com with SMTP id t4so3261613ljc.2 for ; Thu, 04 Apr 2019 13:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eYqmvWtL2dBFReY5T53bjMy7K/Ka+ZEzCOL2OVrFB08=; b=KdeOJ7ZkPcCwS03a2RdwMO7t9na8oge+X+usfZw/BjBMiDttJD8QrM4s0/ECeaVImc PQ2OmyLrAkfTbsL8Yjt9+3WVwJJkCjxeAsVgUUPJ7B6WD8700Z3pqtXZi2RvnrxvVPjF XKKvvAlgstqpk1tEd67bNKdposPNR6lci8CmtKJesl49XjpcZgMfJ9ULIj7AnOGCINqM MjJ0Dg15NYUF/NCksUnWgtxWwvsPqWCREsyFXr8x3/cFXZ8N39bNNXaqrjWNV7zJ+nQf rZxaxR6kc6LY/YzVnESvoJkFzlh1R6F8N1AM0uLO/JpO8hqlXc1e/kKALfeGIKEJwX69 l+Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eYqmvWtL2dBFReY5T53bjMy7K/Ka+ZEzCOL2OVrFB08=; b=oRS2Ks10G0Zo2Sp2ItzPSXGnNgBmrJTbL/T5BpiPYVyrlgnYM7Y/89eHeQ7vWzWT3P ZDwksSpuyOVDSN4ZyIJKxqnsuJ+bMRkeM6hZNkG5m4uCejQw3FQ2oXtjprzD/POWs8oC ePYrTRecLcHZAFX4g7bLkGyLUaM35CNouzssWtBK5ht2Nb8u85sgzYi0VMZ6X4BFSEmI qOTiNtnPtj3tVvTNQ+ZmYZT/VMxcXKEWmvG/1sEEQW38jKhOb13wHk8wRaFc4GGaLpVk ZQAJ6qp1ilABhqGmhMUpQkboo/n8Wt6K/nibJORWQhXmfrJl8QKlDQE42pXkA9TNjNkY rg3Q== X-Gm-Message-State: APjAAAXuBMLg/qx4oLTH33mU53bFtqtwGxLi1ETSpw/x1vOYOwk+zQQi 536rFl5nCOoaH7fZve+xm8Al2XRpxTzUE5uatF/DMQ== X-Google-Smtp-Source: APXvYqzR2SreJaBZ7ZLOKCZogo6k5iWjHqEIJkSWqqFwGCoeaLUwmLFVqMLnf5TxiW4mkVTFXU3corQUyQspb497SGI= X-Received: by 2002:a2e:219:: with SMTP id 25mr4544058ljc.34.1554408825519; Thu, 04 Apr 2019 13:13:45 -0700 (PDT) MIME-Version: 1.0 References: <20190404171007.160878-1-ncrews@chromium.org> <20190404171007.160878-3-ncrews@chromium.org> <20190404185919.GB27340@amd> <20190404191931.GA29984@amd> <20190404200658.GD29984@amd> In-Reply-To: <20190404200658.GD29984@amd> From: Dmitry Torokhov Date: Thu, 4 Apr 2019 13:13:34 -0700 Message-ID: Subject: Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name To: Pavel Machek Cc: Nick Crews , Guenter Roeck , Enric Balletbo i Serra , Benson Leung , linux-leds@vger.kernel.org, Jacek Anaszewski , Alexandre Belloni , Alessandro Zummo , linux-rtc@vger.kernel.org, linux-kernel , Duncan Laurie , Simon Glass Content-Type: text/plain; charset="UTF-8" Sender: linux-rtc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org On Thu, Apr 4, 2019 at 1:06 PM Pavel Machek wrote: > > Hi! > > > > > It is *function* and maybe color that userspace is interested in, and > > > > here we have proper standardization in form of "kbd_backlight". Device > > > > name is, well, device name. It should uniquely identify the device led > > > > is attached to, but otherwise is rarely interesting. If userspace is > > > > really concerned what kind of keyboard backlight it is it should > > > > investigate parent device(s) and see what they end up with. > > > > > > That does not work. Userspace wants to know if it is internal keyboard > > > or USB keyboard, not what kind of i2c controller the LED is connected > > > to. > > > > Why does userspace want to know it? > > For example to turn off backlight on internal keyboard when the lid is closed. Would you not want to turn off external as well? And what to do if internal keyboard is not platform but USB? Like Google "Whiskers"? (I am not sure why you decided to drop my mention of internal USB keyboards completely off your reply). > > > > grep for platform::mic_mute . > > > > > > (And platform is even pretty good match for how the LED is connected > > > in your case). > > > > Until we get a secondary interface that is also "platform"... > > How would that happen? It won't happen on Wilco, but you can't imagine that several blocks get reused in the same device and they end up clashing? Thanks. -- Dmitry