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>] [day] [month] [year] [list]
Message-ID: <1548148782-3414-1-git-send-email-guan.yung.tseng@ni.com>
Date:   Tue, 22 Jan 2019 17:19:42 +0800
From:   Guan Yung Tseng <guan.yung.tseng@...com>
To:     <gregkh@...uxfoundation.org>, <hch@...radead.org>
CC:     <linux-serial@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        "Guan Yung Tseng" <guan.yung.tseng@...com>
Subject: [PATCH v2] 8250_pci.c: Update NI specific devices class to multi serial

On, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
>> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
>> The reason of doing this is because all NI multi port serial cards
>> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
>> serial_pci_is_class_communication test added in the commit 7d8905d06405
>> ("serial: 8250_pci: Enable device after we check black list").
>> 
>> Signed-off-by: Guan Yung Tseng <guan.yung.tseng@...com>
>> ---
>>  drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>> 
>> diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
>> index 4986b4a..0949db1 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
>>  	return 0;
>>  }
>>  
>> +static int pci_ni_probe(struct pci_dev *dev)
>> +{
>> +	dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
>> +			(dev->class & 0xff);

>
> As Christoph said, this looks really odd.  This field comes from the
> PCI structure on the device, it should not be modified by the kernel.
> 
> Unless the device is broken and needs to be fixed up in the kernel?
> 
> Also, you have sent 2 different patches here for this type of issue, are
> both needed?  If so, please resend both of them as a patch series, with
> more explainations in this one as to why you are modifying this field.
> 
> I've dropped all pending patches from you from my queue now.
> 

Hi Christoph and Greg,

Sorry for the confusion sending 2 different patches to solve the same
issue. I should have wait for your response before sending antoher
patch to solve the similar issue.

For some historical reason, NI serial devices use
PCI_CLASS_COMMUNICATION_OTHER class code. Yes, I understand that
the class code should read from config space instead modified from
kernel. But these devices are shipped to the market for many years.
That's why I am trying to fix the problem in the kernel.

I will send another simple patch again to fix the problem.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ