From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
aravind.gopalakrishnan@amd.com, xen-devel@lists.xenproject.org,
andrew.cooper3@citrix.com
Subject: Re: [PATCH v2 2/7] serial: Fix COM1 assumption if pci_uart_config did not find the PCI serial card.
Date: Mon, 10 Mar 2014 12:13:11 -0400 [thread overview]
Message-ID: <20140310161311.GE4262@phenom.dumpdata.com> (raw)
In-Reply-To: <531D95640200007800122404@nat28.tlf.novell.com>
On Mon, Mar 10, 2014 at 09:35:16AM +0000, Jan Beulich wrote:
> >>> On 07.03.14 at 20:01, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > The io_base by default is set to be 0x3f8 for COM1 and 0x2f8 for COM2
> > in __setup_xen. Then we call 'ns16550_init' which copies those in
> > the appropiate uart, which then calls 'ns16550_parse_port_config'
> > to deal with parameter parsing. If the 'pci' or 'amt' parameter
> > has been specified we further call 'pci_uart_config code' which
> > scans the PCI bus. If it does not find any relevant devices
> > it will overwrite io_base with 0x3f8 regardless whether this is
> > COM1 or COM2. The overwrite is a way to set it back to the
> > failsafe defaults - except for COM2 of course.
> >
> > This in theory (as I don't have a machine with two COM ports
> > readily available) means that if the user specified 'com2=9600,8n1,pci'
> > and the device did not have an PCI serial card, instead of using 0x2f8
> > for the io_base it ends up using 0x3f8 - and we don't get the
> > output on COM2.
> >
> > Fix it by saving the original io_base before starting the
> > scan of the PCI bus. If we don't find an serial PCI device then
> > assign the original io_base value back.
>
> While reviewing patch 1 I was specifically thinking of why you didn't
> do this at once. But then I realized that this is done only in the AMT
> case, and was assuming that you, when originally adding AMT
> support, specifically did it that way knowing that if anything it could
> only sit on port 0x3f8. If that wasn't the original intention, the
That (AMT support) was eons ago. I sadly don't remember why it was
done that way :-(
> change is fine, but the description should be updated to say that
> this only affects the AMT case.
Yes, let me update the commit description. Since I already had sent an
updated patch, let me just copy in the new description:
serial: Fix COM1 assumption if pci_uart_config did not find the PCI serial card (AMT one).
The io_base by default is set to be 0x3f8 for COM1 and 0x2f8 for COM2
in __setup_xen. Then we call 'ns16550_init' which copies those in
the appropiate uart, which then calls 'ns16550_parse_port_config'
to deal with parameter parsing. If the 'pci' or 'amt' parameter
has been specified we further call 'pci_uart_config code' which
scans the PCI bus. If it does not find any relevant devices
it will overwrite io_base with 0x3f8 regardless whether this is
COM1 or COM2. The overwrite is a way to set it back to the
failsafe defaults - except for COM2 of course.
This in theory (as I don't have a machine with two COM ports
readily available) means that if the user specified 'com2=9600,8n1,pci'
or 'com2=9600,8n1,amt' and the device did not have an PCI serial card
(or AMT), instead of using 0x2f8 for the io_base it ends up using 0x3f8
- and we don't get the output on COM2.
Worst yet, we also uncondionally reset the IRQ value - so we would
never get the proper interrupt when falling back to the legacy
0x3f8 and 0x2f8 COM ports.
This bug was introduced with the original AMT support and I cannot
recall why it was done that way - it is a bug.
Fix it by saving the original io_base before starting the
scan of the PCI bus. If we don't find an serial PCI device (because
we did not exit out of the loop using return) then
assign the original io_base value back.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Also remove the irq override spotted by Jan]
next prev parent reply other threads:[~2014-03-10 16:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 19:01 [PATCH v2] Enable serial output for Oxford Semiconductor PCIe cards and fixes Konrad Rzeszutek Wilk
2014-03-07 19:01 ` [PATCH v2 1/7] serial: Skip over PCIe device which have no quirks (fix AMT regression) Konrad Rzeszutek Wilk
2014-03-10 9:26 ` Jan Beulich
2014-03-07 19:01 ` [PATCH v2 2/7] serial: Fix COM1 assumption if pci_uart_config did not find the PCI serial card Konrad Rzeszutek Wilk
2014-03-10 9:35 ` Jan Beulich
2014-03-10 16:07 ` Konrad Rzeszutek Wilk
2014-03-10 16:20 ` Jan Beulich
2014-03-10 16:13 ` Konrad Rzeszutek Wilk [this message]
2014-03-10 16:23 ` Jan Beulich
2014-03-10 16:45 ` Konrad Rzeszutek Wilk
2014-03-10 17:06 ` Jan Beulich
2014-03-07 19:01 ` [PATCH v2 3/7] serial: Support OXPCIe952 aka Oxford Semiconductor Ltd Device c138 (1415:c138) Konrad Rzeszutek Wilk
2014-03-07 19:01 ` [PATCH v2 4/7] serial: Seperate the PCI device ids and parameters Konrad Rzeszutek Wilk
2014-03-10 9:41 ` Jan Beulich
2014-03-10 16:23 ` Konrad Rzeszutek Wilk
2014-03-10 16:30 ` Jan Beulich
2014-03-10 16:38 ` Konrad Rzeszutek Wilk
2014-03-10 16:51 ` Konrad Rzeszutek Wilk
2014-03-10 17:07 ` Jan Beulich
2014-03-07 19:01 ` [PATCH v2 5/7] serial: Use #defines for PCI vendors Konrad Rzeszutek Wilk
2014-03-10 9:44 ` Jan Beulich
2014-03-07 19:01 ` [PATCH v2 6/7] serial: Expand the PCI serial quirks for OXPCIe200 and OXPCIe952 1 Native UART Konrad Rzeszutek Wilk
2014-03-07 19:01 ` [PATCH v2 7/7] pci: Put all PCI device vendor and models in one file Konrad Rzeszutek Wilk
2014-03-10 9:46 ` Jan Beulich
2014-03-07 21:27 ` [PATCH v2] Enable serial output for Oxford Semiconductor PCIe cards and fixes Aravind Gopalakrishnan
2014-03-07 22:06 ` Konrad Rzeszutek Wilk
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=20140310161311.GE4262@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=aravind.gopalakrishnan@amd.com \
--cc=konrad@kernel.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.