From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Esben Haabendal <esben@haabendal.dk>
Cc: Lee Jones <lee.jones@linaro.org>,
linux-serial@vger.kernel.org, Jiri Slaby <jslaby@suse.com>,
Nishanth Menon <nm@ti.com>, Vignesh R <vigneshr@ti.com>,
Tony Lindgren <tony@atomide.com>,
Lokesh Vutla <lokeshvutla@ti.com>,
Florian Fainelli <f.fainelli@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] serial: 8250: Add support for 8250/16550 as MFD function
Date: Tue, 21 May 2019 14:56:51 +0200 [thread overview]
Message-ID: <20190521125651.GA6264@kroah.com> (raw)
In-Reply-To: <87lfz0m3ge.fsf@haabendal.dk>
On Tue, May 21, 2019 at 01:50:25PM +0200, Esben Haabendal wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>
> > On Tue, May 21, 2019 at 01:11:08PM +0200, Esben Haabendal wrote:
> >> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> >>
> >> >> I will try ad hold back with this thread until you get back to it.
> >> >
> >> > Ok, I have no idea what is going on here, sorry. This is a really long
> >> > and meandering thread, and I can't even find the original patches in my
> >> > queue.
> >> >
> >> > So can you resend things and we can start over? :)
> >>
> >> Will do.
> >>
> >> > But note, using a mfd for a uart seems VERY odd to me...
> >>
> >> Ok. In my case, I have a pcie card with an fpga which includes 5 uart
> >> ports, 3 ethernet interfaces and a number of custom IP blocks.
> >> I believe that an mfd driver for that pcie card in that case.
> >
> > I believe you need to fix that fpga to expose individual pci devices
> > such that you can properly bind the individual devices to the expected
> > drivers :)
>
> Well, that is really out-of-scope of what I am doing here.
Not really, if you have control over the fpga firmware (and odds are you
do), just fix that and instantly your device works with all kernels, no
need to change anything.
Why not do this?
> > Seriously, who makes such a broken fpga device that goes against the PCI
> > spec that way? Well, not so much as "goes against it", as "ignores all
> > of the proper ideas of the past 20 years for working with PCI devices".
>
> Might be. But that is the firmware I have to work with here, and I
> still hope we can find a good solution for implementing a driver without
> having to maintain out-of-tree patches.
As this hardware will not work on any operating system as-is, why not
fix the firmware to keep from having to support a one-off device that no
one else would be crazy enough to create? :)
thanks,
greg k-h
next prev parent reply other threads:[~2019-05-21 12:56 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 8:40 [PATCH 0/2] serial: 8250: Add support for 8250/16550 as MFD function Esben Haabendal
2019-04-26 8:40 ` [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF Esben Haabendal
2019-04-26 14:39 ` Andy Shevchenko
2019-04-26 16:54 ` Esben Haabendal
2019-04-26 21:51 ` Andy Shevchenko
2019-04-27 8:58 ` Esben Haabendal
2019-04-27 11:57 ` Enrico Weigelt, metux IT consult
2019-04-29 6:37 ` Esben Haabendal
2019-04-27 16:41 ` Andy Shevchenko
2019-04-29 6:27 ` Esben Haabendal
2019-04-29 8:33 ` Andy Shevchenko
2019-04-29 9:29 ` Esben Haabendal
2019-04-29 12:56 ` Enrico Weigelt, metux IT consult
2019-04-29 13:35 ` Andy Shevchenko
2019-04-29 14:25 ` Esben Haabendal
2019-04-26 8:40 ` [PATCH 2/2] serial: 8250: Add support for 8250/16550 as MFD function Esben Haabendal
2019-05-07 11:49 ` Lee Jones
2019-05-07 12:04 ` Esben Haabendal
2019-05-07 13:38 ` Lee Jones
2019-05-14 8:00 ` Esben Haabendal
2019-05-14 10:47 ` Lee Jones
2019-05-14 12:26 ` Greg Kroah-Hartman
2019-05-14 12:41 ` Esben Haabendal
2019-05-21 10:09 ` Greg Kroah-Hartman
2019-05-21 11:11 ` Esben Haabendal
2019-05-21 11:18 ` Greg Kroah-Hartman
2019-05-21 11:50 ` Esben Haabendal
2019-05-21 12:56 ` Greg Kroah-Hartman [this message]
2019-05-21 14:31 ` Esben Haabendal
2019-05-21 14:43 ` Greg Kroah-Hartman
2019-05-27 19:56 ` Enrico Weigelt, metux IT consult
2019-04-26 14:35 ` [PATCH 0/2] " Andy Shevchenko
2019-04-26 16:57 ` Esben Haabendal
2019-04-26 17:21 ` Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2019-04-26 16:55 [PATCH 2/2] " Esben Haabendal
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=20190521125651.GA6264@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=esben@haabendal.dk \
--cc=f.fainelli@gmail.com \
--cc=jslaby@suse.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=tony@atomide.com \
--cc=vigneshr@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).