On Fri, Jun 07, 2013 at 02:14:19AM -0700, Guenter Roeck wrote:
> On Fri, Jun 07, 2013 at 09:45:19AM +0200, Johannes Thumshirn wrote:
> > On Thu, Jun 06, 2013 at 10:08:28AM -0700, Guenter Roeck wrote:
> > > On Thu, Jun 06, 2013 at 03:00:55PM +0200, Johannes Thumshirn wrote:
> > > > On Thu, Jun 06, 2013 at 04:31:10AM -0700, Guenter Roeck wrote:
> > > > > On Thu, Jun 06, 2013 at 12:51:03PM +0200, Johannes Thumshirn wrote:
> > > > > > On Mon, Jun 03, 2013 at 11:50:26AM +0200, Johannes Thumshirn wrote:
> > > > > > > On Fri, May 31, 2013 at 09:15:23PM -0700, Guenter Roeck wrote:
> > > > > > > > On Fri, May 31, 2013 at 02:55:19PM +0200, Johannes Thumshirn
> > > > > > > > wrote:
> > > > > > > > > Hi Guenther,
> > > > > > > > > On Fri, May 31, 2013 at 04:40:37AM -0700, Guenter Roeck wrote:
> > > > > > > > > > > +#define GPIO_WD_ENAB 169
> > > > > > > > > > > +#define GPIO_WD_FAST 170
> > > > > > > > > > > +#define GPIO_WD_TRIG 171
> > > > > > > > > > > +
> > > > > > > > > > > +#define GPIO_RST_CAUSE_BASE 166
> > > > > > > > > > > +
> > > > > > > > > >
> > > > > > > > > > I think I asked that before ... as you are supporting
> > > > > > > > > > devicetree, gpio pins
> > > > > > > > > > should really be provided through devicetree properties and
> > > > > > > > > > not be hardcoded.
> > > > > > > > > >
> > > > > > > > > Yes you did and I didn't come up with a solution to this
> > > > > > > > > problem yet. I understand
> > > > > > > > > and agree to your concerns but I'm lacking example
> > > > > > > > > code/documentation for it, maybe
> > > > > > > > > you can point me to an example on that and then I'll update
> > > > > > > > > my code accordingly.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Have a look at
> > > > > > > > Documentation/devicetree/bindings/gpio/gpio-fan.txt and
> > > > > > > > drivers/hwmon/gpio-fan.c.
> > > > > > >
> > > > > > > Thanks a lot, this really helped me out. Updated patch is comming
> > > > > > > today
> > > > > > > including the bindings document Arnd Bergmann requested. I only
> > > > > > > need to rebase
> > > > > > > the sysfs patch on top of that changes.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Johannes
> > > > > >
> > > > > > Regarding the sysfs patch, I have a funny effect in my (rebased)
> > > > > > sysfs code.
> > > > > >
> > > > > > Given the following code:
> > > > > >
> > > > > > +static ssize_t rebootcause_show(struct device *dev,
> > > > > > + struct device_attribute *attr,
> > > > > > + char *buf)
> > > > > > +{
> > > > > > + struct a21_wdt_drv *drv = dev_get_drvdata(dev);
> > > > > > + unsigned int reset = 0;
> > > > > > +
> > > > > > + if (!drv)
> > > > > > + return -EIO;
> > > > > > +
> > > > > > + reset = a21_wdt_get_bootstatus(drv);
> > > > > > +
> > > > > > + return sprintf(buf, "%s\n", reset_causes[reset]);
> > > > > > +}
> > > > > > +static DEVICE_ATTR(rebootcause, S_IRUGO, rebootcause_show, NULL);
> > > > > >
> > > > > > I actually need the check for if (!drv) to prevent an OOPS, as
> > > > > > dev_get_drvdata(dev) returns NULL., though it is set at the end of
> > > > > > my probe
> > > > > > function via:
> > > > > >
> > > > > > [...]
> > > > > > + ret = watchdog_register_device(&a21_wdt);
> > > > > > + if (ret) {
> > > > > > + dev_err(&pdev->dev, "Cannot register watchdog
> > > > > > device\n");
> > > > > > + goto err_register_wd;
> > > > > > + }
> > > > > > +
> > > > > > + dev_set_drvdata(&pdev->dev, drv);
> > > > > > +
> > > > > > + return 0;
> > > > > > [...]
> > > > > >
> > > > > > The watchdog driver itself is working without any troubles.
> > > > > >
> > > > > > Some advice here would be worth its weight in gold.
> > > > > >
> > > > > It has to be set before the attribute is created. Are you doing that
> > > > > ? Also, is
> > > > > 'dev' the same device pointer (ie is the 'dev' in your function the
> > > > > same as
> > > > > &pdev->dev) ?
> > > > >
> > > > > Guenter
> > > >
> > > > Hi Guenter,
> > > >
> > > > Thanks for the quick reply. Indeed 'dev' in my function is a struct
> > > > watchdog_device's dev (for device_create_file) and not &pdev->dev.
> > > > Which in turn
> > > > are not the same.
> > > >
> > > > A call to dev_set_drvdata(a21_wdt.dev, drv); solved the NULL pointer
> > > > access. So
> > > > last question, is it save to set the drvdata of a dev inside the struct
> > > > watchdog_device or do I break something vital that way?
> > > >
> > > Good question. At issue is if your driver 'owns' struct watchdog_device,
> > > or if the watchdog core owns it.
> > >
> > > However, since you know that a21_wdt.dev is the device, you can use
> > > container_of() to get a reference to a21_wdt, and watchdog_get_drvdata
> > > to get access to drv from a21_wdt. So you should not really need it.
> > >
> > > Thanks,
> > > Guenter
> >
> > OK, but doesn't the container_of() macro only work if the parent struct
> > embeds
> > the child struct and not a pointer to it? But struct watchdog_device only
> > has a
> > pointer to a struct device (checked my 3.10-rc4 as well as
> > watchdog-next/master,
> > just in case I missed something).
> >
> Yes, you are right, sorry for the noise.
>
> Guenter
No problem. Actually I hoped you tell me I was wrong and point me to the right
practice for this.
Anyway I'll send the patch as it is and hope it's clean for inclusion.
Thanks for your help.
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
