Date: Tue, 13 Dec 2005 18:00:53 +0000 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, imp@freebsd.org, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: puc fails to attach serial ports Message-ID: <1134496853.15730.118.camel@buffy.york.ac.uk> In-Reply-To: <200512131101.44375.jhb@freebsd.org> References: <20051211181324.G71610@ury.york.ac.uk> <1134481135.15730.76.camel@buffy.york.ac.uk> <1134485368.15730.95.camel@buffy.york.ac.uk> <200512131101.44375.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2005-12-13 at 11:01 -0500, John Baldwin wrote: > > OK, I've cracked what's happening. Indeed we are somehow missing a call > > to devclass_add_driver(9). I was loading puc as a module, and in that > > case the following relevant calls to devclass_add_driver are made: > > > Because sio(4) only includes sio_puc.c in the kernel if you have 'puc' in your > kernel config, and the puc kernel module only includes the puc files, it > doesn't include sio_puc.c and ppc_puc.c. uart has the same issue as well. > Looking at the three attachments, there's no reason for them to be dependent > on puc, they don't actually call any symbols in the puc(4) kernel module > itself, so they can be compiled into kernels w/o puc without causing any > harm. Then loading puc as a module would work. Here's a patch: Thanks! I can confirm that this patch fixes the problem I was seeing. I understand David O'Brien's concerns about the patch and associated increase in kernel size, but as it stands, there seems to be little point in creating a puc module as it cannot work with the GENERIC kernel (other than for devices using uart, as that isn't in GENERIC). Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1134496853.15730.118.camel>