Re: New maintainer for dwc2
On Mon, Jan 12, 2015 at 11:14:54PM +, Paul Zimmerman wrote: Hi everyone, I will be leaving Synopsys on Friday, Jan 16th, so the dwc2 driver will need a new maintainer. I am recommending John Youn johny...@synopsys.com as the new maintainer. On the plus side, John has quite a bit of experience with the dwc2 controller, and has previous experience submitting kernel patches (for the xhci and dwc3 drivers). And being a Synopsys employee, he will have access to internal resources for support. On the minus side, John has not worked directly with the in-kernel dwc2 driver until very recently, and has not done maintainer work before. If no one has any objections, I will submit a patch to MAINTAINERS in a couple of days making John the new dwc2 maintainer. I don't have any objections. John will still be sending patches to Felipe through email, and not directly to me, right? thanks, greg k-h -- 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 0/5] Tools: hv: fix compiler warnings and do minor cleanup
On Fri, Jan 09, 2015 at 08:58:08PM +, KY Srinivasan wrote: > > Please resend everything, there has been a mess of different patches and > > discussions and I can't figure out what should be applied and what should > > not. I'll guess at a few easy ones, but getting the "correct" > > ones from you is the best thing. > Will do. Vitaly, could you please resend the patches. You are the subsystem maintainer, right? It's your job to bundle them up and resend if needed. thanks, greg k-h -- 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 0/5] Tools: hv: fix compiler warnings and do minor cleanup
On Thu, Jan 08, 2015 at 05:04:20PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > Sent: Thursday, January 8, 2015 8:02 AM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; de...@linuxdriverproject.org; Haiyang > > Zhang; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor > > cleanup > > > > KY Srinivasan writes: > > > > >> -Original Message- > > >> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] > > >> On Behalf Of gre...@linuxfoundation.org > > >> Sent: Wednesday, December 10, 2014 6:48 AM > > >> To: Vitaly Kuznetsov > > >> Cc: de...@linuxdriverproject.org; Haiyang Zhang; linux- > > >> ker...@vger.kernel.org > > >> Subject: Re: [PATCH 0/5] Tools: hv: fix compiler warnings and do > > >> minor cleanup > > >> > > >> On Wed, Dec 10, 2014 at 10:22:40AM +0100, Vitaly Kuznetsov wrote: > > >> > Dexuan Cui writes: > > >> > > > >> > >> -Original Message- > > >> > >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > >> > >> Sent: Tuesday, December 9, 2014 23:48 PM > > >> > >> To: KY Srinivasan > > >> > >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- > > >> > >> ker...@vger.kernel.org; Dexuan Cui > > >> > >> Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do > > >> > >> minor cleanup > > >> > >> > > >> > >> When someone does 'make' in tools/hv/ issues appear: > > >> > >> - hv_fcopy_daemon is not being built; > > >> > >> - lots of compiler warnings. > > >> > >> > > >> > >> This is just a cleanup. Compile-tested by myself on top of > > >> > >> linux- > > >> next/master. > > >> > >> > > >> > >> Piggyback this series and send "[PATCH 5/5] Tools: hv: do not > > >> > >> add redundant '/' > > >> > >> in hv_start_fcopy()" > > >> > >> > > >> > >> Vitaly Kuznetsov (5): > > >> > >> Tools: hv: add mising fcopyd to the Makefile > > >> > >> Tools: hv: remove unused bytes_written from kvp_update_file() > > >> > >> Tools: hv: address compiler warnings for hv_kvp_daemon.c > > >> > >> Tools: hv: address compiler warnings for hv_fcopy_daemon.c > > >> > >> Tools: hv: do not add redundant '/' in hv_start_fcopy() > > >> > >> > > >> > >> tools/hv/Makefile | 4 ++-- > > >> > >> tools/hv/hv_fcopy_daemon.c | 10 ++ > > >> > >> tools/hv/hv_kvp_daemon.c | 29 + > > >> > >> 3 files changed, 17 insertions(+), 26 deletions(-) > > >> > >> > > >> > >> -- > > >> > >> 1.9.3 > > >> > > > > >> > > Hi Vitaly, > > >> > > Thanks for the patchset! > > >> > > > > >> > > Acked-by: Dexuan Cui > > >> > > > > >> > > PS, I added Greg into the TO list. > > >> > > The hv code in drivers/hv/ and tools/hv/ usually has to go into > > >> > > Greg's tree first. > > >> > > > >> > Well, I don't mind spamming Greg but he's not on the > > >> > scripts/get_maintainer.pl output. In case he's not monitoring the > > >> > list for patches by some other tool (patchwork?) a patch adding him > > >> > to MAINTAINERS would do the job. > > >> > > > >> > Greg, do you want to become an official Hyper-V maintainer in > > >> > MAINTAINERS? I can send a patch then :-) > > >> > > >> No. It's up to the "real" maintainers to take the patches and then > > >> forward them on to me for inclusion in the kernel tree. KY knows this... > > > > > > I will take care of this. > > > > > > > Hi KY, > > > > I just found out these patches never made it to any repo, at least I can't > > see > > them in char-misc-next. Do I need to resend? > > Greg, > > I have signed off on these patches. Do you want us to resend them. On a > different note, I too have a > Few patches that I sent some weeks ago. Should I be resending them as well. Please resend everything, there has been a mess of different patches and discussions and I can't figure out what should be applied and what should not. I'll guess at a few easy ones, but getting the "correct" ones from you is the best thing. thanks, greg k-h -- 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 0/5] Tools: hv: fix compiler warnings and do minor cleanup
On Fri, Jan 09, 2015 at 08:58:08PM +, KY Srinivasan wrote: Please resend everything, there has been a mess of different patches and discussions and I can't figure out what should be applied and what should not. I'll guess at a few easy ones, but getting the correct ones from you is the best thing. Will do. Vitaly, could you please resend the patches. You are the subsystem maintainer, right? It's your job to bundle them up and resend if needed. thanks, greg k-h -- 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 0/5] Tools: hv: fix compiler warnings and do minor cleanup
On Thu, Jan 08, 2015 at 05:04:20PM +, KY Srinivasan wrote: -Original Message- From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] Sent: Thursday, January 8, 2015 8:02 AM To: KY Srinivasan Cc: gre...@linuxfoundation.org; de...@linuxdriverproject.org; Haiyang Zhang; linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup KY Srinivasan k...@microsoft.com writes: -Original Message- From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf Of gre...@linuxfoundation.org Sent: Wednesday, December 10, 2014 6:48 AM To: Vitaly Kuznetsov Cc: de...@linuxdriverproject.org; Haiyang Zhang; linux- ker...@vger.kernel.org Subject: Re: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup On Wed, Dec 10, 2014 at 10:22:40AM +0100, Vitaly Kuznetsov wrote: Dexuan Cui de...@microsoft.com writes: -Original Message- From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] Sent: Tuesday, December 9, 2014 23:48 PM To: KY Srinivasan Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- ker...@vger.kernel.org; Dexuan Cui Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup When someone does 'make' in tools/hv/ issues appear: - hv_fcopy_daemon is not being built; - lots of compiler warnings. This is just a cleanup. Compile-tested by myself on top of linux- next/master. Piggyback this series and send [PATCH 5/5] Tools: hv: do not add redundant '/' in hv_start_fcopy() Vitaly Kuznetsov (5): Tools: hv: add mising fcopyd to the Makefile Tools: hv: remove unused bytes_written from kvp_update_file() Tools: hv: address compiler warnings for hv_kvp_daemon.c Tools: hv: address compiler warnings for hv_fcopy_daemon.c Tools: hv: do not add redundant '/' in hv_start_fcopy() tools/hv/Makefile | 4 ++-- tools/hv/hv_fcopy_daemon.c | 10 ++ tools/hv/hv_kvp_daemon.c | 29 + 3 files changed, 17 insertions(+), 26 deletions(-) -- 1.9.3 Hi Vitaly, Thanks for the patchset! Acked-by: Dexuan Cui de...@microsoft.com PS, I added Greg into the TO list. The hv code in drivers/hv/ and tools/hv/ usually has to go into Greg's tree first. Well, I don't mind spamming Greg but he's not on the scripts/get_maintainer.pl output. In case he's not monitoring the list for patches by some other tool (patchwork?) a patch adding him to MAINTAINERS would do the job. Greg, do you want to become an official Hyper-V maintainer in MAINTAINERS? I can send a patch then :-) No. It's up to the real maintainers to take the patches and then forward them on to me for inclusion in the kernel tree. KY knows this... I will take care of this. Hi KY, I just found out these patches never made it to any repo, at least I can't see them in char-misc-next. Do I need to resend? Greg, I have signed off on these patches. Do you want us to resend them. On a different note, I too have a Few patches that I sent some weeks ago. Should I be resending them as well. Please resend everything, there has been a mess of different patches and discussions and I can't figure out what should be applied and what should not. I'll guess at a few easy ones, but getting the correct ones from you is the best thing. thanks, greg k-h -- 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: [char-misc-next 1/3 V2] mei: add ABI documentation for fw_status exported through sysfs
On Thu, Dec 18, 2014 at 09:37:12AM +, Winkler, Tomas wrote: > > > > > > Signed-off-by: Tomas Winkler > > --- > > V2: rephrase the description > > Documentation/ABI/testing/sysfs-class-mei | 15 +++ > > 1 file changed, 15 insertions(+) > > > Greg you've included 'mei: export fw status registers through sysfs' to > 3.19-rc1 pull request > but left this documentation patch out. I don't remember what happened there, can you resend and I will queue it up for after 3.19-rc1? thanks, greg k-h -- 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: [char-misc-next 1/3 V2] mei: add ABI documentation for fw_status exported through sysfs
On Thu, Dec 18, 2014 at 09:37:12AM +, Winkler, Tomas wrote: Signed-off-by: Tomas Winkler tomas.wink...@intel.com --- V2: rephrase the description Documentation/ABI/testing/sysfs-class-mei | 15 +++ 1 file changed, 15 insertions(+) Greg you've included 'mei: export fw status registers through sysfs' to 3.19-rc1 pull request but left this documentation patch out. I don't remember what happened there, can you resend and I will queue it up for after 3.19-rc1? thanks, greg k-h -- 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 0/5] Tools: hv: fix compiler warnings and do minor cleanup
On Wed, Dec 10, 2014 at 10:22:40AM +0100, Vitaly Kuznetsov wrote: > Dexuan Cui writes: > > >> -Original Message- > >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > >> Sent: Tuesday, December 9, 2014 23:48 PM > >> To: KY Srinivasan > >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- > >> ker...@vger.kernel.org; Dexuan Cui > >> Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup > >> > >> When someone does 'make' in tools/hv/ issues appear: > >> - hv_fcopy_daemon is not being built; > >> - lots of compiler warnings. > >> > >> This is just a cleanup. Compile-tested by myself on top of > >> linux-next/master. > >> > >> Piggyback this series and send "[PATCH 5/5] Tools: hv: do not add redundant > >> '/' > >> in hv_start_fcopy()" > >> > >> Vitaly Kuznetsov (5): > >> Tools: hv: add mising fcopyd to the Makefile > >> Tools: hv: remove unused bytes_written from kvp_update_file() > >> Tools: hv: address compiler warnings for hv_kvp_daemon.c > >> Tools: hv: address compiler warnings for hv_fcopy_daemon.c > >> Tools: hv: do not add redundant '/' in hv_start_fcopy() > >> > >> tools/hv/Makefile | 4 ++-- > >> tools/hv/hv_fcopy_daemon.c | 10 ++ > >> tools/hv/hv_kvp_daemon.c | 29 + > >> 3 files changed, 17 insertions(+), 26 deletions(-) > >> > >> -- > >> 1.9.3 > > > > Hi Vitaly, > > Thanks for the patchset! > > > > Acked-by: Dexuan Cui > > > > PS, I added Greg into the TO list. > > The hv code in drivers/hv/ and tools/hv/ usually has to go into > > Greg's tree first. > > Well, I don't mind spamming Greg but he's not on the > scripts/get_maintainer.pl output. In case he's not monitoring the list > for patches by some other tool (patchwork?) a patch adding him to > MAINTAINERS would do the job. > > Greg, do you want to become an official Hyper-V maintainer in > MAINTAINERS? I can send a patch then :-) No. It's up to the "real" maintainers to take the patches and then forward them on to me for inclusion in the kernel tree. KY knows this... thanks, greg k-h -- 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 0/5] Tools: hv: fix compiler warnings and do minor cleanup
On Wed, Dec 10, 2014 at 10:22:40AM +0100, Vitaly Kuznetsov wrote: Dexuan Cui de...@microsoft.com writes: -Original Message- From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] Sent: Tuesday, December 9, 2014 23:48 PM To: KY Srinivasan Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- ker...@vger.kernel.org; Dexuan Cui Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup When someone does 'make' in tools/hv/ issues appear: - hv_fcopy_daemon is not being built; - lots of compiler warnings. This is just a cleanup. Compile-tested by myself on top of linux-next/master. Piggyback this series and send [PATCH 5/5] Tools: hv: do not add redundant '/' in hv_start_fcopy() Vitaly Kuznetsov (5): Tools: hv: add mising fcopyd to the Makefile Tools: hv: remove unused bytes_written from kvp_update_file() Tools: hv: address compiler warnings for hv_kvp_daemon.c Tools: hv: address compiler warnings for hv_fcopy_daemon.c Tools: hv: do not add redundant '/' in hv_start_fcopy() tools/hv/Makefile | 4 ++-- tools/hv/hv_fcopy_daemon.c | 10 ++ tools/hv/hv_kvp_daemon.c | 29 + 3 files changed, 17 insertions(+), 26 deletions(-) -- 1.9.3 Hi Vitaly, Thanks for the patchset! Acked-by: Dexuan Cui de...@microsoft.com PS, I added Greg into the TO list. The hv code in drivers/hv/ and tools/hv/ usually has to go into Greg's tree first. Well, I don't mind spamming Greg but he's not on the scripts/get_maintainer.pl output. In case he's not monitoring the list for patches by some other tool (patchwork?) a patch adding him to MAINTAINERS would do the job. Greg, do you want to become an official Hyper-V maintainer in MAINTAINERS? I can send a patch then :-) No. It's up to the real maintainers to take the patches and then forward them on to me for inclusion in the kernel tree. KY knows this... thanks, greg k-h -- 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] serial: samsung: Fix serial config dependencies for exynos7
On Sun, Nov 16, 2014 at 07:47:02AM +0530, Abhilash Kesavan wrote: > Hello Greg, > > On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan > wrote: > > Hi Greg, > > > > On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan > > wrote: > >> Hi Tomasz, > >> > >> On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa wrote: > >>> Hi Abhilash, > >>> > >>> The patch itself seems fine, but I wonder if those config options aren't > >>> really just leftovers from the past and couldn't be completely removed. > >>> > >>> On 29.09.2014 07:16, Abhilash Kesavan wrote: > From: Pankaj Dubey > > Exynos7 has a similar serial controller to that present in older Samsung > SoCs. To re-use the existing serial driver on Exynos7 we need to have > SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not > possible because these symbols are dependent on PLAT_SAMSUNG which is > not present for the ARMv8 based exynos7. > > Change the dependency of these symbols from PLAT_SAMSUNG to the serial > driver thus making it available on exynos7. As the existing platform > specific code making use of these symbols is related to uart driver this > change in dependency should not cause any issues. > > Signed-off-by: Pankaj Dubey > Signed-off-by: Naveen Krishna Chatradhi > Signed-off-by: Abhilash Kesavan > Cc: Greg Kroah-Hartman > --- > Build tested with s3c6400_defconfig, exynos_defconfig and arm64's > defconfig > with and without the serial driver enabled. > > drivers/tty/serial/Kconfig |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 81f6ee7..e6c0bcb 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG > > config SERIAL_SAMSUNG_UARTS_4 > bool > - depends on PLAT_SAMSUNG > + depends on SERIAL_SAMSUNG > default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || > CPU_S3C2442) > help > Internal node for the common case of 4 Samsung compatible UARTs > >>> > >>> The only place where this symbol is used is below. > >>> > > config SERIAL_SAMSUNG_UARTS > int > - depends on PLAT_SAMSUNG > + depends on SERIAL_SAMSUNG > default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 > default 3 > help > > >>> > >>> With this symbol the situation isn't that easy, but still should be > >>> manageable. > >>> > >>> Looking at the serial-samsung driver, all occurrences of > >>> CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally > >>> defined number equal to the maximum value - in this case 4. > >>> > >>> There are also two places in arch/arm where this symbol is used: > >>> > >>> 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial > >>> ports which need suspend/resume handling. Since on s3c64xx the number is > >>> always 4, it can be simply defined locally as a constant. > >>> > >>> 2) In arch/arm/plat-samsung/init.c it is used to determine size of a > >>> static array of UART ports and to check whether the UART driver is > >>> enabled. In former case I believe it should be safe to hardcode it to 4 > >>> as well, in latter CONFIG_SERIAL_SAMSUNG can be used. > >> > >> I will post patches removing these two symbols. > > > > I posted a couple of patches handling Tomasz' comments but Kukjin > > prefers the approach in this patch (Discussion here: > > http://www.spinics.net/lists/linux-samsung-soc/msg38742.html). > > Can you please review the patch. > > This is a gentle reminder. The patch is required for serial enablement > on the new exynos7 SoC, kindly take a look. What patch? I fail to see anything in my inboxes that I can apply, only this long thread that makes no sense at all. Please resend anything that you want to have applied, in a format that I can apply it, _AND_ get everyone to agree that it is the correct solution. Asking me to go look up random web archives, of mailing list threads I was never copied on, is a sure way to get your email ignored, as again, there is nothing I can do with it. You know better than this. greg k-h -- 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] serial: samsung: Fix serial config dependencies for exynos7
On Sun, Nov 16, 2014 at 07:47:02AM +0530, Abhilash Kesavan wrote: Hello Greg, On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: Hi Greg, On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: Hi Tomasz, On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Abhilash, The patch itself seems fine, but I wonder if those config options aren't really just leftovers from the past and couldn't be completely removed. On 29.09.2014 07:16, Abhilash Kesavan wrote: From: Pankaj Dubey pankaj.du...@samsung.com Exynos7 has a similar serial controller to that present in older Samsung SoCs. To re-use the existing serial driver on Exynos7 we need to have SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not possible because these symbols are dependent on PLAT_SAMSUNG which is not present for the ARMv8 based exynos7. Change the dependency of these symbols from PLAT_SAMSUNG to the serial driver thus making it available on exynos7. As the existing platform specific code making use of these symbols is related to uart driver this change in dependency should not cause any issues. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig with and without the serial driver enabled. drivers/tty/serial/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 81f6ee7..e6c0bcb 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG config SERIAL_SAMSUNG_UARTS_4 bool - depends on PLAT_SAMSUNG + depends on SERIAL_SAMSUNG default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442) help Internal node for the common case of 4 Samsung compatible UARTs The only place where this symbol is used is below. config SERIAL_SAMSUNG_UARTS int - depends on PLAT_SAMSUNG + depends on SERIAL_SAMSUNG default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 default 3 help With this symbol the situation isn't that easy, but still should be manageable. Looking at the serial-samsung driver, all occurrences of CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally defined number equal to the maximum value - in this case 4. There are also two places in arch/arm where this symbol is used: 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial ports which need suspend/resume handling. Since on s3c64xx the number is always 4, it can be simply defined locally as a constant. 2) In arch/arm/plat-samsung/init.c it is used to determine size of a static array of UART ports and to check whether the UART driver is enabled. In former case I believe it should be safe to hardcode it to 4 as well, in latter CONFIG_SERIAL_SAMSUNG can be used. I will post patches removing these two symbols. I posted a couple of patches handling Tomasz' comments but Kukjin prefers the approach in this patch (Discussion here: http://www.spinics.net/lists/linux-samsung-soc/msg38742.html). Can you please review the patch. This is a gentle reminder. The patch is required for serial enablement on the new exynos7 SoC, kindly take a look. What patch? I fail to see anything in my inboxes that I can apply, only this long thread that makes no sense at all. Please resend anything that you want to have applied, in a format that I can apply it, _AND_ get everyone to agree that it is the correct solution. Asking me to go look up random web archives, of mailing list threads I was never copied on, is a sure way to get your email ignored, as again, there is nothing I can do with it. You know better than this. greg k-h -- 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] arm: armv7: perf: fix armv7 ref-cycles error
On Thu, Oct 09, 2014 at 03:13:00PM +0800, zhangzhiqiang wrote: > On 2014/10/9 11:41, gre...@linuxfoundation.org wrote: > > On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote: > >> On 2014/10/8 21:38, Will Deacon wrote: > >>> On Wed, Oct 08, 2014 at 02:31:47PM +0100, gre...@linuxfoundation.org > >>> wrote: > >>>> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: > >>>>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: > >>>>>> hi all, > >>>>>> > >>>>>> > >>>>>> ref-cycles event is specially to Intel core, but can still used in arm > >>>>>> architecture > >>>>>> with the wrong return value with 3.10 stable. for instance: > >>>>>> > >>>>>> perf stat -e ref-cycles sleep 1 > >>>>>> > >>>>>> Performance counter stats for 'sleep 1': > >>>>>> > >>>>>>0 ref-cycles > >>>>>> > >>>>>>1.002381916 seconds time elapsed > >>>>>> > >>>>>> this patch fix the bug and make it return NOT SUPPORTED > >>>>>> distinctly. > >>>>>> > >>>>>> In upstream this bug has been fixed by other way(not primary for the > >>>>>> bug), which changes more than one file > >>>>>> and more than 1000 lines. the primary commit is > >>>>>> 6b7658ec8a100b608e59e3cde353434db51f5be0. > >>>>>> besides we can not simply cherry-pick. > >>>>> > >>>>> I thought I saw Greg pick this up the other day? > >>>> > >>>> Yes, it's in 3.16.4, did I do something wrong by accepting it? > >>> > >>> Nah, it's a trivial patch that I struggle to get excited about. I'm just > >>> not > >>> sure why it's being sent again, after you already accepted it. > >> > >> Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into > >> 3.10 or > >> do we have the plan? > > > > Does it apply to 3.10-stable? Did you test it there and see if it > > resolves your issue? > > I have tested in 3.10.56, the bug is still existing and the patch is apply to > 3.10-stable. > Follow is the result without/with this patch based on 3.10.56. > > 3.10.56 without the patch: > bash-4.2# perf stat -e ref-cycles sleep 1 > > Performance counter stats for 'sleep 1': > > 0 ref-cycles > >1.002461500 seconds time elapsed > > 3.10.56 with the patch: > bash-4.2# perf stat -e ref-cycles sleep 1 > > Performance counter stats for 'sleep 1': > > ref-cycles > >1.002385243 seconds time elapsed Given I have no idea what the patch even does, or is supposed to be doing, I don't know how to answer this, except it looks like I shouldn't be applying this to the 3.10-stable kernel series :) sorry, greg k-h -- 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] arm: armv7: perf: fix armv7 ref-cycles error
On Thu, Oct 09, 2014 at 03:13:00PM +0800, zhangzhiqiang wrote: On 2014/10/9 11:41, gre...@linuxfoundation.org wrote: On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote: On 2014/10/8 21:38, Will Deacon wrote: On Wed, Oct 08, 2014 at 02:31:47PM +0100, gre...@linuxfoundation.org wrote: On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: hi all, ref-cycles event is specially to Intel core, but can still used in arm architecture with the wrong return value with 3.10 stable. for instance: perf stat -e ref-cycles sleep 1 Performance counter stats for 'sleep 1': 0 ref-cycles 1.002381916 seconds time elapsed this patch fix the bug and make it return NOT SUPPORTED distinctly. In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0. besides we can not simply cherry-pick. I thought I saw Greg pick this up the other day? Yes, it's in 3.16.4, did I do something wrong by accepting it? Nah, it's a trivial patch that I struggle to get excited about. I'm just not sure why it's being sent again, after you already accepted it. Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or do we have the plan? Does it apply to 3.10-stable? Did you test it there and see if it resolves your issue? I have tested in 3.10.56, the bug is still existing and the patch is apply to 3.10-stable. Follow is the result without/with this patch based on 3.10.56. 3.10.56 without the patch: bash-4.2# perf stat -e ref-cycles sleep 1 Performance counter stats for 'sleep 1': 0 ref-cycles 1.002461500 seconds time elapsed 3.10.56 with the patch: bash-4.2# perf stat -e ref-cycles sleep 1 Performance counter stats for 'sleep 1': not supported ref-cycles 1.002385243 seconds time elapsed Given I have no idea what the patch even does, or is supposed to be doing, I don't know how to answer this, except it looks like I shouldn't be applying this to the 3.10-stable kernel series :) sorry, greg k-h -- 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] arm: armv7: perf: fix armv7 ref-cycles error
On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote: > On 2014/10/8 21:38, Will Deacon wrote: > > On Wed, Oct 08, 2014 at 02:31:47PM +0100, gre...@linuxfoundation.org wrote: > >> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: > >>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: > >>>> hi all, > >>>> > >>>> > >>>> ref-cycles event is specially to Intel core, but can still used in arm > >>>> architecture > >>>> with the wrong return value with 3.10 stable. for instance: > >>>> > >>>> perf stat -e ref-cycles sleep 1 > >>>> > >>>> Performance counter stats for 'sleep 1': > >>>> > >>>> 0 ref-cycles > >>>> > >>>>1.002381916 seconds time elapsed > >>>> > >>>> this patch fix the bug and make it return NOT SUPPORTED > >>>> distinctly. > >>>> > >>>> In upstream this bug has been fixed by other way(not primary for the > >>>> bug), which changes more than one file > >>>> and more than 1000 lines. the primary commit is > >>>> 6b7658ec8a100b608e59e3cde353434db51f5be0. > >>>> besides we can not simply cherry-pick. > >>> > >>> I thought I saw Greg pick this up the other day? > >> > >> Yes, it's in 3.16.4, did I do something wrong by accepting it? > > > > Nah, it's a trivial patch that I struggle to get excited about. I'm just not > > sure why it's being sent again, after you already accepted it. > > Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 > or > do we have the plan? Does it apply to 3.10-stable? Did you test it there and see if it resolves your issue? thanks, greg k-h -- 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] arm: armv7: perf: fix armv7 ref-cycles error
On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: > On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: > > hi all, > > > > > > ref-cycles event is specially to Intel core, but can still used in arm > > architecture > > with the wrong return value with 3.10 stable. for instance: > > > > perf stat -e ref-cycles sleep 1 > > > > Performance counter stats for 'sleep 1': > > > > 0 ref-cycles > > > >1.002381916 seconds time elapsed > > > > this patch fix the bug and make it return NOT SUPPORTED > > distinctly. > > > > In upstream this bug has been fixed by other way(not primary for the bug), > > which changes more than one file > > and more than 1000 lines. the primary commit is > > 6b7658ec8a100b608e59e3cde353434db51f5be0. > > besides we can not simply cherry-pick. > > I thought I saw Greg pick this up the other day? Yes, it's in 3.16.4, did I do something wrong by accepting it? confused, greg k-h -- 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] arm: armv7: perf: fix armv7 ref-cycles error
On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: hi all, ref-cycles event is specially to Intel core, but can still used in arm architecture with the wrong return value with 3.10 stable. for instance: perf stat -e ref-cycles sleep 1 Performance counter stats for 'sleep 1': 0 ref-cycles 1.002381916 seconds time elapsed this patch fix the bug and make it return NOT SUPPORTED distinctly. In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0. besides we can not simply cherry-pick. I thought I saw Greg pick this up the other day? Yes, it's in 3.16.4, did I do something wrong by accepting it? confused, greg k-h -- 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] arm: armv7: perf: fix armv7 ref-cycles error
On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote: On 2014/10/8 21:38, Will Deacon wrote: On Wed, Oct 08, 2014 at 02:31:47PM +0100, gre...@linuxfoundation.org wrote: On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: hi all, ref-cycles event is specially to Intel core, but can still used in arm architecture with the wrong return value with 3.10 stable. for instance: perf stat -e ref-cycles sleep 1 Performance counter stats for 'sleep 1': 0 ref-cycles 1.002381916 seconds time elapsed this patch fix the bug and make it return NOT SUPPORTED distinctly. In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0. besides we can not simply cherry-pick. I thought I saw Greg pick this up the other day? Yes, it's in 3.16.4, did I do something wrong by accepting it? Nah, it's a trivial patch that I struggle to get excited about. I'm just not sure why it's being sent again, after you already accepted it. Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or do we have the plan? Does it apply to 3.10-stable? Did you test it there and see if it resolves your issue? thanks, greg k-h -- 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 1/4] drivers/bus: Added Freescale Management Complex APIs
On Mon, Sep 22, 2014 at 02:42:10PM +, Stuart Yoder wrote: -Original Message- From: Kim Phillips [mailto:kim.phill...@freescale.com] Sent: Friday, September 19, 2014 3:58 PM To: Yoder Stuart-B08248 Cc: Alexander Graf; Rivera Jose-B46482; Phillips Kim-R1AAHA; gre...@linuxfoundation.org; a...@arndb.de; linux-kernel@vger.kernel.org; Wood Scott-B07421; linuxppc-rele...@linux.freescale.net Subject: Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs On Fri, 19 Sep 2014 13:25:06 -0500 Yoder Stuart-B08248 stuart.yo...@freescale.com wrote: From: Yoder Stuart-B08248 Sent: Thursday, September 18, 2014 7:19 PM +/** + * @briefDisconnects one endpoint to remove its network link + * + * @param[in] mc_ioPointer to opaque I/O object + * @param[in]dprc_handleHandle to the DPRC object + * @param[in] endpointEndpoint configuration parameters. + * + * @returns'0' on Success; Error code otherwise. + * */ +int dprc_disconnect(struct fsl_mc_io *mc_io, uint16_t dprc_handle, +struct dprc_endpoint *endpoint); + +/*! @} */ this entire file is riddled with non-kernel-doc comment markers: see Documentation/kernel-doc-nano-HOWTO.txt on how to write function and other types of comments in a kernel-doc compliant format. This is because this file is using doxygen comments, as it was developed by another team. Unless someone else has an objection, I will leave the doxygen comments alone and not make any change here. Do you see any other source files in Linux using doxygen comments? Yes. Grep around a bit and you'll see examples of it. I grep'ed for some doxygen tags and found close to 200 source files with them. grepping for the one in this patch above - ! @} - returns nothing. Mixing different documentation styles can easily become a big mess, because you can't generate external documentation consistently for the whole tree. As German mentioned elsewhere, this file is an interface to a hardware block, was written by another team targetting a wide variety of environments-- u-boot, Linux, user space, other OSes etc. We left the doxygen stuff there because while admitedly not used much, there are other examples of it in the kernel and the documentation seems useful. If it can't go into the kernel as is, we can just delete it. ...to be clear, we could just delete the doyxen tags. There is no scenario where I would envision anyone generating documentation from these files in the kernel. The tags are there because of where we grabbed the source from. It certainly would benefit no one by conversion to kerneldoc. except kerneldoc users :) However, just leaving the comments and doxygen tags alone as is would be nice. they are incompatible with kerneldoc. Seriously, no one is going to ever generate docs from this obscure bit of code documenting an internal interface within this driver. Makes no sense to convert the comments to kerneldoc. I completely get what you are saying with respect to comments actually documenting kernel interfaces used by different kernel components or uapi interfaces. The doxygen tags are there because this code originated in a different project. That code was intended to be Linux-style compliant and complies with checkpatch --strict. However, we can sanitize the code and remove the tags if they are causing grief. It's too bad though, because we'll have to fork this interface code from its origin. You forked the code when you asked for it be merged into the kernel tree. You shouldn't ever have to rely on the old version again, so please, remove the doxygen mess. greg k-h -- 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: FIX ME in oxu210p-hcd.c
Damm, didn't configure my kill-file correctly, and this snuck in, so might as well respond... On Sun, Sep 21, 2014 at 10:36:18PM -0400, nick wrote: > On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote: > >> Sorry Greg, > >> I don't want to get banned again. I was trying to help out and learn, I > >> was apologizing not > >> for wasting time as much as for making sure I wasn't wasting maintainer > >> time again. I also > >> am coming to the conclusion that my terrible patches were a waste of time > >> and I am trying > >> to get back into helping out. > > > > You were asked to finish the Eudyptula challenge before bothering any > > other kernel developers with questions / patches. Until that happens, > > you are in my killfile, now with yet-another-email-address. > > > Greg K-H, > I really don't want you to get any more upset with me then you already are. > The reason I gave up on the > challenge was it was mostly driver based and I wanted to learn more in other > areas. If you would like to > discuss with me your concerns about my work on this list and how I can aid > more please let me known. You stopped so early in the challenge, you really have no idea what it is "mostly" about, so don't make rash statements like that. Again, unless you finish it, you will be ignored by me, and probably by everyone else as well. greg k-h -- 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: FIX ME in oxu210p-hcd.c
On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote: > > > On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote: > > On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: > >> > >> > >> On 14-09-21 07:53 PM, Peter Chen wrote: > >>> > >>> > >>>> Subject: Re: FIX ME in oxu210p-hcd.c > >>>> > >>>> > >>>> I found a unfixed FIX ME in the file stated in my above message. I am > >>>> wondering what to set hcd->self.comtroller->dma_mask to as it's now been > >>>> defined to NULL and clearly even as a newbie this seem incorrect. > >>>> Regards Nick > >>> > >>> Usually, it is set at its controller driver or pass through through > >>> device tree or > >>> platform data. > >>> > >>> Peter > >>> > >> Sorry Peter, > >> I apologize for asking for more help here but I will paste the function > >> below and with my changes. > >> Please let me known if I am wrong and how to fix it as I new here. > >> Sorry for Wasting Your Time, > > > > Then please do not. Just because your other email addresses were banned > > from lkml, don't keep popping up and bothering people, it's rude, and > > will cause this address to be banned as well. > > > Sorry Greg, > I don't want to get banned again. I was trying to help out and learn, I was > apologizing not > for wasting time as much as for making sure I wasn't wasting maintainer time > again. I also > am coming to the conclusion that my terrible patches were a waste of time and > I am trying > to get back into helping out. You were asked to finish the Eudyptula challenge before bothering any other kernel developers with questions / patches. Until that happens, you are in my killfile, now with yet-another-email-address. greg k-h -- 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: FIX ME in oxu210p-hcd.c
On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: > > > On 14-09-21 07:53 PM, Peter Chen wrote: > > > > > >> Subject: Re: FIX ME in oxu210p-hcd.c > >> > >> > >> I found a unfixed FIX ME in the file stated in my above message. I am > >> wondering what to set hcd->self.comtroller->dma_mask to as it's now been > >> defined to NULL and clearly even as a newbie this seem incorrect. > >> Regards Nick > > > > Usually, it is set at its controller driver or pass through through device > > tree or > > platform data. > > > > Peter > > > Sorry Peter, > I apologize for asking for more help here but I will paste the function below > and with my changes. > Please let me known if I am wrong and how to fix it as I new here. > Sorry for Wasting Your Time, Then please do not. Just because your other email addresses were banned from lkml, don't keep popping up and bothering people, it's rude, and will cause this address to be banned as well. -- 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: FIX ME in oxu210p-hcd.c
On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: On 14-09-21 07:53 PM, Peter Chen wrote: Subject: Re: FIX ME in oxu210p-hcd.c I found a unfixed FIX ME in the file stated in my above message. I am wondering what to set hcd-self.comtroller-dma_mask to as it's now been defined to NULL and clearly even as a newbie this seem incorrect. Regards Nick Usually, it is set at its controller driver or pass through through device tree or platform data. Peter Sorry Peter, I apologize for asking for more help here but I will paste the function below and with my changes. Please let me known if I am wrong and how to fix it as I new here. Sorry for Wasting Your Time, Then please do not. Just because your other email addresses were banned from lkml, don't keep popping up and bothering people, it's rude, and will cause this address to be banned as well. -- 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: FIX ME in oxu210p-hcd.c
On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote: On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote: On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: On 14-09-21 07:53 PM, Peter Chen wrote: Subject: Re: FIX ME in oxu210p-hcd.c I found a unfixed FIX ME in the file stated in my above message. I am wondering what to set hcd-self.comtroller-dma_mask to as it's now been defined to NULL and clearly even as a newbie this seem incorrect. Regards Nick Usually, it is set at its controller driver or pass through through device tree or platform data. Peter Sorry Peter, I apologize for asking for more help here but I will paste the function below and with my changes. Please let me known if I am wrong and how to fix it as I new here. Sorry for Wasting Your Time, Then please do not. Just because your other email addresses were banned from lkml, don't keep popping up and bothering people, it's rude, and will cause this address to be banned as well. Sorry Greg, I don't want to get banned again. I was trying to help out and learn, I was apologizing not for wasting time as much as for making sure I wasn't wasting maintainer time again. I also am coming to the conclusion that my terrible patches were a waste of time and I am trying to get back into helping out. You were asked to finish the Eudyptula challenge before bothering any other kernel developers with questions / patches. Until that happens, you are in my killfile, now with yet-another-email-address. greg k-h -- 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: FIX ME in oxu210p-hcd.c
Damm, didn't configure my kill-file correctly, and this snuck in, so might as well respond... On Sun, Sep 21, 2014 at 10:36:18PM -0400, nick wrote: On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote: Sorry Greg, I don't want to get banned again. I was trying to help out and learn, I was apologizing not for wasting time as much as for making sure I wasn't wasting maintainer time again. I also am coming to the conclusion that my terrible patches were a waste of time and I am trying to get back into helping out. You were asked to finish the Eudyptula challenge before bothering any other kernel developers with questions / patches. Until that happens, you are in my killfile, now with yet-another-email-address. Greg K-H, I really don't want you to get any more upset with me then you already are. The reason I gave up on the challenge was it was mostly driver based and I wanted to learn more in other areas. If you would like to discuss with me your concerns about my work on this list and how I can aid more please let me known. You stopped so early in the challenge, you really have no idea what it is mostly about, so don't make rash statements like that. Again, unless you finish it, you will be ignored by me, and probably by everyone else as well. greg k-h -- 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: Take dwc2 driver through Felipe's tree?
On Fri, Sep 19, 2014 at 08:52:07PM +, Paul Zimmerman wrote: > Hi Greg, > > How would you feel about Felipe taking the dwc2 driver into his tree? > There has been quite a bit of increased activity with dwc2 lately, and > I know you already have more than enough stuff on your plate already. > So this would mean one less thing for you to worry about. Plus it > would mean an extra layer of review before getting to you. > > I've already talked to Felipe about it, and he's fine with it. If > you're OK with it, I think I just need to send a patch adding a T: > line to the MAINTAINERS entry, showing Felipe's tree? > > I guess we would want to do this just before you close your USB tree, > and you could announce it then? No objection from me. I'm working in my patch backlog right now, should get through them by the end of the day, so feel free to send me a MAINTAINERS patch I can use. thanks, greg k-h -- 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: Take dwc2 driver through Felipe's tree?
On Fri, Sep 19, 2014 at 08:52:07PM +, Paul Zimmerman wrote: Hi Greg, How would you feel about Felipe taking the dwc2 driver into his tree? There has been quite a bit of increased activity with dwc2 lately, and I know you already have more than enough stuff on your plate already. So this would mean one less thing for you to worry about. Plus it would mean an extra layer of review before getting to you. I've already talked to Felipe about it, and he's fine with it. If you're OK with it, I think I just need to send a patch adding a T: line to the MAINTAINERS entry, showing Felipe's tree? I guess we would want to do this just before you close your USB tree, and you could announce it then? No objection from me. I'm working in my patch backlog right now, should get through them by the end of the day, so feel free to send me a MAINTAINERS patch I can use. thanks, greg k-h -- 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 0/2] usb: dwc2: Revert patches causing problems
On Thu, Sep 11, 2014 at 07:11:20PM +, Paul Zimmerman wrote: > > From: Robert Baldyga [mailto:r.bald...@samsung.com] > > Sent: Thursday, September 11, 2014 5:53 AM > > > > These two patches breaks dwc2 driver. The first one causes build break, > > the second breaks gadget at Samsung platforms. > > > > Best regards > > Robert Baldyga > > > > Robert Baldyga (2): > > Revert "usb: dwc2: Update Kconfig to support dual-role" > > Revert "usb: dwc2: move "samsung,s3c6400-hsotg" into common platform" > > > > drivers/usb/dwc2/Kconfig| 63 > > +++-- > > drivers/usb/dwc2/Makefile | 21 +++ > > drivers/usb/dwc2/gadget.c | 1 + > > drivers/usb/dwc2/platform.c | 1 - > > 4 files changed, 38 insertions(+), 48 deletions(-) > > Yep, I can confirm the build breakage. Greg, we should revert these two > before you send your update for the next -rc, if it's not too late. > > Dinh, before resending the series, please test that each individual > patch does not break the build. I tested and didn't see the build breakage on my end, but I don't test-build arm stuff... Anyway, this is in the usb-next branch, not usb-linus, right? thanks, greg k-h -- 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 0/2] usb: dwc2: Revert patches causing problems
On Thu, Sep 11, 2014 at 07:11:20PM +, Paul Zimmerman wrote: From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Thursday, September 11, 2014 5:53 AM These two patches breaks dwc2 driver. The first one causes build break, the second breaks gadget at Samsung platforms. Best regards Robert Baldyga Robert Baldyga (2): Revert usb: dwc2: Update Kconfig to support dual-role Revert usb: dwc2: move samsung,s3c6400-hsotg into common platform drivers/usb/dwc2/Kconfig| 63 +++-- drivers/usb/dwc2/Makefile | 21 +++ drivers/usb/dwc2/gadget.c | 1 + drivers/usb/dwc2/platform.c | 1 - 4 files changed, 38 insertions(+), 48 deletions(-) Yep, I can confirm the build breakage. Greg, we should revert these two before you send your update for the next -rc, if it's not too late. Dinh, before resending the series, please test that each individual patch does not break the build. I tested and didn't see the build breakage on my end, but I don't test-build arm stuff... Anyway, this is in the usb-next branch, not usb-linus, right? thanks, greg k-h -- 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 RESEND v3 00/12] usb: dwc2/gadget: fix series
On Tue, Aug 19, 2014 at 03:46:58PM +, Paul Zimmerman wrote: > > From: Robert Baldyga [mailto:r.bald...@samsung.com] > > Sent: Tuesday, August 19, 2014 1:54 AM > > > > Hi Paul, > > > > I'm resending this patchset rebased on linux-next. Now it should apply. > > > > Thanks, > > Robert Baldyga > > > > Changelog: > > v3: https://lkml.org/lkml/2014/8/4/617 > > - use endpoint index instead of FIFO index for EPFIFO > > - extend patch description > > > > v2: https://lkml.org/lkml/2014/7/16/199 > > - add patch usb: dwc2/gadget: avoid disabling ep0 > > - fix FIFO flushing when it's assigned to endpoint dynamically > > - write to proper FIFO in s3c_hsotg_write_fifo() function > > - use real FIFO size in kill_all_requests > > - fix comment in s3c_hsotg_init_fifo() function > > > > v1: https://lkml.org/lkml/2014/6/23/67 > > > > Andrzej Pietrasiewicz (1): > > usb: dwc2/gadget: Fix comment text > > > > Kamil Debski (3): > > usb: dwc2/gadget: fix phy disable sequence > > usb: dwc2/gadget: fix phy initialization sequence > > usb: dwc2/gadget: move phy bus legth initialization > > > > Marek Szyprowski (5): > > usb: dwc2/gadget: hide some not really needed debug messages > > usb: dwc2/gadget: ensure that all fifos have correct memory buffers > > usb: dwc2/gadget: break infinite loop in endpoint disable code > > usb: dwc2/gadget: do not call disconnect method in pullup > > usb: dwc2/gadget: delay enabling irq once hardware is configured > > properly > > > > Robert Baldyga (3): > > usb: dwc2/gadget: assign TX FIFO dynamically > > usb: dwc2/gadget: disable clock when it's not needed > > usb: dwc2/gadget: avoid disabling ep0 > > > > drivers/usb/dwc2/core.h | 3 + > > drivers/usb/dwc2/gadget.c | 184 > > +++--- > > 2 files changed, 111 insertions(+), 76 deletions(-) > > Thanks Robert. > > For the entire series, > Acked-by: Paul Zimmerman > > Greg, can you please apply this to your usb-next tree? Thanks. For 3.17-final, or 3.18-rc1? thanks, greg k-h -- 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 v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote: > Hi Greg, > > Any feedback on this patch ? The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, _and_ my queue is currently sitting at: $ mdfrm -c ~/mail/todo/ 1317 messages in /home/gregkh/mail/todo/ So please be patient. I'll get to it in a few weeks. greg k-h -- 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 v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote: Hi Greg, Any feedback on this patch ? The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, _and_ my queue is currently sitting at: $ mdfrm -c ~/mail/todo/ 1317 messages in /home/gregkh/mail/todo/ So please be patient. I'll get to it in a few weeks. greg k-h -- 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 RESEND v3 00/12] usb: dwc2/gadget: fix series
On Tue, Aug 19, 2014 at 03:46:58PM +, Paul Zimmerman wrote: From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Tuesday, August 19, 2014 1:54 AM Hi Paul, I'm resending this patchset rebased on linux-next. Now it should apply. Thanks, Robert Baldyga Changelog: v3: https://lkml.org/lkml/2014/8/4/617 - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) Thanks Robert. For the entire series, Acked-by: Paul Zimmerman pa...@synopsys.com Greg, can you please apply this to your usb-next tree? Thanks. For 3.17-final, or 3.18-rc1? thanks, greg k-h -- 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: location for new bus driver-- drivers/bus? drivers/misc?
On Mon, Aug 11, 2014 at 04:25:49PM +, Stuart Yoder wrote: > Greg, > > We (Freescale) have a patch series nearly ready to send out > for a new bus driver. It's for a block we call the Freescale > 'Management Complex' which manages discoverable hardware objects. > The Linux bus driver enumerates these objects, binds discovered > objects to drivers just like PCI or any normal bus driver. Sounds good. > Question is-- where should this go in the kernel and who would > the maintainer be to cc: the RFC? I don't think it warrants > a top level driver directory beside pci, usb, etc. Most likely > place is drivers/bus or drivers/misc (?). > > We currently have it in drivers/bus, but as far as I can see > there is no maintainer per se for that directory. You and > Arnd manage misc so thought I would ask. I don't remember why drivers/bus/ came about, Arnd, you created it, should we be putting random bus controllers in this directory? And if so, sure, I can maintain drivers/bus/ along with the misc/char drivers, it's not a big deal. thanks, greg k-h -- 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: location for new bus driver-- drivers/bus? drivers/misc?
On Mon, Aug 11, 2014 at 04:25:49PM +, Stuart Yoder wrote: Greg, We (Freescale) have a patch series nearly ready to send out for a new bus driver. It's for a block we call the Freescale 'Management Complex' which manages discoverable hardware objects. The Linux bus driver enumerates these objects, binds discovered objects to drivers just like PCI or any normal bus driver. Sounds good. Question is-- where should this go in the kernel and who would the maintainer be to cc: the RFC? I don't think it warrants a top level driver directory beside pci, usb, etc. Most likely place is drivers/bus or drivers/misc (?). We currently have it in drivers/bus, but as far as I can see there is no maintainer per se for that directory. You and Arnd manage misc so thought I would ask. I don't remember why drivers/bus/ came about, Arnd, you created it, should we be putting random bus controllers in this directory? And if so, sure, I can maintain drivers/bus/ along with the misc/char drivers, it's not a big deal. thanks, greg k-h -- 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 RESEND] staging: et131x: Fix errors caused by phydev->addr accesses before initialisation
On Mon, Aug 11, 2014 at 12:32:55AM +0300, Anca Emanuel wrote: > Do you have this hardware ? And did you test this ? Mark is the maintainer of this driver, I assume he has the hardware, if not, I don't care, I trust him :) > How can you cc stable without an Tested by somebody else ? Since when is a tested-by a requirement for a stable@ marking? Please read Documentation/stable_kernel_rules.txt for the details. thanks, greg k-h -- 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 RESEND] staging: et131x: Fix errors caused by phydev-addr accesses before initialisation
On Mon, Aug 11, 2014 at 12:32:55AM +0300, Anca Emanuel wrote: Do you have this hardware ? And did you test this ? Mark is the maintainer of this driver, I assume he has the hardware, if not, I don't care, I trust him :) How can you cc stable without an Tested by somebody else ? Since when is a tested-by a requirement for a stable@ marking? Please read Documentation/stable_kernel_rules.txt for the details. thanks, greg k-h -- 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 v2 3/3] staging:r8190: coding style: Fixed checkpatch reported Error
On Wed, Aug 06, 2014 at 09:33:56AM +, Sharma, Sanjeev wrote: > Hello All, > > I have submitted few patches last week and also get reply from Greg that > patches will show up in linux-next tree and in parallel I need to submit new > patches and now Looks like I need to > Sync my tree with linux-next tree before start working on New set of change > and as soon as I am pulling change I always get conflicts. > > Anyone has idea who to overcome this problem ? Use a separate branch for your work, and also never use 'git pull' with linux-next, that just will not work at all. greg k-h -- 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 v2 3/3] staging:r8190: coding style: Fixed checkpatch reported Error
On Wed, Aug 06, 2014 at 09:33:56AM +, Sharma, Sanjeev wrote: Hello All, I have submitted few patches last week and also get reply from Greg that patches will show up in linux-next tree and in parallel I need to submit new patches and now Looks like I need to Sync my tree with linux-next tree before start working on New set of change and as soon as I am pulling change I always get conflicts. Anyone has idea who to overcome this problem ? Use a separate branch for your work, and also never use 'git pull' with linux-next, that just will not work at all. greg k-h -- 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 v3 00/12] usb: dwc2/gadget: fix series
On Mon, Aug 04, 2014 at 07:53:35PM +, Paul Zimmerman wrote: > > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > Sent: Monday, August 04, 2014 12:11 PM > > > > On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: > > > > From: Paul Zimmerman > > > > Sent: Friday, July 18, 2014 12:19 PM > > > > > > > > > From: Robert Baldyga [mailto:r.bald...@samsung.com] > > > > > Sent: Friday, July 18, 2014 4:39 AM > > > > > > > > > > This patchset contains fixes for dwc2 gadget driver. It touches PHY, > > > > > FIFO configuration, initialization sequence and adds many other small > > > > > fixes. > > > > > > > > > > Best regards > > > > > Robert Baldyga > > > > > Samsung R Institute Poland > > > > > > > > > > Changelog: > > > > > v3: > > > > > - use endpoint index instead of FIFO index for EPFIFO > > > > > - extend patch description > > > > > > > > > > v2: https://lkml.org/lkml/2014/7/16/199 > > > > > - add patch usb: dwc2/gadget: avoid disabling ep0 > > > > > - fix FIFO flushing when it's assigned to endpoint dynamically > > > > > - write to proper FIFO in s3c_hsotg_write_fifo() function > > > > > - use real FIFO size in kill_all_requests > > > > > - fix comment in s3c_hsotg_init_fifo() function > > > > > > > > > > v1: https://lkml.org/lkml/2014/6/23/67 > > > > > > > > > > Andrzej Pietrasiewicz (1): > > > > > usb: dwc2/gadget: Fix comment text > > > > > > > > > > Kamil Debski (3): > > > > > usb: dwc2/gadget: fix phy disable sequence > > > > > usb: dwc2/gadget: fix phy initialization sequence > > > > > usb: dwc2/gadget: move phy bus legth initialization > > > > > > > > > > Marek Szyprowski (5): > > > > > usb: dwc2/gadget: hide some not really needed debug messages > > > > > usb: dwc2/gadget: ensure that all fifos have correct memory buffers > > > > > usb: dwc2/gadget: break infinite loop in endpoint disable code > > > > > usb: dwc2/gadget: do not call disconnect method in pullup > > > > > usb: dwc2/gadget: delay enabling irq once hardware is configured > > > > > properly > > > > > > > > > > Robert Baldyga (3): > > > > > usb: dwc2/gadget: assign TX FIFO dynamically > > > > > usb: dwc2/gadget: disable clock when it's not needed > > > > > usb: dwc2/gadget: avoid disabling ep0 > > > > > > > > > > drivers/usb/dwc2/core.h | 3 + > > > > > drivers/usb/dwc2/gadget.c | 184 > > > > > +++--- > > > > > 2 files changed, 111 insertions(+), 76 deletions(-) > > > > > > > > For the entire series: > > > > > > > > Acked-by: Paul Zimmerman > > > > > > Hi Greg, > > > > > > I don't see this series from Robert in your tree yet. Is it still in > > > your queue, or should Robert resend it? > > > > I thought this was coming in from Felipe's tree, sorry. It's too late > > for 3.17-rc1, I just sent out those patches to Linus. > > > > If someone wants me to take a patch series, please be explicit and say > > something like "Greg please take these in your tree", otherwise it is > > very easy to get lost in my inbox... > > Ah, OK. I guess that's my fault. > > Still, the mainline merge window is open for two weeks, right? Any reason > why you can't still send this series to Linus? I'd hate to see Robert > lose out due to my screwup. Patches had to be in my tree for the week _before_ the merge window opened, to get testing in linux-next. It's been that way for years, sorry. greg k-h -- 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 v3 00/12] usb: dwc2/gadget: fix series
On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: > > From: Paul Zimmerman > > Sent: Friday, July 18, 2014 12:19 PM > > > > > From: Robert Baldyga [mailto:r.bald...@samsung.com] > > > Sent: Friday, July 18, 2014 4:39 AM > > > > > > This patchset contains fixes for dwc2 gadget driver. It touches PHY, > > > FIFO configuration, initialization sequence and adds many other small > > > fixes. > > > > > > Best regards > > > Robert Baldyga > > > Samsung R Institute Poland > > > > > > Changelog: > > > v3: > > > - use endpoint index instead of FIFO index for EPFIFO > > > - extend patch description > > > > > > v2: https://lkml.org/lkml/2014/7/16/199 > > > - add patch usb: dwc2/gadget: avoid disabling ep0 > > > - fix FIFO flushing when it's assigned to endpoint dynamically > > > - write to proper FIFO in s3c_hsotg_write_fifo() function > > > - use real FIFO size in kill_all_requests > > > - fix comment in s3c_hsotg_init_fifo() function > > > > > > v1: https://lkml.org/lkml/2014/6/23/67 > > > > > > Andrzej Pietrasiewicz (1): > > > usb: dwc2/gadget: Fix comment text > > > > > > Kamil Debski (3): > > > usb: dwc2/gadget: fix phy disable sequence > > > usb: dwc2/gadget: fix phy initialization sequence > > > usb: dwc2/gadget: move phy bus legth initialization > > > > > > Marek Szyprowski (5): > > > usb: dwc2/gadget: hide some not really needed debug messages > > > usb: dwc2/gadget: ensure that all fifos have correct memory buffers > > > usb: dwc2/gadget: break infinite loop in endpoint disable code > > > usb: dwc2/gadget: do not call disconnect method in pullup > > > usb: dwc2/gadget: delay enabling irq once hardware is configured > > > properly > > > > > > Robert Baldyga (3): > > > usb: dwc2/gadget: assign TX FIFO dynamically > > > usb: dwc2/gadget: disable clock when it's not needed > > > usb: dwc2/gadget: avoid disabling ep0 > > > > > > drivers/usb/dwc2/core.h | 3 + > > > drivers/usb/dwc2/gadget.c | 184 > > > +++--- > > > 2 files changed, 111 insertions(+), 76 deletions(-) > > > > For the entire series: > > > > Acked-by: Paul Zimmerman > > Hi Greg, > > I don't see this series from Robert in your tree yet. Is it still in > your queue, or should Robert resend it? I thought this was coming in from Felipe's tree, sorry. It's too late for 3.17-rc1, I just sent out those patches to Linus. If someone wants me to take a patch series, please be explicit and say something like "Greg please take these in your tree", otherwise it is very easy to get lost in my inbox... greg k-h -- 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 v3 00/12] usb: dwc2/gadget: fix series
On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: From: Paul Zimmerman Sent: Friday, July 18, 2014 12:19 PM From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Friday, July 18, 2014 4:39 AM This patchset contains fixes for dwc2 gadget driver. It touches PHY, FIFO configuration, initialization sequence and adds many other small fixes. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series: Acked-by: Paul Zimmerman pa...@synopsys.com Hi Greg, I don't see this series from Robert in your tree yet. Is it still in your queue, or should Robert resend it? I thought this was coming in from Felipe's tree, sorry. It's too late for 3.17-rc1, I just sent out those patches to Linus. If someone wants me to take a patch series, please be explicit and say something like Greg please take these in your tree, otherwise it is very easy to get lost in my inbox... greg k-h -- 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 v3 00/12] usb: dwc2/gadget: fix series
On Mon, Aug 04, 2014 at 07:53:35PM +, Paul Zimmerman wrote: From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] Sent: Monday, August 04, 2014 12:11 PM On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: From: Paul Zimmerman Sent: Friday, July 18, 2014 12:19 PM From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Friday, July 18, 2014 4:39 AM This patchset contains fixes for dwc2 gadget driver. It touches PHY, FIFO configuration, initialization sequence and adds many other small fixes. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series: Acked-by: Paul Zimmerman pa...@synopsys.com Hi Greg, I don't see this series from Robert in your tree yet. Is it still in your queue, or should Robert resend it? I thought this was coming in from Felipe's tree, sorry. It's too late for 3.17-rc1, I just sent out those patches to Linus. If someone wants me to take a patch series, please be explicit and say something like Greg please take these in your tree, otherwise it is very easy to get lost in my inbox... Ah, OK. I guess that's my fault. Still, the mainline merge window is open for two weeks, right? Any reason why you can't still send this series to Linus? I'd hate to see Robert lose out due to my screwup. Patches had to be in my tree for the week _before_ the merge window opened, to get testing in linux-next. It's been that way for years, sorry. greg k-h -- 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 v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
On Thu, Jul 24, 2014 at 01:54:58AM +, Dexuan Cui wrote: > Ping again -- any one has further comment for the v3 version? > > It looks the framebuffer layer's Tomi and Jean-Christophe are out recently? > Recently I don't see mail from them since Jul 1 and Jul 8 in the lists. > > Though the patch belongs to driver/video/fbdev/, it only changes hyper-v stuff > and only changes one file and the patch itself is straightforward IMO. > > So, hi Greg and all, > If you think the patch itself is OK, may I know if it's OK for the patch to go > into Greg's char-misc.git tree, as some other hyper-v patches did? No, it needs to go through the fb tree, not mine, sorry. greg k-h -- 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 v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
On Thu, Jul 24, 2014 at 01:54:58AM +, Dexuan Cui wrote: Ping again -- any one has further comment for the v3 version? It looks the framebuffer layer's Tomi and Jean-Christophe are out recently? Recently I don't see mail from them since Jul 1 and Jul 8 in the lists. Though the patch belongs to driver/video/fbdev/, it only changes hyper-v stuff and only changes one file and the patch itself is straightforward IMO. So, hi Greg and all, If you think the patch itself is OK, may I know if it's OK for the patch to go into Greg's char-misc.git tree, as some other hyper-v patches did? No, it needs to go through the fb tree, not mine, sorry. greg k-h -- 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 v2] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
On Tue, Jul 08, 2014 at 10:17:48PM +, Dexuan Cui wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Tuesday, July 8, 2014 17:27 PM > > To: Dexuan Cui > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- > > de...@linuxdriverproject.org; plagn...@jcrosoft.com; > > tomi.valkei...@ti.com; linux-fb...@vger.kernel.org; o...@aepfle.de; > > a...@canonical.com; jasow...@redhat.com; Haiyang Zhang > > Subject: Re: [PATCH v2] video: hyperv: hyperv_fb: refresh the VM screen by > > force on VM panic > > > > Don't use likely/unlikely unless you have benchmark numbers to show that > > it makes a speed up. > > > > regards, > > dan carpenter > > Hi Dan, > Here the variable 'synchronous_fb' is only set to true when the system panics. > So before the system panics, it's always 'unlikely'. :-) Then take advantage of gcc's and your processor's prediction, which knows that 0 is the "common" case and will choose to do the right thing here. Dan is right, never put those markings in your code unless you can benchmark the difference. Which means in reality, never put them in your code. thanks, gerg k-h -- 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 v2] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
On Tue, Jul 08, 2014 at 10:17:48PM +, Dexuan Cui wrote: -Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Tuesday, July 8, 2014 17:27 PM To: Dexuan Cui Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- de...@linuxdriverproject.org; plagn...@jcrosoft.com; tomi.valkei...@ti.com; linux-fb...@vger.kernel.org; o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Haiyang Zhang Subject: Re: [PATCH v2] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic Don't use likely/unlikely unless you have benchmark numbers to show that it makes a speed up. regards, dan carpenter Hi Dan, Here the variable 'synchronous_fb' is only set to true when the system panics. So before the system panics, it's always 'unlikely'. :-) Then take advantage of gcc's and your processor's prediction, which knows that 0 is the common case and will choose to do the right thing here. Dan is right, never put those markings in your code unless you can benchmark the difference. Which means in reality, never put them in your code. thanks, gerg k-h -- 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[[vme/bridges/vme_ca91cx42.c:1382: Bad if test Bug Fix]
On Thu, Jun 12, 2014 at 04:17:36AM +, Nick Krause wrote: > Here is the fixed patch as per Greg's recommendations. Unforunalty my email > client removes tabs so I will have to be sending it as a patch file if that's > Ok. > Nick HTML is rejected by the mailing lists, and we can't take a base64 attachment either :( Take a look at Documentation/email_clients.txt for ideas on how to fix this up on your end. thanks, greg k-h -- 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[vme/bridges/vme_ca91cx42.c:1382: Bad if test Bug Fix]
On Thu, Jun 12, 2014 at 03:44:34AM +, Nick Krause wrote:
> Hey Fellow Developers,
> This is my first patch so if there are any errors please reply as i will
> fix them. Below is the patch.
> -- drivers/vme/bridges/vme_ca91cx42.h.orig 2014-06-11 22:50:29.339671939
> -0400
> +++ drivers/vme/bridges/vme_ca91cx42.h 2014-06-11 23:15:36.027685173 -0400
> @@ -526,7 +526,7 @@ static const int CA91CX42_LINT_LM[] = {
> #define CA91CX42_VSI_CTL_SUPER_SUPR (1<<21)
>
> #define CA91CX42_VSI_CTL_VAS_M (7<<16)
> -#define CA91CX42_VSI_CTL_VAS_A16 0
> +#define CA91CX42_VSI_CTL_VAS_A16 (3<<16)
> #define CA91CX42_VSI_CTL_VAS_A24 (1<<16)
> #define CA91CX42_VSI_CTL_VAS_A32 (1<<17)
> #define CA91CX42_VSI_CTL_VAS_USER1 (3<<17)
> @@ -549,7 +549,7 @@ static const int CA91CX42_LINT_LM[] = {
> #define CA91CX42_LM_CTL_SUPR (1<<21)
> #define CA91CX42_LM_CTL_NPRIV (1<<20)
> #define CA91CX42_LM_CTL_AS_M (5<<16)
> -#define CA91CX42_LM_CTL_AS_A16 0
> +#define CA91CX42_LM_CTL_AS_A16 (3<<16)
> #define CA91CX42_LM_CTL_AS_A24 (1<<16)
> #define CA91CX42_LM_CTL_AS_A32 (1<<17)
> Signed-off-by: Nicholas Krause
Always run your patch through scripts/checkpatch.pl first to catch the
issues that are 'obvious'.
After that, the signed-off-by: needs to be up in the changelog area,
there needs to be a changelog explaining why this patch is needed, and
the tabs need to be put back in the patch (your email client ate them.)
Can you try again?
thanks,
greg k-h
--
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[vme/bridges/vme_ca91cx42.c:1382: Bad if test Bug Fix]
On Thu, Jun 12, 2014 at 03:44:34AM +, Nick Krause wrote:
Hey Fellow Developers,
This is my first patch so if there are any errors please reply as i will
fix them. Below is the patch.
-- drivers/vme/bridges/vme_ca91cx42.h.orig 2014-06-11 22:50:29.339671939
-0400
+++ drivers/vme/bridges/vme_ca91cx42.h 2014-06-11 23:15:36.027685173 -0400
@@ -526,7 +526,7 @@ static const int CA91CX42_LINT_LM[] = {
#define CA91CX42_VSI_CTL_SUPER_SUPR (121)
#define CA91CX42_VSI_CTL_VAS_M (716)
-#define CA91CX42_VSI_CTL_VAS_A16 0
+#define CA91CX42_VSI_CTL_VAS_A16 (316)
#define CA91CX42_VSI_CTL_VAS_A24 (116)
#define CA91CX42_VSI_CTL_VAS_A32 (117)
#define CA91CX42_VSI_CTL_VAS_USER1 (317)
@@ -549,7 +549,7 @@ static const int CA91CX42_LINT_LM[] = {
#define CA91CX42_LM_CTL_SUPR (121)
#define CA91CX42_LM_CTL_NPRIV (120)
#define CA91CX42_LM_CTL_AS_M (516)
-#define CA91CX42_LM_CTL_AS_A16 0
+#define CA91CX42_LM_CTL_AS_A16 (316)
#define CA91CX42_LM_CTL_AS_A24 (116)
#define CA91CX42_LM_CTL_AS_A32 (117)
Signed-off-by: Nicholas Krause nickkra...@sympatico.ca
Always run your patch through scripts/checkpatch.pl first to catch the
issues that are 'obvious'.
After that, the signed-off-by: needs to be up in the changelog area,
there needs to be a changelog explaining why this patch is needed, and
the tabs need to be put back in the patch (your email client ate them.)
Can you try again?
thanks,
greg k-h
--
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[[vme/bridges/vme_ca91cx42.c:1382: Bad if test Bug Fix]
On Thu, Jun 12, 2014 at 04:17:36AM +, Nick Krause wrote: Here is the fixed patch as per Greg's recommendations. Unforunalty my email client removes tabs so I will have to be sending it as a patch file if that's Ok. Nick HTML is rejected by the mailing lists, and we can't take a base64 attachment either :( Take a look at Documentation/email_clients.txt for ideas on how to fix this up on your end. thanks, greg k-h -- 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: Fwd: [crypto:master 60/60] arch/x86/crypto/ghash-clmulni-intel_glue.c:71:25: sparse: cast to restricted __be64
On Fri, Apr 11, 2014 at 09:48:42PM +0200, Ard Biesheuvel wrote: > On 11 April 2014 18:03, gre...@linuxfoundation.org > wrote: > > On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote: > >> Greg, > >> > >> This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel - > >> use C implementation for setkey()) that has been pulled by Linus > >> during the current merge window. > >> > >> It is missing two things: > >> - a cc to stable annotation > >> - a fix for the sparse warning below (change cast from __be64 to __force > >> __be64) > >> > >> The reason for cc'ing stable on this patch is that it fixes a > >> potential data corruption issue where the ghash setkey() method uses > >> SSE registers without calling kernel_fpu_begin() first. This issue was > >> introduced by 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated > >> implementation). > >> > >> So how would you like to proceed with this? Should I propose a new > >> patch somewhere? > > > > No problem, I'll apply this as-is. But it doesn't apply to the > > 3.4-stable tree cleanly, can you send me a backported version if it's > > still needed there as well? > > > > Yes, the code was broken from the start. 3.4 version is attached, the > only difference is the missing ENDPROC() at the end of the asm file. Now applied, thanks. > In the mean time, Herbert has submitted a fix for the sparse warning, > but we settled on a different fix than I had suggested before. > https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=0ea481466d1c > > Note that this code has not been tested (not by me, at least), so I > wouldn't suggest you take it straight away, but if you care about the > sparse warning, we could add a cc stable to it as well, I suppose. If it's a real bugfix that people can hit, then yse, I'll take it. Just let me know when it hits Linus's tree. greg k-h -- 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: Fwd: [crypto:master 60/60] arch/x86/crypto/ghash-clmulni-intel_glue.c:71:25: sparse: cast to restricted __be64
On Fri, Apr 11, 2014 at 09:48:42PM +0200, Ard Biesheuvel wrote: On 11 April 2014 18:03, gre...@linuxfoundation.org gre...@linuxfoundation.org wrote: On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote: Greg, This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel - use C implementation for setkey()) that has been pulled by Linus during the current merge window. It is missing two things: - a cc to stable annotation - a fix for the sparse warning below (change cast from __be64 to __force __be64) The reason for cc'ing stable on this patch is that it fixes a potential data corruption issue where the ghash setkey() method uses SSE registers without calling kernel_fpu_begin() first. This issue was introduced by 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation). So how would you like to proceed with this? Should I propose a new patch somewhere? No problem, I'll apply this as-is. But it doesn't apply to the 3.4-stable tree cleanly, can you send me a backported version if it's still needed there as well? Yes, the code was broken from the start. 3.4 version is attached, the only difference is the missing ENDPROC() at the end of the asm file. Now applied, thanks. In the mean time, Herbert has submitted a fix for the sparse warning, but we settled on a different fix than I had suggested before. https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=0ea481466d1c Note that this code has not been tested (not by me, at least), so I wouldn't suggest you take it straight away, but if you care about the sparse warning, we could add a cc stable to it as well, I suppose. If it's a real bugfix that people can hit, then yse, I'll take it. Just let me know when it hits Linus's tree. greg k-h -- 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] serial_core: fix uart PORT_UNKNOWN handling
On Wed, Apr 09, 2014 at 05:06:24PM +0200, Thomas Pfaff wrote: > > On Wed, 9 Apr 2014, One Thousand Gnomes wrote: > > > On Wed, 9 Apr 2014 13:22:14 +0200 > > Thomas Pfaff wrote: > > > > > 1. uart_change_pm ist called during uart_open and calls the uart pm > > > function > > >without checking for PORT_UNKNOWN. > > > > Removing this breaks other parts of the code assume that the port will be > > powered up (notably setserial paths). So it makes sense that > > uart_change_pm for a "none" port is a no-op but needs logic in the > > setserial path to power up a port when we move none->known and power it > > down on known->none > > > > Then why not move uart_change_pm into uart_port_startup, where it will be > called > when needed ? > A reworked patch is below. > > > > 2. uart_shutdown is called from uart_set_info and does not check it > > > either. > > > > I don't see why this one matters. We would have done > > > > uart_startup > > uart_port_startup > > uport->type == PORT_UNKNOWN > > return 1; > > ASYNCB_INITIALIZED is not set > > > > uart_shutdown > > ASYNCB_INITIALISED is not set > > Skip call to uart_port_shutdown > > > > So that code looks correct to me. > > I agree, i have overlooked this. > > Signed-off-by: Thomas Pfaff Can you resend this in a format that I can apply this in? thanks, greg k-h -- 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] serial_core: fix uart PORT_UNKNOWN handling
On Wed, Apr 09, 2014 at 05:06:24PM +0200, Thomas Pfaff wrote: On Wed, 9 Apr 2014, One Thousand Gnomes wrote: On Wed, 9 Apr 2014 13:22:14 +0200 Thomas Pfaff tpf...@pcs.com wrote: 1. uart_change_pm ist called during uart_open and calls the uart pm function without checking for PORT_UNKNOWN. Removing this breaks other parts of the code assume that the port will be powered up (notably setserial paths). So it makes sense that uart_change_pm for a none port is a no-op but needs logic in the setserial path to power up a port when we move none-known and power it down on known-none Then why not move uart_change_pm into uart_port_startup, where it will be called when needed ? A reworked patch is below. 2. uart_shutdown is called from uart_set_info and does not check it either. I don't see why this one matters. We would have done uart_startup uart_port_startup uport-type == PORT_UNKNOWN return 1; ASYNCB_INITIALIZED is not set uart_shutdown ASYNCB_INITIALISED is not set Skip call to uart_port_shutdown So that code looks correct to me. I agree, i have overlooked this. Signed-off-by: Thomas Pfaff tpf...@pcs.com Can you resend this in a format that I can apply this in? thanks, greg k-h -- 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: Fwd: [crypto:master 60/60] arch/x86/crypto/ghash-clmulni-intel_glue.c:71:25: sparse: cast to restricted __be64
On Fri, Apr 11, 2014 at 09:48:42PM +0200, Ard Biesheuvel wrote: > On 11 April 2014 18:03, gre...@linuxfoundation.org > wrote: > > On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote: > >> Greg, > >> > >> This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel - > >> use C implementation for setkey()) that has been pulled by Linus > >> during the current merge window. > >> > >> It is missing two things: > >> - a cc to stable annotation > >> - a fix for the sparse warning below (change cast from __be64 to __force > >> __be64) > >> > >> The reason for cc'ing stable on this patch is that it fixes a > >> potential data corruption issue where the ghash setkey() method uses > >> SSE registers without calling kernel_fpu_begin() first. This issue was > >> introduced by 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated > >> implementation). > >> > >> So how would you like to proceed with this? Should I propose a new > >> patch somewhere? > > > > No problem, I'll apply this as-is. But it doesn't apply to the > > 3.4-stable tree cleanly, can you send me a backported version if it's > > still needed there as well? > > > > Yes, the code was broken from the start. 3.4 version is attached, the > only difference is the missing ENDPROC() at the end of the asm file. > > In the mean time, Herbert has submitted a fix for the sparse warning, > but we settled on a different fix than I had suggested before. > https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=0ea481466d1c > > Note that this code has not been tested (not by me, at least), so I > wouldn't suggest you take it straight away, but if you care about the > sparse warning, we could add a cc stable to it as well, I suppose. No, I don't care about a sparse warning, unless it's fixing a real bug. I'll queue this up for the next 3.4 release after the one that happens this weekend, thanks. greg k-h -- 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: Fwd: [crypto:master 60/60] arch/x86/crypto/ghash-clmulni-intel_glue.c:71:25: sparse: cast to restricted __be64
On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote: > Greg, > > This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel - > use C implementation for setkey()) that has been pulled by Linus > during the current merge window. > > It is missing two things: > - a cc to stable annotation > - a fix for the sparse warning below (change cast from __be64 to __force > __be64) > > The reason for cc'ing stable on this patch is that it fixes a > potential data corruption issue where the ghash setkey() method uses > SSE registers without calling kernel_fpu_begin() first. This issue was > introduced by 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated > implementation). > > So how would you like to proceed with this? Should I propose a new > patch somewhere? No problem, I'll apply this as-is. But it doesn't apply to the 3.4-stable tree cleanly, can you send me a backported version if it's still needed there as well? thanks, greg k-h -- 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: Fwd: [crypto:master 60/60] arch/x86/crypto/ghash-clmulni-intel_glue.c:71:25: sparse: cast to restricted __be64
On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote: Greg, This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel - use C implementation for setkey()) that has been pulled by Linus during the current merge window. It is missing two things: - a cc to stable annotation - a fix for the sparse warning below (change cast from __be64 to __force __be64) The reason for cc'ing stable on this patch is that it fixes a potential data corruption issue where the ghash setkey() method uses SSE registers without calling kernel_fpu_begin() first. This issue was introduced by 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation). So how would you like to proceed with this? Should I propose a new patch somewhere? No problem, I'll apply this as-is. But it doesn't apply to the 3.4-stable tree cleanly, can you send me a backported version if it's still needed there as well? thanks, greg k-h -- 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: Fwd: [crypto:master 60/60] arch/x86/crypto/ghash-clmulni-intel_glue.c:71:25: sparse: cast to restricted __be64
On Fri, Apr 11, 2014 at 09:48:42PM +0200, Ard Biesheuvel wrote: On 11 April 2014 18:03, gre...@linuxfoundation.org gre...@linuxfoundation.org wrote: On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote: Greg, This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel - use C implementation for setkey()) that has been pulled by Linus during the current merge window. It is missing two things: - a cc to stable annotation - a fix for the sparse warning below (change cast from __be64 to __force __be64) The reason for cc'ing stable on this patch is that it fixes a potential data corruption issue where the ghash setkey() method uses SSE registers without calling kernel_fpu_begin() first. This issue was introduced by 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation). So how would you like to proceed with this? Should I propose a new patch somewhere? No problem, I'll apply this as-is. But it doesn't apply to the 3.4-stable tree cleanly, can you send me a backported version if it's still needed there as well? Yes, the code was broken from the start. 3.4 version is attached, the only difference is the missing ENDPROC() at the end of the asm file. In the mean time, Herbert has submitted a fix for the sparse warning, but we settled on a different fix than I had suggested before. https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=0ea481466d1c Note that this code has not been tested (not by me, at least), so I wouldn't suggest you take it straight away, but if you care about the sparse warning, we could add a cc stable to it as well, I suppose. No, I don't care about a sparse warning, unless it's fixing a real bug. I'll queue this up for the next 3.4 release after the one that happens this weekend, thanks. greg k-h -- 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]: UIO read(2)/write(2) overrides
On Fri, Mar 21, 2014 at 02:49:28PM +, Matt Sickler wrote: > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > > >On Fri, Mar 21, 2014 at 02:20:11PM +, Matt Sickler wrote: > >> Tiny patch to let uio-based drivers override the read(2), write(2), and > >> poll(2) syscalls. > >> The rationale is that some uio-based drivers might want the mmap(2) > >> functionality of UIO, but have no need for the IRQ semantics of read(2) > >> and write(2). > > > >Can you submit a driver that uses these new interfaces as well? I don't > >want to add something that isn't used in the kernel. > > We're developing a driver for a new product but the driver is still in > a state of flux, so it's not ready for posting yet. > We will definitely get this out there once it's more polished. > If you want to hold off applying this patch until we have something to > submit that uses it, I'm fine with that. Yes, we will have to wait until we see that driver, thanks. greg k-h -- 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]: UIO read(2)/write(2) overrides
On Fri, Mar 21, 2014 at 02:20:11PM +, Matt Sickler wrote: > Tiny patch to let uio-based drivers override the read(2), write(2), and > poll(2) syscalls. > The rationale is that some uio-based drivers might want the mmap(2) > functionality > of UIO, but have no need for the IRQ semantics of read(2) and write(2). Can you submit a driver that uses these new interfaces as well? I don't want to add something that isn't used in the kernel. > > Signed-Off-by: Matt Sickler > --- > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c > index a673e5b..da1bfc8 100644 > --- a/drivers/uio/uio.c > +++ b/drivers/uio/uio.c > @@ -505,6 +505,9 @@ static unsigned int uio_poll(struct file *filep, > poll_table *wait) > struct uio_listener *listener = filep->private_data; > struct uio_device *idev = listener->dev; > > + if (idev->info->poll) > + return idev->info->poll(filep, wait); > + Your email client ate all the tabs and created a patch that can't be applied :( -- 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]: UIO read(2)/write(2) overrides
On Fri, Mar 21, 2014 at 02:20:11PM +, Matt Sickler wrote: Tiny patch to let uio-based drivers override the read(2), write(2), and poll(2) syscalls. The rationale is that some uio-based drivers might want the mmap(2) functionality of UIO, but have no need for the IRQ semantics of read(2) and write(2). Can you submit a driver that uses these new interfaces as well? I don't want to add something that isn't used in the kernel. Signed-Off-by: Matt Sickler matt.sick...@daktronics.com --- diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index a673e5b..da1bfc8 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -505,6 +505,9 @@ static unsigned int uio_poll(struct file *filep, poll_table *wait) struct uio_listener *listener = filep-private_data; struct uio_device *idev = listener-dev; + if (idev-info-poll) + return idev-info-poll(filep, wait); + Your email client ate all the tabs and created a patch that can't be applied :( -- 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]: UIO read(2)/write(2) overrides
On Fri, Mar 21, 2014 at 02:49:28PM +, Matt Sickler wrote: From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] On Fri, Mar 21, 2014 at 02:20:11PM +, Matt Sickler wrote: Tiny patch to let uio-based drivers override the read(2), write(2), and poll(2) syscalls. The rationale is that some uio-based drivers might want the mmap(2) functionality of UIO, but have no need for the IRQ semantics of read(2) and write(2). Can you submit a driver that uses these new interfaces as well? I don't want to add something that isn't used in the kernel. We're developing a driver for a new product but the driver is still in a state of flux, so it's not ready for posting yet. We will definitely get this out there once it's more polished. If you want to hold off applying this patch until we have something to submit that uses it, I'm fine with that. Yes, we will have to wait until we see that driver, thanks. greg k-h -- 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: gadget: fsl: Add FSL USB Gadget entry in platform device id
On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
> > > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > > fsl_udc_devtype[] = {
> > > > > > }, {
> > > > > > .name = "imx-udc-mx51",
> > > > > > }, {
> > > > > > + .name = "fsl-usb2-udc",
> > > > >
> > > > > why aren't you just using chipidea ?
> > > > > [SuresH] This is our legacy driver for all previous and existing
> > > > > ppc socs. Many of our customers are already using this, and we
> > > > > need to support them on this driver. We do have plans to shift to
> > > > > chipidea, but after some time.
> > > >
> > > > cool, you already have plans, so we will see a new glue layer for
> > > > v3.16 right ? Which means I don't need to take this patch either.
> > > >
> > > we do have plans, but in remote future. Right now, we need to support
> > > customers on the present legacy driver. We'll phase out this driver
> > > slowly when we integrate chipidea. At this time I would request you to
> > > please accept this patch
> >
> > Even if Felipe takes the patch, I'll reject it as you should be doing the
> > correct thing here, and if it's accepted, it will never be changed...
>
> Hi Greg, I agree that moving to the chipidea driver is the right thing to do.
> However, does this mean that companies have to phase out their current legacy
> drivers as soon as a new controller specific driver is introduced in kernel ??
If their drivers aren't merged upstream, then yes they do, we can't have
duplicate drivers controlling the same hardware blobs.
> Can't they decide their own schedule based on their own requirements. Our
> only
> concern is to keep supporting our customers till we move to the new driver.
Your support issues / requirements is not any of our business, we just
can't accept duplicate code, which I'm sure you can understand.
> I would really appreciate if you could accept this as this would give us
> some time to move to chipidea driver.
What is preventing you from doing this within a week or so? Is it
really that hard of a transistion? If so, is this a problem with the
chipidea driver or something else?
thanks,
greg k-h
--
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: gadget: fsl: Add FSL USB Gadget entry in platform device id
On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
@@ -2654,6 +2654,8 @@ static const struct platform_device_id
fsl_udc_devtype[] = {
}, {
.name = imx-udc-mx51,
}, {
+ .name = fsl-usb2-udc,
why aren't you just using chipidea ?
[SuresH] This is our legacy driver for all previous and existing
ppc socs. Many of our customers are already using this, and we
need to support them on this driver. We do have plans to shift to
chipidea, but after some time.
cool, you already have plans, so we will see a new glue layer for
v3.16 right ? Which means I don't need to take this patch either.
we do have plans, but in remote future. Right now, we need to support
customers on the present legacy driver. We'll phase out this driver
slowly when we integrate chipidea. At this time I would request you to
please accept this patch
Even if Felipe takes the patch, I'll reject it as you should be doing the
correct thing here, and if it's accepted, it will never be changed...
Hi Greg, I agree that moving to the chipidea driver is the right thing to do.
However, does this mean that companies have to phase out their current legacy
drivers as soon as a new controller specific driver is introduced in kernel ??
If their drivers aren't merged upstream, then yes they do, we can't have
duplicate drivers controlling the same hardware blobs.
Can't they decide their own schedule based on their own requirements. Our
only
concern is to keep supporting our customers till we move to the new driver.
Your support issues / requirements is not any of our business, we just
can't accept duplicate code, which I'm sure you can understand.
I would really appreciate if you could accept this as this would give us
some time to move to chipidea driver.
What is preventing you from doing this within a week or so? Is it
really that hard of a transistion? If so, is this a problem with the
chipidea driver or something else?
thanks,
greg k-h
--
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: gadget: fsl: Add FSL USB Gadget entry in platform device id
On Wed, Mar 19, 2014 at 02:25:25PM +, suresh.gu...@freescale.com wrote:
> Hi
>
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Saturday, March 15, 2014 7:10 AM
> > To: Gupta Suresh-B42813
> > Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
> > platform device id
> >
> > On Fri, Mar 14, 2014 at 08:52:19PM +, suresh.gu...@freescale.com
> > wrote:
> > > Hi,
> > > Thanks for reviewing my patches.
> > > Please find my comments inline
> > >
> > > -Original Message-
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Thursday, March 13, 2014 8:56 PM
> > > To: Gupta Suresh-B42813
> > > Cc: ba...@ti.com; gre...@linuxfoundation.org;
> > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Gupta
> > > Suresh-B42813
> > > Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
> > > platform device id
> > >
> > > On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
> > > > From: Suresh Gupta
> > > >
> > > > Add FSL USB Gadget entry in platform device id table
> > >
> > > why this tab ?
> > > [SuresH] I will remove it in next version.
> > >
> > > > Signed-off-by: Suresh Gupta
> > > > ---
> > > > drivers/usb/gadget/fsl_udc_core.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/usb/gadget/fsl_udc_core.c
> > > > b/drivers/usb/gadget/fsl_udc_core.c
> > > > index b7dea4e..35b20e6 100644
> > > > --- a/drivers/usb/gadget/fsl_udc_core.c
> > > > +++ b/drivers/usb/gadget/fsl_udc_core.c
> > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > fsl_udc_devtype[] = {
> > > > }, {
> > > > .name = "imx-udc-mx51",
> > > > }, {
> > > > + .name = "fsl-usb2-udc",
> > >
> > > why aren't you just using chipidea ?
> > > [SuresH] This is our legacy driver for all previous and existing ppc
> > > socs. Many of our customers are already using this, and we need to
> > > support them on this driver. We do have plans to shift to chipidea,
> > > but after some time.
> >
> > cool, you already have plans, so we will see a new glue layer for v3.16
> > right ? Which means I don't need to take this patch either.
> >
> we do have plans, but in remote future. Right now, we need to support
> customers on the present legacy driver. We'll phase out this driver
> slowly when we integrate chipidea. At this time I would request you
> to please accept this patch
Even if Felipe takes the patch, I'll reject it as you should be doing
the correct thing here, and if it's accepted, it will never be
changed...
greg k-h
--
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: gadget: fsl: Add FSL USB Gadget entry in platform device id
On Wed, Mar 19, 2014 at 02:25:25PM +, suresh.gu...@freescale.com wrote:
Hi
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Saturday, March 15, 2014 7:10 AM
To: Gupta Suresh-B42813
Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
platform device id
On Fri, Mar 14, 2014 at 08:52:19PM +, suresh.gu...@freescale.com
wrote:
Hi,
Thanks for reviewing my patches.
Please find my comments inline
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, March 13, 2014 8:56 PM
To: Gupta Suresh-B42813
Cc: ba...@ti.com; gre...@linuxfoundation.org;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Gupta
Suresh-B42813
Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
platform device id
On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
From: Suresh Gupta b42...@freescale.com
Add FSL USB Gadget entry in platform device id table
why this tab ?
[SuresH] I will remove it in next version.
Signed-off-by: Suresh Gupta b42...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index b7dea4e..35b20e6 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2654,6 +2654,8 @@ static const struct platform_device_id
fsl_udc_devtype[] = {
}, {
.name = imx-udc-mx51,
}, {
+ .name = fsl-usb2-udc,
why aren't you just using chipidea ?
[SuresH] This is our legacy driver for all previous and existing ppc
socs. Many of our customers are already using this, and we need to
support them on this driver. We do have plans to shift to chipidea,
but after some time.
cool, you already have plans, so we will see a new glue layer for v3.16
right ? Which means I don't need to take this patch either.
we do have plans, but in remote future. Right now, we need to support
customers on the present legacy driver. We'll phase out this driver
slowly when we integrate chipidea. At this time I would request you
to please accept this patch
Even if Felipe takes the patch, I'll reject it as you should be doing
the correct thing here, and if it's accepted, it will never be
changed...
greg k-h
--
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 v3 1/2] Staging: comedi: convert while loops to timeouts in s626.c
On Fri, Mar 14, 2014 at 06:43:37PM -0700, Chase Southwood wrote: > >On Tuesday, March 11, 2014 9:26 AM, Ian Abbott wrote: > > >>On 2014-03-09 04:00, Chase Southwood wrote: > >> This patch changes a handful of while loops to timeouts to prevent > >> infinite looping on hardware failure. A couple such loops are in a > >> function (s626_debi_transfer()) which is called from critical sections, > >> so comedi_timeout() is unusable for them, and an iterative timeout is > >> used instead. For the while loops in a context where comedi_timeout() is > >> allowed, a new callback function, s626_send_dac_eoc(), has been defined > >> to evaluate the conditions that the while loops are testing. The new > >> callback employs a switch statement based on a simple new enum so that > >> it is usable for all of the different conditions tested in while loops > >> in s626_send_dac(). The proper comedi_timeout() calls are then used. > >> > >> Signed-off-by: Chase Southwood > >> --- > >> Ian, here is a version of this patchset employing the enum you recommended. > >> The second patch has been rebased on top of this one. > >> > >> 2: Used comedi_timeout() where appropriate, introduce callback function > >> > >> 3: Updated callback to switch on new enum.> > > > >Reviewed-by: Ian Abbott > > > >For future reference, for patches affecting a single comedi driver, we > >usually title the patches like this: > > > >staging: comedi: name_of_driver: summary of patch > > > > > Hi Greg! > > I was just writing to inquire whether you were able to add this patch as well > as > PATCH 2/2 Propagate timeout errors in s626.c, to your queue in their current > state. > I had to resend this patch to you about a week ago because the subject line > got > a little messed up, which might have lead to a bit of confusion regarding the > 2 > patch series, and I wanted to check in to see whether you need me to do > anything > further. I've been on vacation this week and will dig through my huge patch queue next week. Then I will need another vacation... Give me a chance to catch up, I'll let you know if I have problems with them. thanks, greg k-h -- 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 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
On Fri, Mar 14, 2014 at 04:50:23PM +, Julien Grall wrote: > On 02/24/2014 08:49 PM, Stefano Stabellini wrote: > > On Mon, 24 Feb 2014, gre...@linuxfoundation.org wrote: > > Julien is proposing to store the list of "safe" devices on an hash table > > in the Xen specific code (in arch/arm/xen/enlighten.c, see > > http://marc.info/?l=linux-kernel=139291370526082=2). > > Whenever Linux is about to do DMA, we would check in the hashtable to > > figure out whether we need to go through the swiotlb or we can simply > > use the native dma_ops. > > > > Ian and I were thinking that it would be much easier and faster to have > > a "xen_safe_device" parameter in struct device and just check for that. > > It doesn't actually need to be in struct device, it could simply be a > > flag in struct device_dma_parameters as Ian was suggesting. > > > > Julien, could you please come up with a simple patch to demonstrate the > > concept? > > Hello Stefano and Greg, > > Sorry for the late answer. I wrote a simple patch which depend on patch #1. > Let me know if it's the right direction. I have no context here, care to start the patch series over? thanks, greg k-h -- 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 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
On Fri, Mar 14, 2014 at 04:50:23PM +, Julien Grall wrote: On 02/24/2014 08:49 PM, Stefano Stabellini wrote: On Mon, 24 Feb 2014, gre...@linuxfoundation.org wrote: Julien is proposing to store the list of safe devices on an hash table in the Xen specific code (in arch/arm/xen/enlighten.c, see http://marc.info/?l=linux-kernelm=139291370526082w=2). Whenever Linux is about to do DMA, we would check in the hashtable to figure out whether we need to go through the swiotlb or we can simply use the native dma_ops. Ian and I were thinking that it would be much easier and faster to have a xen_safe_device parameter in struct device and just check for that. It doesn't actually need to be in struct device, it could simply be a flag in struct device_dma_parameters as Ian was suggesting. Julien, could you please come up with a simple patch to demonstrate the concept? Hello Stefano and Greg, Sorry for the late answer. I wrote a simple patch which depend on patch #1. Let me know if it's the right direction. I have no context here, care to start the patch series over? thanks, greg k-h -- 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 v3 1/2] Staging: comedi: convert while loops to timeouts in s626.c
On Fri, Mar 14, 2014 at 06:43:37PM -0700, Chase Southwood wrote: On Tuesday, March 11, 2014 9:26 AM, Ian Abbott abbo...@mev.co.uk wrote: On 2014-03-09 04:00, Chase Southwood wrote: This patch changes a handful of while loops to timeouts to prevent infinite looping on hardware failure. A couple such loops are in a function (s626_debi_transfer()) which is called from critical sections, so comedi_timeout() is unusable for them, and an iterative timeout is used instead. For the while loops in a context where comedi_timeout() is allowed, a new callback function, s626_send_dac_eoc(), has been defined to evaluate the conditions that the while loops are testing. The new callback employs a switch statement based on a simple new enum so that it is usable for all of the different conditions tested in while loops in s626_send_dac(). The proper comedi_timeout() calls are then used. Signed-off-by: Chase Southwood chase.southw...@yahoo.com --- Ian, here is a version of this patchset employing the enum you recommended. The second patch has been rebased on top of this one. 2: Used comedi_timeout() where appropriate, introduce callback function 3: Updated callback to switch on new enum. Reviewed-by: Ian Abbott abbo...@mev.co.uk For future reference, for patches affecting a single comedi driver, we usually title the patches like this: staging: comedi: name_of_driver: summary of patch Hi Greg! I was just writing to inquire whether you were able to add this patch as well as PATCH 2/2 Propagate timeout errors in s626.c, to your queue in their current state. I had to resend this patch to you about a week ago because the subject line got a little messed up, which might have lead to a bit of confusion regarding the 2 patch series, and I wanted to check in to see whether you need me to do anything further. I've been on vacation this week and will dig through my huge patch queue next week. Then I will need another vacation... Give me a chance to catch up, I'll let you know if I have problems with them. thanks, greg k-h -- 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: [GIT PULL] PHY for 3.15
On Sun, Mar 09, 2014 at 11:15:46PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Pls find the updated PULL request. > > It contains new PHY drivers (SATA, USB) adapted to generic PHY framework > for a couple of platforms and a bunch of cleanups and fixes. The > Documentation problem with the old PULL request has been fixed in this. > > Pls let me know If I have to make any other changes. > > Thanks > Kishon > > The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: > >Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) > > are available in the git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > tags/for_3.15 > > for you to fetch changes up to 88e670fe9d240c751fd9735ae3ee2906ed68e63d: > >PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-09 > 12:45:13 +0530) > line-wrap :( Anyway, pulled and pushed out, thanks. greg k-h -- 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: [GIT PULL] PHY for 3.15
On Sun, Mar 09, 2014 at 11:15:46PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, Pls find the updated PULL request. It contains new PHY drivers (SATA, USB) adapted to generic PHY framework for a couple of platforms and a bunch of cleanups and fixes. The Documentation problem with the old PULL request has been fixed in this. Pls let me know If I have to make any other changes. Thanks Kishon The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git tags/for_3.15 for you to fetch changes up to 88e670fe9d240c751fd9735ae3ee2906ed68e63d: PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-09 12:45:13 +0530) line-wrap :( Anyway, pulled and pushed out, thanks. greg k-h -- 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] Staging: comedi: Fix line length exceeding 80 characters
On Tue, Feb 25, 2014 at 09:46:19AM +, Ian Abbott wrote: > On 2014-02-24 16:49, Monam Agarwal wrote: > > Signed-off-by: Monam Agarwal > > --- > > drivers/staging/comedi/comedi_fops.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/staging/comedi/comedi_fops.c > > b/drivers/staging/comedi/comedi_fops.c > > index ac1edd9..7da8566 100644 > > --- a/drivers/staging/comedi/comedi_fops.c > > +++ b/drivers/staging/comedi/comedi_fops.c > > @@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev, > > async->cmd.data = NULL; > > /* load channel/gain list */ > > async->cmd.chanlist = memdup_user(user_chanlist, > > - async->cmd.chanlist_len * > > sizeof(int)); > > + async->cmd.chanlist_len > > + * sizeof(int)); > > The `*` operator should go at the end of the line according to the > CodingStyle. Which is why I modified it by hand before applying it :) -- 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] Staging: comedi: Fix line length exceeding 80 characters
On Tue, Feb 25, 2014 at 09:46:19AM +, Ian Abbott wrote: On 2014-02-24 16:49, Monam Agarwal wrote: Signed-off-by: Monam Agarwal monamagarwal...@gmail.com --- drivers/staging/comedi/comedi_fops.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index ac1edd9..7da8566 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev, async-cmd.data = NULL; /* load channel/gain list */ async-cmd.chanlist = memdup_user(user_chanlist, - async-cmd.chanlist_len * sizeof(int)); + async-cmd.chanlist_len + * sizeof(int)); The `*` operator should go at the end of the line according to the CodingStyle. Which is why I modified it by hand before applying it :) -- 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 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
On Mon, Feb 24, 2014 at 12:19:11PM +, Stefano Stabellini wrote: > CC'ing Greg. > > On Thu, 20 Feb 2014, Ian Campbell wrote: > > On Thu, 2014-02-20 at 16:21 +, Julien Grall wrote: > > > Only Xen is able to know if a device can safely avoid to use xen-swiotlb. > > > This patch introduce a new property "protected-devices" for the hypervisor > > > node which list device which the IOMMU are been correctly programmed by > > > Xen. > > > > > > During Linux boot, Xen specific code will create an hash table which > > > contains all these devices. The hash table will be used in > > > need_xen_dma_ops > > > to check if the Xen DMA ops needs to be used for the current device. > > > > Is it out of the question to find a field within struct device itself to > > store this e.g. in struct device_dma_parameters perhaps and avoid the > > need for a hashtable lookup. > > > > device->iommu_group might be another option, if we can create our own > > group? > > I agree that a field in struct device would be ideal. > Greg, get_maintainer.pl points at you as main maintainer of device.h, do > you have an opinion on this? I need a whole lot more context here please. With a patch would be even better so that I know exactly what you are referring to... -- 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 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
On Mon, Feb 24, 2014 at 12:19:11PM +, Stefano Stabellini wrote: CC'ing Greg. On Thu, 20 Feb 2014, Ian Campbell wrote: On Thu, 2014-02-20 at 16:21 +, Julien Grall wrote: Only Xen is able to know if a device can safely avoid to use xen-swiotlb. This patch introduce a new property protected-devices for the hypervisor node which list device which the IOMMU are been correctly programmed by Xen. During Linux boot, Xen specific code will create an hash table which contains all these devices. The hash table will be used in need_xen_dma_ops to check if the Xen DMA ops needs to be used for the current device. Is it out of the question to find a field within struct device itself to store this e.g. in struct device_dma_parameters perhaps and avoid the need for a hashtable lookup. device-iommu_group might be another option, if we can create our own group? I agree that a field in struct device would be ideal. Greg, get_maintainer.pl points at you as main maintainer of device.h, do you have an opinion on this? I need a whole lot more context here please. With a patch would be even better so that I know exactly what you are referring to... -- 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 v2 0/2] generic CPU feature based udev module autoprobing
On Sun, Feb 16, 2014 at 06:11:27PM +0100, Ard Biesheuvel wrote: > On 16 February 2014 17:39, gre...@linuxfoundation.org > wrote: > > On Sun, Feb 16, 2014 at 03:40:04PM +0100, Ard Biesheuvel wrote: > >> Ping? > > > > Sorry, still digging out from the -rc1 backlog. Give me a few days, > > Monday is a holliday in the US. > > > > Yes, please, whenever you have some time. Both now applied to my tree. greg k-h -- 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 v2 0/2] generic CPU feature based udev module autoprobing
On Sun, Feb 16, 2014 at 06:11:27PM +0100, Ard Biesheuvel wrote: On 16 February 2014 17:39, gre...@linuxfoundation.org gre...@linuxfoundation.org wrote: On Sun, Feb 16, 2014 at 03:40:04PM +0100, Ard Biesheuvel wrote: Ping? Sorry, still digging out from the -rc1 backlog. Give me a few days, Monday is a holliday in the US. Yes, please, whenever you have some time. Both now applied to my tree. greg k-h -- 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 v2 0/2] generic CPU feature based udev module autoprobing
On Sun, Feb 16, 2014 at 03:40:04PM +0100, Ard Biesheuvel wrote: > Ping? Sorry, still digging out from the -rc1 backlog. Give me a few days, Monday is a holliday in the US. greg k-h -- 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 v2 0/2] generic CPU feature based udev module autoprobing
On Sun, Feb 16, 2014 at 03:40:04PM +0100, Ard Biesheuvel wrote: Ping? Sorry, still digging out from the -rc1 backlog. Give me a few days, Monday is a holliday in the US. greg k-h -- 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] firmware: give a protection when map page failed
On Wed, Jan 29, 2014 at 02:23:47AM +, Zhang, Jun wrote: > >From 9c23aedc1c1a1446dae96ffec8f20a2f52942281 Mon Sep 17 00:00:00 2001 > From: jzha144 > Date: Wed, 29 Jan 2014 09:57:05 +0800 > Subject: [PATCH] firmware: give a protection when map page failed What is that mess? Please don't make me hand-edit your patch, when dealing with patches that the scale we have to, that's not ok. Just use 'git send-email' and all should be fine. > > [ 7341.474236] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive > unpin_work! > [ 7341.494464] atomisp-css2400b0_v21 :00:03.0: unhandled css stored > event: 0x20 > [ 7341.503627] vmap allocation for size 208896 failed: use vmalloc= to > increase size.<=== map failed > [ 7341.507135] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive > unpin_work! > [ 7341.503848] BUG: unable to handle kernel NULL pointer dereference at > (null) > [ 7341.520394] IP: [] sst_load_all_modules_elf+0x1bb/0x850 > [ 7341.527216] *pdpt = 30dfe001 *pde = > [ 7341.533640] Oops: [#1] PREEMPT SMP > [ 7341.540360] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive > unpin_work! > [ 7341.538037] Modules linked in: atomisp_css2400b0_v21 lm3554 ov2722 imx1x5 > atmel_mxt_ts vxd392 videobuf_vmalloc videobuf_core lm_dump(O) bcm_bt_lpm > hdmi_audio bcm4334x(O) > [ 7341.563531] CPU: 1 PID: 525 Comm: mediaserver Tainted: GW O > 3.10.20-262518-ga83c053 #1 > [ 7341.573253] task: f0994ec0 ti: f09f task.ti: f09f > [ 7341.579284] EIP: 0060:[] EFLAGS: 00010246 CPU: 1 > [ 7341.585415] EIP is at sst_load_all_modules_elf+0x1bb/0x850 > [ 7341.591541] EAX: EBX: e3595ba0 ECX: EDX: 00031c1c > [ 7341.598541] ESI: e04a EDI: EBP: f09f1d80 ESP: f09f1cf4 > [ 7341.605542] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068 > [ 7341.611573] CR0: 80050033 CR2: CR3: 30db4000 CR4: 001007f0 > [ 7341.618573] DR0: DR1: DR2: DR3: > [ 7341.625575] DR6: 0ff0 DR7: 0400 > [ 7341.629856] Stack: > [ 7341.632097] f09f1d57 0019 c1d656d7 c1d658d3 c1d56409 0f28 > c1d64af9 18000103 > [ 7341.640766] 0101 0008 c1f910a0 f326f4c8 0034 f326f520 > 0002 e04a02bc > [ 7341.649465] 0001 f326e014 c1f910b0 e04a c0080100 00031c1c > e3595ba0 c0080100 > [ 7341.658149] Call Trace: > [ 7341.660888] [] sst_post_download_byt+0x58/0xb0 > [ 7341.666925] [] sst_load_fw+0xdc/0x510 > [ 7341.672086] [] ? __mutex_lock_slowpath+0x250/0x370 > [ 7341.678507] [] ? sub_preempt_count+0x55/0xe0 > [ 7341.684346] [] sst_download_fw+0x14/0x60 > [ 7341.689796] [] ? mutex_lock+0x23/0x30 > [ 7341.694954] [] intel_sst_check_device+0x6c/0x120 > [ 7341.701181] [] sst_set_generic_params+0x1b8/0x4a0 > [ 7341.707504] [] ? sub_preempt_count+0x55/0xe0 > [ 7341.713341] [] ? sub_preempt_count+0x55/0xe0 > [ 7341.719178] [] ? __mutex_lock_slowpath+0x250/0x370 > [ 7341.725600] [] ? __kmalloc_track_caller+0xe4/0x1d0 > [ 7341.732022] [] sst_set_mixer_param+0x25/0x40 > [ 7341.737859] [] lpe_mixer_ihf_set+0xb3/0x160 > [ 7341.743602] [] snd_ctl_ioctl+0xa89/0xb40 > [ 7341.749052] [] ? path_openat+0xa5/0x3d0 > [ 7341.754409] [] ? avc_has_perm_flags+0xc7/0x170 > [ 7341.760441] [] ? snd_ctl_elem_add_user+0x540/0x540 > [ 7341.766862] [] do_vfs_ioctl+0x77/0x5e0 > [ 7341.772117] [] ? inode_has_perm.isra.42.constprop.79+0x3a/0x50 > [ 7341.779705] [] ? file_has_perm+0xa0/0xb0 > [ 7341.785155] [] ? selinux_file_ioctl+0x48/0xe0 > [ 7341.791090] [] SyS_ioctl+0x78/0x90 > [ 7341.795958] [] syscall_call+0x7/0xb > [ 7341.800925] [] ? mm_fault_error+0x13c/0x198 All you do is include an oops here, which tells me nothing. > Signed-off-by: jzha144 I some how doubt this is really your name given that it differs from your "From:" line above. Intel has kernel developers who are very willing to look at patches from other Intel people, so that simple problems like this are fixed before annoying grumpy maintainers. Please use them. greg k-h -- 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] firmware: give a protection when map page failed
On Wed, Jan 29, 2014 at 02:23:47AM +, Zhang, Jun wrote: From 9c23aedc1c1a1446dae96ffec8f20a2f52942281 Mon Sep 17 00:00:00 2001 From: jzha144 jun.zh...@intel.com Date: Wed, 29 Jan 2014 09:57:05 +0800 Subject: [PATCH] firmware: give a protection when map page failed What is that mess? Please don't make me hand-edit your patch, when dealing with patches that the scale we have to, that's not ok. Just use 'git send-email' and all should be fine. [ 7341.474236] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work! [ 7341.494464] atomisp-css2400b0_v21 :00:03.0: unhandled css stored event: 0x20 [ 7341.503627] vmap allocation for size 208896 failed: use vmalloc=size to increase size.=== map failed [ 7341.507135] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work! [ 7341.503848] BUG: unable to handle kernel NULL pointer dereference at (null) [ 7341.520394] IP: [c18f5c1b] sst_load_all_modules_elf+0x1bb/0x850 [ 7341.527216] *pdpt = 30dfe001 *pde = [ 7341.533640] Oops: [#1] PREEMPT SMP [ 7341.540360] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work! [ 7341.538037] Modules linked in: atomisp_css2400b0_v21 lm3554 ov2722 imx1x5 atmel_mxt_ts vxd392 videobuf_vmalloc videobuf_core lm_dump(O) bcm_bt_lpm hdmi_audio bcm4334x(O) [ 7341.563531] CPU: 1 PID: 525 Comm: mediaserver Tainted: GW O 3.10.20-262518-ga83c053 #1 [ 7341.573253] task: f0994ec0 ti: f09f task.ti: f09f [ 7341.579284] EIP: 0060:[c18f5c1b] EFLAGS: 00010246 CPU: 1 [ 7341.585415] EIP is at sst_load_all_modules_elf+0x1bb/0x850 [ 7341.591541] EAX: EBX: e3595ba0 ECX: EDX: 00031c1c [ 7341.598541] ESI: e04a EDI: EBP: f09f1d80 ESP: f09f1cf4 [ 7341.605542] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068 [ 7341.611573] CR0: 80050033 CR2: CR3: 30db4000 CR4: 001007f0 [ 7341.618573] DR0: DR1: DR2: DR3: [ 7341.625575] DR6: 0ff0 DR7: 0400 [ 7341.629856] Stack: [ 7341.632097] f09f1d57 0019 c1d656d7 c1d658d3 c1d56409 0f28 c1d64af9 18000103 [ 7341.640766] 0101 0008 c1f910a0 f326f4c8 0034 f326f520 0002 e04a02bc [ 7341.649465] 0001 f326e014 c1f910b0 e04a c0080100 00031c1c e3595ba0 c0080100 [ 7341.658149] Call Trace: [ 7341.660888] [c18f6308] sst_post_download_byt+0x58/0xb0 [ 7341.666925] [c18f4fbc] sst_load_fw+0xdc/0x510 [ 7341.672086] [c1a7b2c0] ? __mutex_lock_slowpath+0x250/0x370 [ 7341.678507] [c1a80e05] ? sub_preempt_count+0x55/0xe0 [ 7341.684346] [c18f1294] sst_download_fw+0x14/0x60 [ 7341.689796] [c1a7b403] ? mutex_lock+0x23/0x30 [ 7341.694954] [c18f191c] intel_sst_check_device+0x6c/0x120 [ 7341.701181] [c18f1d08] sst_set_generic_params+0x1b8/0x4a0 [ 7341.707504] [c1a80e05] ? sub_preempt_count+0x55/0xe0 [ 7341.713341] [c1a80e05] ? sub_preempt_count+0x55/0xe0 [ 7341.719178] [c1a7b2c0] ? __mutex_lock_slowpath+0x250/0x370 [ 7341.725600] [c1320d84] ? __kmalloc_track_caller+0xe4/0x1d0 [ 7341.732022] [c18e35f5] sst_set_mixer_param+0x25/0x40 [ 7341.737859] [c18e3853] lpe_mixer_ihf_set+0xb3/0x160 [ 7341.743602] [c1855b99] snd_ctl_ioctl+0xa89/0xb40 [ 7341.749052] [c1331e65] ? path_openat+0xa5/0x3d0 [ 7341.754409] [c1447857] ? avc_has_perm_flags+0xc7/0x170 [ 7341.760441] [c1855110] ? snd_ctl_elem_add_user+0x540/0x540 [ 7341.766862] [c1334047] do_vfs_ioctl+0x77/0x5e0 [ 7341.772117] [c144842a] ? inode_has_perm.isra.42.constprop.79+0x3a/0x50 [ 7341.779705] [c14490a0] ? file_has_perm+0xa0/0xb0 [ 7341.785155] [c14493b8] ? selinux_file_ioctl+0x48/0xe0 [ 7341.791090] [c1334628] SyS_ioctl+0x78/0x90 [ 7341.795958] [c1a7dde8] syscall_call+0x7/0xb [ 7341.800925] [c1a7] ? mm_fault_error+0x13c/0x198 All you do is include an oops here, which tells me nothing. Signed-off-by: jzha144 jun.zh...@intel.com I some how doubt this is really your name given that it differs from your From: line above. Intel has kernel developers who are very willing to look at patches from other Intel people, so that simple problems like this are fixed before annoying grumpy maintainers. Please use them. greg k-h -- 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: hub: Avoid tight loop holding hdev lock
On Tue, Dec 31, 2013 at 02:26:41PM +0530, Manoj Chourasia wrote: > Hi All, > > I was facing an issue bad usb device which was affecting other system. Kernel > was trying to enumerate the device but it was failing continuously. > Unfortunately that device was on mounted onboard in the platform so I cannot > remove it. > The continuous re-enumeration of the device causing other application > malfunctioning which were using libusb. I found that usb_find_devices() call > was stuck in usb_open for very long time. It was stuck in getting device lock > which was taken in hub_event thread. > Solution was to add msleep in the loop to prevent is spinning tightly. > > --- > usb: hub: Avoid tight loop holding hdev lock > >Other system call(like usb_open) to root port device > starved in getting device lock when the while loop > in hub_event loops tightly because of misbehaving device. > > Adding a small msleep provides chance to system calls to > schedule. > > The issue was returning -EPROTO and re-enumerating with > continuous hub_events. That was makes the while loop in > hub_event to spin tightly. > > usb_find_devices call from libusb tries to open all devices > including root hub. The call to usb_open stuck for very > long time(sometimes forever) because the priority of > kernel thread is higher than that system call in this case. > > Signed-off-by: Manoj Chourasia Please don't make me hand-edit patches in order to be able to apply them. I don't scale at all, so if you want this applied, please resend it. Also, this isn't how you submit patches to the stable kernel tree, please read Documentation/stable_kernel_rules.txt for how to do that. > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index c5c3667..b968fd5 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -4899,6 +4899,9 @@ static void hub_events(void) > usb_unlock_device(hdev); > kref_put(>kref, hub_release); > > + /* preventing tight loop holding hdev lock */ > + msleep(20); This feels like a horrible hack for some seriously broken hardware. Now I know we work around broken hardware all the time, is this really the only way the system can recover? thanks, greg k-h -- 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: hub: Avoid tight loop holding hdev lock
On Tue, Dec 31, 2013 at 02:26:41PM +0530, Manoj Chourasia wrote: Hi All, I was facing an issue bad usb device which was affecting other system. Kernel was trying to enumerate the device but it was failing continuously. Unfortunately that device was on mounted onboard in the platform so I cannot remove it. The continuous re-enumeration of the device causing other application malfunctioning which were using libusb. I found that usb_find_devices() call was stuck in usb_open for very long time. It was stuck in getting device lock which was taken in hub_event thread. Solution was to add msleep in the loop to prevent is spinning tightly. --- usb: hub: Avoid tight loop holding hdev lock Other system call(like usb_open) to root port device starved in getting device lock when the while loop in hub_event loops tightly because of misbehaving device. Adding a small msleep provides chance to system calls to schedule. The issue was returning -EPROTO and re-enumerating with continuous hub_events. That was makes the while loop in hub_event to spin tightly. usb_find_devices call from libusb tries to open all devices including root hub. The call to usb_open stuck for very long time(sometimes forever) because the priority of kernel thread is higher than that system call in this case. Signed-off-by: Manoj Chourasia mchoura...@nvidia.com Please don't make me hand-edit patches in order to be able to apply them. I don't scale at all, so if you want this applied, please resend it. Also, this isn't how you submit patches to the stable kernel tree, please read Documentation/stable_kernel_rules.txt for how to do that. diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c5c3667..b968fd5 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4899,6 +4899,9 @@ static void hub_events(void) usb_unlock_device(hdev); kref_put(hub-kref, hub_release); + /* preventing tight loop holding hdev lock */ + msleep(20); This feels like a horrible hack for some seriously broken hardware. Now I know we work around broken hardware all the time, is this really the only way the system can recover? thanks, greg k-h -- 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 1/1] Drivers: hv: Implement the file copy service
On Thu, Jan 09, 2014 at 11:09:21PM +0300, Dan Carpenter wrote: > We've had this discussion before where you urge me to trust the host... > > Problem: This code is racy. > Solution: The host will only send one message at a time. > > Now I have to audit the user space code on the host and I don't feel > like doing that so you win. > > I wish we had a better way to do IPC. If kdbus were ready, that might > have worked for this, and it's a better solution because both sender and > reciever code will be written in a less trusting way. kdbus is almost ready, it might make 3.15, depending on the result of work that is happening at linux.conf.au and FOSDEM. If it would be a better solution for this, that's even more reason to get kdbus merged soon, no need to add something that doesn't really work. But, how will kdbus help with this? It's a userspace <-> userspace message transmission bus, would you want the kernel to be a receiver or sender here? thanks, greg k-h -- 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 1/1] Drivers: hv: Implement the file copy service
On Thu, Jan 09, 2014 at 11:09:21PM +0300, Dan Carpenter wrote: We've had this discussion before where you urge me to trust the host... Problem: This code is racy. Solution: The host will only send one message at a time. Now I have to audit the user space code on the host and I don't feel like doing that so you win. I wish we had a better way to do IPC. If kdbus were ready, that might have worked for this, and it's a better solution because both sender and reciever code will be written in a less trusting way. kdbus is almost ready, it might make 3.15, depending on the result of work that is happening at linux.conf.au and FOSDEM. If it would be a better solution for this, that's even more reason to get kdbus merged soon, no need to add something that doesn't really work. But, how will kdbus help with this? It's a userspace - userspace message transmission bus, would you want the kernel to be a receiver or sender here? thanks, greg k-h -- 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] Staging: TIDSPBRIDGE: Remove UUID helper
On Sat, Dec 07, 2013 at 10:41:36AM +0200, Ivajlo Dimitrov wrote: > > On 06.12.2013 17:10, gre...@linuxfoundation.org wrote: > > On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote: > >> Hi Greg, > >> > >> On 01.12.2013 19:07, Ivaylo DImitrov wrote: > >>> From: Ivaylo Dimitrov > >>> > >>> Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't > >>> need to be exported. It can also be made way simpler by using sscanf. > >>> > >>> Signed-off-by: Ivaylo Dimitrov > >>> --- > >>>drivers/staging/tidspbridge/Makefile |2 +- > >>>drivers/staging/tidspbridge/gen/uuidutil.c | 85 > >>> > >>>.../tidspbridge/include/dspbridge/uuidutil.h | 18 > >>>drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- > >>>4 files changed, 39 insertions(+), 108 deletions(-) > >>>delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c > >>> > >> I guess the initial mail somehow didn't make it through your spam filter: > >> https://lkml.org/lkml/2013/12/1/70 > > It did, but I thought that people asked for it to be changed in the > > thread afterwards, so I was expecting an updated version from you. > > > > Care to fix things up and resend it? > > > > thanks, > > > > greg k-h > > Sure, the change I was asked for is trivial, but I didn't get the reason > why it is needed. Neither there is a reply to my follow-up comment [0]. > Sorry, I am pretty much new on LKML and could miss things that are > supposed to be clear from the start, but my impression is that when > someone says "it is better", he/she should explain why it is better or > at least what is wrong with the patch he/she wants to be changed. > > However, I don't want to enter some arguing loop, so if you think I > should change the code as per Joe's comment, just confirm it and I'll do it. Please try. -- 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] Staging: TIDSPBRIDGE: Remove UUID helper
On Sat, Dec 07, 2013 at 10:41:36AM +0200, Ivajlo Dimitrov wrote: On 06.12.2013 17:10, gre...@linuxfoundation.org wrote: On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote: Hi Greg, On 01.12.2013 19:07, Ivaylo DImitrov wrote: From: Ivaylo Dimitrov freemangor...@abv.bg Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't need to be exported. It can also be made way simpler by using sscanf. Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg --- drivers/staging/tidspbridge/Makefile |2 +- drivers/staging/tidspbridge/gen/uuidutil.c | 85 .../tidspbridge/include/dspbridge/uuidutil.h | 18 drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- 4 files changed, 39 insertions(+), 108 deletions(-) delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c I guess the initial mail somehow didn't make it through your spam filter: https://lkml.org/lkml/2013/12/1/70 It did, but I thought that people asked for it to be changed in the thread afterwards, so I was expecting an updated version from you. Care to fix things up and resend it? thanks, greg k-h Sure, the change I was asked for is trivial, but I didn't get the reason why it is needed. Neither there is a reply to my follow-up comment [0]. Sorry, I am pretty much new on LKML and could miss things that are supposed to be clear from the start, but my impression is that when someone says it is better, he/she should explain why it is better or at least what is wrong with the patch he/she wants to be changed. However, I don't want to enter some arguing loop, so if you think I should change the code as per Joe's comment, just confirm it and I'll do it. Please try. -- 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] Staging: TIDSPBRIDGE: Remove UUID helper
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote: > Hi Greg, > > On 01.12.2013 19:07, Ivaylo DImitrov wrote: > > From: Ivaylo Dimitrov > > > > Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't > > need to be exported. It can also be made way simpler by using sscanf. > > > > Signed-off-by: Ivaylo Dimitrov > > --- > > drivers/staging/tidspbridge/Makefile |2 +- > > drivers/staging/tidspbridge/gen/uuidutil.c | 85 > > > > .../tidspbridge/include/dspbridge/uuidutil.h | 18 > > drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- > > 4 files changed, 39 insertions(+), 108 deletions(-) > > delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c > > > > I guess the initial mail somehow didn't make it through your spam filter: > https://lkml.org/lkml/2013/12/1/70 It did, but I thought that people asked for it to be changed in the thread afterwards, so I was expecting an updated version from you. Care to fix things up and resend it? thanks, greg k-h -- 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] Staging: TIDSPBRIDGE: Remove UUID helper
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote: Hi Greg, On 01.12.2013 19:07, Ivaylo DImitrov wrote: From: Ivaylo Dimitrov freemangor...@abv.bg Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't need to be exported. It can also be made way simpler by using sscanf. Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg --- drivers/staging/tidspbridge/Makefile |2 +- drivers/staging/tidspbridge/gen/uuidutil.c | 85 .../tidspbridge/include/dspbridge/uuidutil.h | 18 drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- 4 files changed, 39 insertions(+), 108 deletions(-) delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c I guess the initial mail somehow didn't make it through your spam filter: https://lkml.org/lkml/2013/12/1/70 It did, but I thought that people asked for it to be changed in the thread afterwards, so I was expecting an updated version from you. Care to fix things up and resend it? thanks, greg k-h -- 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: Add memory barrier when waiting on futex
On Mon, Nov 25, 2013 at 01:15:17PM +, Ma, Xindong wrote: > We encountered following panic several times: > [ 74.671982] BUG: unable to handle kernel NULL pointer dereference at > 0008 > [ 74.672101] IP: [] wake_futex+0x47/0x80 > [ 74.672185] *pdpt = 10108001 *pde = > [ 74.672278] Oops: 0002 [#1] PREEMPT SMP > [ 74.672403] Modules linked in: atomisp_css2400b0_v2 atomisp_css2400_v2 > dfrgx bcm_bt_lpm videobuf_vmalloc videobuf_core hdmi_audio tngdisp bcm4335 > kct_daemon(O) cfg80211 > [ 74.672815] CPU: 0 PID: 1477 Comm: zygote Tainted: GW O > 3.10.1-259934-g0bfb86e #1 > [ 74.672855] Hardware name: Intel Corporation Merrifield/SALT BAY, BIOS 404 > 2013.10.09:15.29.48 > [ 74.672894] task: d4c97220 ti: cfaa8000 task.ti: cfaa8000 > [ 74.672933] EIP: 0060:[] EFLAGS: 00210246 CPU: 0 > [ 74.672975] EIP is at wake_futex+0x47/0x80 > [ 74.673012] EAX: EBX: ECX: EDX: > [ 74.673049] ESI: def4de5c EDI: EBP: cfaa9eb4 ESP: cfaa9ea0 > [ 74.673086] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > [ 74.673123] CR0: 8005003b CR2: 0008 CR3: 10109000 CR4: 001007f0 > [ 74.673160] DR0: DR1: DR2: DR3: > [ 74.673196] DR6: 0ff0 DR7: 0400 > [ 74.673229] Stack: > [ 74.673260] 0001 def4de5c c225eb50 cfaa9ee4 > c129bc29 > [ 74.673536] 7fff c225eb30 b4f38000 ec1a4b40 0f90 > 7fff 0001 > [ 74.673814] b4f38f90 cfaa9f58 c129da0b cfaa9f10 > c195d835 0001 > [ 74.674092] Call Trace: > [ 74.674144] [] futex_wake+0xc9/0x110 > [ 74.674195] [] do_futex+0xeb/0x950 > [ 74.674246] [] ? sub_preempt_count+0x55/0xe0 > [ 74.674293] [] ? wake_up_new_task+0xee/0x190 > [ 74.674341] [] ? _raw_spin_unlock_irqrestore+0x3b/0x70 > [ 74.674388] [] ? wake_up_new_task+0xee/0x190 > [ 74.674436] [] ? do_fork+0xec/0x350 > [ 74.674484] [] SyS_futex+0x9b/0x140 > [ 74.674533] [] ? SyS_mprotect+0x188/0x1e0 > [ 74.674582] [] syscall_call+0x7/0xb > > On smp systems, setting current task to q->task in queue_me() may > not visible immediately to another cpu, some times this will > cause panic in wake_futex(). Adding memory barrier to avoid this. > > Signed-off-by: Leon Ma > Signed-off-by: xiaobing tu > --- > kernel/futex.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. -- 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: Add memory barrier when waiting on futex
On Mon, Nov 25, 2013 at 01:15:17PM +, Ma, Xindong wrote: We encountered following panic several times: [ 74.671982] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 74.672101] IP: [c129bb27] wake_futex+0x47/0x80 [ 74.672185] *pdpt = 10108001 *pde = [ 74.672278] Oops: 0002 [#1] PREEMPT SMP [ 74.672403] Modules linked in: atomisp_css2400b0_v2 atomisp_css2400_v2 dfrgx bcm_bt_lpm videobuf_vmalloc videobuf_core hdmi_audio tngdisp bcm4335 kct_daemon(O) cfg80211 [ 74.672815] CPU: 0 PID: 1477 Comm: zygote Tainted: GW O 3.10.1-259934-g0bfb86e #1 [ 74.672855] Hardware name: Intel Corporation Merrifield/SALT BAY, BIOS 404 2013.10.09:15.29.48 [ 74.672894] task: d4c97220 ti: cfaa8000 task.ti: cfaa8000 [ 74.672933] EIP: 0060:[c129bb27] EFLAGS: 00210246 CPU: 0 [ 74.672975] EIP is at wake_futex+0x47/0x80 [ 74.673012] EAX: EBX: ECX: EDX: [ 74.673049] ESI: def4de5c EDI: EBP: cfaa9eb4 ESP: cfaa9ea0 [ 74.673086] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 74.673123] CR0: 8005003b CR2: 0008 CR3: 10109000 CR4: 001007f0 [ 74.673160] DR0: DR1: DR2: DR3: [ 74.673196] DR6: 0ff0 DR7: 0400 [ 74.673229] Stack: [ 74.673260] 0001 def4de5c c225eb50 cfaa9ee4 c129bc29 [ 74.673536] 7fff c225eb30 b4f38000 ec1a4b40 0f90 7fff 0001 [ 74.673814] b4f38f90 cfaa9f58 c129da0b cfaa9f10 c195d835 0001 [ 74.674092] Call Trace: [ 74.674144] [c129bc29] futex_wake+0xc9/0x110 [ 74.674195] [c129da0b] do_futex+0xeb/0x950 [ 74.674246] [c195d835] ? sub_preempt_count+0x55/0xe0 [ 74.674293] [c1275aee] ? wake_up_new_task+0xee/0x190 [ 74.674341] [c195a31b] ? _raw_spin_unlock_irqrestore+0x3b/0x70 [ 74.674388] [c1275aee] ? wake_up_new_task+0xee/0x190 [ 74.674436] [c1241afc] ? do_fork+0xec/0x350 [ 74.674484] [c129e30b] SyS_futex+0x9b/0x140 [ 74.674533] [c1312298] ? SyS_mprotect+0x188/0x1e0 [ 74.674582] [c195a718] syscall_call+0x7/0xb On smp systems, setting current task to q-task in queue_me() may not visible immediately to another cpu, some times this will cause panic in wake_futex(). Adding memory barrier to avoid this. Signed-off-by: Leon Ma xindong...@intel.com Signed-off-by: xiaobing tu xiaobing...@intel.com --- kernel/futex.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- 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: [char-misc-next 0/3] mei: driver cleanups
On Mon, Nov 11, 2013 at 11:35:40AM +, Winkler, Tomas wrote: > > > > > > *** BLURB HERE *** > Oops, sorry for that. So, any hint for what these are for? I can't take patches until 3.13-rc1 is out, which will be a few weeks. But then, which should this be for, 3.13 as these are regression fixes, or 3.14 as they are only "cleanups"? thanks, greg k-h -- 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: [char-misc-next 0/3] mei: driver cleanups
On Mon, Nov 11, 2013 at 11:35:40AM +, Winkler, Tomas wrote: *** BLURB HERE *** Oops, sorry for that. So, any hint for what these are for? I can't take patches until 3.13-rc1 is out, which will be a few weeks. But then, which should this be for, 3.13 as these are regression fixes, or 3.14 as they are only cleanups? thanks, greg k-h -- 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: driver core patches
On Tue, Nov 05, 2013 at 10:53:36PM +, Stuart Yoder wrote: > Hi Greg, > > Any feedback on the driver core patches in Kim Phillips patch series > from mid-October? > > The 3rd patch of the series has some open issues related to vfio-pci, > but the first two are driver core related and am wondering if they > are acceptable. As I saw there was lots of discussion, and some rework needed, I haven't paid any attention to them, expecting to see another set show up. Also, it's way past the merge window, and I can't do anything with any new patches until after 3.13-rc1 is out, combined with a travel-schedule-from-hell, and I really am not going to want to review these types of patches for a number of weeks. So take the time, fix them up, and send them after 3.13-rc2 is out or so and I should have a chance to look at them then. Hopefully I'll hate them less by then, but I'm not guaranteeing anything... thanks, greg k-h -- 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: driver core patches
On Tue, Nov 05, 2013 at 10:53:36PM +, Stuart Yoder wrote: Hi Greg, Any feedback on the driver core patches in Kim Phillips patch series from mid-October? The 3rd patch of the series has some open issues related to vfio-pci, but the first two are driver core related and am wondering if they are acceptable. As I saw there was lots of discussion, and some rework needed, I haven't paid any attention to them, expecting to see another set show up. Also, it's way past the merge window, and I can't do anything with any new patches until after 3.13-rc1 is out, combined with a travel-schedule-from-hell, and I really am not going to want to review these types of patches for a number of weeks. So take the time, fix them up, and send them after 3.13-rc2 is out or so and I should have a chance to look at them then. Hopefully I'll hate them less by then, but I'm not guaranteeing anything... thanks, greg k-h -- 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 1/1] support new huawei devices in option.c
On Fri, Oct 11, 2013 at 03:48:21AM +, Fangxiaozhi (Franko) wrote:
> 1. Add new supporting declarations to option.c, to support Huawei new devices
> with new bInterfaceSubClass value.
> Signed-off-by: fangxiaozhi
In the future, can you use an email client that doesn't turn tabs into
spaces, so I don't have to edit the patch by hand?
Also:
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x01) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x02) },
That's a huge list of ids, is there any way we can just mark all of
these as used by the device in an easier manner?
I'll take this for now, but I have a feeling that this list is just
going to get worse over time, right?
thanks,
greg k-h
--
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 1/1] support new huawei devices in option.c
On Fri, Oct 11, 2013 at 03:48:21AM +, Fangxiaozhi (Franko) wrote:
1. Add new supporting declarations to option.c, to support Huawei new devices
with new bInterfaceSubClass value.
Signed-off-by: fangxiaozhi huana...@huawei.com
In the future, can you use an email client that doesn't turn tabs into
spaces, so I don't have to edit the patch by hand?
Also:
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x02) },
snip
That's a huge list of ids, is there any way we can just mark all of
these as used by the device in an easier manner?
I'll take this for now, but I have a feeling that this list is just
going to get worse over time, right?
thanks,
greg k-h
--
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: RFC: (re-)binding the VFIO platform driver to a platform device
On Wed, Oct 09, 2013 at 07:02:25PM +, Yoder Stuart-B08248 wrote:
> Have been thinking about this issue some more. As Scott mentioned,
> 'wildcard' matching for a driver can be fairly done in the platform
> bus driver. We could add a new flag to the platform driver struct:
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 4f8bef3..4d6cf14 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -727,6 +727,10 @@ static int platform_match(struct device *dev, struct
> device_driver *drv)
> struct platform_device *pdev = to_platform_device(dev);
> struct platform_driver *pdrv = to_platform_driver(drv);
>
> + /* the driver matches any device */
> + if (pdrv->match_any)
> + return 1;
> +
> /* Attempt an OF style match first */
> if (of_driver_match_device(dev, drv))
> return 1;
>
> However, the more problematic issue is that a bus driver has no way to
> differentiate from an explicit bind request via sysfs and a bind that
> happened through bus probing.
That was by design, nice to see I implemented it properly :)
> I think something like the new flag in the snippet below would enable the
> platform
> bus to support platform drivers that only bind on explicit request:
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 4c289ab..daf6d24 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -201,7 +201,7 @@ static ssize_t bind_store(struct device_driver *drv,
> const char *buf,
> int err = -ENODEV;
>
> dev = bus_find_device_by_name(bus, NULL, buf);
> - if (dev && dev->driver == NULL && driver_match_device(drv, dev)) {
> + if (dev && dev->driver == NULL && driver_match_device(drv, dev, 1)) {
Magic flags are the spawn of your favorite anti-$DIETY. I'm never going
to accept that, sorry.
If you really want to do something "special" for the platform bus, then
do it only for the platform bus. But even then, you'll find me arguing
that you really don't want to do it at all, sorry.
I'm still yet to be convinced this is even an issue at all, but maybe
that's just the jetlag talking...
greg k-h
--
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: RFC: (re-)binding the VFIO platform driver to a platform device
On Wed, Oct 09, 2013 at 07:02:25PM +, Yoder Stuart-B08248 wrote:
Have been thinking about this issue some more. As Scott mentioned,
'wildcard' matching for a driver can be fairly done in the platform
bus driver. We could add a new flag to the platform driver struct:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4f8bef3..4d6cf14 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -727,6 +727,10 @@ static int platform_match(struct device *dev, struct
device_driver *drv)
struct platform_device *pdev = to_platform_device(dev);
struct platform_driver *pdrv = to_platform_driver(drv);
+ /* the driver matches any device */
+ if (pdrv-match_any)
+ return 1;
+
/* Attempt an OF style match first */
if (of_driver_match_device(dev, drv))
return 1;
However, the more problematic issue is that a bus driver has no way to
differentiate from an explicit bind request via sysfs and a bind that
happened through bus probing.
That was by design, nice to see I implemented it properly :)
I think something like the new flag in the snippet below would enable the
platform
bus to support platform drivers that only bind on explicit request:
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 4c289ab..daf6d24 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -201,7 +201,7 @@ static ssize_t bind_store(struct device_driver *drv,
const char *buf,
int err = -ENODEV;
dev = bus_find_device_by_name(bus, NULL, buf);
- if (dev dev-driver == NULL driver_match_device(drv, dev)) {
+ if (dev dev-driver == NULL driver_match_device(drv, dev, 1)) {
Magic flags are the spawn of your favorite anti-$DIETY. I'm never going
to accept that, sorry.
If you really want to do something special for the platform bus, then
do it only for the platform bus. But even then, you'll find me arguing
that you really don't want to do it at all, sorry.
I'm still yet to be convinced this is even an issue at all, but maybe
that's just the jetlag talking...
greg k-h
--
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/
