linux-mips
[Top] [All Lists]

Re: [PATCH V2] MIPS: Alchemy: fix build with SERIAL_8250=n

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH V2] MIPS: Alchemy: fix build with SERIAL_8250=n
From: Manuel Lauss <manuel.lauss@googlemail.com>
Date: Fri, 10 Dec 2010 21:56:11 +0100
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZjZzNRviWvRpOlgS2gDZj7meviUxj/GGYfYeeIoflBc=; b=HAzIvD4Q6ejMsDKXJCe2DWR5NaALWPd2MPZWmRiAhvkqD6LHvSZ/d47ijDc71ehdue Pk7eg3v0YVUBniKJeuKD9ZX1FuavYWbe3HvwIngEZzDvWD0G1IbbDHu4RwdoPf1w/6yu JJ4OegfjlHuBhnoDFViFXbSKTWHaCm5QAXScg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZH/vxbINf5VcVtn++UXav2zhre1ylFknjGtHV/kvED6pgQnpNQ4Ok6ep6CbcAy1Jan 1aHmbCKy9XIJsLEqPkn5ScVStbkrtJyAANKUAW/CvguE1mVZYJBUTJz7gE9sN3g978f2 +X6yJi4MDIJaMFM+pKKAPSQPJB8AwKQE+L3A0=
In-reply-to: <20101210204052.GA1274@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1288025051-17145-1-git-send-email-manuel.lauss@googlemail.com> <20101210204052.GA1274@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Fri, Dec 10, 2010 at 9:40 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
>
> On Mon, Oct 25, 2010 at 06:44:11PM +0200, Manuel Lauss wrote:
>
> > In commit 7d172bfe ("Alchemy: Add UART PM methods") I introduced
> > platform PM methods which call a function of the 8250 driver;
> > this patch works around link failures when the kernel is built
> > without 8250 support.
> >
> > Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
> > ---
> > V2: added commit name to patch description as per Sergei's suggestion.
>
> Applied, thanks.
>
> Though anything like a CONFIG_SERIAL_8250 in board code always strikes me
> as wrong.  What if the driver is built as a module?  What if the kernel is
> built without the driver, then later on the module is built separately and
> then inserted?

Hm, I think I understand.  How's this approach (untested)?

--

<Prev in Thread] Current Thread [Next in Thread>