From: Jiri Slaby <jslaby@suse.cz>
To: Josh Boyer <jwboyer@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 8250.nr_uarts broken in 3.7
Date: Sat, 09 Mar 2013 10:14:14 +0100 [thread overview]
Message-ID: <513AFD66.3030404@suse.cz> (raw)
In-Reply-To: <20130308234404.GP13719@hansolo.jdub.homelinux.org>
On 03/09/2013 12:44 AM, Josh Boyer wrote:
> On Fri, Mar 08, 2013 at 06:28:09PM -0500, Josh Boyer wrote:
>> On Sat, Mar 09, 2013 at 12:14:23AM +0100, Jiri Slaby wrote:
>>> On 03/09/2013 12:10 AM, Jiri Slaby wrote:
>>>> On 03/08/2013 11:58 PM, Jiri Slaby wrote:
>>>>> On 03/08/2013 11:49 PM, Josh Boyer wrote:
>>>>>> On Fri, Mar 08, 2013 at 11:47:01PM +0100, Jiri Slaby wrote:
>>>>>>> Yeah, I agree this is ugly. Just re-definining MODULE_PARAM_PREFIX at
>>>>>>> the end of the file should do the trick (followed by
>>>>>>> "module_param(nr_uarts, uint, 0644)").
>>>>>>
>>>>>> For some reason, I thought I had tried that. Maybe I didn't. I'll look
>>>>>> into it again.
>>>>>
>>>>> I see. Because we would re-define some global variables. What if we put
>>>>> module_param into a function?
>>>>
>>>> Something like this?
>>>> #ifdef MODULE
>>
>> I don't think you want this surrounded in #ifdef MODULE, do you? That
>> won't let people building the driver into the kernel continue to use
>> 8250.<whatever> on the kernel command line.
Yes, you're right. I sort of thought the prefix is not used for
non-modules. But it is.
>>>> static void __unused splat(void) {
>>>
>>> I meant __used. It should make no difference though.
>>>
>>>> # undef MODULE_PARAM_PREFIX
>>>> # define MODULE_PARAM_PREFIX "8250."
>>>> module_param_cb(nr_uarts, ¶m_ops_uint, &nr_uarts, 0644);
>>>> ...
>>>> }
>>>> #endif
>>>>
>>>> Not nice, but should work. The other way is to have those in a separate
>>>> file linked to 8250 (to avoid re-definition errors).
>>
>> Ew. I'll try the function first.
>
> OK, the function (without the surrounding ifdef) seems to be working OK.
> I'll do a bit more testing and send out a v2 in a bit.
>
> Thanks for the tip. It's still not pretty, but at least I don't feel
> ashamed about it.
I'm thinking about deprecating the 8250_core.* in some way. Better
sooner than later. The view of having both of them with that hack in the
kernel forever drives me bananas.
--
js
suse labs
next prev parent reply other threads:[~2013-03-09 9:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 18:56 8250.nr_uarts broken in 3.7 Josh Boyer
2013-03-07 18:58 ` Josh Boyer
2013-03-07 19:07 ` Jiri Slaby
2013-03-07 19:10 ` Josh Boyer
2013-03-07 21:14 ` Josh Boyer
2013-03-07 23:12 ` Greg Kroah-Hartman
2013-03-08 1:01 ` Josh Boyer
2013-03-08 1:39 ` Greg Kroah-Hartman
2013-03-08 21:27 ` Josh Boyer
2013-03-08 22:47 ` Jiri Slaby
2013-03-08 22:49 ` Josh Boyer
2013-03-08 22:58 ` Jiri Slaby
2013-03-08 23:10 ` Jiri Slaby
2013-03-08 23:14 ` Jiri Slaby
2013-03-08 23:28 ` Josh Boyer
2013-03-08 23:44 ` Josh Boyer
2013-03-09 9:14 ` Jiri Slaby [this message]
2013-03-09 13:30 ` Josh Boyer
2013-03-09 14:14 ` Jiri Slaby
2013-03-09 17:02 ` Josh Boyer
2013-03-10 14:33 ` [PATCH v2] serial: 8250: Keep 8250.<xxxx> module options functional after driver rename Josh Boyer
2013-03-10 22:33 ` Jiri Slaby
2013-03-10 12:21 ` 8250.nr_uarts broken in 3.7 Sean Young
2013-03-08 23:11 ` Josh Boyer
2013-03-08 23:11 ` Josh Boyer
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=513AFD66.3030404@suse.cz \
--to=jslaby@suse.cz \
--cc=gregkh@linuxfoundation.org \
--cc=jwboyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.