From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: linux-kernel@vger.kernel.org,
Jerome Oufella <jerome.oufella@savoirfairelinux.com>,
platform-driver-x86@vger.kernel.org,
linux-serial@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [RFC 2/5] gpio: add support for Technologic Systems TS-5500 GPIOs
Date: Sat, 30 Apr 2011 11:15:36 +0100 [thread overview]
Message-ID: <20110430111536.5cb49d59@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <1304115712-5299-3-git-send-email-vivien.didelot@savoirfairelinux.com>
> + * The TS-5500 board has 38 GPIOs referred to as DIOs in the product's
> + * litterature.
literature
> +#define MODULE_NAME "ts5500-gpio"
see dev_dbg etc and the fmt support in them - they will do all this for
you nicely and the various printks can become dev_* which will tidy it up
and give more info
> +
> +#define PORT_BIT_SET(addr, bit) \
> + do { \
> + u8 var; \
> + var = inb(addr); \
> + var |= (1 << bit); \
> + outb(var, addr); \
> + } while (0)
> +
> +#define PORT_BIT_CLEAR(addr, bit) \
> + do { \
> + u8 var; \
> + var = inb(addr); \
> + var &= ~(1 << bit); \
> + outb(var, addr); \
> + } while (0)
These shouldn't be magic macros especially if creating variables and give
the multiple references to addr will break on things like ++ - use a
function so it is typechecked and variables behave as espected.
> + /* Request DIO1 */
> + if (!request_region(0x7A, 3, "ts5500-gpio-DIO1")) {
> + dev_err(&pdev->dev, "Cannot request I/O port 0x7A-7C\n");
> + goto err_req_dio1;
> + }
> +
> + /* Request DIO2 */
> + if (!request_region(0x7D, 3, "ts5500-gpio-DIO2")) {
> + dev_err(&pdev->dev, "Cannot request I/O port 0x7D-7F\n");
> + goto err_req_dio2;
> + }
> +
> + /* Request LCDIO if wanted */
> + if (use_lcdio && !request_region(0x72, 2, "ts5500-gpio-LCD")) {
> + dev_err(&pdev->dev, "Cannot request I/O port 0x72-73\n");
> + goto err_req_lcdio;
> + }
I'd have expected these to be resources of the platform device but I
guess that if they are entirely fixed it doesn't really matter much.
> + /* Enable IRQ generation */
> + mutex_lock(&drvdata->gpio_lock);
> + PORT_BIT_SET(0x7A, 7); /* DIO1_13 on IRQ7 */
> + PORT_BIT_SET(0x7D, 7); /* DIO2_13 on IRQ6 */
> + if (use_lcdio) {
> + PORT_BIT_CLEAR(0x7D, 4); /* Enable LCD header usage as DIO */
> + PORT_BIT_SET(0x7D, 6); /* LCD_RS on IRQ1 */
> + }
What happens if an IRQ occurs at this point, you have no handler for it ?
> +err_gpiochip_add:
> + printk(KERN_ERR "gpio: Failed registering gpio chip.\n");
> + kfree(drvdata);
pr_err/dev_err etc - in general
> +
> +static int __init ts5500_gpio_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&ts5500_gpio_driver);
> + if (ret)
> + return ret;
> +
> + ret = platform_device_register(&gpio_device);
> + if (ret) {
> + printk(MODULE_NAME ": Failed to register platform device\n");
> + platform_driver_unregister(&ts5500_gpio_driver);
> + return ret;
> + }
> +
> + printk(MODULE_NAME ": GPIO/DIO driver loaded.\n");
prinkt isn't needed
Also you've done no checks to see if it's being loaded on the right
board. I'd actually have expected a single chunk of code in
arch/x86/platform/ts5500 or similar to do the board check and create the
platform devices, and this code to just register them.
next prev parent reply other threads:[~2011-04-30 10:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 22:21 [RFC 0/5] Support for Technologic Systems TS-5500 board Vivien Didelot
2011-04-29 22:21 ` [RFC 1/5] platform-drivers-x86: add support for Technologic Systems TS-5xxx detection Vivien Didelot
2011-04-29 23:32 ` Greg KH
2011-05-02 21:07 ` Vivien Didelot
2011-05-02 21:55 ` Greg KH
2011-05-03 9:39 ` Alan Cox
2011-05-03 14:13 ` Greg KH
2011-04-30 10:07 ` Alan Cox
2011-05-04 15:15 ` Vivien Didelot
2011-05-04 15:29 ` Alan Cox
2011-05-04 20:34 ` Vivien Didelot
2011-05-05 13:38 ` Alan Cox
2011-05-11 22:24 ` Vivien Didelot
2011-05-17 12:37 ` Sean Young
2011-05-18 15:03 ` Vivien Didelot
2011-04-29 22:21 ` [RFC 2/5] gpio: add support for Technologic Systems TS-5500 GPIOs Vivien Didelot
2011-04-30 10:15 ` Alan Cox [this message]
2011-05-13 21:33 ` Vivien Didelot
2011-05-13 22:03 ` Alan Cox
2011-05-04 16:29 ` Arnd Bergmann
2011-04-29 22:21 ` [RFC 3/5] serial: add support for Technologic Systems TS-5500 RS-485 serial port Vivien Didelot
2011-04-30 10:17 ` Alan Cox
2011-06-06 20:48 ` Vivien Didelot
2011-04-29 22:21 ` [RFC 4/5] leds: add support for Technologic Systems TS-5500 leds Vivien Didelot
2011-05-03 6:04 ` Govindraj
2011-04-29 22:21 ` [RFC 5/5] hwmon: add support for Technologic Systems TS-5500 A-D converter Vivien Didelot
2011-04-30 3:39 ` [lm-sensors] " Guenter Roeck
2011-04-30 9:56 ` Jonathan Cameron
2011-05-03 15:55 ` Vivien Didelot
2011-05-03 17:33 ` Guenter Roeck
2011-05-04 9:03 ` Jonathan Cameron
2011-04-30 10:20 ` Alan Cox
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=20110430111536.5cb49d59@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=jerome.oufella@savoirfairelinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.com \
/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
all inboxes | Powered by JetHome®