public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Brunner <mibru@gmx.de>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Cox <alan@linux.intel.com>,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH] pch_uart: Add Kontron COMe-mTT10 uart clock quirk
Date: Fri, 23 Mar 2012 00:34:56 +0100	[thread overview]
Message-ID: <20120323003456.6f7fea2e@mail.gmx.de> (raw)
In-Reply-To: <4F6B9E7B.9090005@linux.intel.com>

> 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

  reply	other threads:[~2012-03-22 23:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-22 20:19 [PATCH] pch_uart: Add Kontron COMe-mTT10 uart clock quirk Michael Brunner
2012-03-22 20:39 ` Darren Hart
2012-03-22 21:31   ` Michael Brunner
2012-03-22 21:49     ` Darren Hart
2012-03-22 23:34       ` Michael Brunner [this message]
2012-03-23 10:06       ` [PATCHv2] " Michael Brunner
2012-03-23 14:25         ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120323003456.6f7fea2e@mail.gmx.de \
    --to=mibru@gmx.de \
    --cc=alan@linux.intel.com \
    --cc=dvhart@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox