Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp5122151imm; Tue, 16 Oct 2018 05:38:18 -0700 (PDT) X-Google-Smtp-Source: ACcGV62J65SIbE3DwMWXLQwR4o6S8SI3kvLt/Grp4oYJtrjA+oINroiH7buoZuUgdYsU2Wg+sBRc X-Received: by 2002:a63:5fc5:: with SMTP id t188-v6mr19956259pgb.346.1539693498776; Tue, 16 Oct 2018 05:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539693498; cv=none; d=google.com; s=arc-20160816; b=XDyLtDfVrHzKivaVGzVxDYsDIGNPs3Nl6T/UEQa67An8cQaUsFb4IjomHa7QJRuwpB MKhgXl+Lzsfh9KScjFWZ8Aggd7FSkwTmypjd0Agne/88mut9MhXtFqFi5y22u3nOSELe YGgQCbvgMbUL0Ampac/QCRA3KvidcB+WQFDU8z/NETDAXLg+c9u97a8o/zM6itAh3owi kGjaOikGOkiFvcth6IJLaRreXHVnV9QCCnL9lsGgkbUbuivht9BQxsmL9fxG3RNG1hos jhb36KqZyi7FC5OvCzcHJKtsEWzkZru+siOtYVi+5Cv76iQSejpuRofMYkmg10VXm63d Uw8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=vn3vAKIV6U8ZGwKzgT5KzryOu4kLMo5Nr37LCH62etQ=; b=qWRw1DCPLfG8ElYXwG4fWizzHa1V46A8o/JSsM/cTZwTtYUOFIrz9uSU3NZqXBHjp+ nDghjKlDbuEYAzpcz86HS0kOPAqBENGgiduhG/J5GrFHhRHn2dUFTc0ZQGHh/xdRaj5h WP0/8AblaygBOctKe4SA6wpVN/5GOgdHiqeJS7jf4K2dzrCyRSQDO2/oIMi46WFi86lb U2Ox+OWOSQSWCOkI+zkEboHaJj7QZ25K/XzvnT9zMPTfrZE+8ks4vPpNhGZ9GVFfNSyY vuNXiYwVZzZpDGR+jmayyoWT1KRj1gNhChuXxIgke9Dt1LMNMf7MTLOqY7ryZ6juXYeC q49Q== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mok.nu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 62-v6si14434687pla.203.2018.10.16.05.38.02; Tue, 16 Oct 2018 05:38:18 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mok.nu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727061AbeJPU13 (ORCPT + 99 others); Tue, 16 Oct 2018 16:27:29 -0400 Received: from proxy04.fsdata.se ([89.221.252.227]:48520 "EHLO mail-gw01.fsdata.se" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726718AbeJPU13 (ORCPT ); Tue, 16 Oct 2018 16:27:29 -0400 X-Greylist: delayed 932 seconds by postgrey-1.27 at vger.kernel.org; Tue, 16 Oct 2018 16:27:28 EDT Received: from localhost (94.234.42.202) by DAG01.HMC.local (192.168.46.11) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 16 Oct 2018 14:21:02 +0200 From: Mattias Jacobsson <2pi@mok.nu> To: CC: , , <2pi@mok.nu> Subject: [PATCH] USB: misc: appledisplay: fix backlight update_status return code Date: Tue, 16 Oct 2018 14:20:08 +0200 Message-ID: <20181016122008.8384-1-2pi@mok.nu> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [94.234.42.202] X-ClientProxiedBy: PROXY04.HMC.local (192.168.46.54) To DAG01.HMC.local (192.168.46.11) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Upon success the update_status handler returns a positive number corresponding to the number of bytes transferred by usb_control_msg. However the return code of the update_status handler should indicate if an error occurred(negative) or how many bytes of the user's input to sysfs that was consumed. Return code zero indicates all bytes were consumed. The bug can for example result in the update_status handler being called twice, the second time with only the "unconsumed" part of the user's input to sysfs. Effectively setting an incorrect brightness. Change the update_status handler to return zero for all successful transactions and forward usb_control_msg's error code upon failure. Signed-off-by: Mattias Jacobsson <2pi@mok.nu> --- I've not found any documentation regarding the return code from the update_status handler. The information above is based on looking at other driver and how the return code is used for by the caller of the update_status handler. Please let me know if it is incorrect. --- drivers/usb/misc/appledisplay.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c index d746c26a8055..bd539f3058bc 100644 --- a/drivers/usb/misc/appledisplay.c +++ b/drivers/usb/misc/appledisplay.c @@ -146,8 +146,11 @@ static int appledisplay_bl_update_status(struct backlight_device *bd) pdata->msgdata, 2, ACD_USB_TIMEOUT); mutex_unlock(&pdata->sysfslock); - - return retval; + + if (retval < 0) + return retval; + else + return 0; } static int appledisplay_bl_get_brightness(struct backlight_device *bd) -- 2.19.1