On Tue, Oct 10, 2017 at 06:21:34PM +0100, Srinivas Kandagatla wrote:
> On 10/10/17 17:49, Vinod Koul wrote:
> >>>>+static int slim_device_probe(struct device *dev)
> >>>>+{
> >>>>+ struct slim_device *sbdev;
> >>>>+ struct slim_driver *sbdrv;
> >>>>+ int status = 0;
> >>>>+
> >>>>+ sbdev = to_slim_device(dev);
> >>>>+ sbdrv = to_slim_driver(dev->driver);
> >>>>+
> >>>>+ sbdev->driver = sbdrv;
> >>>>+
> >>>>+ if (sbdrv->probe)
> >>>>+ status = sbdrv->probe(sbdev);
> >>>>+
> >>>>+ if (status)
> >>>>+ sbdev->driver = NULL;
> >>>>+ else if (sbdrv->device_up)
> >>>>+ schedule_slim_report(sbdev->ctrl, sbdev, true);
> >>>
> >>>can you please explain what this is trying to do?
> >>
> >>It is scheduling a device_up() callback in workqueue for reporting
> >>discovered device.
> >
> >any reason for that? Would the device not announce itself on the bus and
> >then you can synchronously update the device.
> You are correct, Device should announce itself in all cases. core should
> only call this callback only when device is announced, it does not make
> sense for this call in slim_device_probe(). Will remove it from here in next
> version.
Okay great. Btw do you need a notify being scheduled in those cases? I guess
your controller would get an interrupt and you will handle that in bottom
half and then cll this, so why not call in the bottom half?
> >>>>+/**
> >>>>+ * slim_register_controller: Controller bring-up and registration.
> ...
> >>>>+
> >>>>+ mutex_init(&ctrl->m_ctrl);
> >>>>+ ret = device_register(&ctrl->dev);
> >>>
> >>>one more device_register?? Can you explain why
> >>>
> >>
> >>This is a device for each controller.
> >
> >wont the controller have its own platform_device?
>
> Reason could be that slim_register controller can be called from any code
> not just platform devices..
ah which cases would those be. I was expecting that you would have a
platform_device as a slimbus controller which would call slim_register?
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
