Thanks for clarifying Dmitry. I'll get a patch pushed up next week. On Wed, Aug 12, 2020 at 7:21 PM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > On Thu, Aug 06, 2020 at 09:28:41AM -0600, Raul Rangel wrote: > > > > > > <- atkbd_event_work->atkbd_set_leds > > > [KB recv data: 0xed] # CMD 10 > > > <- Wait, where is the data? > > > > > > <- Continuation of i8042_port_close? > > > [KB recv cmd: 0x60] # CMD #14 > > > [KB recv data: 0x43] > > > [KB eaten by STATE_WRITE_CMD_BYTE: 0x43] > > > [KB set CTR_RAM(0x00)=0x43 (old:0x41)] > > > [AUX IRQ enable] > > > > > > <- Here is the data! > > > [KB recv data: 0x00] # CMD 10 (data) > > > [KB Unsupported i8042 data 0x00] > > > [KB recv data: 0x00] <- Did the host retry? > > > [KB Unsupported i8042 data 0x00] > > > > > > <- atkbd_event_work->atkbd_set_repeat_rate > > > [KB recv data: 0xf3] # CMD #11 > > > [KB recv data: 0x00] > > > [KB eaten by STATE_SETREP: 0x00] > > > > > > [KB recv cmd: 0xd4] # CMD #15 > > > [KB recv data: 0xf2] > > > [STATE_SEND_TO_MOUSE: 0xf2] > > > > As you can see CMD #10 starts between #13 and #14, and then completes > > after #14. Is this expected behavior? > > > > I'm not quite sure if #13 and #14 are coming from i8042_port_close. I > > don't have a function trace available, but it seems to fit. > > > > I found this comment: > > /* > > * Writers to AUX and KBD ports as well as users issuing i8042_command > > * directly should acquire i8042_mutex (by means of calling > > * i8042_lock_chip() and i8042_unlock_ship() helpers) to ensure that > > * they do not disturb each other (unfortunately in many i8042 > > * implementations write to one of the ports will immediately abort > > * command that is being processed by another port). > > */ > > static DEFINE_MUTEX(i8042_mutex); > > > > Does that not mean that i8042_port_close, i8042_enable_kbd_port, > > i8042_enable_aux_port, + any other function that calls i8042_command > > should be taking the lock before calling i8042_command? > > Yeah, I think this is right. When I added the mutex it was because 2 > deices were clashing with each other and I did not consider that closing > port in the i8042 driver itself may also disturb in-flight command. > > Thanks. > > -- > Dmitry
