All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: devicetree-discuss@lists.ozlabs.org, grant.likely@secretlab.ca,
	john.williams@petalogix.com, linux-kernel@vger.kernel.org,
	hjk@linutronix.de, gregkh@suse.de
Subject: Re: [PATCH] uio/pdrv_genirq: Add OF support
Date: Thu, 31 Mar 2011 15:28:41 +0200	[thread overview]
Message-ID: <4D948189.9070606@monstr.eu> (raw)
In-Reply-To: <20110331124925.GA2202@pengutronix.de>

Wolfram Sang wrote:
> On Thu, Mar 31, 2011 at 02:30:00PM +0200, Michal Simek wrote:
>> Support OF support. "generic-uio" compatible property is used.
> 
> And exactly this was the issue last time (when I tried). This is a
> generic property, which is linux-specific and not describing HW. The
> agreement back then was to we probably need to add compatible-entries at
> runtime (something like new_id for USB). So the uio-of-driver could be
> matched against any device. Otherwise, we would collect a lot of
> potential entries like "vendor,special-card1". Although I wonder
> meanwhile if it is really going to be that bad; we don't have so much
> UIO-driver in tree as well. Maybe worth a try?

I will read reactions to get better picture to be able to argue. :-)

> 
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>>  drivers/uio/uio_pdrv_genirq.c |   60 ++++++++++++++++++++++++++++++++++++++--
>>  1 files changed, 57 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
>> index 7174d51..9e89806 100644
>> --- a/drivers/uio/uio_pdrv_genirq.c
>> +++ b/drivers/uio/uio_pdrv_genirq.c
>> @@ -23,6 +23,10 @@
>>  #include <linux/pm_runtime.h>
>>  #include <linux/slab.h>
>>  
>> +#include <linux/of.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/of_address.h>
>> +
>>  #define DRIVER_NAME "uio_pdrv_genirq"
>>  
>>  struct uio_pdrv_genirq_platdata {
>> @@ -92,11 +96,44 @@ static int uio_pdrv_genirq_irqcontrol(struct uio_info *dev_info, s32 irq_on)
>>  static int uio_pdrv_genirq_probe(struct platform_device *pdev)
>>  {
>>  	struct uio_info *uioinfo = pdev->dev.platform_data;
>> -	struct uio_pdrv_genirq_platdata *priv;
>> +	struct uio_pdrv_genirq_platdata *priv = NULL;
> 
> unrelated?

you are right here. I changed order and this is not necessary.


> 
>>  	struct uio_mem *uiomem;
>>  	int ret = -EINVAL;
>>  	int i;
>>  
>> +	if (!uioinfo) {
>> +		struct resource r_irq; /* Interrupt resources */
>> +		int rc = 0;
>> +
>> +		rc = of_address_to_resource(pdev->dev.of_node, 0,
>> +							&pdev->resource[0]);
>> +		if (rc) {
>> +			dev_err(&pdev->dev, "invalid address\n");
>> +			goto bad2;
>> +		}
>> +		pdev->num_resources = 1;
>> +
>> +		/* alloc uioinfo for one device */
>> +		uioinfo = kzalloc(sizeof(*uioinfo), GFP_KERNEL);
>> +		if (!uioinfo) {
>> +			ret = -ENOMEM;
>> +			dev_err(&pdev->dev, "unable to kmalloc\n");
>> +			goto bad2;
>> +		}
>> +		uioinfo->name = pdev->dev.of_node->name;
>> +		/* Use version for storing full IP name for identification */
>> +		uioinfo->version = pdev->dev.of_node->full_name;
> 
> I don't think this is apropriate, but will leave that to Hans.

I was thinking what to add and I choose full_name because I can read this value 
and identify which UIO is this device.
I know that there should be version but there is no version string in DTS.

> 
>> +		/* Get IRQ for the device */
>> +		rc = of_irq_to_resource(pdev->dev.of_node, 0, &r_irq);
>> +		if (rc == NO_IRQ)
>> +			dev_err(&pdev->dev, "no IRQ found\n");
> 
> No error, I think. Sometimes just mmaping the registers is enough.

OK. Let's changed it to dev_info if you like.


> 
>> +		else {
>> +			uioinfo->irq = r_irq.start;
>> +			dev_info(&pdev->dev, "irq %d\n", (u32)uioinfo->irq);
>> +		}
>> +	}
>> +
>>  	if (!uioinfo || !uioinfo->name || !uioinfo->version) {
>>  		dev_err(&pdev->dev, "missing platform_data\n");
>>  		goto bad0;
>> @@ -176,10 +213,15 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
>>  
>>  	platform_set_drvdata(pdev, priv);
>>  	return 0;
>> - bad1:
>> +
>> +bad1:
> 
> The spaces before labels are intentional, better keep them.

I found both cases. checkpatch doesn't show any problem for both cases that's 
why if you like space before label, I am fine with this.

Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

  parent reply	other threads:[~2011-03-31 13:28 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-31 12:29 UIO OF support Michal Simek
2011-03-31 12:29 ` Michal Simek
2011-03-31 12:30 ` [PATCH] uio/pdrv_genirq: Add " Michal Simek
2011-03-31 12:30   ` Michal Simek
2011-03-31 12:49   ` Wolfram Sang
2011-03-31 12:49     ` Wolfram Sang
     [not found]     ` <20110331124925.GA2202-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-03-31 13:10       ` John Williams
2011-03-31 13:23         ` Wolfram Sang
2011-03-31 13:23           ` Wolfram Sang
2011-03-31 13:37           ` Michal Simek
2011-03-31 13:37             ` Michal Simek
2011-03-31 13:47           ` John Williams
2011-03-31 13:47             ` John Williams
2011-03-31 16:25             ` Grant Likely
2011-03-31 16:25               ` Grant Likely
2011-03-31 13:11     ` John Williams
2011-03-31 13:11       ` John Williams
2011-03-31 13:25       ` Arnd Bergmann
2011-03-31 13:25         ` Arnd Bergmann
2011-03-31 13:51         ` Michal Simek
2011-03-31 16:34           ` Grant Likely
2011-03-31 13:28     ` Michal Simek [this message]
2011-03-31 17:03       ` Hans J. Koch
2011-03-31 17:57         ` Michal Simek
2011-03-31 19:23           ` Hans J. Koch
2011-03-31 19:48             ` Grant Likely
2011-03-31 20:30               ` Hans J. Koch
2011-04-02 10:35                 ` Wolfram Sang
2011-04-02 10:35                   ` Wolfram Sang
2011-04-04 17:04                   ` Hans J. Koch
2011-04-04 17:04                     ` Hans J. Koch
2011-04-04 17:31                     ` Wolfram Sang
2011-04-04 17:31                       ` Wolfram Sang
2011-04-04 18:24                       ` Hans J. Koch
2011-04-04 18:24                         ` Hans J. Koch
2011-04-05  6:25                         ` Michal Simek
2011-04-05  6:25                           ` Michal Simek
2011-04-05 11:50                           ` Hans J. Koch
2011-04-05 11:50                             ` Hans J. Koch
2011-03-31 16:43   ` Grant Likely
2011-03-31 16:43     ` Grant Likely
2011-03-31 17:54     ` Michal Simek
2011-03-31 17:54       ` Michal Simek

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=4D948189.9070606@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@suse.de \
    --cc=hjk@linutronix.de \
    --cc=john.williams@petalogix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=w.sang@pengutronix.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 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.