Skip to content
Permalink
Browse files

Revert "microblaze: UIO setup compatible property"

This reverts commit 3976b66.

This patch removes "generic-uio" compatible string from the driver.
This hack is in our tree for a long time and it is time
to fix it. For ensuring the same behaviour please add
uio_pdrv_genirq.of_id="generic-uio" to bootargs.

Feel free to use different compatible string for your purpose.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
  • Loading branch information...
michalsimek committed Jan 16, 2015
1 parent 6fea4f8 commit 7ebd62dbc727ef343b07c01c852a15fc4d9cc9e5
Showing with 0 additions and 1 deletion.
  1. +0 −1 drivers/uio/uio_pdrv_genirq.c
@@ -253,7 +253,6 @@ static const struct dev_pm_ops uio_pdrv_genirq_dev_pm_ops = {

#ifdef CONFIG_OF
static struct of_device_id uio_of_genirq_match[] = {
{ .compatible = "generic-uio", },
{ /* This is filled with module_parm */ },
{ /* Sentinel */ },
};

9 comments on commit 7ebd62d

@jeff-dagenais

This comment has been minimized.

Copy link
Contributor

replied Jun 17, 2016

Is there documentation for why this was reverted? Should I expect problems by using generic-uio on a custom PL block?

@skuep

This comment has been minimized.

Copy link

replied Nov 8, 2016

Any explanation on why this is a "hack"? How would one use the UIO driver now for custom PL blocks, now where .compatible ="generic-uio" is not available in the DTS anymore?
The only option I see right now would be
chosen { bootargs = "console=ttyPS0,115200 earlyprintk uio_pdrv_genirq.of_id=generic-uio"; };

@klyone

This comment has been minimized.

Copy link

replied Jan 17, 2017

Has anyone got more information about the reason of this hack? I am interested to know because this change implies you have to implement a custom UIO driver necessarily as @skuep said.

@michalsimek

This comment has been minimized.

Copy link
Member Author

replied Jan 17, 2017

Hack was to use generic-uio compatible string. If you want to use it please follow instructions in commit message which is adding uio_pdrv_genirq.of_id="generic-uio" to command line.

@jeff-dagenais

This comment has been minimized.

Copy link
Contributor

replied Jan 17, 2017

Hi all, I think having uio_pdrv_genirq declaring affinity to "generic-uio" was a good idea, it makes sense, and unless I am missing something, it didn't hurt anyone.

uio_pdrv_genirq just isn't like that upstream and I'm guessing Xilinx people already have their hands full debating other kernel changes with the linux "authorities" for upstream merging. Right Michal?

If adding a default compatible string to uio_pdrv_genirq is important to you, you should take it with the UIO maintainers, and carry it in your kernel fork until then.

@michalsimek

This comment has been minimized.

Copy link
Member Author

replied Jan 17, 2017

It was already discussed that in past and the idea having any compatible property was declined and solution was to define it via cmdline, at module probing time, etc.
It means this is final solution compatible with mainline.

@klyone

This comment has been minimized.

Copy link

replied Jan 26, 2017

Oks, thanks a lot @michalsimek @jeff-dagenais for explanations! I think I understand better why it was performed. Only one question more, if I would want to define it at module probing time, What do I have to do?

@michalsimek

This comment has been minimized.

Copy link
Member Author

replied Jan 26, 2017

what about this modprobe uio_pdrv_genirq.ko of_id="generic-uio"?

@klyone

This comment has been minimized.

Copy link

replied Jan 26, 2017

Ahms oook @michalsimek you have to pass it as module parameter. That's fine! Thanks again!

Please sign in to comment.
You can’t perform that action at this time.