linux-kernel - Re: [PATCH v3 2/4] USB: serial: cp210x: Switch to new 16-bit register access functions.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jan 2016 18:23:26 +0000
From:	Martyn Welch <martyn.welch@...labora.co.uk>
To:	Konstantin Shkolnyy <Konstantin.Shkolnyy@...abs.com>,
	Konstantin Shkolnyy <konstantin.shkolnyy@...il.com>,
	"johan@...nel.org" <johan@...nel.org>
CC:	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/4] USB: serial: cp210x: Switch to new 16-bit register
 access functions.



On 14/01/16 18:22, Konstantin Shkolnyy wrote:
>> -----Original Message-----
>> From: linux-usb-owner@...r.kernel.org [mailto:linux-usb-
>> owner@...r.kernel.org] On Behalf Of Martyn Welch
>> Sent: Thursday, January 14, 2016 11:44
>> To: Konstantin Shkolnyy; johan@...nel.org
>> Cc: linux-usb@...r.kernel.org; linux-kernel@...r.kernel.org
>> Subject: Re: [PATCH v3 2/4] USB: serial: cp210x: Switch to new 16-bit register
>> access functions.
> ...
>
>>> @@ -697,14 +685,11 @@ static unsigned int
>> cp210x_quantise_baudrate(unsigned int baud)
>>>
>>>    static int cp210x_open(struct tty_struct *tty, struct usb_serial_port *port)
>>>    {
>>> -	int result;
>>> +	int err;
>>>
>>> -	result = cp210x_set_config_single(port, CP210X_IFC_ENABLE,
>>> -
>> 	UART_ENABLE);
>>> -	if (result) {
>>> -		dev_err(&port->dev, "%s - Unable to enable UART\n",
>> __func__);
>>> -		return result;
>>> -	}
>>> +	err = cp210x_write_u16_reg(port, CP210X_IFC_ENABLE,
>> UART_ENABLE);
>>> +	if (err)
>>> +		return err;
>>
>> Any reason for dropping the error message?
>
> I already print a message if the underlying usb_control_msg fails, so it should be covered there.
>

Sounds like a very valid reason :-)

Martyn