On Mon, Sep 09, 2019 at 03:00:46PM +0200, Fabian Henneke wrote: > Hi, > > On Mon, Sep 9, 2019 at 2:15 PM Pavel Machek <pavel@xxxxxxx> wrote: > > > Hi! > > > > > [ Upstream commit 48d9cc9d85dde37c87abb7ac9bbec6598ba44b56 ] > > > > > > Let hidp_send_message return the number of successfully queued bytes > > > instead of an unconditional 0. > > > > > > With the return value fixed to 0, other drivers relying on hidp, such as > > > hidraw, can not return meaningful values from their respective > > > implementations of write(). In particular, with the current behavior, a > > > hidraw device's write() will have different return values depending on > > > whether the device is connected via USB or Bluetooth, which makes it > > > harder to abstract away the transport layer. > > > > So, does this change any actual behaviour? > > > > Is it fixing a bug, or is it just preparation for a patch that is not > > going to make it to stable? > > > > I created this patch specifically in order to ensure that user space > applications can use HID devices with hidraw without needing to care about > whether the transport is USB or Bluetooth. Without the patch, every > hidraw-backed Bluetooth device needs to be treated specially as its write() > violates the usual return value contract, which could be viewed as a bug. > > Please note that a later patch ( > https://www.spinics.net/lists/linux-input/msg63291.html) fixes some > important error checks that were relying on the old behavior (and were > unfortunately missed by me). As that patch doesn't seem to be in Linus's tree yet, we should postpone taking this one in the stable tree right now, correct? thanks, greg k-h
