From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Olof Johansson <olof@lixom•net>
Cc: linuxppc-dev@ozlabs•org, Guennadi Liakhovetski <g.liakhovetski@gmx•de>
Subject: Re: [PATCH] Move serial_dev_init to device_initcall()
Date: Fri, 24 Aug 2007 06:59:38 +0200 [thread overview]
Message-ID: <1187931578.5972.25.camel@localhost.localdomain> (raw)
In-Reply-To: <20070823231510.GA5619@lixom.net>
On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote:
> On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> > On Wed, 22 Aug 2007, Olof Johansson wrote:
> >
> > > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > > initcall is now called before I/O space is setup, but it's dependent on
> > > it being available.
> > >
> > > Since there's no way to make dependencies between initcalls, we'll just
> > > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > > aware of any better solution at this time.
> >
> > Do I understand it right, that with this change all UARTs, controlled by
> > legacy_serial will be initialized later, and that for example console
> > output will be first possible later?
>
> Yes, unfortunately. Unless they've got a udbg driver, since that
> would give console output during early boot anyway (even without using
> EARLY_DEBUG).
Legacy ports should get udbg first.
> > Maybe, if there is really no other
> > possibility for I/O space devices, we could have both calls
> >
> > arch_initcall(serial_mem_dev_init);
> > device_initcall(serial_io_dev_init);
> >
> > so, that at least MEMIO based UARTs could still initialize as before?
>
> That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
> on how to get the IO setup earlier instead.
IO space allocation now relies on get_vm_area() which can't be done too
early (not in setup_arch) which is why I allocate all PCI IO space at
PHB scanning time, which is a subsys initcall.
An option would be to do it from some other init call, but that's a bit
ugly. That means PCI would be split into setup_arch() setting up PHBs,
that initcall allocating the IO spaces, and later, the actual scan.
It would be tricky though as my current interface relies on pci_bus
structures. So you would also need to re-split that into a low-level
that works on the PHB and a high level version that works on the bus.
Is this really necessary ?
Ben.
next prev parent reply other threads:[~2007-08-24 4:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-23 0:26 [PATCH] Move serial_dev_init to device_initcall() Olof Johansson
2007-08-23 23:21 ` Guennadi Liakhovetski
2007-08-23 23:15 ` Olof Johansson
2007-08-24 4:59 ` Benjamin Herrenschmidt [this message]
2007-08-24 4:33 ` Olof Johansson
2007-08-29 22:52 ` Olof Johansson
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=1187931578.5972.25.camel@localhost.localdomain \
--to=benh@kernel$(echo .)crashing.org \
--cc=g.liakhovetski@gmx$(echo .)de \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=olof@lixom$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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