Re: Future of dosfstools project (FAT)
> On Oct 12, 2018, at 7:40 AM, Pali Rohár wrote: > >> On Friday 12 October 2018 11:19:41 Andreas Henriksson wrote: >> Hello everyone, >> >>> On Tue, Oct 02, 2018 at 04:44:10AM -0400, Jaroslav Skarvada wrote: >>> I am downstream maintainer of dosfstools in Fedora/RHEL. My personal opinion >>> with such kind of projects is that one or two years without activity doesn't >>> mean the project is dead. I don't know what happened with Andreas, but >>> in case of no response my +1 for the GitHub fork. I think it's non offensive >>> solution which can be easily reverted if needed. Please let me know if you >>> do it >> >> It seems Andreas is a Debian Developer (like myself), so I used the >> debian tooling for 'missing in action' (mia-query) and it seems >> he is occationally active (but showing obvious signs of busyness). >> >> I even found his irc nick and found him online. I told him about this >> mailing list thread and he replied that he has been extremely busy >> with things in his personal life lately and said he should really >> try to find some time to catch up with things, but since he hasn't >> replied here I thought I'd just let you know about the situation. >> Hopefully things calms down for him soon to allow him to catch up. >> >> I hope you find a good way to handle things in the mean time. More >> people probably need to help out reviewing incoming issues/PRs and other >> things that can help Andreas out with the maintenance burden, but with >> his current lack of time it might be better if someone motivated and >> capable just forks the project on github and starts doing the >> maintenance work in the fork. If things works out well, maybe this gives >> Andreas confidence he can safely hand over the official maintainer role >> to someone with more time for it (and you can 'unfork' again). >> >> Regards, >> Andreas Henriksson > > Ok, so it would be great if somebody can help Andreas with reviewing > opened dosfstools pull requests on github... > > https://github.com/dosfstools/dosfstools/pulls > > -- > Pali Rohár > pali.ro...@gmail.com Rather than fork it could he give someone access as a maintainer to the existing project?
Re: Future of dosfstools project (FAT)
> On Oct 12, 2018, at 7:40 AM, Pali Rohár wrote: > >> On Friday 12 October 2018 11:19:41 Andreas Henriksson wrote: >> Hello everyone, >> >>> On Tue, Oct 02, 2018 at 04:44:10AM -0400, Jaroslav Skarvada wrote: >>> I am downstream maintainer of dosfstools in Fedora/RHEL. My personal opinion >>> with such kind of projects is that one or two years without activity doesn't >>> mean the project is dead. I don't know what happened with Andreas, but >>> in case of no response my +1 for the GitHub fork. I think it's non offensive >>> solution which can be easily reverted if needed. Please let me know if you >>> do it >> >> It seems Andreas is a Debian Developer (like myself), so I used the >> debian tooling for 'missing in action' (mia-query) and it seems >> he is occationally active (but showing obvious signs of busyness). >> >> I even found his irc nick and found him online. I told him about this >> mailing list thread and he replied that he has been extremely busy >> with things in his personal life lately and said he should really >> try to find some time to catch up with things, but since he hasn't >> replied here I thought I'd just let you know about the situation. >> Hopefully things calms down for him soon to allow him to catch up. >> >> I hope you find a good way to handle things in the mean time. More >> people probably need to help out reviewing incoming issues/PRs and other >> things that can help Andreas out with the maintenance burden, but with >> his current lack of time it might be better if someone motivated and >> capable just forks the project on github and starts doing the >> maintenance work in the fork. If things works out well, maybe this gives >> Andreas confidence he can safely hand over the official maintainer role >> to someone with more time for it (and you can 'unfork' again). >> >> Regards, >> Andreas Henriksson > > Ok, so it would be great if somebody can help Andreas with reviewing > opened dosfstools pull requests on github... > > https://github.com/dosfstools/dosfstools/pulls > > -- > Pali Rohár > pali.ro...@gmail.com Rather than fork it could he give someone access as a maintainer to the existing project?
Re: [Xen-devel] [PATCHv3 0/2] libfs, xenfs: replace /proc/xen/xenbus with a symlink
On 6/28/16 2:06 PM, David Vrabel wrote: > Using /proc/xen/xenbus can cause deadlocks on the atomic file position > mutex since this file should behave like a character device and not a > regular file. This is easiest to achive by making it a symlink to the > existing /dev/xen/xenbus device. > > This requires extending simple_fill_super() to add symlinks as well as > regular files. > > Changes in v3: > - Rebased on v4.7-rc5. > > David Just a bit of a nudge to see where the status of this is at? We're at the point of potentially having yet another kernel release go out the door where the default behavior with Xen 4.6 and earlier is to deadlock domUs. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [Xen-devel] [PATCHv3 0/2] libfs, xenfs: replace /proc/xen/xenbus with a symlink
On 6/28/16 2:06 PM, David Vrabel wrote: > Using /proc/xen/xenbus can cause deadlocks on the atomic file position > mutex since this file should behave like a character device and not a > regular file. This is easiest to achive by making it a symlink to the > existing /dev/xen/xenbus device. > > This requires extending simple_fill_super() to add symlinks as well as > regular files. > > Changes in v3: > - Rebased on v4.7-rc5. > > David Just a bit of a nudge to see where the status of this is at? We're at the point of potentially having yet another kernel release go out the door where the default behavior with Xen 4.6 and earlier is to deadlock domUs. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [Xen-devel] [PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs
On 2/2/16 10:58 AM, Boris Ostrovsky wrote: > On 02/02/2016 11:21 AM, David Vrabel wrote: >> This needs some more description in the commit message. >> >>> --- a/arch/x86/xen/smp.c >>> +++ b/arch/x86/xen/smp.c >> [...] >>> +hctxt->cpu_regs.x86_32.cs_base = 0; >>> +hctxt->cpu_regs.x86_32.cs_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.cs_ar = 0xc9b; >>> +hctxt->cpu_regs.x86_32.ds_base = 0; >>> +hctxt->cpu_regs.x86_32.ds_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.ds_ar = 0xc93; >>> +hctxt->cpu_regs.x86_32.es_base = 0; >>> +hctxt->cpu_regs.x86_32.es_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.es_ar = 0xc93; >>> +hctxt->cpu_regs.x86_32.ss_base = 0; >>> +hctxt->cpu_regs.x86_32.ss_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.ss_ar = 0xc93; >>> +hctxt->cpu_regs.x86_32.tr_base = 0; >>> +hctxt->cpu_regs.x86_32.tr_limit = 0xff; >>> +hctxt->cpu_regs.x86_32.tr_ar = 0x8b; >> Lots of hard-coded values here. Should this be #defined somewhere? > > We also don't need to set bases to zero since hctxt is kzalloc'd. I'll > remove that and add a comment. > > As for macros --- I couldn't find the bits defined symbolically anywhere > and since this is the only place this is used the macros would be local > here. > > -boris > It could be useful to have them defined locally if only to give them some more meaning by having a name rather than 0x8b. Just a thought. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [Xen-devel] [PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs
On 2/2/16 10:58 AM, Boris Ostrovsky wrote: > On 02/02/2016 11:21 AM, David Vrabel wrote: >> This needs some more description in the commit message. >> >>> --- a/arch/x86/xen/smp.c >>> +++ b/arch/x86/xen/smp.c >> [...] >>> +hctxt->cpu_regs.x86_32.cs_base = 0; >>> +hctxt->cpu_regs.x86_32.cs_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.cs_ar = 0xc9b; >>> +hctxt->cpu_regs.x86_32.ds_base = 0; >>> +hctxt->cpu_regs.x86_32.ds_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.ds_ar = 0xc93; >>> +hctxt->cpu_regs.x86_32.es_base = 0; >>> +hctxt->cpu_regs.x86_32.es_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.es_ar = 0xc93; >>> +hctxt->cpu_regs.x86_32.ss_base = 0; >>> +hctxt->cpu_regs.x86_32.ss_limit = ~0u; >>> +hctxt->cpu_regs.x86_32.ss_ar = 0xc93; >>> +hctxt->cpu_regs.x86_32.tr_base = 0; >>> +hctxt->cpu_regs.x86_32.tr_limit = 0xff; >>> +hctxt->cpu_regs.x86_32.tr_ar = 0x8b; >> Lots of hard-coded values here. Should this be #defined somewhere? > > We also don't need to set bases to zero since hctxt is kzalloc'd. I'll > remove that and add a comment. > > As for macros --- I couldn't find the bits defined symbolically anywhere > and since this is the only place this is used the macros would be local > here. > > -boris > It could be useful to have them defined locally if only to give them some more meaning by having a name rather than 0x8b. Just a thought. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails
On 12/2/15 4:35 AM, David Vrabel wrote: > On 26/11/15 20:32, Doug Goldstein wrote: >> When allocating a pciback device fails, avoid the possibility of a >> use after free. > > We should not require clearing drvdata for correctness. We should > ensure we retain drvdata for as long as it is needed. > > I note that pcistub_device_release() has: > > kfree(dev_data); > pci_set_drvdata(dev, NULL); > > /* Clean-up the device */ > xen_pcibk_config_free_dyn_fields(dev); > xen_pcibk_config_free_dev(dev); > > Which should (at a minimum) be reordered to move the kfree(dev_data) to > after the calls that require it > > David > I apologize but at this point I'm confused at what action I should be taking. Are you saying NACK to the original patch and suggesting this as the replacement? Or saying that this should be done in addition to the original patch? I created the original patch when looking through the other probe() calls and seeing that they all did pci_set_drvdata() with memory they allocated but probe() failed they ensured that pci_set_drvdata() was cleared. But the behavior in xen-pciback was different. It kfree()'d the memory that passed to pci_set_drvdata() and never set that pointer to NULL. Which could possibly result in a use after free. The use after free doesn't occur today as Konrad pointed out but in the future its possible should some other code changes occur. It was more of a defensive coding patch in the end. I had planned on resubmitting the patch with a reworded commit message after Konrad pointed out there was currently no use after free and retaining the Reviewed-By since the code wouldn't change but if that's not what I should be doing I will gladly go another route. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails
On 12/2/15 4:35 AM, David Vrabel wrote: > On 26/11/15 20:32, Doug Goldstein wrote: >> When allocating a pciback device fails, avoid the possibility of a >> use after free. > > We should not require clearing drvdata for correctness. We should > ensure we retain drvdata for as long as it is needed. > > I note that pcistub_device_release() has: > > kfree(dev_data); > pci_set_drvdata(dev, NULL); > > /* Clean-up the device */ > xen_pcibk_config_free_dyn_fields(dev); > xen_pcibk_config_free_dev(dev); > > Which should (at a minimum) be reordered to move the kfree(dev_data) to > after the calls that require it > > David > I apologize but at this point I'm confused at what action I should be taking. Are you saying NACK to the original patch and suggesting this as the replacement? Or saying that this should be done in addition to the original patch? I created the original patch when looking through the other probe() calls and seeing that they all did pci_set_drvdata() with memory they allocated but probe() failed they ensured that pci_set_drvdata() was cleared. But the behavior in xen-pciback was different. It kfree()'d the memory that passed to pci_set_drvdata() and never set that pointer to NULL. Which could possibly result in a use after free. The use after free doesn't occur today as Konrad pointed out but in the future its possible should some other code changes occur. It was more of a defensive coding patch in the end. I had planned on resubmitting the patch with a reworded commit message after Konrad pointed out there was currently no use after free and retaining the Reviewed-By since the code wouldn't change but if that's not what I should be doing I will gladly go another route. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails
On 12/1/15 1:35 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 01, 2015 at 11:47:17AM -0500, Konrad Rzeszutek Wilk wrote: >> On Thu, Nov 26, 2015 at 02:32:39PM -0600, Doug Goldstein wrote: >>> When allocating a pciback device fails, avoid the possibility of a >>> use after free. >> >> Reviewed-by: Konrad Rzeszutek Wilk >> >> Ugh, and it looks like xen-blkfront has the same issue. > > Nope. No problems there. > > The ->probe if it fails (so xenbus_dev_probe returns the error) > ends up in the 'probe_failed' label in really_probe which takes care by doing: > > dev_set_drvdata(dev, NULL); > > Wheew! > > either way the patch should go in, but the 'possibility' should > be perhaps removed? Unless there is some other path I missed? I put 'possibility' in there because it will only happen when the function returns failure. I was also trying to not make it sound panicky I guess. I can resubmit the patch with that word dropped if that's desirable. > >> >>> >>> Reported-by: Jonathan Creekmore >>> Signed-off-by: Doug Goldstein >>> --- >>> drivers/xen/xen-pciback/xenbus.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/xen/xen-pciback/xenbus.c >>> b/drivers/xen/xen-pciback/xenbus.c >>> index 98bc345..4843741 100644 >>> --- a/drivers/xen/xen-pciback/xenbus.c >>> +++ b/drivers/xen/xen-pciback/xenbus.c >>> @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct >>> xenbus_device *xdev) >>> dev_dbg(>dev, "allocated pdev @ 0x%p\n", pdev); >>> >>> pdev->xdev = xdev; >>> - dev_set_drvdata(>dev, pdev); >>> >>> mutex_init(>dev_lock); >>> >>> @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct >>> xenbus_device *xdev) >>> kfree(pdev); >>> pdev = NULL; >>> } >>> + >>> + dev_set_drvdata(>dev, pdev); >>> + >>> out: >>> return pdev; >>> } >>> -- >>> 2.4.10 >>> -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails
On 12/1/15 10:47 AM, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 26, 2015 at 02:32:39PM -0600, Doug Goldstein wrote: >> When allocating a pciback device fails, avoid the possibility of a >> use after free. > > Reviewed-by: Konrad Rzeszutek Wilk > > Ugh, and it looks like xen-blkfront has the same issue. I believe that case is covered because xen_blkbk_remove() is called in all the failure cases of xen_blkbk_probe() in that case. > >> >> Reported-by: Jonathan Creekmore >> Signed-off-by: Doug Goldstein >> --- >> drivers/xen/xen-pciback/xenbus.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/xen/xen-pciback/xenbus.c >> b/drivers/xen/xen-pciback/xenbus.c >> index 98bc345..4843741 100644 >> --- a/drivers/xen/xen-pciback/xenbus.c >> +++ b/drivers/xen/xen-pciback/xenbus.c >> @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct >> xenbus_device *xdev) >> dev_dbg(>dev, "allocated pdev @ 0x%p\n", pdev); >> >> pdev->xdev = xdev; >> -dev_set_drvdata(>dev, pdev); >> >> mutex_init(>dev_lock); >> >> @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct >> xenbus_device *xdev) >> kfree(pdev); >> pdev = NULL; >> } >> + >> +dev_set_drvdata(>dev, pdev); >> + >> out: >> return pdev; >> } >> -- >> 2.4.10 >> -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [Xen-devel] [PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option
On 12/1/15 4:44 AM, David Vrabel wrote: > On 01/12/15 10:42, David Vrabel wrote: >> On 30/11/15 21:35, Doug Goldstein wrote: >>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated >>> and /dev/xen/xenbus via pvops is used instead. This is an effort to >>> eventually drop this interface after a reasonable amount of time. >> >> I would prefer the ... /proc/xen/evtchn files to be > > I meant /proc/xen/privcmd here. > > David > I can look into that. I do have a few questions, some of which are out of scope from the original patch. Would it be preferable to just remove "xenbus" from the xenfs filesystem? Ever since Linux 3.14 even if you are running a version of Xen earlier than 4.6 you will not be able to have a disaggregated xenstore (which is the xenbus consumer) due to the addition of F_ATOMIC_POS. Is it safe for a kernel virtual filesystem to provide a symlink outside of itself where the destination can't be verified? Its possible this already exists and I just don't know off any cases off the top of my head. Since the /proc/xen mount point has been marked as COMPAT for nearly 6 years would the eventual goal be to move xenfs to somewhere like /sys/hypervisor given that most of the virtual filesystems are mounted under /sys now days? -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails
On 12/1/15 1:35 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 01, 2015 at 11:47:17AM -0500, Konrad Rzeszutek Wilk wrote: >> On Thu, Nov 26, 2015 at 02:32:39PM -0600, Doug Goldstein wrote: >>> When allocating a pciback device fails, avoid the possibility of a >>> use after free. >> >> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >> >> Ugh, and it looks like xen-blkfront has the same issue. > > Nope. No problems there. > > The ->probe if it fails (so xenbus_dev_probe returns the error) > ends up in the 'probe_failed' label in really_probe which takes care by doing: > > dev_set_drvdata(dev, NULL); > > Wheew! > > either way the patch should go in, but the 'possibility' should > be perhaps removed? Unless there is some other path I missed? I put 'possibility' in there because it will only happen when the function returns failure. I was also trying to not make it sound panicky I guess. I can resubmit the patch with that word dropped if that's desirable. > >> >>> >>> Reported-by: Jonathan Creekmore <jonathan.creekm...@gmail.com> >>> Signed-off-by: Doug Goldstein <car...@cardoe.com> >>> --- >>> drivers/xen/xen-pciback/xenbus.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/xen/xen-pciback/xenbus.c >>> b/drivers/xen/xen-pciback/xenbus.c >>> index 98bc345..4843741 100644 >>> --- a/drivers/xen/xen-pciback/xenbus.c >>> +++ b/drivers/xen/xen-pciback/xenbus.c >>> @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct >>> xenbus_device *xdev) >>> dev_dbg(>dev, "allocated pdev @ 0x%p\n", pdev); >>> >>> pdev->xdev = xdev; >>> - dev_set_drvdata(>dev, pdev); >>> >>> mutex_init(>dev_lock); >>> >>> @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct >>> xenbus_device *xdev) >>> kfree(pdev); >>> pdev = NULL; >>> } >>> + >>> + dev_set_drvdata(>dev, pdev); >>> + >>> out: >>> return pdev; >>> } >>> -- >>> 2.4.10 >>> -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails
On 12/1/15 10:47 AM, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 26, 2015 at 02:32:39PM -0600, Doug Goldstein wrote: >> When allocating a pciback device fails, avoid the possibility of a >> use after free. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > > Ugh, and it looks like xen-blkfront has the same issue. I believe that case is covered because xen_blkbk_remove() is called in all the failure cases of xen_blkbk_probe() in that case. > >> >> Reported-by: Jonathan Creekmore <jonathan.creekm...@gmail.com> >> Signed-off-by: Doug Goldstein <car...@cardoe.com> >> --- >> drivers/xen/xen-pciback/xenbus.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/xen/xen-pciback/xenbus.c >> b/drivers/xen/xen-pciback/xenbus.c >> index 98bc345..4843741 100644 >> --- a/drivers/xen/xen-pciback/xenbus.c >> +++ b/drivers/xen/xen-pciback/xenbus.c >> @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct >> xenbus_device *xdev) >> dev_dbg(>dev, "allocated pdev @ 0x%p\n", pdev); >> >> pdev->xdev = xdev; >> -dev_set_drvdata(>dev, pdev); >> >> mutex_init(>dev_lock); >> >> @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct >> xenbus_device *xdev) >> kfree(pdev); >> pdev = NULL; >> } >> + >> +dev_set_drvdata(>dev, pdev); >> + >> out: >> return pdev; >> } >> -- >> 2.4.10 >> -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [Xen-devel] [PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option
On 12/1/15 4:44 AM, David Vrabel wrote: > On 01/12/15 10:42, David Vrabel wrote: >> On 30/11/15 21:35, Doug Goldstein wrote: >>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated >>> and /dev/xen/xenbus via pvops is used instead. This is an effort to >>> eventually drop this interface after a reasonable amount of time. >> >> I would prefer the ... /proc/xen/evtchn files to be > > I meant /proc/xen/privcmd here. > > David > I can look into that. I do have a few questions, some of which are out of scope from the original patch. Would it be preferable to just remove "xenbus" from the xenfs filesystem? Ever since Linux 3.14 even if you are running a version of Xen earlier than 4.6 you will not be able to have a disaggregated xenstore (which is the xenbus consumer) due to the addition of F_ATOMIC_POS. Is it safe for a kernel virtual filesystem to provide a symlink outside of itself where the destination can't be verified? Its possible this already exists and I just don't know off any cases off the top of my head. Since the /proc/xen mount point has been marked as COMPAT for nearly 6 years would the eventual goal be to move xenfs to somewhere like /sys/hypervisor given that most of the virtual filesystems are mounted under /sys now days? -- Doug Goldstein signature.asc Description: OpenPGP digital signature
[PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option
Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
and /dev/xen/xenbus via pvops is used instead. This is an effort to
eventually drop this interface after a reasonable amount of time.
Signed-off-by: Doug Goldstein
---
drivers/xen/Kconfig | 12
drivers/xen/xenfs/super.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..7003984 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -123,6 +123,18 @@ config XEN_COMPAT_XENFS
a xen platform.
If in doubt, say yes.
+config XEN_COMPAT_XENFS_XENBUS
+ bool "xenbus accessible from xenfs"
+ depends on XENFS
+ default y
+ help
+ Since Xen 4.6.0, xenstore will prefer to use the /dev/xen/xenbus
+ device over the "xenbus" interface on the xenfs filesystem.
+ Selecting this causes the kernel to include the "xenbus"
+ interface on the xenfs filesystem and you can safely say no for
+ Xen 4.6.0 and newer.
+ If in doubt, say yes.
+
config XEN_SYS_HYPERVISOR
bool "Create xen entries under /sys/hypervisor"
depends on SYSFS
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..86ff5b3 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -45,14 +45,20 @@ static const struct file_operations capabilities_file_ops =
{
static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
{
static struct tree_descr xenfs_files[] = {
- [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+ [2] =
+#ifdef CONFIG_XEN_COMPAT_XENFS_XENBUS
+ { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+#endif
{ "capabilities", _file_ops, S_IRUGO },
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
{""},
};
static struct tree_descr xenfs_init_files[] = {
- [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+ [2] =
+#ifdef CONFIG_XEN_COMPAT_XENFS_XENBUS
+ { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+#endif
{ "capabilities", _file_ops, S_IRUGO },
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
--
2.4.10
--
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/
[PATCH 2/2] xen: wrap privcmd on xenfs with COMPAT option
Since Xen 4.7.0, using privcmd via xenfs (/proc/xen/privcmd) is deprecated
and /dev/xen/privcmd via pvops is used instead. This is an effort to
eventually drop this interface after a reasonable amount of time.
Signed-off-by: Doug Goldstein
---
drivers/xen/Kconfig | 12
drivers/xen/xenfs/super.c | 4
2 files changed, 16 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 7003984..c610902 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -135,6 +135,18 @@ config XEN_COMPAT_XENFS_XENBUS
Xen 4.6.0 and newer.
If in doubt, say yes.
+config XEN_COMPAT_XENFS_PRIVCMD
+ bool "privcmd accessible from xenfs"
+ depends on XENFS
+ default y
+ help
+ Since Xen 4.7.0, Xen userland will prefer to use the
+ /dev/xen/privcmd device over the "privcmd" interface on the
+ xenfs filesystem. Selecting this causes the kernel to include
+ the "privcmd" interface on the xenfs filesystem and you can
+ safely say no for Xen 4.7.0 and newer.
+ If in doubt, say yes.
+
config XEN_SYS_HYPERVISOR
bool "Create xen entries under /sys/hypervisor"
depends on SYSFS
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 86ff5b3..bb40970b 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -50,7 +50,9 @@ static int xenfs_fill_super(struct super_block *sb, void
*data, int silent)
{ "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
#endif
{ "capabilities", _file_ops, S_IRUGO },
+#ifdef CONFIG_XEN_COMPAT_XENFS_PRIVCMD
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+#endif
{""},
};
@@ -60,7 +62,9 @@ static int xenfs_fill_super(struct super_block *sb, void
*data, int silent)
{ "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
#endif
{ "capabilities", _file_ops, S_IRUGO },
+#ifdef CONFIG_XEN_COMPAT_XENFS_PRIVCMD
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+#endif
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
#ifdef CONFIG_XEN_SYMS
--
2.4.10
--
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/
[PATCH 2/2] xen: wrap privcmd on xenfs with COMPAT option
Since Xen 4.7.0, using privcmd via xenfs (/proc/xen/privcmd) is deprecated
and /dev/xen/privcmd via pvops is used instead. This is an effort to
eventually drop this interface after a reasonable amount of time.
Signed-off-by: Doug Goldstein <car...@cardoe.com>
---
drivers/xen/Kconfig | 12
drivers/xen/xenfs/super.c | 4
2 files changed, 16 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 7003984..c610902 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -135,6 +135,18 @@ config XEN_COMPAT_XENFS_XENBUS
Xen 4.6.0 and newer.
If in doubt, say yes.
+config XEN_COMPAT_XENFS_PRIVCMD
+ bool "privcmd accessible from xenfs"
+ depends on XENFS
+ default y
+ help
+ Since Xen 4.7.0, Xen userland will prefer to use the
+ /dev/xen/privcmd device over the "privcmd" interface on the
+ xenfs filesystem. Selecting this causes the kernel to include
+ the "privcmd" interface on the xenfs filesystem and you can
+ safely say no for Xen 4.7.0 and newer.
+ If in doubt, say yes.
+
config XEN_SYS_HYPERVISOR
bool "Create xen entries under /sys/hypervisor"
depends on SYSFS
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 86ff5b3..bb40970b 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -50,7 +50,9 @@ static int xenfs_fill_super(struct super_block *sb, void
*data, int silent)
{ "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
#endif
{ "capabilities", _file_ops, S_IRUGO },
+#ifdef CONFIG_XEN_COMPAT_XENFS_PRIVCMD
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+#endif
{""},
};
@@ -60,7 +62,9 @@ static int xenfs_fill_super(struct super_block *sb, void
*data, int silent)
{ "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
#endif
{ "capabilities", _file_ops, S_IRUGO },
+#ifdef CONFIG_XEN_COMPAT_XENFS_PRIVCMD
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+#endif
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
#ifdef CONFIG_XEN_SYMS
--
2.4.10
--
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/
[PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option
Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
and /dev/xen/xenbus via pvops is used instead. This is an effort to
eventually drop this interface after a reasonable amount of time.
Signed-off-by: Doug Goldstein <car...@cardoe.com>
---
drivers/xen/Kconfig | 12
drivers/xen/xenfs/super.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..7003984 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -123,6 +123,18 @@ config XEN_COMPAT_XENFS
a xen platform.
If in doubt, say yes.
+config XEN_COMPAT_XENFS_XENBUS
+ bool "xenbus accessible from xenfs"
+ depends on XENFS
+ default y
+ help
+ Since Xen 4.6.0, xenstore will prefer to use the /dev/xen/xenbus
+ device over the "xenbus" interface on the xenfs filesystem.
+ Selecting this causes the kernel to include the "xenbus"
+ interface on the xenfs filesystem and you can safely say no for
+ Xen 4.6.0 and newer.
+ If in doubt, say yes.
+
config XEN_SYS_HYPERVISOR
bool "Create xen entries under /sys/hypervisor"
depends on SYSFS
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..86ff5b3 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -45,14 +45,20 @@ static const struct file_operations capabilities_file_ops =
{
static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
{
static struct tree_descr xenfs_files[] = {
- [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+ [2] =
+#ifdef CONFIG_XEN_COMPAT_XENFS_XENBUS
+ { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+#endif
{ "capabilities", _file_ops, S_IRUGO },
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
{""},
};
static struct tree_descr xenfs_init_files[] = {
- [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+ [2] =
+#ifdef CONFIG_XEN_COMPAT_XENFS_XENBUS
+ { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+#endif
{ "capabilities", _file_ops, S_IRUGO },
{ "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
--
2.4.10
--
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/
[PATCH] xen-pciback: fix up cleanup path when alloc fails
When allocating a pciback device fails, avoid the possibility of a use after free. Reported-by: Jonathan Creekmore Signed-off-by: Doug Goldstein --- drivers/xen/xen-pciback/xenbus.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c index 98bc345..4843741 100644 --- a/drivers/xen/xen-pciback/xenbus.c +++ b/drivers/xen/xen-pciback/xenbus.c @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) dev_dbg(>dev, "allocated pdev @ 0x%p\n", pdev); pdev->xdev = xdev; - dev_set_drvdata(>dev, pdev); mutex_init(>dev_lock); @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) kfree(pdev); pdev = NULL; } + + dev_set_drvdata(>dev, pdev); + out: return pdev; } -- 2.4.10 -- 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/
[PATCH] xen-pciback: fix up cleanup path when alloc fails
When allocating a pciback device fails, avoid the possibility of a use after free. Reported-by: Jonathan Creekmore <jonathan.creekm...@gmail.com> Signed-off-by: Doug Goldstein <car...@cardoe.com> --- drivers/xen/xen-pciback/xenbus.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c index 98bc345..4843741 100644 --- a/drivers/xen/xen-pciback/xenbus.c +++ b/drivers/xen/xen-pciback/xenbus.c @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) dev_dbg(>dev, "allocated pdev @ 0x%p\n", pdev); pdev->xdev = xdev; - dev_set_drvdata(>dev, pdev); mutex_init(>dev_lock); @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) kfree(pdev); pdev = NULL; } + + dev_set_drvdata(>dev, pdev); + out: return pdev; } -- 2.4.10 -- 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/
Re: [PATCH] USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
On Wed, Mar 25, 2015 at 3:44 AM, Johan Hovold wrote: > On Mon, Mar 23, 2015 at 08:34:48PM -0500, Doug Goldstein wrote: >> This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order >> to avoid attaching a TTY to the JTAG port as this board is based on the >> CALAO Systems reference design and needs the same fix up. > > Thanks for the patch. Could you please provide the full "lsusb -v" > output for the device before I apply it? > > Thanks, > Johan Johan, This is the "lsusb -v" of the device in question. Bus 002 Device 114: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6010 FT2232C Dual USB-UART/FIFO IC bcdDevice5.00 iManufacturer 1 Synapse iProduct2 SNAP Connect E10 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 2 SNAP Connect E10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 2 SNAP Connect E10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) I'm game for a better way of avoiding having a tty bound to the first interface. I've been trying to figure out if I can do it via udev as well but have had no luck there. -- Doug Goldstein -- 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/
Re: [PATCH] USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
On Wed, Mar 25, 2015 at 3:44 AM, Johan Hovold jo...@kernel.org wrote: On Mon, Mar 23, 2015 at 08:34:48PM -0500, Doug Goldstein wrote: This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order to avoid attaching a TTY to the JTAG port as this board is based on the CALAO Systems reference design and needs the same fix up. Thanks for the patch. Could you please provide the full lsusb -v output for the device before I apply it? Thanks, Johan Johan, This is the lsusb -v of the device in question. Bus 002 Device 114: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6010 FT2232C Dual USB-UART/FIFO IC bcdDevice5.00 iManufacturer 1 Synapse iProduct2 SNAP Connect E10 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 2 SNAP Connect E10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 2 SNAP Connect E10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) I'm game for a better way of avoiding having a tty bound to the first interface. I've been trying to figure out if I can do it via udev as well but have had no luck there. -- Doug Goldstein -- 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/
[PATCH] USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order to avoid attaching a TTY to the JTAG port as this board is based on the CALAO Systems reference design and needs the same fix up. Signed-off-by: Doug Goldstein CC: stable --- drivers/usb/serial/ftdi_sio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 3086dec..27076d7 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1884,7 +1884,8 @@ static int ftdi_8u2232c_probe(struct usb_serial *serial) struct usb_device *udev = serial->dev; if ((udev->manufacturer && !strcmp(udev->manufacturer, "CALAO Systems")) || - (udev->product && !strcmp(udev->product, "BeagleBone/XDS100V2"))) + (udev->product && !strcmp(udev->product, "BeagleBone/XDS100V2")) || + (udev->product && !strcmp(udev->product, "SNAP Connect E10"))) return ftdi_jtag_probe(serial); return 0; -- 2.0.5 -- 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/
[PATCH] USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order to avoid attaching a TTY to the JTAG port as this board is based on the CALAO Systems reference design and needs the same fix up. Signed-off-by: Doug Goldstein car...@cardoe.com CC: stable sta...@vger.kernel.org --- drivers/usb/serial/ftdi_sio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 3086dec..27076d7 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1884,7 +1884,8 @@ static int ftdi_8u2232c_probe(struct usb_serial *serial) struct usb_device *udev = serial-dev; if ((udev-manufacturer !strcmp(udev-manufacturer, CALAO Systems)) || - (udev-product !strcmp(udev-product, BeagleBone/XDS100V2))) + (udev-product !strcmp(udev-product, BeagleBone/XDS100V2)) || + (udev-product !strcmp(udev-product, SNAP Connect E10))) return ftdi_jtag_probe(serial); return 0; -- 2.0.5 -- 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/
[PATCH] USB: ftdi_sio: Added custom PID for Synapse Wireless product
Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their
SNAP Stick 200 product.
Signed-off-by: Doug Goldstein
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 3086dec..247130b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -997,6 +997,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_SYNAPSE_SS200_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 56b1b55..4e4f46f 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -561,6 +561,12 @@
*/
#define FTDI_NT_ORIONLXM_PID 0x7c90 /* OrionLXm Substation Automation
Platform */
+/*
+ * Synapse Wireless product ids (FTDI_VID)
+ * http://www.synapse-wireless.com
+ */
+#define FTDI_SYNAPSE_SS200_PID 0x9090 /* SS200 - SNAP Stick 200 */
+
//
/** third-party VID/PID combos **/
--
2.0.5
--
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/
[PATCH] USB: ftdi_sio: Added custom PID for Synapse Wireless product
Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their
SNAP Stick 200 product.
Signed-off-by: Doug Goldstein car...@cardoe.com
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 3086dec..247130b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -997,6 +997,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_SYNAPSE_SS200_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 56b1b55..4e4f46f 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -561,6 +561,12 @@
*/
#define FTDI_NT_ORIONLXM_PID 0x7c90 /* OrionLXm Substation Automation
Platform */
+/*
+ * Synapse Wireless product ids (FTDI_VID)
+ * http://www.synapse-wireless.com
+ */
+#define FTDI_SYNAPSE_SS200_PID 0x9090 /* SS200 - SNAP Stick 200 */
+
//
/** third-party VID/PID combos **/
--
2.0.5
--
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/
Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu
0x73 > [] tick_sched_timer+0x7c/0x9b > [] __run_hrtimer.clone.24+0x4e/0xc1 > [] hrtimer_interrupt+0xc7/0x1ac > [] smp_apic_timer_interrupt+0x81/0x94 > [] apic_timer_interrupt+0x6a/0x70 >[] ? console_unlock+0x2c2/0x2ed > [] ? panic+0x189/0x1c5 > [] ? panic+0xee/0x1c5 > [] do_exit+0x357/0x7b2 > [] oops_end+0xb2/0xba > [] no_context+0x266/0x275 > [] __bad_area_nosemaphore+0x1bb/0x1db > [] ? sysfs_addrm_finish+0x2f/0xa6 > [] bad_area_nosemaphore+0xe/0x10 > [] __do_page_fault+0x360/0x39f > [] ? ida_get_new_above+0xf9/0x19e > [] ? slab_node+0x59/0xa2 > [] ? mutex_unlock+0x9/0xb > [] ? klist_put+0x4c/0x70 > [] ? klist_next+0x30/0xb6 > [] ? pci_do_find_bus+0x49/0x49 > [] do_page_fault+0x9/0xb > [] page_fault+0x22/0x30 > [] ? nv_msi_ht_cap_quirk_all+0x10/0x10 > [] ? pci_get_dma_source+0xf/0x41 > [] intel_iommu_add_device+0x95/0x167 > [] add_iommu_group+0x3a/0x41 > [] ? bus_set_iommu+0x44/0x44 > [] bus_for_each_dev+0x54/0x81 > [] bus_set_iommu+0x3d/0x44 > [] intel_iommu_init+0xae5/0xb5e > [] ? free_initrd+0x9e/0x9e > [] ? memblock_find_dma_reserve+0x13f/0x13f > [] pci_iommu_init+0x16/0x41 > [] ? pci_proc_init+0x6b/0x6b > [] do_one_initcall+0x7a/0x129 > [] kernel_init+0x139/0x2a2 > [] ? loglevel+0x31/0x31 > [] ? rest_init+0x6f/0x6f > [] ret_from_fork+0x7c/0xb0 > [] ? rest_init+0x6f/0x6f > ---[ end trace 5c5a2ceca067e0ed ]--- > > -- > -- Matthew Thode (prometheanfire) The root cause of Matt's issue is that intel_iommu_add_device() calls pci_get_domain_bus_and_slot() which is returning NULL. Which is not an expected value. The reason NULL is being returned is that Matt has a card with a TI XIO2000A/XIO2200A PCIe-PCI bridge (VID: 104C, DID: 8231) on it. This device already has a quirk setup for disabling fast back to back transfers on its secondary bus. If we cause it to use the primary bus, that appears to resolve the issue. I'm not sure exactly how to proceed from here due to relative lack of knowledge of PCI. Do all PCIe-PCI bridges with secondary buses need their DMA parent to be the primary bus or is that just something that should be done for the TI XIO2000A due to the existing quirk? The failing call with arguments was pci_get_domain_bus_and_slot(0, 5, 0), while pci_get_domain_bus_and_slot(0, 4, 0) resulted in a system that didn't panic and a device that worked. $ lspci -tvn -+-[:ff]-+-00.0 8086:2c40 | +-00.1 8086:2c01 | +-02.0 8086:2c10 | +-02.1 8086:2c11 | +-02.4 8086:2c14 | +-02.5 8086:2c15 | +-03.0 8086:2c18 | +-03.1 8086:2c19 | +-03.2 8086:2c1a | +-03.4 8086:2c1c | +-04.0 8086:2c20 | +-04.1 8086:2c21 | +-04.2 8086:2c22 | +-04.3 8086:2c23 | +-05.0 8086:2c28 | +-05.1 8086:2c29 | +-05.2 8086:2c2a | +-05.3 8086:2c2b | +-06.0 8086:2c30 | +-06.1 8086:2c31 | +-06.2 8086:2c32 | \-06.3 8086:2c33 \-[:00]-+-00.0 8086:3406 +-01.0-[01]--+-00.0 8086:10c9 |\-00.1 8086:10c9 +-03.0-[02]-- +-05.0-[03]-- +-07.0-[04-05]00.0-[05]08.0 d161:8006 +-09.0-[06]00.0 8086:10b9 +-13.0 8086:342d +-14.0 8086:342e +-14.1 8086:3422 +-14.2 8086:3423 +-14.3 8086:3438 +-16.0 8086:3430 +-16.1 8086:3431 +-16.2 8086:3432 +-16.3 8086:3433 +-16.4 8086:3429 +-16.5 8086:342a +-16.6 8086:342b +-16.7 8086:342c +-1a.0 8086:3a37 +-1a.1 8086:3a38 +-1a.2 8086:3a39 +-1a.7 8086:3a3c +-1d.0 8086:3a34 +-1d.1 8086:3a35 +-1d.2 8086:3a36 +-1d.7 8086:3a3a +-1e.0-[07]01.0 102b:0532 +-1f.0 8086:3a16 +-1f.2 8086:3a22 \-1f.3 8086:3a30 If someone can craft the correct patch that'd be great or answer the above question and I'll gladly craft it. Thanks. -- Doug Goldstein -- 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/
Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu
[810a132f] update_process_times+0x62/0x73 [810cb78b] tick_sched_timer+0x7c/0x9b [810b0f83] __run_hrtimer.clone.24+0x4e/0xc1 [810b15b0] hrtimer_interrupt+0xc7/0x1ac [8104ef01] smp_apic_timer_interrupt+0x81/0x94 [816f71ca] apic_timer_interrupt+0x6a/0x70 EOI [81097ffc] ? console_unlock+0x2c2/0x2ed [816f32fc] ? panic+0x189/0x1c5 [816f3261] ? panic+0xee/0x1c5 [8109ab6b] do_exit+0x357/0x7b2 [810371b8] oops_end+0xb2/0xba [8105841d] no_context+0x266/0x275 [810585e7] __bad_area_nosemaphore+0x1bb/0x1db [8118de46] ? sysfs_addrm_finish+0x2f/0xa6 [81058615] bad_area_nosemaphore+0xe/0x10 [81058bdb] __do_page_fault+0x360/0x39f [81394afa] ? ida_get_new_above+0xf9/0x19e [8112a077] ? slab_node+0x59/0xa2 [816f3ffd] ? mutex_unlock+0x9/0xb [816da653] ? klist_put+0x4c/0x70 [816da581] ? klist_next+0x30/0xb6 [813b8cf9] ? pci_do_find_bus+0x49/0x49 [81058c42] do_page_fault+0x9/0xb [816f6232] page_fault+0x22/0x30 [813bd3a8] ? nv_msi_ht_cap_quirk_all+0x10/0x10 [813bd796] ? pci_get_dma_source+0xf/0x41 [815d02c9] intel_iommu_add_device+0x95/0x167 [815cd5a4] add_iommu_group+0x3a/0x41 [815cd56a] ? bus_set_iommu+0x44/0x44 [8145eca1] bus_for_each_dev+0x54/0x81 [815cd563] bus_set_iommu+0x3d/0x44 [81cd3fa3] intel_iommu_init+0xae5/0xb5e [81ca0277] ? free_initrd+0x9e/0x9e [81ca4248] ? memblock_find_dma_reserve+0x13f/0x13f [81ca425e] pci_iommu_init+0x16/0x41 [81cc4140] ? pci_proc_init+0x6b/0x6b [81000231] do_one_initcall+0x7a/0x129 [816dac14] kernel_init+0x139/0x2a2 [81c9d4c7] ? loglevel+0x31/0x31 [816daadb] ? rest_init+0x6f/0x6f [816f66ac] ret_from_fork+0x7c/0xb0 [816daadb] ? rest_init+0x6f/0x6f ---[ end trace 5c5a2ceca067e0ed ]--- -- -- Matthew Thode (prometheanfire) The root cause of Matt's issue is that intel_iommu_add_device() calls pci_get_domain_bus_and_slot() which is returning NULL. Which is not an expected value. The reason NULL is being returned is that Matt has a card with a TI XIO2000A/XIO2200A PCIe-PCI bridge (VID: 104C, DID: 8231) on it. This device already has a quirk setup for disabling fast back to back transfers on its secondary bus. If we cause it to use the primary bus, that appears to resolve the issue. I'm not sure exactly how to proceed from here due to relative lack of knowledge of PCI. Do all PCIe-PCI bridges with secondary buses need their DMA parent to be the primary bus or is that just something that should be done for the TI XIO2000A due to the existing quirk? The failing call with arguments was pci_get_domain_bus_and_slot(0, 5, 0), while pci_get_domain_bus_and_slot(0, 4, 0) resulted in a system that didn't panic and a device that worked. $ lspci -tvn -+-[:ff]-+-00.0 8086:2c40 | +-00.1 8086:2c01 | +-02.0 8086:2c10 | +-02.1 8086:2c11 | +-02.4 8086:2c14 | +-02.5 8086:2c15 | +-03.0 8086:2c18 | +-03.1 8086:2c19 | +-03.2 8086:2c1a | +-03.4 8086:2c1c | +-04.0 8086:2c20 | +-04.1 8086:2c21 | +-04.2 8086:2c22 | +-04.3 8086:2c23 | +-05.0 8086:2c28 | +-05.1 8086:2c29 | +-05.2 8086:2c2a | +-05.3 8086:2c2b | +-06.0 8086:2c30 | +-06.1 8086:2c31 | +-06.2 8086:2c32 | \-06.3 8086:2c33 \-[:00]-+-00.0 8086:3406 +-01.0-[01]--+-00.0 8086:10c9 |\-00.1 8086:10c9 +-03.0-[02]-- +-05.0-[03]-- +-07.0-[04-05]00.0-[05]08.0 d161:8006 +-09.0-[06]00.0 8086:10b9 +-13.0 8086:342d +-14.0 8086:342e +-14.1 8086:3422 +-14.2 8086:3423 +-14.3 8086:3438 +-16.0 8086:3430 +-16.1 8086:3431 +-16.2 8086:3432 +-16.3 8086:3433 +-16.4 8086:3429 +-16.5 8086:342a +-16.6 8086:342b +-16.7 8086:342c +-1a.0 8086:3a37 +-1a.1 8086:3a38 +-1a.2 8086:3a39 +-1a.7 8086:3a3c +-1d.0 8086:3a34 +-1d.1 8086:3a35 +-1d.2 8086:3a36 +-1d.7 8086:3a3a +-1e.0-[07]01.0 102b:0532 +-1f.0 8086:3a16 +-1f.2 8086:3a22 \-1f.3 8086:3a30 If someone can craft the correct patch that'd be great or answer the above question and I'll gladly craft it. Thanks. -- Doug Goldstein -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord
Re: [PATCH] vlan: set sysfs device_type to 'vlan'
On Sun, Nov 4, 2012 at 11:53 PM, David Miller wrote: > From: Doug Goldstein > Date: Sun, 4 Nov 2012 23:45:56 -0600 > >> As Ben Greear pointed out this would allow shell scripts and other >> scripting languages to better detect vlans. Kay pointed out that this >> would allow better uevent filters in the future as well. So there are >> some merits to this patch. If you'd prefer I can resubmit with a >> better commit message entailing the reasons behind it. > > For the thousandth time: > > All of those scripts and other users of this new facility will > need to have backup code to detect vlan devices when this > sysfs thing is not present. > > They are already to determine this information already, and > they alreayd have to be ugly to handle EVERY EXISTING KERNEL > ON THE PLANET. > > So the effective value is zero. By this argument we shouldn't ever improve any API or add new syscalls since we'll have to have fallback code to handle the old interfaces when the new ones aren't available. Since everything already has the existing implementations to handle every existing kernel on the planet then this patch doesn't harm anything and should I want to write a shell script that only works on Linux 3.8 (assuming this patch is in there) and is only forward looking then I can use the more complete sysfs. So the effective penalty is zero and you get a more complete sysfs, which is where you're value is. -- Doug Goldstein -- 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/
Re: [PATCH] vlan: set sysfs device_type to 'vlan'
On Tue, Oct 23, 2012 at 1:36 AM, David Miller wrote: > From: Doug Goldstein > Date: Mon, 22 Oct 2012 00:53:57 -0500 > >> Sets the sysfs device_type to 'vlan' for udev. This makes it easier for >> applications that query network information via udev to identify vlans >> instead of using strrchr(). >> >> Signed-off-by: Doug Goldstein > > You're extremely misguided. This change, in fact, makes it ten times > harder for such applications to query such devices. > > Because now the application has to decide whether it wants to support > EVERY EXISTING SYSTEM OUT THERE or not. Hundreds of millions of Linux > systems do not provide this attribute. > > Applications have to handle the case of not having the 'vlan' device > type available attribute essentially forever. > > So providing it in new kernels provides zero value whatsoever. > > I'm not applying this patch, sorry. Dave, As others on this thread have discussed there are other merits to the patch as well. Yes you are correct that netlink is the preferred method to gather information about network devices but the point was really to make the sysfs layout more correct a matter of completeness. As Ben Greear pointed out this would allow shell scripts and other scripting languages to better detect vlans. Kay pointed out that this would allow better uevent filters in the future as well. So there are some merits to this patch. If you'd prefer I can resubmit with a better commit message entailing the reasons behind it. Thanks. -- Doug Goldstein -- 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/
Re: [PATCH] vlan: set sysfs device_type to 'vlan'
On Tue, Oct 23, 2012 at 1:36 AM, David Miller da...@davemloft.net wrote: From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. Because now the application has to decide whether it wants to support EVERY EXISTING SYSTEM OUT THERE or not. Hundreds of millions of Linux systems do not provide this attribute. Applications have to handle the case of not having the 'vlan' device type available attribute essentially forever. So providing it in new kernels provides zero value whatsoever. I'm not applying this patch, sorry. Dave, As others on this thread have discussed there are other merits to the patch as well. Yes you are correct that netlink is the preferred method to gather information about network devices but the point was really to make the sysfs layout more correct a matter of completeness. As Ben Greear pointed out this would allow shell scripts and other scripting languages to better detect vlans. Kay pointed out that this would allow better uevent filters in the future as well. So there are some merits to this patch. If you'd prefer I can resubmit with a better commit message entailing the reasons behind it. Thanks. -- Doug Goldstein -- 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/
Re: [PATCH] vlan: set sysfs device_type to 'vlan'
On Sun, Nov 4, 2012 at 11:53 PM, David Miller da...@davemloft.net wrote: From: Doug Goldstein car...@cardoe.com Date: Sun, 4 Nov 2012 23:45:56 -0600 As Ben Greear pointed out this would allow shell scripts and other scripting languages to better detect vlans. Kay pointed out that this would allow better uevent filters in the future as well. So there are some merits to this patch. If you'd prefer I can resubmit with a better commit message entailing the reasons behind it. For the thousandth time: All of those scripts and other users of this new facility will need to have backup code to detect vlan devices when this sysfs thing is not present. They are already to determine this information already, and they alreayd have to be ugly to handle EVERY EXISTING KERNEL ON THE PLANET. So the effective value is zero. By this argument we shouldn't ever improve any API or add new syscalls since we'll have to have fallback code to handle the old interfaces when the new ones aren't available. Since everything already has the existing implementations to handle every existing kernel on the planet then this patch doesn't harm anything and should I want to write a shell script that only works on Linux 3.8 (assuming this patch is in there) and is only forward looking then I can use the more complete sysfs. So the effective penalty is zero and you get a more complete sysfs, which is where you're value is. -- Doug Goldstein -- 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/
[PATCH] vlan: set sysfs device_type to 'vlan'
Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
applications that query network information via udev to identify vlans
instead of using strrchr().
Signed-off-by: Doug Goldstein
---
Pre-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: INTERFACE=br0.4
E: IFINDEX=6
E: SUBSYSTEM=net
Post-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: DEVTYPE=vlan
E: INTERFACE=br0.4
E: IFINDEX=12
E: SUBSYSTEM=net
The intent was to match other virtual network types such as bridges.
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0
P: /devices/virtual/net/br0
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0
E: DEVTYPE=bridge
E: INTERFACE=br0
E: IFINDEX=5
E: SUBSYSTEM=net
---
net/8021q/vlan_dev.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 4024424..78a8744 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -531,6 +531,10 @@ static const struct header_ops vlan_header_ops = {
.parse = eth_header_parse,
};
+static struct device_type vlan_type = {
+ .name = "vlan",
+};
+
static const struct net_device_ops vlan_netdev_ops;
static int vlan_dev_init(struct net_device *dev)
@@ -579,6 +583,8 @@ static int vlan_dev_init(struct net_device *dev)
dev->netdev_ops = _netdev_ops;
+ SET_NETDEV_DEVTYPE(dev, _type);
+
if (is_vlan_dev(real_dev))
subclass = 1;
--
1.7.8.6
--
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/
[PATCH] vlan: set sysfs device_type to 'vlan'
Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
applications that query network information via udev to identify vlans
instead of using strrchr().
Signed-off-by: Doug Goldstein car...@cardoe.com
---
Pre-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: INTERFACE=br0.4
E: IFINDEX=6
E: SUBSYSTEM=net
Post-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: DEVTYPE=vlan
E: INTERFACE=br0.4
E: IFINDEX=12
E: SUBSYSTEM=net
The intent was to match other virtual network types such as bridges.
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0
P: /devices/virtual/net/br0
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0
E: DEVTYPE=bridge
E: INTERFACE=br0
E: IFINDEX=5
E: SUBSYSTEM=net
---
net/8021q/vlan_dev.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 4024424..78a8744 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -531,6 +531,10 @@ static const struct header_ops vlan_header_ops = {
.parse = eth_header_parse,
};
+static struct device_type vlan_type = {
+ .name = vlan,
+};
+
static const struct net_device_ops vlan_netdev_ops;
static int vlan_dev_init(struct net_device *dev)
@@ -579,6 +583,8 @@ static int vlan_dev_init(struct net_device *dev)
dev-netdev_ops = vlan_netdev_ops;
+ SET_NETDEV_DEVTYPE(dev, vlan_type);
+
if (is_vlan_dev(real_dev))
subclass = 1;
--
1.7.8.6
--
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/
