Re: [PATCH] Add RIFFA PCIe driver to staging tree
On Tue, Oct 16, 2018 at 07:41:45AM +, Cheng Fei Phung wrote: > Patch changelog content: > > Add a PCIe linux driver called RIFFA to the linux staging tree. It has full > duplex capability compared to the original RIFFA linux driver that you can > easily find from https://github.com/KastnerRG/riffa/tree/master/driver/linux > > For more context, please refer to > https://github.com/promach/riffa/tree/full_duplex/driver/linux > > > > phung@UbuntuHW15:~/linux$ cat > patches/0001-Added-a-full-duplex-riffa-PCIe-linux-staging-driver..patch > >From 7c3050c7e86017d85c75c640ea38376f505b2763 Mon Sep 17 00:00:00 2001 > From: promach > Date: Mon, 15 Oct 2018 18:28:16 +0800 > Subject: [PATCH] Added a full duplex riffa PCIe linux staging driver. > Signed-off-by: PHUNG CHENG FEI (feiph...@hotmail.com) > This whole format is very odd. Please look at how other patches are posted to the list. I need a proper changelog and signed-off-by line in the correct place. Also, no need to 'cat' the file here, just use git send-email to send the patch correctly. Because of this, all of your tabs got converted to spaces, so the patch you sent here is corrupted. Try sending it to yourself first, run the result of that email through scripts/checkpatch.pl and apply it to the tree to verify that it really does work. Also, for staging drivers I need a TODO file that lists the remaining tasks that are left to be done in order to get the driver out of the staging portion of the kernel tree. Look at the patch that was sent today that added a new driver to the staging portion of the kernel as an example of how to do all of this correctly. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : Add RIFFA PCIe driver
On Tue, Oct 16, 2018 at 10:54:28AM +, Cheng Fei Phung wrote:
> This patch adds RIFFA PCIe linux driver for
> https://github.com/promach/riffa/tree/full_duplex/driver/linux
>
> TODO:
>
> 1) this driver needs further speed optimization although it can now achieve
> defined PCIe speed grade
> 2) solve all the coding style errors from scripts/checkpatch.pl
Can you please wrap your lines at 72 columns like your editor wanted you
to? :)
>
> Signed-off-by: PHUNG CHENG FEI (feiph...@hotmail.com)
So close, you need to use '<' and '>' here, not '(' and ')'
>
> ---
> Changes in v1:
> - added full-duplex capability
>
> drivers/staging/riffa/Makefile | 157 +++
> drivers/staging/riffa/README.txt | 38 +
> drivers/staging/riffa/circ_queue.c | 188 +++
> drivers/staging/riffa/circ_queue.h | 96 ++
> drivers/staging/riffa/riffa.c | 152 +++
> drivers/staging/riffa/riffa.h | 121 ++
> drivers/staging/riffa/riffa_driver.c | 1633 ++
> drivers/staging/riffa/riffa_driver.h | 131 +++
> 8 files changed, 2516 insertions(+)
> create mode 100644 drivers/staging/riffa/Makefile
> create mode 100644 drivers/staging/riffa/README.txt
> create mode 100644 drivers/staging/riffa/circ_queue.c
> create mode 100644 drivers/staging/riffa/circ_queue.h
> create mode 100644 drivers/staging/riffa/riffa.c
> create mode 100644 drivers/staging/riffa/riffa.h
> create mode 100644 drivers/staging/riffa/riffa_driver.c
> create mode 100644 drivers/staging/riffa/riffa_driver.h
This does not actually add the driver to the kernel build process at
all. How are you testing this? You need to hook it up by adding a
Kconfig file and touching the drivers/staging/Kconfig and
drivers/staging/Makefile files to add your code to the build system.
As it is, this doesn't work at all :(
And none of your code has any tabs in it at all. You should at least
fix that up first, otherwise the very first patch people are going to
be forced to send will be to replace all lines in all of these files
with that type of modification. It is better if you do that first.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
On Wed, Oct 31, 2018 at 11:23:54PM +, Dexuan Cui wrote:
> > From: Michael Kelley
> > Sent: Wednesday, October 24, 2018 08:38
> > From: k...@linuxonhyperv.com Sent: Wednesday,
> > October 17, 2018 10:10 PM
> > > From: Dexuan Cui
> > >
> > > In kvp_send_key(), we do need call process_ib_ipinfo() if
> > > message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
> > > the userland hv_kvp_daemon needs the info of operation, adapter_id and
> > > addr_family. With the incorrect fc62c3b1977d, the host can't get the
> > > VM's IP via KVP.
> > >
> > > And, fc62c3b1977d added a "break;", but actually forgot to initialize
> > > the key_size/value in the case of KVP_OP_SET, so the default key_size of
> > > 0 is passed to the kvp daemon, and the pool files
> > > /var/lib/hyperv/.kvp_pool_* can't be updated.
> > >
> > > This patch effectively rolls back the previous fc62c3b1977d, and
> > > correctly fixes the "this statement may fall through" warnings.
> > >
> > > This patch is tested on WS 2012 R2 and 2016.
> > >
> > > Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall
> > through" warnings")
> > > Signed-off-by: Dexuan Cui
> > > Cc: K. Y. Srinivasan
> > > Cc: Haiyang Zhang
> > > Cc: Stephen Hemminger
> > > Cc:
> > > Signed-off-by: K. Y. Srinivasan
> > > ---
> > > drivers/hv/hv_kvp.c | 26 ++
> > > 1 file changed, 22 insertions(+), 4 deletions(-)
> > >
> > Reviewed-by: Michael Kelley
>
> Hi Greg,
> Can you please take a look at this patch?
Nope, I'm not the hv maintainer, they need to look at this and ack it,
not me :)
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
On Thu, Nov 01, 2018 at 07:22:28PM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org
> > Sent: Thursday, November 1, 2018 11:57
> > To: Dexuan Cui
> >
> > On Wed, Oct 31, 2018 at 11:23:54PM +, Dexuan Cui wrote:
> > > > From: Michael Kelley
> > > > Sent: Wednesday, October 24, 2018 08:38
> > > > From: k...@linuxonhyperv.com Sent:
> > Wednesday,
> > > > October 17, 2018 10:10 PM
> > > > > From: Dexuan Cui
> > > > >
> > > > > In kvp_send_key(), we do need call process_ib_ipinfo() if
> > > > > message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns
> > out
> > > > > the userland hv_kvp_daemon needs the info of operation, adapter_id
> > and
> > > > > addr_family. With the incorrect fc62c3b1977d, the host can't get the
> > > > > VM's IP via KVP.
> > > > >
> > > > > And, fc62c3b1977d added a "break;", but actually forgot to initialize
> > > > > the key_size/value in the case of KVP_OP_SET, so the default key_size
> > > > > of
> > > > > 0 is passed to the kvp daemon, and the pool files
> > > > > /var/lib/hyperv/.kvp_pool_* can't be updated.
> > > > >
> > > > > This patch effectively rolls back the previous fc62c3b1977d, and
> > > > > correctly fixes the "this statement may fall through" warnings.
> > > > >
> > > > > This patch is tested on WS 2012 R2 and 2016.
> > > > >
> > > > > Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may
> > > > > fall
> > > > through" warnings")
> > > > > Signed-off-by: Dexuan Cui
> > > > > Cc: K. Y. Srinivasan
> > > > > Cc: Haiyang Zhang
> > > > > Cc: Stephen Hemminger
> > > > > Cc:
> > > > > Signed-off-by: K. Y. Srinivasan
> > > > > ---
> > > > > drivers/hv/hv_kvp.c | 26 ++
> > > > > 1 file changed, 22 insertions(+), 4 deletions(-)
> > > > >
> > > > Reviewed-by: Michael Kelley
> > >
> > > Hi Greg,
> > > Can you please take a look at this patch?
> >
> > Nope, I'm not the hv maintainer, they need to look at this and ack it,
> > not me :)
> >
> > greg k-h
>
> Hi Greg,
> KY has added his Signed-off-by in the mail.
>
> I'll ask the other HV maintainers to take a look as well.
Ok, then I'll look at it after 4.20-rc1 is out, nothing I can do until
then anyway...
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : Add RIFFA PCIe driver
On Mon, Oct 22, 2018 at 03:41:05AM +, Cheng Fei Phung wrote:
> This patch adds RIFFA PCIe linux driver for
> https://github.com/promach/riffa/tree/full_duplex/driver/linux
> This staging driver is modified from this upstream driver at
> https://github.com/KastnerRG/riffa/tree/master/driver/linux
Please properly line-wrap your changelog text at 72 columns when you
can.
>
> Signed-off-by: PHUNG CHENG FEI
No need to put your name in ALL CAPS. It should also match your from:
line in the email header, which it does not here.
There's lots to fix up in this code, and normally that is fine, but I
can't take the driver right now because of these lines:
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0)
> +static DEFINE_PCI_DEVICE_TABLE(fpga_ids) =
> +#else
> +static const struct pci_device_id fpga_ids[] =
> +#endif
> + {
> + { PCI_DEVICE(VENDOR_ID0, PCI_ANY_ID) },
> + { PCI_DEVICE(VENDOR_ID1, PCI_ANY_ID) },
> + { 0 },
> + };
> +
> +MODULE_DEVICE_TABLE(pci, fpga_ids);
You are grabbing ALL pci devices from these two vendors (Xilinx and
Altera). That will instantly break any of the existing kernel drivers
for any random device from those vendors by having this driver bind to
the device instead. And that's not ok, you can not break working
systems, sorry.
Please be very specific and only have the driver bind to the correct
hardware devices.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
On Sun, Nov 11, 2018 at 04:18:03AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org
> > Sent: Thursday, November 1, 2018 21:54
> > To: Dexuan Cui
> > Cc: Michael Kelley ; KY Srinivasan
> > ; linux-ker...@vger.kernel.org;
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > jasow...@redhat.com; Stephen Hemminger ;
> > vkuznets ; Sasha Levin
> > ; Haiyang Zhang ;
> > sta...@vger.kernel.org
> > Subject: Re: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression
> > caused
> > by incorrect clean-up
> >
> > On Thu, Nov 01, 2018 at 07:22:28PM +, Dexuan Cui wrote:
> > > > From: gre...@linuxfoundation.org
> > > > Sent: Thursday, November 1, 2018 11:57
> > > > To: Dexuan Cui
> > > >
> > > > On Wed, Oct 31, 2018 at 11:23:54PM +, Dexuan Cui wrote:
> > > > > > From: Michael Kelley
> > > > > > Sent: Wednesday, October 24, 2018 08:38
> > > > > > From: k...@linuxonhyperv.com Sent:
> > > > Wednesday,
> > > > > > October 17, 2018 10:10 PM
> > > > > > > From: Dexuan Cui
> > > > > > >
> > > > > > > In kvp_send_key(), we do need call process_ib_ipinfo() if
> > > > > > > message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it
> > turns
> > > > out
> > > > > > > the userland hv_kvp_daemon needs the info of operation, adapter_id
> > > > and
> > > > > > > addr_family. With the incorrect fc62c3b1977d, the host can't get
> > > > > > > the
> > > > > > > VM's IP via KVP.
> > > > > > >
> > > > > > > And, fc62c3b1977d added a "break;", but actually forgot to
> > > > > > > initialize
> > > > > > > the key_size/value in the case of KVP_OP_SET, so the default
> > > > > > > key_size
> > of
> > > > > > > 0 is passed to the kvp daemon, and the pool files
> > > > > > > /var/lib/hyperv/.kvp_pool_* can't be updated.
> > > > > > >
> > > > > > > This patch effectively rolls back the previous fc62c3b1977d, and
> > > > > > > correctly fixes the "this statement may fall through" warnings.
> > > > > > >
> > > > > > > This patch is tested on WS 2012 R2 and 2016.
> > > > > > >
> > > > > > > Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement
> > > > > > > may
> > fall
> > > > > > through" warnings")
> > > > > > > Signed-off-by: Dexuan Cui
> > > > > > > Cc: K. Y. Srinivasan
> > > > > > > Cc: Haiyang Zhang
> > > > > > > Cc: Stephen Hemminger
> > > > > > > Cc:
> > > > > > > Signed-off-by: K. Y. Srinivasan
> > > > > > > ---
> > > > > > > drivers/hv/hv_kvp.c | 26 ++
> > > > > > > 1 file changed, 22 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > Reviewed-by: Michael Kelley
> > > > >
> > > > > Hi Greg,
> > > > > Can you please take a look at this patch?
> > > >
> > > > Nope, I'm not the hv maintainer, they need to look at this and ack it,
> > > > not me :)
> > > >
> > > > greg k-h
> > >
> > > Hi Greg,
> > > KY has added his Signed-off-by in the mail.
> > >
> > > I'll ask the other HV maintainers to take a look as well.
> >
> > Ok, then I'll look at it after 4.20-rc1 is out, nothing I can do until
> > then anyway...
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
> Can you please take a look at the patch now?
It's in my queue, sorry, it's big right now due to travel...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vc04_services: bcm2835-audio: Fixed warnings
On Mon, Nov 12, 2018 at 07:00:20PM -0500, Arnold Chand wrote: > Fixed warnings provided by checkpatch.pl Please be much more specific as to what you changed or "fixed". Please fix this up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vc04_services: bcm2835-audio: Fixed warnings, checks
On Mon, Nov 12, 2018 at 07:29:09PM -0500, Arnold Chand wrote:
> Corrected warnings and checks issued by scripts/checkpatch.pl which includes:
> alignment of
> parenthesis, lines over 80 characters and mutex definition without comment.
> Signed-off-by: Arnold Chand ---
> .../vc04_services/bcm2835-audio/bcm2835-ctl.c | 18 +++---
> .../vc04_services/bcm2835-audio/bcm2835-pcm.c | 25 .../bcm2835-
> audio/bcm2835-vchiq.c | 59 ++-
> .../vc04_services/bcm2835-audio/bcm2835.h | 4 +- 4 files changed, 56
> insertions(+), 50 deletions(-)
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.cindex
> a6ec72a5f0be..04df4e7a1d24 100644--- a/drivers/staging/vc04_services/bcm2835-
> audio/bcm2835-ctl.c+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-
> ctl.c@@ -68,7 +68,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol
> *kcontrol, } static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,-
> struct snd_ctl_elem_value *ucontrol)+
>struct snd_ctl_elem_value *ucontrol) { struct bcm2835_chip
> *chip =
> snd_kcontrol_chip(kcontrol); int val, *valp;@@ -101,7 +101,8 @@ static const
> struct snd_kcontrol_new snd_bcm2835_ctl[] = { { .iface =
> SNDRV_CTL_ELEM_IFACE_MIXER, .name = "PCM Playback Volume",-
> .access = SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_TLV_READ,+
> .access = SNDRV_CTL_ELEM_ACCESS_READWRITE |+ SNDRV
> _CTL_ELEM_ACCESS_TLV_READ,.private_value = PCM_PLAYBACK_VOLUME,
> .info = snd_bcm2835_ctl_info, .get = snd_bcm2835_ctl_get,@@
> -129,7 +130,7 @@ static const struct snd_kcontrol_new snd_bcm2835_ctl[] = {
> }; static int snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol,-
> struct snd_ctl_elem_info *uinfo)+ struc
> t snd_ctl_elem_info *uinfo) { uinfo->type =
> SNDRV_CTL_ELEM_TYPE_IEC958;
> uinfo->count = 1;@@ -137,7 +138,7 @@ static int
> snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol, } static int
> snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol,- struct
> snd_ctl_elem_value *ucontrol)+ struct
> snd_ctl_elem_value *ucontrol) { struct bcm2835_chip *chip =
> snd_kcontrol_chip(kcontrol); int i;@@ -153,7 +154,7 @@ static int
> snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol, } static int
> snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol,- struct
> snd_ctl_elem_value *ucontrol)+ struct
> snd_ctl_elem_value *ucontrol) { struct bcm2835_chip *chip =
> snd_kcontrol_chip(kcontrol); unsigned int val = 0;@@ -162,7 +163,8 @@ static
> int snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol, mutex_l
> ock(&chip->audio_mutex); for (i = 0; i < 4; i++)-val |=
> (unsigned int)ucontrol->value.iec958.status[i] << (i * 8);+ val |=
> (unsigned int)ucontrol->value.iec958.status[i] <<+ (i *
> 8); change = val != chip->spdif_status; chip->spdif_status = val;@@
> -172,7 +174,7 @@ static int snd_bcm2835_spdif_default_put(struct snd_kcontrol
> *kcontrol, } static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol
> *kcontrol,- struct snd_ctl_elem_info *uinfo)+
>struct snd_ctl_elem_info *uinfo) { uinfo->type =
> SNDRV_CTL_ELEM_TYPE_IEC958; uinfo->count = 1;@@ -180,7 +182,7 @@ static int
> snd_bcm2835_spdif_mask_info(struct snd_kcontrol *kcontrol, } static int
> snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,-struct
> snd_ctl_elem_value *ucontrol)+ struct
> snd_ctl_elem_value *ucontrol) { /* * bcm2835 supports only
> consumer mode and sets all other format flagsdiff --git
> a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.cindex
> e66da11af5cf..68766e57f6e2 100644--- a/drivers/staging/vc04_services/bcm2835-
> audio/bcm2835-pcm.c+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-
> pcm.c@@ -81,17 +81,17 @@ void bcm2835_playback_fifo(struct bcm2835_alsa_stream
> *alsa_stream, } /* open callback */-static int
Something went really wrong with your email client here :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: vc04_services: bcm2835-audio: Fixed warnings, checks
On Mon, Nov 12, 2018 at 07:45:00PM -0500, Arnold Chand wrote: > Corrected warnings and checks provided by scripts/checkpatch.pl which > includes: alignment of parenthesis, lines over 80 characters and mutex > definition without comment. > > Signed-off-by: Arnold Chand > --- > .../vc04_services/bcm2835-audio/bcm2835-ctl.c | 18 +++--- > .../vc04_services/bcm2835-audio/bcm2835-pcm.c | 25 > .../bcm2835-audio/bcm2835-vchiq.c | 59 ++- > .../vc04_services/bcm2835-audio/bcm2835.h | 4 +- > 4 files changed, 56 insertions(+), 50 deletions(-) What changed from v1? Always put that below the --- line. v3? :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V4] binder: ipc namespace support for android binder
On Thu, Nov 15, 2018 at 02:33:49PM -0800, Andrew Morton wrote: > On Mon, 12 Nov 2018 09:37:51 + chouryzhou(周威) > wrote: > > > Currently android's binder is not isolated by ipc namespace. Since binder > > is a form of IPC and therefore should be tied to ipc namespace. With this > > patch, we can run multiple instances of android container on one host. > > > > This patch move "binder_procs" and "binder_context" into ipc_namespace, > > driver will find the context from it when opening. For debugfs, binder_proc > > is namespace-aware, but not for binder dead nodes, binder_stats and > > binder_transaction_log_entry (we added ipc inum to trace it). > > > > ... > > > > drivers/android/binder.c | 133 > > -- > > include/linux/ipc_namespace.h | 15 + > > ipc/namespace.c | 10 +++- > > 3 files changed, 125 insertions(+), 33 deletions(-) > > Well, it's mainly an android patch so I suggest this be taken via the > android tree. > > Acked-by: Andrew Morton > A number of us have talked about this in the plumbers Android track, and a different proposal for how to solve this has been made that should be much more resiliant. So I will drop this patch from my queue and wait for the patches based on the discussions we had there. I think there's some notes/slides on the discussion online somewhere, but it hasn't been published as the conference is still happening, otherwise I would link to it here... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : Add RIFFA PCIe driver
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://daringfireball.net/2007/07/on_top On Sun, Nov 18, 2018 at 01:46:52PM +, Cheng Fei Phung wrote: > Hi, > > if I only have one particular hardware (Altera DE4 FPGA) that I could test > with (there are a bunch of hardware boards that RIFFA supports as you can see > from https://github.com/KastnerRG/riffa/blob/master/fpga/altera/Makefile#L42 > and > https://github.com/KastnerRG/riffa/blob/master/fpga/xilinx/Makefile#L42-L43 > ), what could I do in this case ? Just use the board you can test with for now, let others add their device ids as they test. > I do not understand what you exactly mean by "72 columns" ? Your email was written all in one line, as above, and you did not wrap your columns at 72 characters. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: Fix off-by-one in core/rtw_mlme_ext.c
On Tue, Nov 27, 2018 at 07:29:07AM +, Yang Xiao wrote: > From: Young_X Please use your "full" name like you did in your from: line of your email > > The error at line 3267 was the result of an off-by-one error in > a for loop in line 3253. > If condition in line 3254 never satisfies, then the value of > pstat->aid is NUM_STA+1. This will lead to out-of-bound access > in line 3267. Why is this indented? No need for that. Can you fix that up and resend? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Thu, Nov 29, 2018 at 04:36:43AM +, Dexuan Cui wrote:
>
> vmbus_process_offer() mustn't call channel->sc_creation_callback()
> directly for sub-channels, because sc_creation_callback() ->
> vmbus_open() may never get the host's response to the
> OPEN_CHANNEL message (the host may rescind a channel at any time,
> e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
> may not wake up the vmbus_open() as it's blocked due to a non-zero
> vmbus_connection.offer_in_progress, and finally we have a deadlock.
>
> The above is also true for primary channels, if the related device
> drivers use sync probing mode by default.
>
> And, usually the handling of primary channels and sub-channels can
> depend on each other, so we should offload them to different
> workqueues to avoid possible deadlock, e.g. in sync-probing mode,
> NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
> rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
> and waits for all the sub-channels to appear, but the latter
> can't get the rtnl_lock and this blocks the handling of sub-channels.
>
> The patch can fix the multiple-NIC deadlock described above for
> v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
> of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
> but don't enable async-probing for Hyper-V drivers (yet).
>
> The patch can also fix the hang issue in sub-channel's handling described
> above for all versions of kernels, including v4.19 and v4.20-rc4.
>
> So, actually the patch should be applied to all the existing kernels,
> not only the kernels that have 8195b1396ec8.
>
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Cc: sta...@vger.kernel.org
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Signed-off-by: Dexuan Cui
> Signed-off-by: K. Y. Srinivasan
> ---
>
> There is no change in this repost. I just rebased this patch to today's
> char-misc's char-misc-next branch. Previously KY posted the patch with his
> Signed-off-by (which is kept in this repost), but there was a conflict issue.
>
> Note: the patch can't be cleanly applied to char-misc's char-misc-linus
> branch --
> to do that, we need to cherry-pick the supporting patch first:
> 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> vmbus_get_outgoing_channel()")
That is not going to work for the obvious reason that this dependant
patch is not going to be merged into 4.20-final.
So, what do you expect us to do here? The only way this can be accepted
is to have it go into my -next branch, which means it will show up in
4.21-rc1, is that ok?
But then, if that happens, it will fail to apply to any stable tree for
4.20 and older, like you are asking it to be done for.
So what do you expect me to do here with this?
totally confused,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : Add RIFFA PCIe driver
On Tue, Nov 27, 2018 at 05:59:48AM +, Cheng Fei Phung wrote: > This patch adds RIFFA PCIe linux driver for > https://github.com/promach/riffa/tree/full_duplex/driver/linux > > This staging driver is modified from this upstream driver at > https://github.com/KastnerRG/riffa/tree/master/driver/linux > > For further details, please refer to > https://github.com/KastnerRG/riffa/pull/31 > > Signed-off-by: Cheng Fei Phung > > --- > Changes in v1: > - added full-duplex capability > > drivers/staging/riffa/Kconfig|5 + > drivers/staging/riffa/Makefile |1 + > drivers/staging/riffa/TODO |7 + > drivers/staging/riffa/circ_queue.c | 188 +++ > drivers/staging/riffa/circ_queue.h | 96 ++ > drivers/staging/riffa/riffa.c| 152 +++ > drivers/staging/riffa/riffa.h| 121 ++ > drivers/staging/riffa/riffa_driver.c | 1643 ++ > drivers/staging/riffa/riffa_driver.h | 131 ++ > 9 files changed, 2344 insertions(+) > create mode 100644 drivers/staging/riffa/Kconfig > create mode 100644 drivers/staging/riffa/Makefile > create mode 100644 drivers/staging/riffa/TODO > create mode 100644 drivers/staging/riffa/circ_queue.c > create mode 100644 drivers/staging/riffa/circ_queue.h > create mode 100644 drivers/staging/riffa/riffa.c > create mode 100644 drivers/staging/riffa/riffa.h > create mode 100644 drivers/staging/riffa/riffa_driver.c > create mode 100644 drivers/staging/riffa/riffa_driver.h > > diff --git a/drivers/staging/riffa/Kconfig b/drivers/staging/riffa/Kconfig > new file mode 100644 > index ..afe5beee1882 > --- /dev/null > +++ b/drivers/staging/riffa/Kconfig > @@ -0,0 +1,5 @@ > +config RIFFA_PCIE > +tristate "a simple framework for communicating data from a host CPU to a > FPGA via a PCI Express bus" > +default n n is always the default, no need to put it :) Also, you have no dependancies at all? Not even PCI? I think PCI is needed here or the build will blow up on non-pci systems, right? And please use tabs in this file. > +help > +Transfers data with full duplex capability using PCIe protocol > diff --git a/drivers/staging/riffa/Makefile b/drivers/staging/riffa/Makefile > new file mode 100644 > index ..79ef3b9b8c8f > --- /dev/null > +++ b/drivers/staging/riffa/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_RIFFA) += riffa.o circ_queue.o riffa_driver.o riffa_mod.o > diff --git a/drivers/staging/riffa/TODO b/drivers/staging/riffa/TODO > new file mode 100644 > index ..5f1b0287cb52 > --- /dev/null > +++ b/drivers/staging/riffa/TODO > @@ -0,0 +1,7 @@ > +TODO: > +- optimize the driver code for further speed improvement although it can now > achieve defined PCIe speed grade > +- solve all the coding style errors from scripts/checkpatch.pl > +- add vendor and device IDs for more supported devices after actual hardware > testing > + > +Please send any patches to Greg Kroah-Hartman > +and Phung Cheng Fei > diff --git a/drivers/staging/riffa/circ_queue.c > b/drivers/staging/riffa/circ_queue.c > new file mode 100644 > index ..fb43ca22e3c0 > --- /dev/null > +++ b/drivers/staging/riffa/circ_queue.c > @@ -0,0 +1,188 @@ > +// -- > +// Copyright (c) 2016, The Regents of the University of California All > +// rights reserved. > +// > +// Redistribution and use in source and binary forms, with or without > +// modification, are permitted provided that the following conditions are > +// met: > +// > +// * Redistributions of source code must retain the above copyright > +// notice, this list of conditions and the following disclaimer. > +// > +// * Redistributions in binary form must reproduce the above > +// copyright notice, this list of conditions and the following > +// disclaimer in the documentation and/or other materials provided > +// with the distribution. > +// > +// * Neither the name of The Regents of the University of California > +// nor the names of its contributors may be used to endorse or > +// promote products derived from this software without specific > +// prior written permission. > +// > +// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > +// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > +// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > +// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL REGENTS OF THE > +// UNIVERSITY OF CALIFORNIA BE LIABLE FOR ANY DIRECT, INDIRECT, > +// INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, > +// BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS > +// OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND > +// ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR > +// TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Fri, Nov 30, 2018 at 06:09:54PM +, Dexuan Cui wrote:
> > From: KY Srinivasan
> > Sent: Friday, November 30, 2018 9:31 AM
> > > From: Dexuan Cui
> > > Sent: Thursday, November 29, 2018 12:17 AM
> > > To: gre...@linuxfoundation.org
> > > Cc: KY Srinivasan ; Haiyang Zhang
> > > ; Stephen Hemminger
> > > ; linux-ker...@vger.kernel.org;
> > > de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> > > ; o...@aepfle.de; jasow...@redhat.com; Michael
> > > Kelley
> > > Subject: RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of
> > > channels to two workqueues
> > >
> > > > From: gre...@linuxfoundation.org
> > > > Sent: Wednesday, November 28, 2018 11:45 PM
> > > > >
> > > > > There is no change in this repost. I just rebased this patch to
> > > > > today's
> > > > > char-misc's char-misc-next branch. Previously KY posted the patch with
> > > his
> > > > > Signed-off-by (which is kept in this repost), but there was a
> > > > > conflict issue.
> > > > >
> > > > > Note: the patch can't be cleanly applied to char-misc's
> > > > > char-misc-linus
> > > branch
> > > > --
> > > > > to do that, we need to cherry-pick the supporting patch first:
> > > > > 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> > > > vmbus_get_outgoing_channel()")
> > > >
> > > > That is not going to work for the obvious reason that this dependant
> > > > patch is not going to be merged into 4.20-final.
> > >
> > > It looks the dependent patch (4d3c5c69191f) is going to miss the v4.20
> > > release.
> > > This is not a big issue, as the dependent patch isn't really important.
> > >
> > > > So, what do you expect us to do here? The only way this can be accepted
> > > > is to have it go into my -next branch, which means it will show up in
> > > > 4.21-rc1, is that ok?
> > >
> > > Is there any chance for this patch ("Drivers: hv: vmbus: Offload the
> > > handling
> > > ...") to
> > > go into v4.20?
> > >
> > > If yes, I can quickly do a rebase to char-misc's char-misc-linus branch,
> > > because actually the conflict can be very easily fixed. And I can help to
> > > fix any
> > > conflict when the dependent patch is backported to v4.20.1.
> >
> > This patch fixes an important bug while the patch this depends on is not
> > critical.
> > I suggest we revert the patch that this patch depends on
> > and we can submit a new version of this patch that can go in now - into 4.20
> > release.
> >
> > K. Y
>
> I agree.
>
> Hi Greg,
> Please let us know what we can do to try to push this important fix into
> v4.20.
>
> Actually it's straightforward, though it looks big. And, we ave done a full
> testing
> with the patch.
Ok, you all need to figure this out on your own, sorry. Please give me
a patch that I can actually apply to the tree if you need it merged into
4.20-final. This shouldn't be tough, you all have been doing this long
enough by now...
I have no bandwidth to do this myself for you,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Sun, Dec 02, 2018 at 08:47:03AM +, Dexuan Cui wrote: > Hi Greg, > Please use the attached patch: I rebased the patch to today's char-misc's > char-misc-linus branch. It can also cleanly apply to Linus's master branch > today. I can't use an attached patch, you know better. Please fix up and resend properly. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : Add RIFFA PCIe staging driver
On Tue, Dec 04, 2018 at 02:19:38AM +, Cheng Fei Phung wrote:
> This patch adds RIFFA PCIe linux driver for
> https://github.com/promach/riffa/tree/full_duplex/driver/linux
>
> This staging driver is modified from this upstream driver at
> https://github.com/KastnerRG/riffa/tree/master/driver/linux
Please properly wrap your changelog text at 72 columns
> For further details, please refer to
> https://github.com/KastnerRG/riffa/pull/31
That is not permanent, please provide the details here.
> Signed-off-by: Cheng Fei Phung
>
> ---
> Changes in v1:
> - added full-duplex capability
And ignored everything else I asked about? That's not nice to reviewers
at all. Please at least comment on things that have been asked about,
otherwise why would anyone want to review this?
Also, is this "v2"? You didn't say so in your subject line.
Please fix this all up and submit a v3, after at least commenting on the
things asked previously.
Also, you still have this line which prevents me from being able to
accept this patch, as I talked about previously:
> + {PCI_DEVICE(VENDOR_ID1, PCI_ANY_ID)},
Do NOT just bind to all PCI devices from a vendor, that will break other
drivers in the system.
Also, do not use a random MAJOR number that you just picked out of no
where, that too will break working systems and needs to be fixed. Use
the dynamic allocation method, or better yet, just use a misc device.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] v2 Staging : Add RIFFA PCIe staging driver
On Tue, Dec 04, 2018 at 08:13:10AM +, Cheng Fei Phung wrote:
>
> > For further details, please refer to
> > https://github.com/KastnerRG/riffa/pull/31
> > That is not permanent, please provide the details here.
>
> This patch helps to enable bi-directional PCIe communication at PCIe gen2
> speed grade
> Major change in this patch is the enabling of chnl_recv() scatter-gather list
> first in the case of loopback,
> as you can see in
> https://github.com/promach/riffa/blob/full_duplex/driver/linux/riffa_driver.c#L832-L836
>
> Some other changes include splitting TX and RX into two separate FSMs in two
> always blocks as you can see in chnl_tester.v
> Also, I need to give credit to @marzoul for maintaining the kernel functions
> which I have already included in this patch altogether.
>
> However, this patch degrades bandwidth measurement result with respect to
> Xillybus
> and riffa original driver (slower with an approximate factor of 3 at the same
> given data batch length)
Put all of this in your patch description, and again, properly line-wrap
your lines at 72 columns. I'm getting tired of asking this...
> > Please fix this all up and submit a v3, after at least commenting on the
> > things asked previously.
>
> Please allows time to clear up my confusion first regarding the following
> questions about subvendor ID and subdevice ID before v3 patch submission
>
>
> > Also, you still have this line which prevents me from being able to
> > accept this patch, as I talked about previously:
>
> > + {PCI_DEVICE(VENDOR_ID1, PCI_ANY_ID)},
>
> > Do NOT just bind to all PCI devices from a vendor, that will break other
> > drivers in the system.
>
> This line is for subvendor ID and subdevice ID. I do not think lspci helps
> here.
What do you mean by this?
You just told the kernel that ALL devices with PCI vendor id of
VENDOR_ID1 (horrible description) are handled properly by this driver.
I do not think that is what you really want, correct?
> Could you suggest how to get around PCI_ANY_ID for subdevice ID ?
> Same question for subvendor ID.
Look at include/linux/pci.h. Use the PCI_DEVICE_SUB() macro here or one
of the other macros defined in that file to properly describe your
device as being unique and not "ALL DEVICES FROM A VENDOR".
> > Also, do not use a random MAJOR number that you just picked out of no
> > where, that too will break working systems and needs to be fixed. Use
> > the dynamic allocation method, or better yet, just use a misc device.
>
> What do you exactly mean by misc device ?
Look at include/linux/miscdevice.h for the details.
> > How do you plan to proceed ?
>
> please keep the driver in the staging state until it can really match
> Xillybus or Riffa original driver's bandwidth benchmark.
>
> I am actually a bit worried with circ_queue structure and its corresponding
> push() and pull() functions which systemtap complains to have some
> significant timing overhead, but to be frank, this is not the root cause of
> why the full duplex version of the driver is slower.
Yes, that's kind of obvious by looking at that code :)
Again, fix up the driver to use the in-kernel data structures for this
type of thing and you will see a much better improvement in performance.
good luck!
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: gdm724x: Fix DMA from stack
On Thu, Feb 11, 2021 at 01:28:41PM +, David Laight wrote: > > Stack allocated buffers cannot be used for DMA > > on all architectures so allocate hci_packet buffer > > using kmalloc. > > I wonder if the usb stack ought/could support a short bounce > buffer within the memory is already has to allocate? No. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 09/12] media: atomisp: Fix PARENTHESIS_ALIGNMENT
On Mon, Dec 14, 2020 at 11:49:56AM +, David Laight wrote: > From: Philipp Gerlesberger > > Sent: 14 December 2020 11:04 > > > > You can sum up the two lines, because the maximum line length of > > 100 columns is not exceeded. > > IIRC the 80 column limit is preferred. Not anymore, checkpatch has changed. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: (style) Expression is always false
On Mon, Jan 07, 2019 at 11:40:08AM +, David Binderman wrote: > > Hello there, > > linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: > (style) Expression is always false because 'else if' condition matches > previous condition at line 410. > > Source code is > > else if (pRaInfo->HighestRate > 0x0b) > pRaInfo->PTModeSS = 2; > else if (pRaInfo->HighestRate > 0x0b) > pRaInfo->PTModeSS = 1; > > Suggest code rework. Patches are always gladly accepted! thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: mt7621-eth/ethtool.c: Correction of SPDX license identifier
On Wed, Jan 30, 2019 at 02:48:27PM +, Carlos Henrique Lima Melara wrote: > This patch fix the checkpatch.p1 warning: > > WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 > +/* Why did you not fix up the indentation that was already mentioned? > It includes the SPDX expression for GPL-2.0 and corrects the comment > format to suit the kernel's coding style. Always properly line-wrap your comments. > > Signed-off-by: Carlos (Charles) Henrique Lima Melara > This needs to match your "From:" line. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: mt7621-eth/ethtool.c: Correction of SPDX license identifier
On Wed, Jan 30, 2019 at 05:38:17PM +0100, Andrew Lunn wrote:
> On Wed, Jan 30, 2019 at 02:48:27PM +, Carlos Henrique Lima Melara wrote:
> > This patch fix the checkpatch.p1 warning:
> >
> > WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
> > +/*
> >
> > It includes the SPDX expression for GPL-2.0 and corrects the comment
> > format to suit the kernel's coding style.
> >
> > Signed-off-by: Carlos (Charles) Henrique Lima Melara
> >
> > ---
> > drivers/staging/mt7621-eth/ethtool.c | 22 --
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/staging/mt7621-eth/ethtool.c
> > b/drivers/staging/mt7621-eth/ethtool.c
> > index 40a7d47be913..49d417de64c8 100644
> > --- a/drivers/staging/mt7621-eth/ethtool.c
> > +++ b/drivers/staging/mt7621-eth/ethtool.c
> > @@ -1,15 +1,17 @@
> > -/* This program is free software; you can redistribute it and/or modify
> > - * it under the terms of the GNU General Public License as published by
> > - * the Free Software Foundation; version 2 of the License
> > +// SPDX-License-Identifier: GPL-2.0
>
> Hi Carlos
>
> drivers/staging/mt7621-eth$ grep LICENSE *
> gsw_mt7621.c:MODULE_LICENSE("GPL");
> mtk_eth_soc.c:MODULE_LICENSE("GPL");
>
> And include/linux/module.h
> says:
>
> /*
> * The following license idents are currently accepted as indicating free
> * software modules
> *
> * "GPL" [GNU Public License v2 or later]
> * "GPL v2"[GNU Public License v2]
>
> So the SPDX string probably does not match the MODULE_LICENSE.
No, ignore the MODULE_LICENSE marking for this, go by what the text at
the top of the file says. See the patch about all of this from Thomas on
lkml yesterday for why this is the case.
So the patch is fine. If the changelog stuff ever gets fixed...
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: mt7621-eth/ethtool.c: Correction of SPDX license identifier
On Wed, Jan 30, 2019 at 08:01:13PM +, Carlos Henrique Lima Melara wrote:
> On 30/01/2019 13:29, gre...@linuxfoundation.org wrote:
> > On Wed, Jan 30, 2019 at 02:48:27PM +, Carlos Henrique Lima Melara wrote:
> >>This patch fix the checkpatch.p1 warning:
> >>
> >>WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
> >>+/*
> >
> > Why did you not fix up the indentation that was already mentioned?
>
> The Warning was about the missing SPDX License Identifier, so I added the
> identifier according to the "license-rules.rst" for C source that is:
I mean the indentation of the text in your changelog, nothing to do with
the actual change in your patch below, sorry for the confusion.
> > The SPDX license identifier is added in form of a comment. The comment
> > style depends on the file type::
> >
> > C source: // SPDX-License-Identifier:
> > C header: /* SPDX-License-Identifier: */
> > ASM: /* SPDX-License-Identifier: */
> > scripts: # SPDX-License-Identifier:
> > .rst: .. SPDX-License-Identifier:
> > .dts{i}: // SPDX-License-Identifier:
>
> I think that was the correction needed, right?
Yes.
> Still have a question about the license comment in the "ethtooll.c".
>
> > /* This program is free software; you can redistribute it and/or modify
> > * it under the terms of the GNU General Public License as published by
> > * the Free Software Foundation; version 2 of the License
> > *
> > * This program is distributed in the hope that it will be useful,
> > * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > * GNU General Public License for more details.
> > *
> > * Copyright (C) 2009-2016 John Crispin
> > * Copyright (C) 2009-2016 Felix Fietkau
> > * Copyright (C) 2013-2016 Michael Lee
> > */
>
> It puts 3 spaces between the * and the text, should it be corrected to
> only one space?
If you really want to, but it's not needed.
All of the "boilerplate" license text can also be removed after the SPDX
line is added, if you want to do that. But leave the copyright lines,
that needs to stay.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: greybus: pwm: fixed a coding style issue
On Wed, Mar 13, 2019 at 02:09:15PM +, manuel.ram...@protonmail.com wrote:
> Hello,
>
> this is my very first patch, very simple and check it, so it compiles
> properly and also go no errors on the checkpatch script.
> From c8a66a3bee14fe89ad2a03545a76953bc880b9e6 Mon Sep 17 00:00:00 2001
> From: Manuel Rambow
> Date: Wed, 13 Mar 2019 13:00:35 +0100
> Subject: [PATCH] Staging: greybus: pwm: fixed a coding style issue
>
> Fixed a blank line coding style issue.
>
> Signed-off-by: Manuel Rambow
> ---
> drivers/staging/greybus/pwm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
> index 4a6d394b6c44..de74c37b14e9 100644
> --- a/drivers/staging/greybus/pwm.c
> +++ b/drivers/staging/greybus/pwm.c
> @@ -21,10 +21,10 @@ struct gb_pwm_chip {
> struct pwm_chip chip;
> struct pwm_chip *pwm;
> };
> +
> #define pwm_chip_to_gb_pwm_chip(chip) \
> container_of(chip, struct gb_pwm_chip, chip)
>
> -
> static int gb_pwm_count_operation(struct gb_pwm_chip *pwmc)
> {
> struct gb_pwm_count_response response;
> --
> 2.21.0
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch was attached, please place it inline so that it can be
applied directly from the email message itself.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/3] staging: wfx: replace uintXX_t to uXX and intXX_t to sXX
On Mon, Nov 11, 2019 at 05:04:49PM +, Jerome Pouiller wrote: > I know that uXX is prefered over uintXX_t. However, I dislike to change > 650 lines of code only for this purpose in one batch. It will generate > plenty of conflicts with branches currently in development. Now that the code is in the kernel tree, any "branches currently in development" have to deal with what is merged upstream no matter if they are tiny or big patches. That's just the joy of working with upstream, sorry. If you want to do out-of-tree development, that's fine, but you can't also want the code in-tree at the same time. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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-ker...@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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/37] staging: comedi: tidy up legacy DMA drivers
On Tue, Jan 13, 2015 at 04:08:29PM +, Hartley Sweeten wrote: > On Tuesday, January 13, 2015 5:54 AM, Ian Abbott wrote: > > On 12/01/15 17:55, H Hartley Sweeten wrote: > >> This series removes all the VIRT_TO_BUS dependancies from the legacy comedi > >> drivers. It also tidies up the allocation and freeing of the DMA and the > >> buffers used for DMA. > > > > Reviewed-by: Ian Abbott > > Thanks. > > Greg, > > When these bounced back from the list I noticed that patches 9, 10, > and 11 have Ian's email address incorrect in the Cc. For some reason > they also have my alternate email address (hartl...@visionengravers.com) > in the From line. > > I can fix this and repost the series if you want. No need, I'll take his Reviewed-by which is correct and is all that is needed. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: kpc2000: Add DMA driver
On Mon, Apr 22, 2019 at 02:37:59PM +, Matt Sickler wrote: > >From 6e70cb81c75ebb0ac7897d07c0f12d80505bb22b Mon Sep 17 00:00:00 2001 > From: Matt Sickler > Date: Mon, 22 Apr 2019 09:24:03 -0500 > Subject: [PATCH] staging: kpc2000: Add DMA driver > > Add Daktronics DMA driver. I've added the SPDX license identifiers, Kconfig > entry, and cleaned up as many of the warnings as I could. > > I'm not sure what should be done about the AIO "support" code in this driver. > It's currently guarded by an #ifdef CONFIG_KPC_DMA_AIO. Even if that option > was turned on, the code doesn't compile (aio_complete() was removed since > the original version of this driver) and it probably doesn't work right even > if it did compile. Maybe it's best to just remove it completely? > > --- It's best to just remove the aio stuff entirely, but we can do that in a follow-on patch. This looks ok, but I need a signed-off-by line on the patch, in the changelog text. Can you fix that up and resend it? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: kpc2000: Add DMA driver
On Mon, Apr 22, 2019 at 10:05:58PM +, Matt Sickler wrote: > Add Daktronics DMA driver. I've added the SPDX license identifiers, Kconfig > entry, and cleaned up as many of the warnings as I could. > > The AIO support code will be removed in a future patch. > > Signed-off-by: Matt Sickler Looks good, now applied, thanks for doing this. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: RFC: kpc2000 driver naming
On Fri, May 03, 2019 at 10:24:00PM +, Matt Sickler wrote: > Hello, > > Recently Greg KH posted the first set of drivers for our PCIe device > (kpc2000) and shortly after that I posted the kpc2000_dma driver. I was > wondering about naming / structure standards in the Linux kernel. > First, a real quick background on these devices: Daktronics makes a PCIe > card with an FPGA on it to drive our LED displays (and other processing > tasks). Inside the FPGA, we use something similar to AXI-4 to divide the > PCIe BAR register space [1] into separate "IP cores". The kpc2000 driver is > responsible for probing the PCIe device, doing some basic setup (mapping the > BAR, setting up an IRQ, PCIe configuration, etc) and then enumerating these > "cores". Enumeration of the cores is facilitated by the "board info" core > that is always at the beginning of the BAR and has a defined format. Most > of the cores are controlled entirely by userspace - the driver will add a UIO > sub device for each one which userspace uses to control FPGA registers. > Only 3 core types are handled by drivers: DMA, I2C, SPI. These are IP cores > inside the FPGA that (in the case of i2c and spi) interact with other > physical devices on the PCIe card. > Currently, we only have the one PCIe device (the "P2K" card) but we have more > on our roadmap (one we've been calling "p3k" internally). I'm 99% confident > that the I2C and SPI cores will be exactly the same on the new FPGA design. > I'm 80% confident that the DMA engines themselves will be exactly the same on > the new FPGA design. The next card PCIe driver will quite likely be > separate from the kpc2000 driver because how bitstreams are stored / loaded / > configured is changing due to using a newer FPGA. There will likely be > common code between the two. Please wrap your emails at a sane column, otherwise this is just a huge wall of text that is hard to read/understand. > Now on to my actual questions: Once the drivers are "good enough" to be moved > outside of staging, I'm wondering where the drivers will end up and what > their names will/should be. > Since the I2C and SPI drivers are single-file, I'm guessing they're going to > move to drivers/i2c/busses/i2c-dak/ and drivers/spi/spi-dak/, respectively. > I tweaked the names, since "i2c-dak" and "spi-dak" make more sense to me than > "kpc_i2c" and "kpc_spi". Feel free to rename them to whatever you want, I just randomly picked a name when I did the import of the drivers. > So that leaves the DMA and main PCIe drivers. Where do those end up in the > tree? Would "dak-dma" and "dak-p2k" (and eventually "dak-p3k") make more > sense as names for those drivers? Maybe, as long as it is a "unique" name, that's all that should matter. The subsystem maintainers of those areas might care more, but you can deal with that when you get closer to moving the code out of staging. > The final question relates to how Kconfig entries are setup. The > I2C, SPI, and DMA drivers could be "selected" on their own (even if > the "dak-p2k" and "dak-p3k" drivers aren't selected), but that doesn't > make much sense because they'd never get used in that configuration. > Conversely, if you select the "dak-p2k" driver, the I2C, SPI, and DMA > drivers better get selected too, otherwise the device won't function > correctly. From what I can tell with Kconfig, if A depends on B, you > can't even see (let alone select) A without already selecting B. > Right now, the Kconfig entries are setup like this (using the current names, > not the new ones presented above): > KPC2000_DMA depends on KPC2000 (this compiles the kpc2000_dma driver) > KPC2000_I2C depends on KPC2000 && I2C (this compiles the kpc2000_i2c > driver) > KPC2000_SPI depends on KPC2000 && SPI (this compiles the kpc2000_spi > driver) > KPC2000_CORE depends on KPC2000 > KPC2000 depends on PCI (this compiles the kpc2000 driver) > Greg, what is the purpose of the KPC2000_CORE config option? Nothing (that I > see) depends on it, and it doesn't cause any code to get compiled. I don't remember, I guess I thought that was a chunk of code the others all depended on being present? If that's not the case, please send a patch to fix that up. > I would have thought something like this makes more sense [2]: > KPC2000_DMA depends nothing Not any dma drivers/core? > KPC2000_I2C depends on I2C > KPC2000_SPI depends on SPI > KPC2000 depends on PCI && KPC2000_DMA && KPC2000_I2C && KPC2000_SPI It can't depend on them all, or does it? If so, that's fine, I just got this totally backwards, sorry. > Which way is "better"? Does it even matter which way it's setup? It does matter, try to reflect what depends on what for the code and you should be fine. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org
Re: RFC: kpc2000 driver naming
On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote: > > >-Original Message- > >From: 'gre...@linuxfoundation.org' > >On Fri, May 03, 2019 at 10:24:00PM +, Matt Sickler wrote: > >> Hello, > >> > >> Recently Greg KH posted the first set of drivers for our PCIe device > >(kpc2000) and shortly after that I posted the kpc2000_dma driver. I was > >wondering about naming / structure standards in the Linux kernel. > >> First, a real quick background on these devices: Daktronics makes a PCIe > >card with an FPGA on it to drive our LED displays (and other processing > >tasks). > >Inside the FPGA, we use something similar to AXI-4 to divide the PCIe BAR > >register space [1] into separate "IP cores". The kpc2000 driver is > >responsible > >for probing the PCIe device, doing some basic setup (mapping the BAR, > >setting up an IRQ, PCIe configuration, etc) and then enumerating these > >"cores". Enumeration of the cores is facilitated by the "board info" core > >that is > >always at the beginning of the BAR and has a defined format. Most of the > >cores are controlled entirely by userspace - the driver will add a UIO sub > >device for each one which userspace uses to control FPGA registers. Only 3 > >core types are handled by drivers: DMA, I2C, SPI. These are IP cores inside > >the FPGA that (in the case of i2c and spi) interact with other physical > >devices > >on the PCIe card. > >> Currently, we only have the one PCIe device (the "P2K" card) but we have > >more on our roadmap (one we've been calling "p3k" internally). I'm 99% > >confident that the I2C and SPI cores will be exactly the same on the new FPGA > >design. I'm 80% confident that the DMA engines themselves will be exactly > >the same on the new FPGA design. The next card PCIe driver will quite > >likely > >be separate from the kpc2000 driver because how bitstreams are stored / > >loaded / configured is changing due to using a newer FPGA. There will likely > >be common code between the two. > > > >Please wrap your emails at a sane column, otherwise this is just a huge wall > >of > >text that is hard to read/understand. > > We use Outlook and Office 365, so I figured the emails were going to be > formatted badly. Just for clarity, are you saying I should hard wrap (insert > newlines myself) at an 80-column boundary? If your email client forces that to be the only way, yes :( > >> Now on to my actual questions: Once the drivers are "good enough" to be > >moved outside of staging, I'm wondering where the drivers will end up and > >what their names will/should be. > >> Since the I2C and SPI drivers are single-file, I'm guessing they're going > >> to > >move to drivers/i2c/busses/i2c-dak/ and drivers/spi/spi-dak/, respectively. > >I > >tweaked the names, since "i2c-dak" and "spi-dak" make more sense to me > >than "kpc_i2c" and "kpc_spi". > > > >Feel free to rename them to whatever you want, I just randomly picked a > >name when I did the import of the drivers. > > > >> So that leaves the DMA and main PCIe drivers. Where do those end up in > >the tree? Would "dak-dma" and "dak-p2k" (and eventually "dak-p3k") make > >more sense as names for those drivers? > > > >Maybe, as long as it is a "unique" name, that's all that should matter. > >The subsystem maintainers of those areas might care more, but you can deal > >with that when you get closer to moving the code out of staging. > > > >> The final question relates to how Kconfig entries are setup. The > >> I2C, SPI, and DMA drivers could be "selected" on their own (even if > >> the "dak-p2k" and "dak-p3k" drivers aren't selected), but that doesn't > >> make much sense because they'd never get used in that configuration. > >> Conversely, if you select the "dak-p2k" driver, the I2C, SPI, and DMA > >> drivers better get selected too, otherwise the device won't function > >> correctly. From what I can tell with Kconfig, if A depends on B, you > >> can't even see (let alone select) A without already selecting B. > >> Right now, the Kconfig entries are setup like this (using the current > >> names, > >not the new ones presented above): > >> KPC2000_DMA depends on KPC2000 (this compiles the kpc2000_dma > >driver) &
Re: RFC: kpc2000 driver naming
On Mon, May 06, 2019 at 02:38:16PM +, Matt Sickler wrote: > >-Original Message- > >From: 'gre...@linuxfoundation.org' > >On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote: > >> The I2C and SPI drivers don't depend on anything other than the I2C > >> and SPI subsystems. Actually, they might be depending on the kp2000 > >> driver having the PCIe registers mapped into kernel space instead of doing > >> that themselves. > >> I'm not sure if that's the correct thing to do or not, so that might > >> be something to look closely at with all these drivers. > > > >Are all of these drivers needed for this hardware to work? Should they even > >be separate drivers or should they all be mushed into one? Can anyone do > >anything useful with just one of them? > > > >> Yes, all 4 drivers are required for proper functioning of the card. > >> SPI is used to reprogram the flash chips that store the FPGA > >> bitstream. I2C is used for monitoring and programming clock > >> generators. DMA is required for some parts of other cores. > > > >So should we just merge this into one driver at link time? That would make > >more sense, right? > > Yes. All the drivers are required for the hardware to work. > In some sense, they "could" be used independently, but most likely only within > Daktronics hardware. I guess if someone else had an FPGA design that needed a > SPI controller, they could reuse our driver as long as their FPGA implemented > a compatible SPI controller. > > One thing I would be concerned with would be future FPGA designs that need to > mix-and-match. > For example (using new names), today we have the P2K card which uses the > dak-p2k > main driver, and dak-i2c, dak-spi, and dak-dma "sub-drivers". > Perhaps the next generation hardware would need to use a new dak-p3k main > driver > but can reuse the dak-i2c and dak-dma sub-drivers. And maybe it needs a new > dak-spi-v2 driver (because something in the hardware changed in an > incompatible > way). This is all hypothetical though - it could range from complete driver > reuse to needing all new drivers for everything - we won't know for sure until > the new hardware designs ramp up in the next 6-12 months. > > If there's a way to do link-time trickery to get all 4 drivers compiled into > one .ko, I'd be fine with that. I do think it's a good idea to keep them at > least slightly separated to facilitate that mix-and-match scenario as well as > just ease of maintaining the code. Ok, keeping them separate is fine, just wanted to make sure, thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] kpc_i2c: Remove unused file
On Thu, May 09, 2019 at 02:47:50PM +, Matt Sickler wrote: > >-Original Message- > >From: Dan Carpenter > > > >Add Staging: to the subject. > > Added to my notes so I don't forget it next time. > > >[PATCH v2] Staging: kpc_i2c: Remove unused file fileops.c > > > >On Thu, May 09, 2019 at 01:38:27PM +, Matt Sickler wrote: > >> The whole file was wrapped in an #if 0. I'm guessing it was a > >> leftover file from when we were first developing the driver and we just > >forgot about it. > >> > >> V2: Forgot the signed-off-by line on the first patch. > > > >Put this after the --- cut off line > > > >> > >> Signed-off-by: Matt Sickler > >> --- > > ^^^ > > > >Here. > > Noted. I just looked up a "v2" patch in the mailing list > archive to see what that looks like. I'll try to do that > next time. > > > > >There is something else wrong with the patch and it's corrupted a bit or > >something. Please read the first paragraph of Documentation/process/email- > >clients.rst > > Ugh. I'm about to throw Outlook in the trash and just use > my personal email account. > I know most subsystem maintainers don't accept pull requests > but Daktronics does have a github account that I could push > my changes to and use git-request-pull to ask Greg to pull > from. Greg, would that be an acceptable solution? If not, > I can continue struggle-bussing with Outlook. I can't take git pull requests from github, sorry. Can you use 'git send-email' directly with your exchange server, from the command line? I fixed up this patch by hand and applied it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: isdn: To make hysdn_proc_entry static.
On Sun, Jun 09, 2019 at 12:24:59AM +, Rishiraj Manwatkar wrote: > Made hysdn_proc_entry static as suggested by Sparse tool. Why is this indented? > > Signed-off-by: Rishiraj Manwatkar > --- > drivers/staging/isdn/hysdn/hysdn_procconf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/isdn/hysdn/hysdn_procconf.c > b/drivers/staging/isdn/hysdn/hysdn_procconf.c > index 73079213ec94..3d12c058a6f1 100644 > --- a/drivers/staging/isdn/hysdn/hysdn_procconf.c > +++ b/drivers/staging/isdn/hysdn/hysdn_procconf.c > @@ -349,7 +349,7 @@ static const struct file_operations conf_fops = > /*/ > /* hysdn subdir in /proc/net */ > /*/ > -struct proc_dir_entry *hysdn_proc_entry = NULL; > +static struct proc_dir_entry *hysdn_proc_entry = NULL; I will have to wait until after 5.3-rc1 before taking any drivers/staging/isdn patches, sorry. I suggest waiting until then before resending, and even then, the isdn code is about to be deleted, try working on code that is being accepted. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: kpc2000: To make symbols static
On Mon, Jun 10, 2019 at 05:50:01AM +, Rishiraj Manwatkar wrote: > This patch makes 4 symbols static as suggested by Sparse tool. > > Signed-off-by: Rishiraj Manwatkar Your subject line is very odd, what does that really mean? > --- > drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c > b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c > index cda057569163..e4056607af0b 100644 > --- a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c > +++ b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c > @@ -36,14 +36,14 @@ struct kpc_dma_device *kpc_dma_lookup_device(int minor) > return c; > } > > -void kpc_dma_add_device(struct kpc_dma_device *ldev) > +static void kpc_dma_add_device(struct kpc_dma_device *ldev) This patch does not apply to my latest tree, can you rebase it against the staging-next branch of staging.git on git.kernel.org and resend? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Adjust analogix chip driver location
On Wed, Jun 26, 2019 at 10:44:38AM +, Xin Ji wrote: > Move analogix chip ANX78XX bridge driver into "analogix" directory. > > Signed-off-by: Xin Ji > --- > drivers/gpu/drm/bridge/Kconfig | 10 - > drivers/gpu/drm/bridge/Makefile|3 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 1485 > > drivers/gpu/drm/bridge/analogix-anx78xx.h | 710 -- > drivers/gpu/drm/bridge/analogix/Kconfig| 10 + > drivers/gpu/drm/bridge/analogix/Makefile |2 + > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1485 > > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 710 ++ > 8 files changed, 2208 insertions(+), 2207 deletions(-) > delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.c > delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h 'git format-patch -M' is usually a lot better to use when moving files around, as it shows you only any changes in the files, not a huge delete/add cycle. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fsl-mc/dpio: Fix incorrect comparison
On Thu, Sep 28, 2017 at 01:07:48PM +, Ruxandra Ioana Radulescu wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Thursday, September 28, 2017 3:49 PM > > To: Ruxandra Ioana Radulescu > > Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; > > a...@arndb.de; stuyo...@gmail.com; Roy Pledge ; > > linux-ker...@vger.kernel.org; ag...@suse.de; Bogdan Purcareata > > ; Laurentiu Tudor > > > > Subject: Re: [PATCH] staging: fsl-mc/dpio: Fix incorrect comparison > > > > On Wed, Sep 27, 2017 at 12:57:28PM -0500, Ioana Radulescu wrote: > > > diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c > > b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c > > > index f809682..26922fc 100644 > > > --- a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c > > > +++ b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c > > > @@ -76,7 +76,7 @@ static inline struct dpaa2_io > > *service_select_by_cpu(struct dpaa2_io *d, > > > if (d) > > > return d; > > > > > > - if (unlikely(cpu >= num_possible_cpus())) > > > + if (unlikely(cpu >= (int)num_possible_cpus())) > > > > > > Drivers shouldn't use likely/unlikley. > > I was under the impression it's ok to use them on hotpath > (and while not entirely obvious, this function is called on > other drivers' hotpath). Only use it if you can measure the difference. If you can not, then do not use it as the compiler and the CPU will guess it better than you will. This has been proven many times, something like 80% of our likely/unlikely usage in the kernel is wrong because of this, see the work from Andi Kleen many years ago in this area. So please remove it. Unless you can prove it matters, and if so, document that. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [REVIEW REQUEST] staging: unisys: review request for visorbus
On Mon, Oct 02, 2017 at 03:41:42PM +, Kershner, David A wrote: > Hey Greg, we think the code for visorbus is ready to be moved out > of staging, can you review it to see if we have missed anything? I think your html email got rejected by the list :( > The files include: > /drivers/staging/unisys/visorbus/ > /drivers/staging/unisys/include/visorchannel.h > /drivers/staging/unisys/include/visorbus.h > > The directories staging/drivers/unisys/visornic, visorhba, and visorinput > are not part of the review as well as the file > drivers/staging/unisys/include/iochannel.h. > > We currently have 5 checkpatch.pl warnings that I know about: > - 3 CHECKs in visorchannel that are due to a MACRO that gets passed a FIELD > instead of just a variable > - 2 WARNINGS dealing with char * becoming static const > > > > Dan Carpenter found some extra parenthesis errors that I will address as > well as look through the code to fix, but I would like to ask for the review > while we are working on that. Sure, I'll look at doing it in a week or so when I catch up with other patches in my queue. Everyone else is also welcome to do review :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers
On Fri, Oct 06, 2017 at 01:33:32PM +, Stahl, Manuel wrote: > > Signed-off-by: Manuel Stahl > --- > drivers/uio/uio_pci_dmem_genirq.c | 27 --- > drivers/uio/uio_pci_generic.c | 24 ++-- > 2 files changed, 38 insertions(+), 13 deletions(-) I can't take patches without any changelog text in them, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers
On Fri, Oct 06, 2017 at 07:57:00AM -0700, Stephen Hemminger wrote: > On Fri, 6 Oct 2017 13:50:44 + > "Stahl, Manuel" wrote: > > > MSI(X) interrupts are not shared between devices. So when available > > those should be preferred over legacy interrupts. > > > > Signed-off-by: Manuel Stahl > > --- > > drivers/uio/uio_pci_dmem_genirq.c | 27 --- > > drivers/uio/uio_pci_generic.c | 24 ++-- > > 2 files changed, 38 insertions(+), 13 deletions(-) > > The last time I tried to do MSI-X with pci-generic it got rejected > by the maintainer. Hm, yeah, this would break users today that do not have msi-x, right? Not good, Manuel, how well did you test this? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: don't care about debugfs errors
A caller should never care about a debugfs error return value, and it
should never abort its normal operation if something "odd" goes on. Fix
up the unisys init code to not care if the root debugfs directory for
the subsystem is created or not, as no place it is used will matter.
Cc: David Kershner
Cc: Tim Sell
Cc: Sameer Wadgaonkar
Cc: David Binder
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 2f1e8d36aedf..b604d0cccef1 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1217,8 +1217,6 @@ int visorbus_init(void)
int err;
visorbus_debugfs_dir = debugfs_create_dir("visorbus", NULL);
- if (!visorbus_debugfs_dir)
- return -ENOMEM;
bus_device_info_init(&clientbus_driverinfo, "clientbus", "visorbus");
err = bus_register(&visorbus_type);
if (err < 0)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [REVIEW REQUEST] staging: unisys: review request for visorbus
On Mon, Oct 02, 2017 at 05:49:52PM +0200, gre...@linuxfoundation.org wrote: > On Mon, Oct 02, 2017 at 03:41:42PM +, Kershner, David A wrote: > > Hey Greg, we think the code for visorbus is ready to be moved out > > of staging, can you review it to see if we have missed anything? > > I think your html email got rejected by the list :( > > > The files include: > > /drivers/staging/unisys/visorbus/ > > /drivers/staging/unisys/include/visorchannel.h > > /drivers/staging/unisys/include/visorbus.h > > > > The directories staging/drivers/unisys/visornic, visorhba, and visorinput > > are not part of the review as well as the file > > drivers/staging/unisys/include/iochannel.h. > > > > We currently have 5 checkpatch.pl warnings that I know about: > > - 3 CHECKs in visorchannel that are due to a MACRO that gets passed a FIELD > > instead of just a variable > > - 2 WARNINGS dealing with char * becoming static const > > > > > > > > Dan Carpenter found some extra parenthesis errors that I will address as > > well as look through the code to fix, but I would like to ask for the review > > while we are working on that. > > Sure, I'll look at doing it in a week or so when I catch up with other > patches in my queue. > > Everyone else is also welcome to do review :) Well, don't everone jump in at once :( Anyway, drivers/staging/unisys/visorbus/ looks good, after my one tiny patch I've just sent you. Feel free to send a patch moving it to drivers/visorbus now if you want to. Then the individual drivers can go into the different subsystem locations after they are reviewed by the different subsystem maintainers, but that can't happen until the core moves. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [REVIEW REQUEST] staging: unisys: review request for visorbus
On Mon, Nov 06, 2017 at 03:30:48PM +1100, Tobin C. Harding wrote:
> On Mon, Oct 02, 2017 at 05:49:52PM +0200, gre...@linuxfoundation.org wrote:
> > On Mon, Oct 02, 2017 at 03:41:42PM +, Kershner, David A wrote:
> > > Hey Greg, we think the code for visorbus is ready to be moved out
> > > of staging, can you review it to see if we have missed anything?
> >
> > I think your html email got rejected by the list :(
> >
> > > The files include:
> > > /drivers/staging/unisys/visorbus/
> > > /drivers/staging/unisys/include/visorchannel.h
> > > /drivers/staging/unisys/include/visorbus.h
> > >
> > > The directories staging/drivers/unisys/visornic, visorhba, and visorinput
> > > are not part of the review as well as the file
> > > drivers/staging/unisys/include/iochannel.h.
> > >
> > > We currently have 5 checkpatch.pl warnings that I know about:
> > > - 3 CHECKs in visorchannel that are due to a MACRO that gets passed a
> > > FIELD
> > > instead of just a variable
> > > - 2 WARNINGS dealing with char * becoming static const
> > >
> > >
> > >
> > > Dan Carpenter found some extra parenthesis errors that I will address as
> > > well as look through the code to fix, but I would like to ask for the
> > > review
> > > while we are working on that.
> >
> > Sure, I'll look at doing it in a week or so when I catch up with other
> > patches in my queue.
> >
> > Everyone else is also welcome to do review :)
>
> cppcheck emits a few style warnings, nothing super important but FWIW
> here is a patch
>
> ---
> drivers/staging/unisys/visorbus/visorchannel.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/unisys/visorbus/visorchannel.c
> b/drivers/staging/unisys/visorbus/visorchannel.c
> index aae16073ba03..2c1beddfee29 100644
> --- a/drivers/staging/unisys/visorbus/visorchannel.c
> +++ b/drivers/staging/unisys/visorbus/visorchannel.c
> @@ -131,12 +131,13 @@ int visorchannel_write(struct visorchannel *channel,
> ulong offset, void *dest,
> ulong nbytes)
> {
> size_t chdr_size = sizeof(struct channel_header);
> - size_t copy_size;
>
> if (offset + nbytes > channel->nbytes)
> return -EIO;
>
> if (offset < chdr_size) {
> + size_t copy_size;
> +
Ick, no, the original code here is fine.
> copy_size = min(chdr_size - offset, nbytes);
> memcpy(((char *)(&channel->chan_hdr)) + offset,
> dest, copy_size);
> @@ -260,9 +261,10 @@ int visorchannel_signalremove(struct visorchannel
> *channel, u32 queue,
> void *msg)
> {
> int rc;
> - unsigned long flags;
>
> if (channel->needs_lock) {
> + unsigned long flags;
> +
Same here, the original code is fine.
No idea why the tool wants you to move these around, you should ignore
stuff like that :(
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [REVIEW REQUEST] staging: unisys: review request for visorbus
On Mon, Nov 06, 2017 at 07:17:11PM +1100, Tobin C. Harding wrote:
> On Mon, Nov 06, 2017 at 09:02:21AM +0100, gre...@linuxfoundation.org wrote:
> > On Mon, Nov 06, 2017 at 03:30:48PM +1100, Tobin C. Harding wrote:
> > > On Mon, Oct 02, 2017 at 05:49:52PM +0200, gre...@linuxfoundation.org
> > > wrote:
> > > > On Mon, Oct 02, 2017 at 03:41:42PM +, Kershner, David A wrote:
> > > > > Hey Greg, we think the code for visorbus is ready to be moved out
> > > > > of staging, can you review it to see if we have missed anything?
> > > >
> > > > I think your html email got rejected by the list :(
> > > >
> > > > > The files include:
> > > > > /drivers/staging/unisys/visorbus/
> > > > > /drivers/staging/unisys/include/visorchannel.h
> > > > > /drivers/staging/unisys/include/visorbus.h
> > > > >
> > > > > The directories staging/drivers/unisys/visornic, visorhba, and
> > > > > visorinput
> > > > > are not part of the review as well as the file
> > > > > drivers/staging/unisys/include/iochannel.h.
> > > > >
> > > > > We currently have 5 checkpatch.pl warnings that I know about:
> > > > > - 3 CHECKs in visorchannel that are due to a MACRO that gets passed
> > > > > a FIELD
> > > > > instead of just a variable
> > > > > - 2 WARNINGS dealing with char * becoming static const
> > > > >
> > > > >
> > > > >
> > > > > Dan Carpenter found some extra parenthesis errors that I will address
> > > > > as
> > > > > well as look through the code to fix, but I would like to ask for the
> > > > > review
> > > > > while we are working on that.
> > > >
> > > > Sure, I'll look at doing it in a week or so when I catch up with other
> > > > patches in my queue.
> > > >
> > > > Everyone else is also welcome to do review :)
> > >
> > > cppcheck emits a few style warnings, nothing super important but FWIW
> > > here is a patch
> > >
> > > ---
> > > drivers/staging/unisys/visorbus/visorchannel.c | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/staging/unisys/visorbus/visorchannel.c
> > > b/drivers/staging/unisys/visorbus/visorchannel.c
> > > index aae16073ba03..2c1beddfee29 100644
> > > --- a/drivers/staging/unisys/visorbus/visorchannel.c
> > > +++ b/drivers/staging/unisys/visorbus/visorchannel.c
> > > @@ -131,12 +131,13 @@ int visorchannel_write(struct visorchannel
> > > *channel, ulong offset, void *dest,
> > > ulong nbytes)
> > > {
> > > size_t chdr_size = sizeof(struct channel_header);
> > > - size_t copy_size;
> > >
> > > if (offset + nbytes > channel->nbytes)
> > > return -EIO;
> > >
> > > if (offset < chdr_size) {
> > > + size_t copy_size;
> > > +
> >
> > Ick, no, the original code here is fine.
> >
> > > copy_size = min(chdr_size - offset, nbytes);
> > > memcpy(((char *)(&channel->chan_hdr)) + offset,
> > > dest, copy_size);
> > > @@ -260,9 +261,10 @@ int visorchannel_signalremove(struct visorchannel
> > > *channel, u32 queue,
> > > void *msg)
> > > {
> > > int rc;
> > > - unsigned long flags;
> > >
> > > if (channel->needs_lock) {
> > > + unsigned long flags;
> > > +
> >
> > Same here, the original code is fine.
> >
> > No idea why the tool wants you to move these around, you should ignore
> > stuff like that :(
>
> Oh? I'm surprise at this comment. I have always thought limiting scope
> of local variables was seen as a good thing. Is this a style thing that
> is on case by case basis or do you never like to declare local variables
> within blocks?
It really doesn't matter as the compiler creates the same amount of
stack space (or used to, maybe newer versions are better, haven't looked
at it in a few years).
And functions shouldn't be all _that_ big that you need to limit the
scope of a local variable :)
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: fsl-mc: use 32bits to support 64K size mc-portals
On Wed, Nov 22, 2017 at 10:49:50AM +, Laurentiu Tudor wrote: > > > On 11/22/2017 09:48 AM, Bharat Bhushan wrote: > > As per APIs each mc-portal is of 64K size while currently > > 16bits (type u16) is used to store size of mc-portal. > > In these cases upper bit of portal size gets truncated. > > > > Signed-off-by: Bharat Bhushan > > --- > > Ok, so just to clarify this fixes the case where size is equal (or maybe > larger in the future) to 0x1. Is this something that can happen today? Is this needed in 4.14 to fix a problem people are having and need to be backported to stable, or can it wait until 4.15? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()
On Mon, Dec 04, 2017 at 12:44:32PM +0200, Andrii Vladyka wrote:
> Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by
> sparse
>
> Signed-off-by: Andrii Vladyka
> Signed-off-by: Andreas Dilger
> ---
>
> diff --git a/drivers/staging/lustre/lustre/lov/lov_object.c
> b/drivers/staging/lustre/lustre/lov/lov_object.c
> index 105b707..897cf2c 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_object.c
> +++ b/drivers/staging/lustre/lustre/lov/lov_object.c
> @@ -1335,7 +1335,7 @@ static int lov_object_fiemap(const struct lu_env *env,
> struct cl_object *obj,
> int rc = 0;
> int cur_stripe;
> int stripe_count;
> - struct fiemap_state fs = { 0 };
> + struct fiemap_state fs = { NULL };
> lsm = lov_lsm_addref(cl2lov(obj));
> if (!lsm)
Patch is corrupted, and can not apply, please fix up your email client
and try it again.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/5] vmbus: add driver_override support
On Mon, Aug 13, 2018 at 07:30:50PM +, Michael Kelley (EOSG) wrote:
> From: k...@linuxonhyperv.com Sent: Friday, August
> 10, 2018 4:06 PM
>
> > From: Stephen Hemminger
> >
> > Add support for overriding the default driver for a VMBus device
> > in the same way that it can be done for PCI devices. This patch
> > adds the /sys/bus/vmbus/devices/.../driver_override file
> > and the logic for matching.
> >
> > This is used by driverctl tool to do driver override.
> > https://gitlab.com/driverctl/driverctl
> >
> > Signed-off-by: Stephen Hemminger
> > Signed-off-by: K. Y. Srinivasan
> > ---
> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > index b1b548a21f91..e6d8fdac6d8b 100644
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -498,6 +498,54 @@ static ssize_t device_show(struct device *dev,
> > }
> > static DEVICE_ATTR_RO(device);
> >
> > +static ssize_t driver_override_store(struct device *dev,
> > +struct device_attribute *attr,
> > +const char *buf, size_t count)
> > +{
> > + struct hv_device *hv_dev = device_to_hv_device(dev);
> > + char *driver_override, *old, *cp;
> > +
> > + /* We need to keep extra room for a newline */
> > + if (count >= (PAGE_SIZE - 1))
> > + return -EINVAL;
>
> Does 'count' actually have a relationship to PAGE_SIZE, or
> is PAGE_SIZE just used as an arbitrary size limit? I'm
> wondering what happens on ARM64 with a 64K page size,
> for example. If it's just arbitrary, coding such a constant
> would be better.
sysfs buffers are PAGE_SIZE big.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > > refcounter overflows that might lead to use-after-free > > > situations. > > > > Looks good. Let me know how do you want to route the patch to upstream. > > Greg, you previously mentioned that driver's conversions can go via your > tree. Does this still apply? > Or should I be asking maintainers to merge these patches via their trees? You should ask them to take them through their trees, if they have them. I'll be glad to scoop up all of the remaining ones that get missed, or for subsystems that do not have trees. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors
Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Mar 30, 2017 at 09:51:53AM -0400, Cathy Avery wrote: > Hi, > > So which commit is moving forward and which one is not? > > f1c635b439a5c01776fe3a25b1e2dc546ea82e6f or > 40630f462824ee24bc00d692865c86c3828094e0? > > We have backported 40630f462824ee24bc00d692865c86c3828094e0 and I am unclear > if this is a regression and must be removed or it is a regression but is > fixed > by f1c635b439a5c01776fe3a25b1e2dc546ea82e6f and can remain. Well, I'm not doing anything here until a hyperv maintainer tells me (and stable@) what patches to backport to what kernels... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: hv: vmbus: Removed an unnecessary cast from void *
On Tue, May 15, 2018 at 12:25:01AM +, Dexuan Cui wrote:
>
> In C, we don't need such a cast.
>
> Fixes: ae20b254306a ("Drivers: hv: vmbus: enable VMBus protocol version 5.0")
> Signed-off-by: Dexuan Cui
> Cc: Stephen Hemminger
Should be "Reported-by:", I'll go edit this by hand :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: hv: vmbus: Removed an unnecessary cast from void *
On Tue, May 15, 2018 at 12:25:01AM +, Dexuan Cui wrote:
>
> In C, we don't need such a cast.
>
> Fixes: ae20b254306a ("Drivers: hv: vmbus: enable VMBus protocol version 5.0")
> Reported-by: Stephen Hemminger
> Signed-off-by: Dexuan Cui
> Cc: K. Y. Srinivasan
> ---
>
> Thanks Stephen Hemminger for pointing this out!
>
> So far, ae20b254306a ("Drivers: hv: vmbus: enable VMBus protocol version
> 5.0") only
> appears in the char-misc tree's char-misc-testing and char-misc-next
> branches. If
> possible, please merge both patches into one.
I can not rebase/merge patches in public branches, sorry, so I'll just
apply this one.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8712: Removed unused variable
On Thu, Apr 23, 2015 at 02:12:44PM +, DHANAPAL, GNANACHANDRAN (G.) wrote: > This patch removes unused variable in this file. > > Signed-off-by: Gnanachandran Dhanapal > > Change-Id: I59cc869773d145239d62c3185018b275239fe812 The only thing I can do with a patch that has this line in it is delete it :( Please fix and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux-4.1-rc1/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c:424: bad if test ?
On Mon, Apr 27, 2015 at 08:33:30AM +, David Binderman wrote: > Hello there Greg, > > Static analyser cppcheck says > > [linux-4.1-rc1/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c:424]: > (style) Expression is always false because 'else if' condition matches > previous condition at line 422. > > Source code is > > else if (pRaInfo->HighestRate> 0x0b) > pRaInfo->PTModeSS = 2; > else if (pRaInfo->HighestRate> 0x0b) > pRaInfo->PTModeSS = 1; > > > Regards > > David Binderman Patches always gladly accepted :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: return error directly
On Thu, Apr 30, 2015 at 08:23:08AM +, Gujulan Elango, Hari Prasath (H.) wrote: > Signed-off-by: Hari Prasath Gujulan Elango > > return error directly to avoid unwanted branching where no cleanup > is done.Also removes the ret variable. signed-off-by goes below the description, not above it. Please fix up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote: > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) > wrote: > > This patch removes unwanted semicolon around close braces of code blocks > > > The i2o driver moved into staging ready to be deleted unless someone > steps up with hardware willing to maintain it (which is rather > unlikely). I think it's now time to delete these, want me to do that for 4.2? I can queue that up in my tree now, so that we don't see any more cleanup patches being made for them? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: declare file operations structure as static
On Fri, Apr 24, 2015 at 07:52:31AM +, Gujulan Elango, Hari Prasath (H.) wrote: > The fops structure is referenced only locally and hence could be made static > > Signed-off-by: Hari Prasath Gujulan Elango > --- > drivers/staging/lustre/lustre/mdc/lproc_mdc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Someone else just sent this same patch before you did, sorry :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Thu, Apr 30, 2015 at 11:25:48PM +0100, One Thousand Gnomes wrote: > On Thu, 30 Apr 2015 16:14:06 +0200 > "gre...@linuxfoundation.org" wrote: > > > On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote: > > > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) > > > wrote: > > > > This patch removes unwanted semicolon around close braces of code blocks > > > > > > > > > The i2o driver moved into staging ready to be deleted unless someone > > > steps up with hardware willing to maintain it (which is rather > > > unlikely). > > > > I think it's now time to delete these, want me to do that for 4.2? I > > can queue that up in my tree now, so that we don't see any more cleanup > > patches being made for them? > > Yeah I think it can go I was about to delete it, but what about drivers/scsi/dpt/dpti_i2o.* ? Should that be removed as well? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Fri, May 01, 2015 at 10:28:00AM +0100, Alan Cox wrote: > On Fri, 2015-05-01 at 09:41 +0200, gre...@linuxfoundation.org wrote: > > On Thu, Apr 30, 2015 at 11:25:48PM +0100, One Thousand Gnomes wrote: > > > On Thu, 30 Apr 2015 16:14:06 +0200 > > > "gre...@linuxfoundation.org" wrote: > > > > > > > On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote: > > > > > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) > > > > > wrote: > > > > > > This patch removes unwanted semicolon around close braces of code > > > > > > blocks > > > > > > > > > > > > > > > The i2o driver moved into staging ready to be deleted unless someone > > > > > steps up with hardware willing to maintain it (which is rather > > > > > unlikely). > > > > > > > > I think it's now time to delete these, want me to do that for 4.2? I > > > > can queue that up in my tree now, so that we don't see any more cleanup > > > > patches being made for them? > > > > > > Yeah I think it can go > > > > I was about to delete it, but what about drivers/scsi/dpt/dpti_i2o.* ? > > Should that be removed as well? > > Possibly but that ought to go via staging and really is one for the SCSI > folks to call. The dpt_i2o was a bit more common than i2o proper. But if the staging i2o core is removed, doesn't that mean that this driver will stop working? It uses code in uapi i2o.h, which I'm guessing is implemented in the staging i2o core. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u: Modify if, else if conditions to remove unnecessary equality checks. This change was detected with the help of coccinelle tool.
On Mon, May 18, 2015 at 04:00:00PM +, Dhere, Chaitanya (C.) wrote: > Signed-off-by: Chaitanya Dhere Your subject line is too long :( Put some information in the change log area here please, above the signed-off-by line. > Reply-To: Why is this here? Please fix up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: sm750fb: replace kzalloc with devm_kzalloc
On Wed, May 27, 2015 at 11:49:47AM +0530, Sudip Mukherjee wrote: > On Wed, May 27, 2015 at 05:56:27AM +, Gujulan Elango, Hari Prasath (H.) > wrote: > > On Wed, May 27, 2015 at 11:10:34AM +0530, Sudip Mukherjee wrote: > > > On Tue, May 26, 2015 at 10:04:44AM +, Gujulan Elango, Hari Prasath > > > (H.) wrote: > > > > replace kzalloc with devm_kzalloc thereby removing the corresponding > > > > kfree. > > > your patch is corrupt and can not be applied. > > > But even then, can this be called as code improvement? > > > > > > regards > > > sudip > > > > > > > > Signed-off-by: Hari Prasath Gujulan Elango > > > > --- > > > > May i know whats wrong with the patch ? I am able to apply it without > > any issue. > > ERROR: patch seems to be corrupt (line wrapped?) > #74: FILE: drivers/staging/sm750fb/sm750.c:1113: > =20 use 'git am' and see if that fixes the issue, that's just "normal" encoding that git can handle just fine. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2] Staging: rtl8192e: Casting correct Endianness
On Tue, May 12, 2015 at 11:30:40AM +, DHANAPAL, GNANACHANDRAN (G.) wrote: > Casting correct Endianness for __le16 variable used in assignment and > condition check. > > Signed-off-by: Gnanachandran Dhanapal > --- > v2:Since previous version of the patch had build error.This > version has no build warnings and error. > --- > drivers/staging/rtl8192e/rtllib_softmac.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c > b/drivers/staging/rtl8192e/rtllib_softmac.c > index 98afd3b..b708dce 100644 > --- a/drivers/staging/rtl8192e/rtllib_softmac.c > +++ b/drivers/staging/rtl8192e/rtllib_softmac.c > @@ -1263,7 +1263,7 @@ inline struct sk_buff *rtllib_association_req(struct > rtllib_network *beacon, > skb_put(skb, sizeof(struct rtllib_assoc_request_frame) + 2); > > > - hdr->header.frame_ctl = RTLLIB_STYPE_ASSOC_REQ; > + hdr->header.frame_ctl = cpu_to_le16(RTLLIB_STYPE_ASSOC_REQ); Extra spaces after the '=' character. > hdr->header.duration_id = cpu_to_le16(37); > memcpy(hdr->header.addr1, beacon->bssid, ETH_ALEN); > memcpy(hdr->header.addr2, ieee->dev->dev_addr, ETH_ALEN); > @@ -2233,9 +2233,9 @@ inline int rtllib_rx_assoc_resp(struct rtllib_device > *ieee, struct sk_buff *skb, > u8 *ies; > struct rtllib_assoc_response_frame *assoc_resp; > struct rtllib_hdr_3addr *header = (struct rtllib_hdr_3addr *) skb->data; > - > + u16 fc = le16_to_cpu(header->frame_ctl); You need a blank line here. And how about naming 'fc' to 'frame_ctl' as that's what it is and makes more sense and is easier to read. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: replace printk with subsystem debug
On Mon, May 18, 2015 at 11:27:38AM +, Gujulan Elango, Hari Prasath (H.) wrote: > replace the printk with netdev subsystem debug infrastructure. > > Signed-off-by: Hari Prasath Gujulan Elango This name doesn't match up to the way you order it in the "From:" line of the patch. Can you please be consistent? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8192e: Timer setup using macro rather assignment
On Mon, May 18, 2015 at 10:12:42PM +0530, Sudip Mukherjee wrote: > On Mon, May 18, 2015 at 09:26:03AM -0700, Joe Perches wrote: > > On Mon, 2015-05-18 at 21:35 +0530, Sudip Mukherjee wrote: > > > On Mon, May 18, 2015 at 02:44:15PM +, DHANAPAL, GNANACHANDRAN (G.) > > > wrote: > > > > setup_timer is used for timer parameter setup rather than direct > > > > assignment > > > > > > > > Signed-off-by: Gnanachandran Dhanapal > > > > > > your From: name and Signed-off-by: names are not matching. They should > > > be same. > > > > If there's a specific "From: " in the _body_ of the email, > > that's true, but the sender email "From: " header and the > > Signed-off-by: line do not have to match. > But Greg usually rejects these patches where the sender "From:" header > and Signed-off-by: doesnot match. Just for example: > > https://lkml.org/lkml/2014/11/25/924 Yes, I can't take it where it doesn't match up. Sometimes I miss it, but when it's pointed out, I will not accept it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: fix indentation issue
On Tue, May 12, 2015 at 12:25:22PM +, Gujulan Elango, Hari Prasath (H.) wrote: > Fixed indentation issue in few lines. > > Signed-off-by: Hari Prasath Gujulan Elango Same name problem :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: emxx_udc: remove commented code
On Tue, May 12, 2015 at 01:56:31PM +, Ravindran, Madhusudhanan (M.) wrote: > removed the commented INFO lines. > > Signed-off-by: Madhusudhanan Ravindran The name here doesn't match the From: line above, please fix that up to match here. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: FW: [PATCH] Staging: vt6655: Remove unnecessary equality checks in rxtx.c
On Fri, May 29, 2015 at 03:54:27PM +, Harisangam, Sharvari (S.) wrote: > Modified the if-else statements to remove unnecessary comparisons in rxtx.c. > This change was detected with the help of coccinelle tool > > Signed-off-by: Harisangam Sharvari > --- > drivers/staging/vt6655/rxtx.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Why did you resend this with a forward? Which one should I take? I'm going to drop both as I don't know what to do, please resend the one you wish to have applied. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: vt6655: Remove unnecessary equality checks for a bool variable
On Thu, May 28, 2015 at 06:10:26AM +, Harisangam, Sharvari (S.) wrote: > Modified the if-else statements to remove unnecessary comparisons. > This change was detected with the help of coccinelle tool > > Signed-off-by: Harisangam Sharvari Name doesn't match... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u: Patch to modify if, else conditions
On Tue, May 19, 2015 at 04:55:57PM +, Dhere, Chaitanya (C.) wrote: > In this patch: > 1. the if condition is modified to remove > the unnecessary equality check. > 2. The else if condition is replaced by an else condition > since the variable checked in the if statement is a bool > making the else if unnecessary. > 3. Fixed indentation problem on line 1369. > These changes were detected with help of coccinelle tool. 3 different things means you need to send 3 different patches. Please only do one logical thing per patch. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: lustre: Replace kzalloc followed by memcpy with kmemdup
On Sat, May 30, 2015 at 10:22:17AM +, Dighe, Niranjan (N.) wrote: > Replace kzalloc followed by memcpy by kmemdup. This patch was generated > by 'make coccicheck' > > Signed-off-by: Niranjan Dighe Your name here doesn't match the name in the From: line of your email. Please fix up your email client for all of the patches you sent me and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: remove unwanted assignment
On Thu, May 14, 2015 at 09:04:00AM +, Gujulan Elango, Hari Prasath (H.) wrote: > remove an unwanted assignment to a variable which is overwritten in the > very next line.The first value assigned is not used. > > Signed-off-by: Hari Prasath Gujulan Elango Your name doesn't match the From: line, please fix up your email client and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Replace kzalloc and memcpy by kmemdup
On Wed, May 20, 2015 at 07:04:27AM +, Dumbre, Nitesh Dilip (N.) wrote: > This patch was generated by coccicheck and replaces kzalloc followed > by memcpy with kmemdup > > Signed-off-by: Nitesh Dumbre Name doesn't match the From: line, please fix your broken email client. WHat is up with this company's email, there is a bunch of patches from different people, all of them broken like this. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rts5208: remove variable and check directly
On Fri, May 15, 2015 at 11:33:53AM +, Gujulan Elango, Hari Prasath (H.) wrote: > This trivial patch removes temporary variable to check return value of > a function and checks return value directly. > > Signed-off-by: Hari Prasath Gujulan Elango Same name problem here, and on all of your other patches you sent in. Please fix up and resend all of them, I've now dropped them from my queue. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv3] staging: sm750fb: Add missing Kconfig dependency
On Thu, May 28, 2015 at 08:51:06AM +, Gujulan Elango, Hari Prasath (H.) wrote: > The sm750fb driver has few Framebuffer configuration dependencies that > need to be selected in order to get compiled successfully. > > Signed-off-by: Gujulan Elango Hari Prasath > --- > v3: Fix alignment issues addressed by Dan Carpenter. > > v2:Addressed the review comments by Sudhip Mukherjee as I had > missed out a few other dependencies for this driver in my previous > version of the patch. > > Signed-off-by: Gujulan Elango Hari Prasath 2 signed-off-by lines??? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] Drivers: hv: vmbus: Use the vp_index map even for channels bound to CPU 0
On Fri, May 29, 2015 at 05:41:34PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Friday, May 29, 2015 10:00 AM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > vkuzn...@redhat.com; jasow...@redhat.com > > Subject: Re: [PATCH 1/3] Drivers: hv: vmbus: Use the vp_index map even for > > channels bound to CPU 0 > > > > On Fri, May 29, 2015 at 11:09:02AM -0700, K. Y. Srinivasan wrote: > > > Map target_cpu to target_vcpu using the mapping table. > > > > > > > It's really hard to tell from this changelog what the user visible > > effects of this patch are. > > We should use the map to transform guest CPU ID to VP Index as is done > For the non-performance critical channels. While the value CPU 0 is special > and will > map to VP index 0, it is good to be consistent. Then put that in the changelog! Please fix up and resend the series. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Replace kzalloc and memcpy by kmemdup
On Sun, May 31, 2015 at 06:13:00AM -0700, Joe Perches wrote: > On Sun, 2015-05-31 at 11:35 +0900, gre...@linuxfoundation.org wrote: > > On Wed, May 20, 2015 at 07:04:27AM +, Dumbre, Nitesh Dilip (N.) wrote: > > > This patch was generated by coccicheck and replaces kzalloc followed > > > by memcpy with kmemdup > > > > > > Signed-off-by: Nitesh Dumbre > > > > Name doesn't match the From: line, please fix your broken email client. > > > > WHat is up with this company's email, there is a bunch of patches from > > different people, all of them broken like this. > > Greg you are being a bit silly here. > > The names match, but the company's email naming > policy is not "first last" but "last, first". > > People generally sign their names "first last". > > Nothing is broken but your desire for exact name > matching. There's also an odd "(H)." in the From line as well. And yes, I do desire that as I know all about the tools we have that try to check these things (numbers of developers, etc.) and some of them don't like mismatched names. Also, it's good for people to learn about "From:" in the body of the email, that's what it is there for :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dgnc: remove ununsed Macro
On Mon, Jun 01, 2015 at 10:08:46AM +, Gujulan Elango, Hari Prasath (H.) wrote: > From: Hari Prasath Gujulan Elango > > Remove the ununsed Macro.This patch needs to be applied after my > previous patch is applied whose title is given below because this macro > becomes ununsed after that.This was suggested by Sudip. If you need patches to be applied in order, please send a patch series, properly numbered. You sent me 3 patches for this driver, and I have no idea what order they need to go in, so I'm going to just drop them all and wait for you to resend them. Remember the text you have in the changelog stays there for forever, don't put things in it that do not matter. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2 1/2] staging: dgnc: delete all references to 'flipbuf'
On Mon, Jun 01, 2015 at 11:29:44PM +0200, Konrad Zapalowicz wrote: > On 06/01, Gujulan Elango, Hari Prasath (H.) wrote: > > From: Hari Prasath Gujulan Elango > > The above line should not be here and it will appear as long as the > email client is not configured correctly. Just take a step back and > fix it as this is something that you do once and then it remains > *correct* forever. We've been over this before, and I have no problem with the way this is done. Some people can't change their email From: line. And even if they can, having a duplicate header with the same line in it doesn't bother me at all, there's far worse issues to complain about with patches. So nothing needs to change here at all, please don't worry about it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: wilc1000: remove unwanted assignment
On Tue, Jun 02, 2015 at 11:37:11AM +, Gujulan Elango, Hari Prasath (H.) wrote: > >From : Hari Prasath Gujulan Elango You need to write this as "From: " not "From :", otherwise git will not work properly. Also, you sent me 5 patches for the same driver, yet no hint as to what order to apply them in. Please resend them in a patch series, properly numbered, so that I can apply them properly. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: vt6655: Remove unnecessary equality checks in rxtx.c
On Mon, Jun 01, 2015 at 04:16:50AM +, Harisangam, Sharvari (S.) wrote: > From: Sharvari Harisangam > > Modified the if-else statements to remove unnecessary comparisons in rxtx.c. > This change was detected with the help of coccinelle tool > > Signed-off-by: Sharvari Harisangam > --- > drivers/staging/vt6655/rxtx.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) This patch can not be applied to my tree :( Please fix it up and resend. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2 1/2] staging: dgnc: delete all references to 'flipbuf'
On Mon, Jun 01, 2015 at 01:06:15PM +, Gujulan Elango, Hari Prasath (H.) wrote: > From: Hari Prasath Gujulan Elango > > This patch deletes all references to 'flipbuf'.Memory is allocated and > freed but never used anywhere in the driver.Also deleted an ununsed > Macro defined in the header file. > > Signed-off-by: Hari Prasath Gujulan Elango > --- > drivers/staging/dgnc/dgnc_driver.c | 9 - > drivers/staging/dgnc/dgnc_driver.h | 1 - > 2 files changed, 10 deletions(-) Does not apply :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] Staging: rtl8192e: Casting correct Endianness
On Tue, Jun 02, 2015 at 03:59:32PM +, DHANAPAL, GNANACHANDRAN (G.) wrote: > From: Gnanachandran Dhanapal > > Casting correct Endianness for __le16 variable used in assignment and > condition check > > Signed-off-by: Gnanachandran Dhanapal > --- > v3: Greg review comments addressed > > --- > drivers/staging/rtl8192e/rtllib_softmac.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c > b/drivers/staging/rtl8192e/rtllib_softmac.c > index 9dce121..a842170 100644 > --- a/drivers/staging/rtl8192e/rtllib_softmac.c > +++ b/drivers/staging/rtl8192e/rtllib_softmac.c > @@ -1265,7 +1265,7 @@ inline struct sk_buff *rtllib_association_req(struct > rtllib_network *beacon, > skb_put(skb, sizeof(struct rtllib_assoc_request_frame) + 2); > > > - hdr->header.frame_ctl = RTLLIB_STYPE_ASSOC_REQ; > + hdr->header.frame_ctl = cpu_to_le16(RTLLIB_STYPE_ASSOC_REQ); > hdr->header.duration_id = cpu_to_le16(37); > ether_addr_copy(hdr->header.addr1, beacon->bssid); > ether_addr_copy(hdr->header.addr2, ieee->dev->dev_addr); > @@ -2244,8 +2244,10 @@ inline int rtllib_rx_assoc_resp(struct rtllib_device > *ieee, struct sk_buff *skb, > struct rtllib_assoc_response_frame *assoc_resp; > struct rtllib_hdr_3addr *header = (struct rtllib_hdr_3addr *) skb->data; > > + u16 frame_ctl = le16_to_cpu(header->frame_ctl); > + Why the blank line before this variable definition? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: fix build warning related to time_after_eq macro
On Tue, Jun 09, 2015 at 06:43:59AM +, Gujulan Elango, Hari Prasath (H.)
wrote:
> From: Hari Prasath Gujulan Elango
>
> This patch fixes a build warning related to the use of the time_after_eq
> macro.Adding a typecast to the second argument suppresses the
> warning.This warning was created by one my previous patch.
>
> Signed-off-by: Hari Prasath Gujulan Elango
> ---
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index 0db7f3d..0441d7b 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -2252,7 +2252,7 @@ void WILC_WFI_p2p_rx (struct net_device *dev, uint8_t
> *buff, uint32_t size)
> if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> PRINT_D(GENERIC_DBG, "Rx Action Frame Type: %x %x\n",
> buff[ACTION_SUBTYPE_ID], buff[P2P_PUB_ACTION_SUBTYPE]);
> - if (priv->bCfgScanning == WILC_TRUE &&
> time_after_eq(jiffies, pstrWFIDrv->u64P2p_MgmtTimeout)) {
> + if (priv->bCfgScanning == WILC_TRUE &&
> time_after_eq(jiffies, (unsigned long)pstrWFIDrv->u64P2p_MgmtTimeout)) {
> PRINT_D(GENERIC_DBG, "Receiving action frames
> from wrong channels\n");
> return;
> }
This patch is corrupted and can not be applied :(
Please fix up and resend.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: Add support for nCipher HSM devices
On Mon, Dec 09, 2019 at 01:56:55PM +, Kim, David wrote:
>
> Hi everybody,
>
> This patch introduces a driver for nCipher's Solo and Solo XC range of PCIe
> hardware security modules (HSM), which provide key creation/management
> and cryptography services.
>
> Upstreaming the nCipher driver into the kernel will allow early adopters
> of the latest kernel to upgrade and maintain their working systems when
> using an nCipher PCIe HSM. Further, having this driver in the kernel will be
> more convenient to our users and make a Linux based solution a more
> attractive option for others.
Odd characters at your line-end here :(
>
> Regards,
> Dave Kim
No need for the "Hi" and "regards" in a changelog text :)
Most importantly, why is this being submitted for the staging directory?
What is keeping it from being added to the "real" part of the kernel
now?
If you need/want it in drivers/staging/ then you need a TODO file that
lists what needs to be done to it in order to get out of
drivers/staging/
thanks,
greg k-h
>
> Co-developed-by: Tim Magee
> Signed-off-by: Tim Magee
> Signed-off-by: David Kim
Odd line-end here :(
>
>
> MAINTAINERS |8 +
> drivers/staging/Kconfig |1 +
> drivers/staging/Makefile |1 +
> drivers/staging/ncipher/Kconfig |8 +
> drivers/staging/ncipher/Makefile |7 +
> drivers/staging/ncipher/fsl.c | 911 ++
> drivers/staging/ncipher/fsl.h | 117 +++
> drivers/staging/ncipher/hostif.c | 1521
> +
> drivers/staging/ncipher/i21555.c | 553 ++
> drivers/staging/ncipher/i21555.h | 68 ++
> drivers/staging/ncipher/solo.h| 316
> include/uapi/linux/nshield_solo.h | 181 +
> 12 files changed, 3692 insertions(+)
>
>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 061d59a4a80b..c1125c999b95 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12605,6 +12605,14 @@ L: linux-...@vger.kernel.org
> S: Supported
> F: drivers/pci/controller/vmd.c
>
> +PCI DRIVER FOR NSHIELD SOLO AND SOLO XC HARDWARE SECURITY MODULES (HSM)
> +M: Tim Magee
> +M: David Kim
> +M: Hamish Cameron
> +L: linux-cry...@vger.kernel.org
> +S: Supported
> +F: drivers/staging/ncipher/
> +
> PCI DRIVER FOR MICROSEMI SWITCHTEC
> M: Kurt Schwemmer
> M: Logan Gunthorpe
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index eaf753b70ec5..0b5498d2415c 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -124,6 +124,7 @@ source "drivers/staging/uwb/Kconfig"
> source "drivers/staging/exfat/Kconfig"
>
> source "drivers/staging/qlge/Kconfig"
> +source "drivers/staging/ncipher/Kconfig"
>
> source "drivers/staging/hp/Kconfig"
>
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 0a4396c9067b..be9f2e811528 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -55,3 +55,4 @@ obj-$(CONFIG_EXFAT_FS) += exfat/
> obj-$(CONFIG_QLGE) += qlge/
> obj-$(CONFIG_NET_VENDOR_HP) += hp/
> obj-$(CONFIG_WFX) += wfx/
> +obj-$(CONFIG_NCIPHER) += ncipher/
> diff --git a/drivers/staging/ncipher/Kconfig b/drivers/staging/ncipher/Kconfig
> new file mode 100644
> index ..5b466cd1896a
> --- /dev/null
> +++ b/drivers/staging/ncipher/Kconfig
> @@ -0,0 +1,8 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Enable support for nCipher's nShield Solo and Solo XC
> +config HSM_NCIPHER_NSHIELD_SOLO
> + tristate "nCipher Solo and Solo XC family of PCIe HSMs"
> + depends on PCI
> + help
> + Select this as built-in or module if you expect to use
> + a Hardware Security Module from nCipher's Solo or Solo XC range.
> diff --git a/drivers/staging/ncipher/Makefile
> b/drivers/staging/ncipher/Makefile
> new file mode 100644
> index ..b4d5f92addee
> --- /dev/null
> +++ b/drivers/staging/ncipher/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Makefile for nCipher nShield HSM drivers
> +#
> +
> +obj-$(CONFIG_HSM_NCIPHER_NSHIELD_SOLO) := nshield_solo.o
> +nshield_solo-y := hostif.o fsl.o i21555.o
> diff --git a/drivers/staging/ncipher/fsl.c b/drivers/staging/ncipher/fsl.c
> new file mode 100644
> index ..5c4edeef64c0
> --- /dev/null
> +++ b/drivers/staging/ncipher/fsl.c
> @@ -0,0 +1,911 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + *
> + * fsl.c: nCipher PCI HSM FSL command driver
> + * Copyright 2019 nCipher Security Ltd
> + *
> + */
> +
> +#include "solo.h"
> +#include "fsl.h"
> +
> +/**
> + * Resets FSL device.
> + *
> + * Extra device info is initialized the first time created.
> + *
> + * @param ndev common device.
> + * @returns 0 if successful, other value if error.
> + */
> +static int fsl_create(struct nfp_dev *ndev)
> +{
> + /* check for device */
> + if (!ndev) {
> + pr_err("%s: error: no device", __func__);
> + return -ENODEV;
> + }
Patch is totally corrupted and could not be applied even if I wanted to
:(
Can yo
Re: [PATCH] drivers: staging: Add support for nCipher HSM devices
On Mon, Dec 09, 2019 at 03:41:51PM +, Kim, David wrote: > Hi Greg, > > Thanks for the speedy reply. I was hoping that setting my client to > plain text only would actually do plain text only but I will try again > with git send-email. > > This is our first driver upstreaming and we targeted staging as a > first entry point. If you feel it's more appropriate when I re-submit > I can go directly to drivers/crypto instead. Well why wouldn't it go to drivers/crypto instead? What is wrong with it that still needs to be done? Only stuff that needs work belongs in drivers/staging/. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: Add MA USB Host driver
On Mon, Jan 20, 2020 at 09:30:43AM +, Vladimir Stankovic wrote: > MA-USB Host driver provides USB connectivity over an available > network, allowing host device to access remote USB devices attached > to one or more MA USB devices (accessible via network). > > This driver has been developed to enable the host to communicate > with DislayLink products supporting MA USB protocol (MA USB device, > in terms of MA USB Specification). > > MA-USB protocol used by MA-USB Host driver has been implemented in > accordance with MA USB Specification Release 1.0b. > > This driver depends on the functions provided by DisplayLink's > user-space driver. > > Signed-off-by: Vladimir Stankovic Why is this being submitted to staging and not to the "real" part of the kernel? You need a TODO file that lists what is left to be done to the driver to get it merged to the proper place in the kernel tree. Can you please resubmit with that file added to the patch? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [External] Re: staging: Add MA USB Host driver
On Wed, Jan 22, 2020 at 07:40:59AM +, Vladimir Stankovic wrote: > Hi Greg, > > Our intention was to follow Linux kernel development process and add our > driver to staging first. That's not the "normal" development process at all, where did you read that? staging is only for code that needs lots of work, and almost always merging a driver through staging takes _more_ work from the submitter than it does to submit it through the "normal" subsystem. So if you want to do more work, hey, by all means, send it here :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [External] Re: staging: Add MA USB Host driver
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Jan 22, 2020 at 08:16:09AM +, Vladimir Stankovic wrote: > Hi Greg, > > It was section 2.5 of the kernel development process, "staging trees". > In particular, statement "where many sub-directories for drivers or > filesystems that are on their way to being added to the kernel tree > live" caught our attention. > > Now, by reading it once again, I see that the rest of the section is in > line with your comment. > > We'll address all comments received so far, and resubmit patch onto > appropriate repository. With that being said, is USB subsystem tree > (drivers/usb within usb.git repo) correct one? Please, advise. If this is a USB host driver, then yes, drivers/usb/host/ would be the correct location for this. Note, at first glance, there is a bunch of work to do on this to get it into "real" mergable shape. Be sure to at the very least get it 'checkpatch.pl clean' before submitting it, that will help out a lot, if it is not already done. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH] staging: exfat: Fix alignment warnings
On Sat, Jan 25, 2020 at 05:49:48PM +0530, Pragat Pandya wrote: > Fix checkpatch warning "Alignment should match open parenthesis". > > Signed-off-by: Pragat Pandya > --- > drivers/staging/exfat/exfat_blkdev.c | 4 ++-- > drivers/staging/exfat/exfat_core.c | 29 ++-- > drivers/staging/exfat/exfat_super.c | 2 +- > 3 files changed, 18 insertions(+), 17 deletions(-) > > diff --git a/drivers/staging/exfat/exfat_blkdev.c > b/drivers/staging/exfat/exfat_blkdev.c > index 7bcd98b13109..3068bfda39e4 100644 > --- a/drivers/staging/exfat/exfat_blkdev.c > +++ b/drivers/staging/exfat/exfat_blkdev.c > @@ -31,7 +31,7 @@ void exfat_bdev_close(struct super_block *sb) > } > > int exfat_bdev_read(struct super_block *sb, sector_t secno, struct > buffer_head **bh, > - u32 num_secs, bool read) > + u32 num_secs, bool read) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch is malformed (tabs converted to spaces, linewrapped, etc.) and can not be applied. Please read the file, Documentation/email-clients.txt in order to fix this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: octeon: delete driver
On Tue, Feb 04, 2020 at 04:02:15AM +, Chris Packham wrote: > I'll pipe up on this thread too > > On Tue, 2019-12-10 at 02:42 -0800, Guenter Roeck wrote: > > On 12/10/19 1:15 AM, Greg Kroah-Hartman wrote: > > > This driver has been in the tree since 2009 with no real movement to get > > > it out. Now it is starting to cause build issues and other problems for > > > people who want to fix coding style problems, but can not actually build > > > it. > > > > > > As nothing is happening here, just delete the module entirely. > > > > > > Reported-by: Guenter Roeck > > > Cc: David Daney > > > Cc: "David S. Miller" > > > Cc: "Matthew Wilcox (Oracle)" > > > Cc: Guenter Roeck > > > Cc: YueHaibing > > > Cc: Aaro Koskinen > > > Cc: Wambui Karuga > > > Cc: Julia Lawall > > > Cc: Florian Westphal > > > Cc: Geert Uytterhoeven > > > Cc: Branden Bonaby > > > Cc: "Petr Štetiar" > > > Cc: Sandro Volery > > > Cc: Paul Burton > > > Cc: Dan Carpenter > > > Cc: Giovanni Gherdovich > > > Cc: Valery Ivanov > > > Signed-off-by: Greg Kroah-Hartman > > > > Acked-by: Guenter Roeck > > Please can we keep this driver. We do have platforms using it and we > would like it to stay around. > > Clearly we'll need to sort things out to a point where they build > successfully. We've been hoping to see this move out of staging ever > since we selected Cavium as a vendor. Great, can you send me a patchset that reverts this and fixes the build issues and accept maintainership of the code? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: octeon-usb: delete the octeon usb host controller driver
On Tue, Feb 04, 2020 at 04:06:51AM +, Chris Packham wrote: > On Tue, 2019-12-10 at 10:15 +0100, Greg Kroah-Hartman wrote: > > This driver was merged back in 2013 and shows no progress toward every > > being merged into the "correct" part of the kernel. The code doesn't > > even build for anyone unless you have the specific hardware platform > > selected, so odds are it doesn't even work anymore. > > > > Remove it for now and is someone comes along that has the hardware and > > is willing to fix it up, it can be reverted. > > > > Cc: Aaro Koskinen > > Cc: David Daney > > Cc: Nishka Dasgupta > > Cc: Himadri Pandya > > Cc: "Frank A. Cancio Bello" > > Cc: Sumit Pundir > > Cc: Laura Lazzati > > Signed-off-by: Greg Kroah-Hartman > > --- > > Similarly we'd really like to keep this too. Great, same thing here! thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/octeon: Mark Ethernet driver as BROKEN
On Tue, Feb 04, 2020 at 12:54:26AM +, Chris Packham wrote: > Hi Greg & All, > > On Mon, 2019-12-02 at 19:15 +0100, Greg Kroah-Hartman wrote: > > On Mon, Dec 02, 2019 at 09:36:20AM -0800, Guenter Roeck wrote: > > > On Mon, Dec 02, 2019 at 05:52:31PM +0100, Greg Kroah-Hartman wrote: > > > > On Mon, Dec 02, 2019 at 06:18:36AM -0800, Guenter Roeck wrote: > > > > > The code doesn't compile due to incompatible pointer errors > > > > > such as > > > > > > > > > > drivers/staging/octeon/ethernet-tx.c:649:50: error: > > > > > passing argument 1 of 'cvmx_wqe_get_grp' from > > > > > incompatible pointer type > > > > > > > > > > This is due to mixing, for example, cvmx_wqe_t with 'struct > > > > > cvmx_wqe'. > > > > > > > > > > Unfortunately, one can not just revert the primary offending > > > > > commit, as doing so > > > > > results in secondary errors. This is made worse by the fact > > > > > that the "removed" > > > > > typedefs still exist and are used widely outside the staging > > > > > directory, > > > > > making the entire set of "remove typedef" changes pointless and > > > > > wrong. > > > > > > > > Ugh, sorry about that. > > > > > > > > > Reflect reality and mark the driver as BROKEN. > > > > > > > > Should I just delete this thing? No one seems to be using it and > > > > there > > > > is no move to get it out of staging at all. > > > > > > > > Will anyone actually miss it? It can always come back of someone > > > > does... > > > > > > > > > > All it does is causing trouble and misguided attempts to clean it > > > up. > > > If anything, the whole thing goes into the wrong direction (declare > > > a > > > complete set of dummy functions just to be able to build the driver > > > with COMPILE_TEST ? Seriously ?). > > > > > > I second the motion to drop it. This has been in staging for 10 > > > years. > > > Don't we have some kind of time limit for code in staging ? If not, > > > should we ? If anyone really needs it, that person or group should > > > really invest the time to get it out of staging for good. > > > > 10 years? Ugh, yes, it's time to drop the thing, I'll do so after > > -rc1 > > is out. > > > > As a long suffering Cavium MIPs customer could I request that this > isn't dropped. I'll get someone here to take a look at fixing the build > issues. > > Given our platform isn't upstream I'm not sure that we'll be able to > meet the criteria for getting it out of staging. > Can't you push this onto Cavium as you are paying them for hardware and support? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: octeon: delete driver
On Tue, Feb 04, 2020 at 12:31:16PM -0800, Matthew Wilcox wrote: > On Tue, Feb 04, 2020 at 08:06:14PM +, Chris Packham wrote: > > On Tue, 2020-02-04 at 07:09 +, gre...@linuxfoundation.org wrote: > > > On Tue, Feb 04, 2020 at 04:02:15AM +, Chris Packham wrote: > > > > I'll pipe up on this thread too > > > > > > > > On Tue, 2019-12-10 at 02:42 -0800, Guenter Roeck wrote: > > > > > On 12/10/19 1:15 AM, Greg Kroah-Hartman wrote: > > > > > > This driver has been in the tree since 2009 with no real movement > > > > > > to get > > > > > > it out. Now it is starting to cause build issues and other > > > > > > problems for > > > > > > people who want to fix coding style problems, but can not actually > > > > > > build > > > > > > it. > > > > > > > > > > > > As nothing is happening here, just delete the module entirely. > > > > > > > > > > > > Reported-by: Guenter Roeck > > > > > > Cc: David Daney > > > > > > Cc: "David S. Miller" > > > > > > Cc: "Matthew Wilcox (Oracle)" > > > > > > Cc: Guenter Roeck > > > > > > Cc: YueHaibing > > > > > > Cc: Aaro Koskinen > > > > > > Cc: Wambui Karuga > > > > > > Cc: Julia Lawall > > > > > > Cc: Florian Westphal > > > > > > Cc: Geert Uytterhoeven > > > > > > Cc: Branden Bonaby > > > > > > Cc: "Petr Štetiar" > > > > > > Cc: Sandro Volery > > > > > > Cc: Paul Burton > > > > > > Cc: Dan Carpenter > > > > > > Cc: Giovanni Gherdovich > > > > > > Cc: Valery Ivanov > > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > > > > Acked-by: Guenter Roeck > > > > > > > > Please can we keep this driver. We do have platforms using it and we > > > > would like it to stay around. > > > > > > > > Clearly we'll need to sort things out to a point where they build > > > > successfully. We've been hoping to see this move out of staging ever > > > > since we selected Cavium as a vendor. > > > > > > Great, can you send me a patchset that reverts this and fixes the build > > > issues and accept maintainership of the code? > > > > > > > Yep will do. > > > > On Tue, 2020-02-04 at 10:21 +0300, Dan Carpenter wrote: > > > My advice is to delete all the COMPILE_TEST code. That stuff was a > > > constant source of confusion and headaches. > > > > I was also going to suggest this. Since the COMPILE_TEST has been a > > source of trouble I was going to propose dropping the || COMPILE_TEST > > from the Kconfig for the octeon drivers. > > Not having it also causes problems. I didn't originally add it for > shits and giggles. Yes, without this option, the code bit-rotted horribly. It needs to be able to be built otherwise people will change the code and it will break and no one will notice except Guenter's build bots and then no one will fix it :( i.e. exactly what was happening before... So this needs to all be fixed up properly, and really, should be merged to the "real" part of the kernel... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers
On Wed, Mar 04, 2020 at 03:19:55PM +, Stahl, Manuel wrote: > Hi Greg, > > so somehow this discussion stopped without any instructions how to proceed. What is "this discussion"? > I think this kind of driver helps every FPGA developer to interface > his design via PCIe to a Linux PC. > So if there is any chance to get this code merged, I'm glad to rebase > this onto the latest kernel release. Please rebase and resubmit, it's a patch from 2 1/2 years ago, not much I can even remember about patch sets sent last week... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Add new uio device for PCI with dynamic memory allocation
On Tue, Apr 28, 2020 at 03:47:42PM +, Stahl, Manuel wrote: > > > > > + return err; > > > + } > > > + pci_set_master(pdev); > > > + > > > + dev_info(&pdev->dev, "Legacy IRQ: %i", pdev->irq); > > > > Again, remove, be quiet :) > > Use dev_dbg() or remove completely? If it helps in debugging, dev_dbg() is fine to use. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Add new uio device for PCI with dynamic memory allocation
On Wed, Apr 29, 2020 at 07:51:01AM +, Stahl, Manuel wrote: > On Di, 2020-04-28 at 15:54 +0200, gregkh @ linuxfoundation . org wrote: > > On Thu, Apr 16, 2020 at 06:38:30PM +0200, Manuel Stahl wrote: > > > > > > + * > > > + * Since the driver does not declare any device ids, you must allocate > > > + * id and bind the device to the driver yourself. For example: > > > + * > > > + * # echo "8086 10f5" > /sys/bus/pci/drivers/uio_pci_dmem_genirq/new_id > > > + * # echo -n :00:19.0 > /sys/bus/pci/drivers/e1000e/unbind > > > + * # echo -n :00:19.0 > /sys/bus/pci/drivers/uio_pci_dmem_genirq/bind > > > + * # ls -l /sys/bus/pci/devices/:00:19.0/driver > > > + * .../:00:19.0/driver -> > > > ../../../bus/pci/drivers/uio_pci_dmem_genirq > > > + * > > > + * Or use a modprobe alias: > > > + * # alias pci:v10EEd1000sv*sd*sc*i* uio_pci_dmem_genirq > > > + * > > > + * Driver won't bind to devices which do not support the Interrupt > > > Disable Bit > > > + * in the command register. All devices compliant to PCI 2.3 (circa > > > 2002) and > > > + * all compliant PCI Express devices should support this bit. > > > + * > > > + * The DMA mask bits and sizes of dynamic regions are derived from module > > > + * parameters. > > > + * > > > + * The format for specifying dynamic region sizes in module parameters > > > + * is as follows: > > > + * > > > + * uio_pci_dmem_genirq.dmem_sizes := > > > [;] > > > + *:= :[,] > > > + *:= : > > > + * := standard linux memsize > > > + * > > > + * Examples: > > > + * > > > + * 1) UIO dmem device with 3 dynamic regions: > > > + * uio_pci_dmem_genirq.dmem_sizes=8086:10f5:4K,16K,4M > > > + * > > > + * 2) Two UIO dmem devices with different number of dynamic regions: > > > + * uio_pci_dmem_genirq.dmem_sizes=8086:10f5:4K,16K,4M;1234:0001:8K > > > > Module parameters are horrid, are you sure there is no other way? > > You're right, seemed to be the simplest solution back when we started > developing this driver. I will try to change it to sysfs, so that one can add > regions while the module is already loaded. /me hands you some \n characters... Anyway, configfs is for configuring stuff, don't make a sysfs file that you have to somehow "parse" please. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 41/48] staging: comedi: pcl812: use comedi_timeout()
On Fri, Feb 07, 2014 at 04:14:01PM +, Hartley Sweeten wrote: > On Friday, February 07, 2014 8:34 AM, Ian Abbott wrote: > > On 2014-02-06 23:49, H Hartley Sweeten wrote: > >> Use comedi_timeout() to wait for the analog input end-of-conversion. > >> > >> Combine the logic for the pcl812 and acl812 end-of-conversion in the > >> helper function to simplify the driver. > >> > >> The interrupt routine also uses the timeout check to make sure data > >> is actually available. Using NULL here for the 'insn' is safe since > >> nothing uses it. > > > > I don't think you can rely on jiffies being updated in the interrupt > > routine. > > From previous comments from Greg I assumed using jiffies for the > timeout was ok in interrupt contexts, we just couldn't use cpu_relax(). > But, I could be wrong. Hopefully someone might be able to provide > some more information on this. Unless you are the timer interrupt, I'm pretty sure that jiffies is ok to use in interrupt context. But I could be totally wrong, it's been years since I looked at that. Try it and see! :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
