On Thu, Jul 07, 2022 at 05:37:53PM +0200, Marek Behún wrote: > On Thu, 7 Jul 2022 17:07:53 +0200 > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, Jul 07, 2022 at 04:53:48PM +0200, Marek Behún wrote: > > > From: Pali Rohár <pali@xxxxxxxxxx> > > > > > > Divisor in the register is a 17-bit wide number. > > > Therefore we need to clamp it on overflow. > > > > Why, what is wrong with it overflowing, what will happen if it does? > > The divisor register is 17-bits wide (14 bits integer part, 3 bits > fractional). So suppose that we compute divisor 0x20001. Writing to > the register puts 0x00001 there, cause the 17th bit gets discarded > (since the register is 17-bits wide). Which will result in dividing by > 1. So worst case, if you have a broken device, is you will get the wrong baudrate? This isn't really a "bug" then, but just making things a bit better if you have a crazy device? > The best thing we can do if we overflow is put the maximum value to the > divisor, to get the lowest baudrate possible. Ok, so not a big deal. > > > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx> > > > Tested-by: Marek Behún <kabel@xxxxxxxxxx> > > > --- > > > drivers/usb/serial/ftdi_sio.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > What commit does this fix? Is it a bugfix? Can this ever happen in a > > device? Should it be backported?. > > It is a bugfix; it can happen (happened to Pali when he was trying some > low baudrates); it should be backported. Ok, then properly tag cc: stable please. thanks, greg k-h
