From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] generic check_legacy_ioport
Date: Wed, 25 Apr 2007 08:34:36 +1000 [thread overview]
Message-ID: <1177454076.14873.128.camel@localhost.localdomain> (raw)
In-Reply-To: <20070424112530.GA11489@aepfle.de>
> Do you think a device_type fdc, i8042 or ipmi will appear outside an isa
> node?
Well, if they do, I don't want that code to recognize them... I'm pretty
sure for example we have IPMI on QS21 blades and it's not on an ISA bus
and shouldn't match the legacy IO ports for example.
> > To be totally correct, we should -also- check if the port number fits in
> > the the actual "reg" property but I'm not sure I can be bothered :-)
>
> Why all this complexity? Its there mainly to match a class of boards,
> not to match a specific device configuration.
>
> Thats how it may look finally, currently only compile tested.
>
> int check_legacy_ioport(unsigned long base_port)
> {
> struct device_node *parent, *np = NULL;
> int ret = -ENODEV;
>
> switch(base_port) {
> case I8042_DATA_REG:
> np = of_find_node_by_type(NULL, "8042");
> break;
> case FDC_BASE: /* FDC1 */
> np = of_find_node_by_type(NULL, "fdc");
> break;
> case 0xca2:
> case 0xca9:
> case 0xe4:
> np = of_find_node_by_type(NULL, "ipmi");
> break;
> #ifdef CONFIG_PPC_PREP
> case _PIDXR:
> case _PNPWRP:
> case PNPBIOS_BASE:
> /* implement me */
> #endif
> default:
> break;
> }
> if (np) {
Why not just
if (np == NULL)
return -ENODEV;
And save some tabs ? :-)
> parent = of_get_parent(np);
> if (parent) {
> ret = strcmp(parent->type, "isa");
> of_node_put(parent);
> }
> of_node_put(np);
> }
> return ret;
> }
Looks good except maybe
ret = strcmp(parent->type, "isa");
should probably be
ret = strcmp(parent->type, "isa") ? -ENODEV : 0;
Cheers,
Ben.
next prev parent reply other threads:[~2007-04-24 22:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-17 21:07 [PATCH] generic check_legacy_ioport Olaf Hering
2007-04-17 21:22 ` Arnd Bergmann
2007-04-17 23:28 ` Segher Boessenkool
2007-04-20 18:51 ` Olaf Hering
2007-04-22 5:15 ` Milton Miller
2007-04-22 6:46 ` Olaf Hering
2007-04-23 8:15 ` [PATCH] " Olaf Hering
2007-04-24 0:53 ` Benjamin Herrenschmidt
2007-04-24 11:25 ` Olaf Hering
2007-04-24 15:45 ` Milton Miller
2007-04-24 18:54 ` Olaf Hering
2007-04-24 22:01 ` Arnd Bergmann
2007-04-25 0:12 ` Benjamin Herrenschmidt
2007-04-25 1:54 ` Segher Boessenkool
2007-04-25 7:49 ` Arnd Bergmann
2007-04-25 13:33 ` Segher Boessenkool
2007-04-25 22:02 ` Arnd Bergmann
2007-04-25 0:09 ` Benjamin Herrenschmidt
2007-04-24 22:34 ` Benjamin Herrenschmidt [this message]
2007-04-25 20:36 ` Olaf Hering
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=1177454076.14873.128.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=olaf@aepfle.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;
as well as URLs for NNTP newsgroup(s).