On 10.09.19 00:59, Greg Kroah-Hartman wrote: > 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 > Yes, please wait for the other patch if it's not in his tree yet and apply the two together. Thank you, Fabian
