Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5402034imm; Tue, 19 Jun 2018 09:48:37 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLOU4knTus7gkmPXxosRcMYCdtSdyKuOLmk6PYculNgjyAxJjQNRCcWwL4A25UtyRitxD6V X-Received: by 2002:a17:902:2702:: with SMTP id c2-v6mr19525603plb.297.1529426917494; Tue, 19 Jun 2018 09:48:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529426917; cv=none; d=google.com; s=arc-20160816; b=oFabtyddqd1HL+Z1sZ2/Mk5y35ogUbmFSkTueLsLL9cyUFZN04x02WJxgF0o7kwmHL DWfTcInTXQYGzm20FyjwkY3ggQG18NNxeCSHIcZDw1LhsMTFk+RvSz96dYC6uo112G+2 tmhWpKJXcZBaTfVgYV8lAddb6h97c8ef75LO7ZXnsiWa/Zq2YHL8esRJl/MMc5FUhCJm mOQUkvJSawb5zcRUqCRwO45LhcHrOuq9JkcDkYPhPI+OJtn7Fm2BNE9ni++LM4ooFD2h EBfjqtD2bbj9LRxyrzYlhFrrBZwFLSIaPfJkbyr4za0DAvPtkul2u0Zw3f0ygOU2yXVX xBnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=j8gsnaoKBiHfvgCxLZul91KtUH3bdsRfVVFkqZtZOY8=; b=M13qMnLqi8XTEKP98+j7DU6+XY1X6qw3JdUe+n8vPKURuis4rzuz98RvkJrcbhfFg0 WEnL19G0WFPnqyETjVjPhBu/lBPHXrqSn+axS/HZCUvh6rqrfrLMwUDTSSunYjSUix3l oQgp+Dg5kRzDcCNN5/Fkkjz7G4/i6lf//u06UPURZeGvfj29S98f04bf6R62Sux9+avd XW9RfsvpA056E2LUMR67EHyIwBTomXNKliQ7BGqL2cpi+x6T59+z8hqtiTy8YY41+Tdv gkSsnE5UQcFH6NFA9+b1bLTsMp9lp9abedYoHWABpVKU7dcE+41qKadlqjJO8V9U9sCI v07Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@endlessm-com.20150623.gappssmtp.com header.s=20150623 header.b=yC8sVFNN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p29-v6si84171pgc.199.2018.06.19.09.48.23; Tue, 19 Jun 2018 09:48:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@endlessm-com.20150623.gappssmtp.com header.s=20150623 header.b=yC8sVFNN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967078AbeFSQq1 (ORCPT + 99 others); Tue, 19 Jun 2018 12:46:27 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:42238 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966733AbeFSQqY (ORCPT ); Tue, 19 Jun 2018 12:46:24 -0400 Received: by mail-ot0-f193.google.com with SMTP id 92-v6so398959otw.9 for ; Tue, 19 Jun 2018 09:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endlessm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j8gsnaoKBiHfvgCxLZul91KtUH3bdsRfVVFkqZtZOY8=; b=yC8sVFNNE5dGZHsiiYM7ihipQeo5YJyx5ZEtuk7dBv7yTxd8UL/jGwBzZjoGJAD9E3 0OFZaAkRHEnHrku2xvc0/KYoc2Vk1wyFjDOGAMBRODPDtPhmwofga9zsCRQnIJAuCwqB 5DKbVY4mE4rhVHBkmMxUSP7C/fJKc88JO5lsxA30mjVKTP+yxsrLYUze/1/uYz4DPMf5 /eGjTKoE+Pc/6sajtsQ8Krtek+HbKJJ2gBHQ8AWLIzAgAi9OQ3XsPRlYVk/YUaqxr49B lrqFg6dHbrh+1CSJ7oXV2Rpa4Qw9YannMZwQcDCIUHqIobpfnVWBG4lxhnz9ULEeMtu+ QOCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j8gsnaoKBiHfvgCxLZul91KtUH3bdsRfVVFkqZtZOY8=; b=e5BintRUxyIJkc3ZGRI1m4pUCj3T3xDwjPTxko9mx00L4Ezbuysygz7pFF89B8n7bw 6ZBqIOqn/sF0ApYukt1HYh5afUWBMDhp0bw303SezvmyPBpFm6xrxguMYOMG+5KqeTuR 2Nzr68FN0YXBm8K6oOaUhT1V2MoFyJfCOvQGscdJeVBT9IKgqJOjto5wnSwA7+yiTfCE JL//LV/hexfXkg1ZbTOAle0FIDLoAd7JxHC/ptmupPqoSpbm+dfjBqwT5YM+L7c7pPkA G5ZAsLbd2LRVBYfG7fad8A2hyIScyGVa/uGAfksVEUKslih+MYvlSaSy766f9nQbgSyT utEA== X-Gm-Message-State: APt69E12vrux8D7H7V+1ZjmlCLu4O/BV1GhibhhFUt71Qy5X3UJLvhJJ b4WNbma3vfFQeAenunmFWkwsxlVN2eg9HONTgWV+VaTCE1E= X-Received: by 2002:a9d:2ed3:: with SMTP id w77-v6mr11475079ota.123.1529426783644; Tue, 19 Jun 2018 09:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:e34:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 09:46:23 -0700 (PDT) In-Reply-To: References: <20180611071838.47945-1-chiu@endlessm.com> From: Daniel Drake Date: Tue, 19 Jun 2018 11:46:23 -0500 Message-ID: Subject: Re: [PATCH v2 1/2] platform/x86: asus-wmi: Call led hw_changed API on kbd brightness change To: Chris Chiu Cc: Andy Shevchenko , Corentin Chary , Darren Hart , Linux Kernel Mailing List , Platform Driver , acpi4asus-user , Hans de Goede , Linux Upstreaming Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Jun 14, 2018 at 1:58 AM, Chris Chiu wrote: > > On Wed, Jun 13, 2018 at 8:49 PM, Andy Shevchenko > wrote: > > On Mon, Jun 11, 2018 at 10:18 AM, Chris Chiu wrote: > >> Make asus-wmi notify on hotkey kbd brightness changes, listen for > >> brightness events and update the brightness directly in the driver. > > > >> For this purpose, bound check on brightness in kbd_led_set must be > >> based on the same data type to prevent illegal value been set. > > > >> @@ -497,9 +498,9 @@ static void kbd_led_set(struct led_classdev *led_cdev, > >> > >> asus = container_of(led_cdev, struct asus_wmi, kbd_led); > >> > >> - if (value > asus->kbd_led.max_brightness) > >> + if ((int)value > (int)asus->kbd_led.max_brightness) > >> value = asus->kbd_led.max_brightness; > >> - else if (value < 0) > >> + else if ((int)value < 0) > >> value = 0; > > > > I didn't quite understand this part of the problem. > > Does it exist in the current code? Can it be split to a separate change? > > > > Can we avoid those ugly castings? > > > > I'd like to remove the ugly castings but there's a concern I may need some > advices. I don't know whether if the bound check logic ever verified before. > Maybe the value passed via sysfs is already correctly bounded? The casts come from the underlying need to limit the minumum and maximum brightness within available bounds, plus difficulties doing that when you are dealing with an enum data type. kbd_led_set is a function pointer (from led_classdev.brightness_set) which has this definition: void (*brightness_set)(struct led_classdev *led_cdev, enum led_brightness brightness); It seems that the compiler has the choice of whether to use a signed or unsigned type for enums. According to your tests, and a quick test app below, it seems like gcc is using unsigned. #include enum led_brightness { LED_OFF = 0 }; int main(void) { enum led_brightness tmp = -1; if (tmp < 0) printf("less than zero\n"); else printf("gt zero\n"); } This test app prints "gt zero" led-class.c:brightness_store() uses kstrtoul() so there is no chance of passing a negative value through this codepath, as you suspected. But we do need to do something with negative bounds for the code that you are adding here. I suggest doing it like this: static void __kbd_led_set(struct led_classdev *led_cdev, int value) { struct asus_wmi *asus; asus = container_of(led_cdev, struct asus_wmi, kbd_led); if (value > asus->kbd_led.max_brightness) value = asus->kbd_led.max_brightness; else if (value < 0) value = 0; asus->kbd_led_wk = value; queue_work(asus->led_workqueue, &asus->kbd_led_work); } static void kbd_led_set(struct led_classdev *led_cdev, enum led_brightness value) { return __kbd_led_set(led_cdev, value); } Now kbd_led_set can continue being a correctly typed function pointer for led_classdev.brightness_set. And from the code you are adding here you can call __kbd_led_set directly with signed integer values, and rely on correct bounds correction without ugly casts. Andy, what do you think? Thanks Daniel