From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/9] ioport.h: Remove struct resource & co
Date: Fri, 29 Jan 2016 21:50:37 +0100 [thread overview]
Message-ID: <201601292150.37191.marex@denx.de> (raw)
In-Reply-To: <20160129155840.GA3017@NP-P-BURTON>
On Friday, January 29, 2016 at 04:58:40 PM, Paul Burton wrote:
> On Fri, Jan 29, 2016 at 03:06:33PM +0100, Marek Vasut wrote:
> > On Friday, January 29, 2016 at 02:54:47 PM, Paul Burton wrote:
> > > We only use struct resource in a single place (drivers/usb/dwc3/core.h)
> > > for a field (xhci_resources) which is never used. Only ARM currently
> > > defines resource_size_t which means linux/ioport.h only compiles there.
> > > In preparation for making use of the IORESOURCE_ flags, remove struct
> > > resource & the various declarations of functions which we don't
> > > implement.
> > >
> > > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > > ---
> > >
> > > drivers/usb/dwc3/core.h | 1 -
> > > include/linux/ioport.h | 104
> > >
> > > ------------------------------------------------ 2 files changed, 105
> > > deletions(-)
> >
> > I believe the driver is imported from Linux kernel, so it'd be much
> > better to sync the driver with mainline Linux instead of starting to
> > diverge.
> >
> > Best regards,
> > Marek Vasut
>
> Hi Marek,
Hi,
> The problem is that the driver can't use struct resource because U-Boot
> has none of the infrastructure around it. The driver model doesn't use
> struct resource, there's basically nothing in U-Boot to fill out the
> struct. So unless that changes this dwc3 driver will always have to
> handle resources differently to on Linux.
>
> I therefore don't see any good reason to keep around an unused struct
> which will only currently compile for one architecture, for a driver
> which can't use it in U-Boot anyway.
>
> The alternative to this patch would be to define resource_size_t for
> other architectures, but then we're just left with dead code.
But the downside is, if we start collecting u-boot specific patches on
top of the driver, syncing with Linux will become painful.
I have to admit I am not decided which way to take with this driver. One
option might be to add simple #ifdef __linux__ around the code you want
to disable, this would be least intrusive way to keep the code around and
make it kinda easy to sync with Linux.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2016-01-29 20:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 13:54 [U-Boot] [PATCH 0/9] Malta UART using device model & device tree Paul Burton
2016-01-29 13:54 ` [U-Boot] [PATCH 1/9] ioport.h: Remove struct resource & co Paul Burton
2016-01-29 14:06 ` Marek Vasut
2016-01-29 15:58 ` Paul Burton
2016-01-29 20:50 ` Marek Vasut [this message]
2016-01-29 13:54 ` [U-Boot] [PATCH 2/9] fdt: Support for ISA busses Paul Burton
2016-01-29 14:56 ` Simon Glass
2016-01-29 16:04 ` Paul Burton
2016-01-29 18:23 ` Simon Glass
2016-01-29 13:54 ` [U-Boot] [PATCH 3/9] fdt: Support providing IORESOURCE_* flags from translation Paul Burton
2016-01-29 14:56 ` Simon Glass
2016-01-29 13:54 ` [U-Boot] [PATCH 4/9] ns16550: Support I/O accessors selected by DT Paul Burton
2016-01-29 14:56 ` Simon Glass
2016-01-29 16:09 ` Paul Burton
2016-01-29 18:23 ` Simon Glass
2016-01-29 13:54 ` [U-Boot] [PATCH 5/9] MIPS: Remove SLOW_DOWN_IO Paul Burton
2016-02-01 21:27 ` Daniel Schwierzeck
2016-01-29 13:54 ` [U-Boot] [PATCH 6/9] MIPS: Support dynamic I/O port base address Paul Burton
2016-02-01 21:27 ` Daniel Schwierzeck
2016-01-29 13:54 ` [U-Boot] [PATCH 7/9] malta: Set I/O port base early Paul Burton
2016-02-01 21:24 ` Daniel Schwierzeck
2016-01-29 13:54 ` [U-Boot] [PATCH 8/9] malta: Use I/O accessors for SuperI/O controller Paul Burton
2016-02-01 21:26 ` Daniel Schwierzeck
2016-01-29 13:54 ` [U-Boot] [PATCH 9/9] malta: Use device model & tree for UART Paul Burton
2016-01-29 14:05 ` [U-Boot] [PATCH 0/9] Malta UART using device model & device tree Marek Vasut
2016-01-29 14:50 ` Daniel Schwierzeck
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=201601292150.37191.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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