linux-kernel - Re: [PATCH] pch_uart: Add Kontron COMe-mTT10 uart clock quirk

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: <20120323003456.6f7fea2e@mail.gmx.de>
Date:	Fri, 23 Mar 2012 00:34:56 +0100
From:	Michael Brunner <mibru@....de>
To:	Darren Hart <dvhart@...ux.intel.com>
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

> 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.

You are right, the development kit uses a customized version of the
COMe-mTT10.

> So what does your DMI_BIOS_VERSION report?

The BIOS for the stock COMe-mTT10 is prefixed with NTC1.

> 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).

Basically this is not a wrong decision, as the FRI2 project code is
unique for the firmware used on the development kit.

> 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.

To be safe we should treat them as separate devices and make sure we
are able to differentiate between them.

> 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.

I understand your concerns and agree with you that in this case the BIOS
version should be checked before the board name, same goes for the
product name. So I will prepare a new patch that puts my BOARD_NAME
comparison to the end.

Michael
--
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/