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]
Message-ID: <4F6B9E7B.9090005@linux.intel.com>
Date:	Thu, 22 Mar 2012 14:49:47 -0700
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Michael Brunner <mibru@....de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Cox <alan@...ux.intel.com>, linux-serial@...r.kernel.org
Subject: Re: [PATCH] pch_uart: Add Kontron COMe-mTT10 uart clock quirk



On 03/22/2012 02:31 PM, Michael Brunner wrote:
>> These boards should already be supported by the following BIOS check.
>> As the DMI_BOARD_NAME was changing, it was Kontron's recommendation
>> to use the FRI2 prefix in the DMI_BIOS_VERSION.
>>
>>
>>>  	cmp = dmi_get_system_info(DMI_BIOS_VERSION);
>>>  	if (cmp && strnstr(cmp, "FRI2", 4))
>>
>> Is this not working for you? If not, what is the DMI_BIOS_VERSION
>> reported by your board?
>>
>> And for clarification, we are talking about this right:
>> http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html
> 
> My changes refer to the embedded module with the project code NTC1:
> <http://us.kontron.com/products/computeronmodules/com+express/com+express+mini/comemtt10.html>
> 
> So unfortunately the FRI2 checks won't work for this.
> 
> Michael

OK, my board has DMI_BOARD_NAME as:

"nETXe-TT 1.0GHz E2 KDMS-FRI" but will also undergo a rename in the near
future. I'm concerned about colliding as I believe this kit may use the
same board you are working with. This COM Express module will be renamed
"COMe-mTT10" which will match your strstr compare.

So what does your DMI_BIOS_VERSION report?

I didn't like basing this on BIOS_VERSION, but I did so at Kontron's
preference. Now we're seeing the fallout (sooner than I expected).

So the question is, do we treat these as separate devices (the board and
the development kit which I believe includes your board) or do we lump
them together.

Since it is the firmware that ultimately decides what the initial
UARTCLK is, we can't base this on the hardware alone. The hardware in
fact should be default if a firmware match isn't found first. So, my
preference would be that you move your new comparison AFTER the FRI2
DMI_BIOS_VERSION comparison. This ensures the FRI2 doesn't match your
new comparison which might get a different UARTCLK in the future for
whatever reason.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ