On Tue, Feb 20, 2018 at 05:49:02PM +0100, Benjamin Tissoires wrote: > On Fri, Feb 16, 2018 at 9:59 PM, Rodrigo Rivas Costa > > But about that +7 in hid_alloc_report_buf(), isn't it to make room for > > the implement()/extract() functions? And IIUIC those are not used for > > raw_requests... they are instead passed directly to usb_control_msg() > > (or whatever the ll driver does). That's the point of being raw, isn't > > it? > > > > If I'm right with that, would it make sense to go back to kzalloc(65)? > > > > If I'm wrong, then if you agree, I'll default to: > > > > hid_hw_raw_request(steam->hid_dev, 0x00, > > buf, hid_report_len(r) + 1, /* count the request number */ > > HID_FEATURE_REPORT, HID_REQ_GET_REPORT); > > > > Then, if hid_report_len() is ever updated to return the +1, this one > > should be removed. And even if it is not, we still have +6 extra bytes > > from hid_alloc_report_buf(), so no real harm done. > > I am fine with your analysis except for the last point :) > We need all 7 extra bytes, not 6 (in implement()). However, as you > said, implement() is not used in the low_level transport functions, so > there is no point bike shedding for ages. > > I'd say please stick to hid_report_alloc_buf (maybe add a comment > about the missing report ID added by usb), and use hid_report_len(r) + > 1 while calling hid_hw_raw_request(). This way, we can always fix the > behavior later and have something which will not break. > > How does that sound? It sound fine to me. I'll try to write a small comment explaining the +1. Thanks Rodrigo -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
