Re: [PATCH v4] staging: gdm724x: Fix DMA from stack

[gre...@linuxfoundation.org]

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

[gre...@linuxfoundation.org]

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: [PATCH v4] Add new uio device for PCI with dynamic memory allocation

[gre...@linuxfoundation.org]

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 v4] Add new uio device for PCI with dynamic memory allocation

[gre...@linuxfoundation.org]

On Tue, Apr 28, 2020 at 03:47:42PM +, Stahl, Manuel wrote:
> > 
> > > + return err;
> > > + }
> > > + pci_set_master(pdev);
> > > +
> > > + dev_info(>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 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

[gre...@linuxfoundation.org]

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 1/2] staging: octeon: delete driver

[gre...@linuxfoundation.org]

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] staging/octeon: Mark Ethernet driver as BROKEN

[gre...@linuxfoundation.org]

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 2/2] staging: octeon-usb: delete the octeon usb host controller driver

[gre...@linuxfoundation.org]

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 1/2] staging: octeon: delete driver

[gre...@linuxfoundation.org]

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: [RESEND PATCH] staging: exfat: Fix alignment warnings

[gre...@linuxfoundation.org]

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: [External] Re: staging: Add MA USB Host driver

[gre...@linuxfoundation.org]

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: [External] Re: staging: Add MA USB Host driver

[gre...@linuxfoundation.org]

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: staging: Add MA USB Host driver

[gre...@linuxfoundation.org]

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: [PATCH] drivers: staging: Add support for nCipher HSM devices

[gre...@linuxfoundation.org]

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: [PATCH] drivers: staging: Add support for nCipher HSM devices

[gre...@linuxfoundation.org]

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 

Re: [PATCH v2 1/3] staging: wfx: replace uintXX_t to uXX and intXX_t to sXX

[gre...@linuxfoundation.org]

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] Adjust analogix chip driver location

[gre...@linuxfoundation.org]

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: kpc2000: To make symbols static

[gre...@linuxfoundation.org]

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] staging: isdn: To make hysdn_proc_entry static.

[gre...@linuxfoundation.org]

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 v2] kpc_i2c: Remove unused file

['gre...@linuxfoundation.org']

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: RFC: kpc2000 driver naming

['gre...@linuxfoundation.org']

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: RFC: kpc2000 driver naming

['gre...@linuxfoundation.org']

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)
> >>   KPC2000_I2C depends on KPC2000 && I2C (this

Re: RFC: kpc2000 driver naming

['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.

> 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

Re: [PATCH v2] staging: kpc2000: Add DMA driver

['gre...@linuxfoundation.org']

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: [PATCH] staging: kpc2000: Add DMA driver

['gre...@linuxfoundation.org']

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] Staging: greybus: pwm: fixed a coding style issue

[gre...@linuxfoundation.org]

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] staging: mt7621-eth/ethtool.c: Correction of SPDX license identifier

[gre...@linuxfoundation.org]

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 v2] staging: mt7621-eth/ethtool.c: Correction of SPDX license identifier

[gre...@linuxfoundation.org]

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

[gre...@linuxfoundation.org]

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: linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: (style) Expression is always false

[gre...@linuxfoundation.org]

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 : Add RIFFA PCIe staging driver

[gre...@linuxfoundation.org]

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] Staging : Add RIFFA PCIe staging driver

[gre...@linuxfoundation.org]

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] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

[gre...@linuxfoundation.org]

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] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

[gre...@linuxfoundation.org]

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] Staging : Add RIFFA PCIe driver

[gre...@linuxfoundation.org]

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 

Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

[gre...@linuxfoundation.org]

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: rtl8188eu: Fix off-by-one in core/rtw_mlme_ext.c

[gre...@linuxfoundation.org]

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] Staging : Add RIFFA PCIe driver

[gre...@linuxfoundation.org]

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 V4] binder: ipc namespace support for android binder

[gre...@linuxfoundation.org]

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 v2] staging: vc04_services: bcm2835-audio: Fixed warnings, checks

[gre...@linuxfoundation.org]

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] staging: vc04_services: bcm2835-audio: Fixed warnings, checks

[gre...@linuxfoundation.org]

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(>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] staging: vc04_services: bcm2835-audio: Fixed warnings

[gre...@linuxfoundation.org]

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 V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

[gre...@linuxfoundation.org]

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 : Add RIFFA PCIe driver

[gre...@linuxfoundation.org]

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

[gre...@linuxfoundation.org]

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 V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

[gre...@linuxfoundation.org]

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] Staging : Add RIFFA PCIe driver

[gre...@linuxfoundation.org]

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] Add RIFFA PCIe driver to staging tree

[gre...@linuxfoundation.org]

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 2/5] vmbus: add driver_override support

[gre...@linuxfoundation.org]

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] Drivers: hv: vmbus: Removed an unnecessary cast from void *

['gre...@linuxfoundation.org']

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] Drivers: hv: vmbus: Removed an unnecessary cast from void *

['gre...@linuxfoundation.org']

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 5/5] staging: fsl-mc/dpio: Remove dead code

[gre...@linuxfoundation.org]

On Tue, Mar 06, 2018 at 06:32:00PM +, Ruxandra Ioana Ciocoi Radulescu wrote:
> > -Original Message-
> > From: Ruxandra Ioana Ciocoi Radulescu
> > Sent: Tuesday, March 6, 2018 7:44 PM
> > To: gre...@linuxfoundation.org
> > Cc: de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org; Roy Pledge
> > <roy.ple...@nxp.com>; Laurentiu Tudor <laurentiu.tu...@nxp.com>
> > Subject: [PATCH 5/5] staging: fsl-mc/dpio: Remove dead code
> > 
> > Function qbman_pull_desc_set_token() is not used at all, so remove it.
> > 
> > Signed-off-by: Ioana Radulescu <ruxandra.radule...@nxp.com>
> > ---
> >  drivers/staging/fsl-mc/bus/dpio/qbman-portal.c | 5 -
> >  1 file changed, 5 deletions(-)
>  
> Hi Greg,
> 
> Please ignore this patch, I've just noticed you already applied another
> patch with the same content a couple of hours ago.

Not a problem, now ignored :)

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()

[gre...@linuxfoundation.org]

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 v3] staging: fsl-mc: use 32bits to support 64K size mc-portals

[gre...@linuxfoundation.org]

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: [REVIEW REQUEST] staging: unisys: review request for visorbus

[gre...@linuxfoundation.org]

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 *)(>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: [REVIEW REQUEST] staging: unisys: review request for visorbus

[gre...@linuxfoundation.org]

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 *)(>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

[gre...@linuxfoundation.org]

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

[PATCH] staging: unisys: don't care about debugfs errors

[gre...@linuxfoundation.org]

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 <david.kersh...@unisys.com>
Cc: Tim Sell <timothy.s...@unisys.com>
Cc: Sameer Wadgaonkar <sameer.wadgaon...@unisys.com>
Cc: David Binder <david.bin...@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>


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(_driverinfo, "clientbus", "visorbus");
err = bus_register(_type);
if (err < 0)
___
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

[gre...@linuxfoundation.org]

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

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

[gre...@linuxfoundation.org]

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: [REVIEW REQUEST] staging: unisys: review request for visorbus

[gre...@linuxfoundation.org]

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] staging: fsl-mc/dpio: Fix incorrect comparison

[gre...@linuxfoundation.org]

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 <ruxandra.radule...@nxp.com>
> > Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org;
> > a...@arndb.de; stuyo...@gmail.com; Roy Pledge <roy.ple...@nxp.com>;
> > linux-ker...@vger.kernel.org; ag...@suse.de; Bogdan Purcareata
> > <bogdan.purcare...@nxp.com>; Laurentiu Tudor
> > <laurentiu.tu...@nxp.com>
> > 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: [PATCH 00/45] staging: unisys: more changes to the code.

[gre...@linuxfoundation.org]

On Thu, Aug 10, 2017 at 08:18:54PM +, Kershner, David A wrote:
> > -Original Message-
> > From: David Kershner [mailto:david.kersh...@unisys.com]
> > Sent: Tuesday, August 1, 2017 10:40 AM
> > To: gre...@linuxfoundation.org; driverdev-devel@linuxdriverproject.org;
> > *S-Par-Maintainer <sparmaintai...@unisys.com>; jes.soren...@gmail.com
> > Cc: Kershner, David A <david.kersh...@unisys.com>
> > Subject: [PATCH 00/45] staging: unisys: more changes to the code.
> > 
> > The following patch series addresses issues from internal code-review as
> > well as checkpatch errors and suggestions from GregKH.
> > 
> > We have updated our commenting style to be more readable (and adopted a
> > kernel-doc like format). We have intentionally not made them kernel-doc by
> > removing the extra asterisk from the first line.
> > 
> 
> Greg, I just realized that although the patchset applies cleanly to
> staging-next, it will conflict with the patch:
> 
>   Subject: [PATCH v2] staging: unisys: Switch to use new generic UUID
> API
>   From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> 
> So feel free to drop the series and accept his and I can fix the conflicts,
> or
> do you want to drop all the patches and I pick it up and resend the series
> with the patch included?

I'll drop all of the patches, and wait for you to resend them all with
his patch as part of the series.  That's the easiest for me :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3] staging: typec: add tcpci_write16_le.

[gre...@linuxfoundation.org]

On Mon, Jun 19, 2017 at 10:11:34AM +, ? ? wrote:
> From: Pan Li 
> 
> Add tcpci_write16_le for pd_message header type __le16.

That says what it does, but you need to explain _why_ it is needed as
well.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] staging: typec: Replace pd_header_cnt with pd_header_cnt_le

[gre...@linuxfoundation.org]

On Mon, Jun 19, 2017 at 10:11:07AM +, ? ? wrote:
> From: Pan Li 
> 
> Convertn __le to cpu type when access pd_header count.

I think you have a typo in this sentance :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] staging: typec: Replace pd_header_cnt with pd_header_cnt_le

[gre...@linuxfoundation.org]

On Sun, Jun 11, 2017 at 10:53:19AM +, ? ? wrote:
> From: Pan Li 
> 
> Convertn __le to cpu type when access pd_header count.

Please do not indent, and please spell check where ever possible.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Restrict argument of tcpci_read16

[gre...@linuxfoundation.org]

On Fri, Jun 02, 2017 at 02:59:32AM +, ? ? wrote:
> From: Pan Li 
> 
> Pan Li (1):
>   Restrict read pointer to 16 bit of tcpci_read16.

Please fix up your subject line to properly describe what part of the
kernel you are modifying.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: sm750fb: Combine set GPIO 30 & 31 into one statement

[gre...@linuxfoundation.org]

On Tue, Apr 25, 2017 at 03:53:02PM +, Lynn Lei wrote:
> Combine two separate set GPIO(30 & 31) operations into one statement.

Why?

> 
> Signed-off-by: Lynn Lei 
> ---
>  drivers/staging/sm750fb/ddk750_hwi2c.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c 
> b/drivers/staging/sm750fb/ddk750_hwi2c.c
> index 68716ef7cb06..ddb7a6dc265a 100644
> --- a/drivers/staging/sm750fb/ddk750_hwi2c.c
> +++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
> @@ -49,8 +49,7 @@ void sm750_hw_i2c_close(void)
>  
>   /* Set GPIO 30 & 31 back as GPIO pins */
>   value = peek32(GPIO_MUX);
> - value &= ~GPIO_MUX_30;
> - value &= ~GPIO_MUX_31;
> + value &= ~(GPIO_MUX_30 | GPIO_MUX_31);

Why does this matter?

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

[gre...@linuxfoundation.org]

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 Mon, Apr 03, 2017 at 05:57:11PM +, Long Li wrote:
> I think we need both going forward. They addressed different problems.

I have no idea what this means or what to do...

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

[gre...@linuxfoundation.org]

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 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[gre...@linuxfoundation.org]

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: [PATCH 05/14] netvsc: remove no longer needed receive staging buffers

[gre...@linuxfoundation.org]

On Tue, Feb 07, 2017 at 12:32:12AM +, Stephen Hemminger wrote:
> The netvsc part is already in net-next.  This patch is not needed.
> The part that removes the per-channel state can be in another patch.

I have no idea what that means to me here, nor what I need to do, so I'm
just deleting this email :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 10:24:32AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > To: Dexuan Cui <de...@microsoft.com>
> > >
> > > v4.4.44 needs 2 patches, i.e. a389fcfd2cb5, and this patch (which is not 
> > > in
> > > Linus's tree yet).  Only backporting the first patch immediately is not 
> > > enough
> > > and is also improper IMO, because the first patch introduces a new issue,
> > > which is being resolved by this patch. So my understanding is that I 
> > > should
> > > backport the 2 patches together.
> > 
> > Ok, that makes a bit more sense, thanks.  I'll wait for your "real"
> > patch to hit Linus's tree then.
> > 
> > greg k-h
> 
> Hi Greg,
> I expect this patch (i.e. the "real" patch) would go in your char-misc tree 
> first,
> then it would be merged into Linus's tree, as we usually did.

That's fine, I'll wait for the maintainer of the subsystem to forward it
on to me, like all other hyperv patches :)

Or, at the very least, have one of them ack it so that I can take it...

thanks,

greg k-hmu

> 
> IMO this is an important fix, but it's not so urgent that Linus would notice
> it and pick it up directly.
> 
> Thanks,
> -- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 09:31:32AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > > > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > > > > > > It's interesting v4.4.44 is not impacted, but actually it needs 
> > > > > > > both the 2
> > > > patches:
> > > > > > > i.e. this patch, and the previous one:
> > > > > > > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> > > > > > hv_need_to_signal_on_read()")
> > > > > >
> > > > > > That patch does not apply to the 4.4-stable tree, which is why it 
> > > > > > was
> > > > > > not included there.  If you feel it should be included, please 
> > > > > > provide a
> > > > > > backport and send it to the sta...@vger.kernel.org mailing list.
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > Thanks! I'll do the backport after this patch goes in the mainline.
> > > >
> > > > Why wait?
> > >
> > > I thought a patch must first appear in Linus's tree, before it can be
> > > back-ported to the stable tree?
> > 
> > Commit a389fcfd2cb5 _IS_ in Linus's tree, it was released in the 4.7-rc1
> > kernel, which happened in May of 2016.
> > 
> > greg k-h
> 
> Sorry, it looks I didn't make it clear. :-)
> 
> v4.4.44 needs 2 patches, i.e. a389fcfd2cb5, and this patch (which is not in
> Linus's tree yet).  Only backporting the first patch immediately is not enough
> and is also improper IMO, because the first patch introduces a new issue,
> which is being resolved by this patch. So my understanding is that I should
> backport the 2 patches together.

Ok, that makes a bit more sense, thanks.  I'll wait for your "real"
patch to hit Linus's tree then.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 08:27:26AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > > > > It's interesting v4.4.44 is not impacted, but actually it needs both 
> > > > > the 2
> > patches:
> > > > > i.e. this patch, and the previous one:
> > > > > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> > > > hv_need_to_signal_on_read()")
> > > >
> > > > That patch does not apply to the 4.4-stable tree, which is why it was
> > > > not included there.  If you feel it should be included, please provide a
> > > > backport and send it to the sta...@vger.kernel.org mailing list.
> > > >
> > > > greg k-h
> > >
> > > Thanks! I'll do the backport after this patch goes in the mainline.
> > 
> > Why wait?
> 
> I thought a patch must first appear in Linus's tree, before it can be
> back-ported to the stable tree?

Commit a389fcfd2cb5 _IS_ in Linus's tree, it was released in the 4.7-rc1
kernel, which happened in May of 2016.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 07:44:46AM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > > Dexuan Cui <de...@microsoft.com> wrote:
> > > As I checked against the kernels listed on the homapage,
> > > the below versions are impacted:
> > > v3.16.39
> > > v3.18.47
> > > v4.1.38
> > > v4.8.17
> > > v4.9.5
> > > v4.10-rc5
> > >
> > > It's interesting v4.4.44 is not impacted, but actually it needs both the 
> > > 2 patches:
> > > i.e. this patch, and the previous one:
> > > Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
> > hv_need_to_signal_on_read()")
> > 
> > That patch does not apply to the 4.4-stable tree, which is why it was
> > not included there.  If you feel it should be included, please provide a
> > backport and send it to the sta...@vger.kernel.org mailing list.
> > 
> > greg k-h
> 
> Thanks! I'll do the backport after this patch goes in the mainline.

Why wait?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

[gre...@linuxfoundation.org]

On Thu, Jan 26, 2017 at 06:10:19AM +, Dexuan Cui wrote:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, January 25, 2017 00:08
> > To: Dexuan Cui <de...@microsoft.com>
> > Cc: gre...@linuxfoundation.org; driverdev-devel@linuxdriverproject.org; KY
> > Srinivasan <k...@microsoft.com>; Haiyang Zhang <haiya...@microsoft.com>;
> > Stephen Hemminger <sthem...@microsoft.com>; o...@aepfle.de; Rolf
> > Neugebauer <rolf.neugeba...@docker.com>; jasow...@redhat.com; linux-
> > ker...@vger.kernel.org; a...@canonical.com
> > Subject: Re: [PATCH] Drivers: hv: vmbus: finally fix 
> > hv_need_to_signal_on_read()
> > 
> > On Tue, 24 Jan 2017 06:54:46 +
> > Dexuan Cui <de...@microsoft.com> wrote:
> > 
> > > +static inline void
> > > +init_cached_read_index(struct vmbus_channel *channel)
> > > +{
> > > + struct hv_ring_buffer_info *rbi = >inbound;
> > > +
> > > + rbi->cached_read_index = rbi->ring_buffer->read_index;
> > > +}
> > 
> > Looks good thanks. This should go in right away. Which versions are 
> > impacted?
> > Should it also go to stable?
> 
> Yes, it needs to go to stable.
> I have Cc-ed  <sta...@vger.kernel.org> in the patch's changelog, so it should 
> be
> included in the stable tree automatically.
> 
> As I checked against the kernels listed on the homapage of www.kernel.org, the
> below versions are impacted:
> v3.16.39
> v3.18.47
> v4.1.38
> v4.8.17
> v4.9.5
> v4.10-rc5
> 
> It's interesting v4.4.44 is not impacted, but actually it needs both the 2 
> patches:
> i.e. this patch, and the previous one:
> Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in 
> hv_need_to_signal_on_read()")

That patch does not apply to the 4.4-stable tree, which is why it was
not included there.  If you feel it should be included, please provide a
backport and send it to the sta...@vger.kernel.org mailing list.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] hyperv: Move hv_pci_dev and related structs to hyperv.h

[gre...@linuxfoundation.org]

On Thu, Dec 08, 2016 at 03:26:06PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> > Behalf Of kbuild test robot
> > Sent: Thursday, December 8, 2016 1:50 AM
> > To: k...@exchange.microsoft.com
> > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;
> > Haiyang Zhang <haiya...@microsoft.com>; linux-ker...@vger.kernel.org;
> > bjorn.helg...@gmail.com; kbuild-...@01.org; a...@canonical.com;
> > de...@linuxdriverproject.org; leann.ogasaw...@canonical.com
> > Subject: Re: [PATCH 1/3] hyperv: Move hv_pci_dev and related structs to
> > hyperv.h
> > 
> > Hi Haiyang,
> > 
> > [auto build test ERROR on next-20161208]
> > [also build test ERROR on v4.9-rc8]
> > [cannot apply to linus/master linux/master pci/next v4.9-rc8 v4.9-rc7 v4.9-
> > rc6]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help
> > improve the system]
> > 
> > url:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> > .com%2F0day-ci%2Flinux%2Fcommits%2Fkys-exchange-microsoft-
> > com%2Fhyperv-Move-hv_pci_dev-and-related-structs-to-hyperv-
> > h%2F20161208-
> > 171643=02%7C01%7Ckys%40microsoft.com%7Ca000870068f645a67492
> > 08d41f4fa963%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6361678
> > 75686353145=2cR2dMEa6sjz94NYUFMx5qC8hEVvXF6uokmCCny%2FgL
> > E%3D=0
> > config: x86_64-randconfig-x012-201649 (attached as .config)
> > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> > 
> > All errors (new ones prefixed by >>):
> > 
> >In file included from drivers/hid/hid-hyperv.c:22:0:
> > >> include/linux/hyperv.h:1660:25: error: field 'msi_info' has incomplete 
> > >> type
> >  struct msi_domain_info msi_info;
> > ^~~~
> > 
> > vim +/msi_info +1660 include/linux/hyperv.h
> > 
> >   1654  struct semaphore enum_sem;
> >   1655  struct list_head resources_for_children;
> >   1656
> >   1657  struct list_head children;
> >   1658  struct list_head dr_list;
> >   1659
> > > 1660  struct msi_domain_info msi_info;
> >   1661  struct msi_controller msi_chip;
> >   1662  struct irq_domain *irq_domain;
> >   1663  };
> > 
> 
> 
> Greg,
> 
> I sent this patch set to show how we plan to use the API to check if a device 
> is a 
> VMBUS device. Given that multiple trees are involved, the patches were based 
> on
> the linux-next tree. I was planning on submitting these patches with minimal
> inter-tree dependency. 

Ok, but how does this simple patch fail so badly?  Maybe just wait for
after 4.10-rc1 is out and then try this as everything will be synced up
then?  It's pretty much past the merge window for all subsystems now
anyway...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: linux-4.9-rc1/drivers/staging/lustre/lustre/osc/osc_request.c:973: always false test ?

[gre...@linuxfoundation.org]

On Mon, Oct 17, 2016 at 07:33:33AM +, David Binderman wrote:
> Hello there,
> 
> 
> 
> linux-4.9-rc1/drivers/staging/lustre/lustre/osc/osc_request.c:973]: (style) 
> Checking if unsigned variable 'cli.cl_avail_grant' is less than zero.
> 
> 
> 
> Source code is
> 
> 
> 
>    if (cli->cl_avail_grant < 0) {
> 
> 
> 
> Suggest code rework.

Great!  Please send a patch.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Cma mem map to cpu address when allocated in ion driver, why do this design?

[gre...@linuxfoundation.org]

On Thu, Sep 01, 2016 at 12:46:32PM +, Yangwei (Yang Wei, Device Chipset Key 
Technologies Platform Development Dept) wrote:
> Hi  all,
> 
> When I review ion code in linux-3.18.y, I find a design that may cause
> a problem in our product. In the design, cma mem is allocated via the
> interface of dma_alloc_coherent ,

3.18 is old and obsolete and isn't supported by the kernel community for
anything except bug fixes.  I suggest you work with whatever group is
forcing you to use this old kernel version as they are the ones that you
are paying to support this kernel for you.

If you wish to discuss the 4.7 or newer kernel versions, and how ion
works there (look in linux-next for the most recent changes in that
area), we would be glad to help you out.

Best of luck!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RESEND 00/28] staging: unisys: fix visorbus & visorinput issues raised by tglx

[gre...@linuxfoundation.org]

On Wed, Jul 27, 2016 at 05:43:27PM +, Kershner, David A wrote:
> > -Original Message-
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, June 16, 2016 3:03 PM
> > To: Kershner, David A <david.kersh...@unisys.com>
> > Cc: Neil Horman <nhor...@redhat.com>; driverdev-
> > de...@linuxdriverproject.org; *S-Par-Maintainer
> > <sparmaintai...@unisys.com>; jes.soren...@redhat.com;
> > t...@linutronix.de; Binder, David Anthony <david.bin...@unisys.com>
> > Subject: Re: [PATCH RESEND 00/28] staging: unisys: fix visorbus & visorinput
> > issues raised by tglx
> > 
> > On Thu, Jun 16, 2016 at 05:35:58PM +, Kershner, David A wrote:
> > >
> > >
> ...
> > > Was wondering what the status of this patch series was and if you
> > > need anything from us?
> > 
> > Again, staging patches are at the bottom of my queue, you are behind 500
> > other staging patches, 275 serial patches, 100 USB patches, and 50+
> > other char/misc patches, please be patient.
> > 
> 
> I understand that the 4.8 window is currently open, and was wondering if we
> are still in the queue or if we need to resend the patch series.

They are still in the queue, sorry for the delay...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RESEND 00/28] staging: unisys: fix visorbus & visorinput issues raised by tglx

[gre...@linuxfoundation.org]

On Thu, Jun 16, 2016 at 05:35:58PM +, Kershner, David A wrote:
> 
> 
> > -Original Message-
> > From: Neil Horman [mailto:nhor...@redhat.com]
> > Sent: Tuesday, June 14, 2016 9:27 AM
> > Subject: Re: [PATCH RESEND 00/28] staging: unisys: fix visorbus & visorinput
> > issues raised by tglx
> > 
> > On Fri, Jun 10, 2016 at 09:47:58PM -0400, David Kershner wrote:
> > > Resending due to imcomplete distribution list.
> > >
> > > This patchset comprises the first 26 patches of the previously-submitted
> > > patchset (but retracted):
> > >
> > >   [PATCH v4 00/29] Fixed issues raised by tglx, then move visorbus to
> > >drivers/virt
> > >
> > > then adds 2 patches to visorinput that:
> > >   * fixes a device initialization race condition
> > >   * converts a semaphore to a mutex
> > >
> > > As described in the email NAKing the previously-submitted patchset,
> > > the reason we are re-submitting this now is to make things a bit
> > > cleaner by separating the fixes we need to make to the code in
> > > staging from the patchset that actually moves the code out of staging.
> > >
> > > The intent of this patchset is to fix all known outstanding
> > > issues with code in drivers/staging/unisys/, so that subsequent
> > > patchsets can move these drivers out of staging.
> > >
> > > tglx: The following patchset fixes issues you raised during your
> > > code review of visorbus on 5/18, and visorinput on 6/1.
> > >
> ...
> > > --
> > > 1.9.1
> > >
> > Series
> > Acked-By: Neil Horman 
> 
> Was wondering what the status of this patch series was and if you
> need anything from us?

Again, staging patches are at the bottom of my queue, you are behind 500
other staging patches, 275 serial patches, 100 USB patches, and 50+
other char/misc patches, please be patient.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

[gre...@linuxfoundation.org]

On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote:
> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On 
> > Behalf
> > Of Dexuan Cui
> > Sent: Tuesday, May 17, 2016 10:46
> > To: David Miller <da...@davemloft.net>
> > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;
> > linux-ker...@vger.kernel.org; j...@perches.com; net...@vger.kernel.org;
> > a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang
> > <haiya...@microsoft.com>
> > Subject: RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> > 
> > > From: David Miller [mailto:da...@davemloft.net]
> > > Sent: Monday, May 16, 2016 1:16
> > > To: Dexuan Cui <de...@microsoft.com>
> > > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > > a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY
> > > Srinivasan <k...@microsoft.com>; Haiyang Zhang <haiya...@microsoft.com>;
> > > j...@perches.com; vkuzn...@redhat.com
> > > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM 
> > > Sockets(hv_sock)
> > >
> > > From: Dexuan Cui <de...@microsoft.com>
> > > Date: Sun, 15 May 2016 09:52:42 -0700
> > >
> > > > Changes since v10
> > > >
> > > > 1) add module params: send_ring_page, recv_ring_page. They can be used
> > to
> > > > enlarge the ringbuffer size to get better performance, e.g.,
> > > > # modprobe hv_sock  recv_ring_page=16 send_ring_page=16
> > > > By default, recv_ring_page is 3 and send_ring_page is 2.
> > > >
> > > > 2) add module param max_socket_number (the default is 1024).
> > > > A user can enlarge the number to create more than 1024 hv_sock sockets.
> > > > By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes.
> > > > (Here 1+1 means 1 page for send/recv buffers per connection, 
> > > > respectively.)
> > >
> > > This is papering around my objections, and create module parameters which
> > > I am fundamentally against.
> > >
> > > You're making the facility unusable by default, just to work around my
> > > memory consumption concerns.
> > >
> > > What will end up happening is that everyone will simply increase the
> > > values.
> > >
> > > You're not really addressing the core issue, and I will be ignoring you
> > > future submissions of this change until you do.
> > 
> > David,
> > I am sorry I came across as ignoring your feedback; that was not my 
> > intention.
> > The current host side design for this feature is such that each socket 
> > connection
> > needs its own channel, which consists of
> > 
> > 1.A ring buffer for host to guest communication
> > 2.A ring buffer for guest to host communication
> > 
> > The memory for the ring buffers has to be pinned down as this will be 
> > accessed
> > both from interrupt level in Linux guest and from the host OS at any time.
> > 
> > To address your concerns, I am planning to re-implement both the receive 
> > path
> > and the send path so that no additional pinned memory will be needed.
> > 
> > Receive Path:
> > When the application does a read on the socket, we will dynamically allocate
> > the buffer and perform the read operation on the incoming ring buffer. Since
> > we will be in the process context, we can sleep here and will set the
> > "GFP_KERNEL | __GFP_NOFAIL" flags. This buffer will be freed once the
> > application consumes all the data.
> > 
> > Send Path:
> > On the send side, we will construct the payload to be sent directly on the
> > outgoing ringbuffer.
> > 
> > So, with these changes, the only memory that will be pinned down will be the
> > memory for the ring buffers on a per-connection basis and this memory will 
> > be
> > pinned down until the connection is torn down.
> > 
> > Please let me know if this addresses your concerns.
> > 
> > -- Dexuan
> 
> Hi David,
> Ping. Really appreciate your comment.

Don't wait for people to respond to random design questions, go work on
the code and figure out if it is workable or not yourself.  Then post
patches.  We aren't responsible for your work, you are.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: comedi: ni_mio_common: fix the ni_write[blw]() functions

[gre...@linuxfoundation.org]

On Fri, Mar 18, 2016 at 05:38:45PM +, Hartley Sweeten wrote:
> On Wednesday, March 16, 2016 3:22 AM, Ian Abbott wrote:
> > On 15/03/16 21:48, H Hartley Sweeten wrote:
> >> Memory mapped io (dev->mmio) should not also be writing to the ioport
> >> (dev->iobase) registers. Add the missing 'else' to these functions.
> >>
> >> Signed-off-by: H Hartley Sweeten <hswee...@visionengravers.com>
> >> Cc: Ian Abbott <abbo...@mev.co.uk>
> >> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> >> ---
> >>   drivers/staging/comedi/drivers/ni_mio_common.c | 12 ++--
> >>   1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > Please add:
> >
> > Fixes: 0953ee4acca0 ("staging: comedi: ni_mio_common: checkpatch.pl 
> > cleanup (else not useful)")
> > Cc: <sta...@vger.kernel.org> # 3.17+
> >
> > Reviewed-by: Ian Abbott <abbo...@mev.co.uk>
> 
> Ugh... Looks like I broke it.
> 
> Greg,
> 
> Would you like me to repost this with the Fixes/Cc added or do you got it?

I got it, no problem.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/6] staging: unisys: visorbus: git rid of gotos in devmajorminor_create_file

[gre...@linuxfoundation.org]

On Wed, Mar 09, 2016 at 05:10:28PM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhor...@redhat.com]
> > Sent: Wednesday, March 09, 2016 11:09 AM
> > To: external-ges-uni...@redhat.com
> > Cc: gre...@linuxfoundation.org; driverdev-devel@linuxdriverproject.org;
> > *S-Par-Maintainer
> > Subject: Re: [PATCH 3/6] staging: unisys: visorbus: git rid of gotos in
> > devmajorminor_create_file
> > 
> > On Tue, Mar 08, 2016 at 08:22:45PM -0500, David Kershner wrote:
> > > The gotos in devmajorminor_create_file aren't needed, get rid of them.
> > >
> > > Signed-off-by: David Kershner <david.kersh...@unisys.com>
> > > Signed-off-by: Timothy Sell <timothy.s...@unisys.com>
> > > ---
> > >  drivers/staging/unisys/visorbus/visorbus_main.c | 25 
> > > -
> > 
> > >  1 file changed, 8 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
> > b/drivers/staging/unisys/visorbus/visorbus_main.c
> > > index e1ec0b8..37a60ec 100644
> > > --- a/drivers/staging/unisys/visorbus/visorbus_main.c
> > > +++ b/drivers/staging/unisys/visorbus/visorbus_main.c
> > > @@ -306,21 +306,17 @@ devmajorminor_create_file(struct visor_device
> > *dev, const char *name,
> > >  {
> > >   int maxdevnodes = ARRAY_SIZE(dev->devnodes) / sizeof(dev-
> > >devnodes[0]);
> > >   struct devmajorminor_attribute *myattr = NULL;
> > > - int x = -1, rc = 0, slot = -1;
> > > + int x = -1, slot = -1;
> > >
> > >   register_devmajorminor_attributes(dev);
> > >   for (slot = 0; slot < maxdevnodes; slot++)
> > >   if (!dev->devnodes[slot].attr)
> > >   break;
> > > - if (slot == maxdevnodes) {
> > > - rc = -ENOMEM;
> > > - goto away;
> > > - }
> > > + if (slot == maxdevnodes)
> > > + return -ENOMEM;
> > >   myattr = kzalloc(sizeof(*myattr), GFP_KERNEL);
> > > - if (!myattr) {
> > > - rc = -ENOMEM;
> > > - goto away;
> > > - }
> > > + if (!myattr)
> > > + return -ENOMEM;
> > >   myattr->show = DEVMAJORMINOR_ATTR;
> > >   myattr->store = NULL;
> > >   myattr->slot = slot;
> > > @@ -331,17 +327,12 @@ devmajorminor_create_file(struct visor_device
> > *dev, const char *name,
> > >   dev->devnodes[slot].minor = minor;
> > >   x = sysfs_create_file(>kobjdevmajorminor, >attr);
> > >   if (x < 0) {
> > > - rc = x;
> > > - goto away;
> > > - }
> > > - kobject_uevent(>device.kobj, KOBJ_ONLINE);
> > > -away:
> > > - if (rc < 0) {
> > >   kfree(myattr);
> > > - myattr = NULL;
> > >   dev->devnodes[slot].attr = NULL;
> > > + return x;
> > >   }
> > > - return rc;
> > > + kobject_uevent(>device.kobj, KOBJ_ONLINE);
> > > + return 0;
> > >  }
> > >
> > >  static void
> > > --
> > > 1.9.1
> > >
> > 
> > This problem wasn't introduced by this patch, but removing the gotos makes
> > it
> > harder to fix.  The first thing you do is call
> > register_devmajorminor_attributes, and if the code fails, you should really
> > unregister those.  What you really need to do is keep the label and gotos,
> > and
> > add an unregister call at the same place you use the kfree call
> > 
> > Neil
> 
> As part of our code audit to get this code out of staging,
> Dan Carpenter has expressed some criticims regarding our use of gotos,
> which included our use of vague label names like "away", and many places
> were we have a single exit-point for both success and failure exits.
> (I believe Dan has researched this and determined this practice to be
> error-prone.)  We have been attempting to clean these up, and as a result
> have found some places where it is cleaner to just remove the gotos
> altogether.  It looks like this was one of those places.
> 
> I see your point about register_devmajorminor_attributes, which is valid,
> but we just so-happen to have a subsequent patch that removes all
> of the devmajorminor stuff, as we don't really need that.  This was a
> result of criticism from Greg about our usages of "raw kobjects".

I don't want to take a patch now that makes it harder to fix a real bug
just to make a mythical future patch somehow better/smaller.  Please fix
this issue now.

I'm dropping this series from my queue, 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: rtl8192e: prefer using eth_broadcast_addr()

[gre...@linuxfoundation.org]

On Wed, Jan 20, 2016 at 01:06:13PM +, Gujulan Elango, Hari Prasath (H.) 
wrote:
> From: Hari Prasath Gujulan Elango

When you do this, you need an email address after the name, otherwise
git complains and refuses to apply the patch.

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: dgnc: convert to wait_event_interruptible_timeout

[gre...@linuxfoundation.org]

On Thu, Dec 24, 2015 at 01:54:12PM +, Gujulan Elango, Hari Prasath (H.) 
wrote:
> This patch makes use of wait_event_interruptible_timeout to achieve timeout
> functionality.This is a TODO mentiond in the comment which is also removed.
> It also aligns with what the function is supposed to do as in the
> comments.
> 
> Signed-off-by: Hari Prasath Gujulan Elango 
> ---
>  drivers/staging/dgnc/dgnc_neo.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
> index 39c76e7..7d9efe0 100644
> --- a/drivers/staging/dgnc/dgnc_neo.c
> +++ b/drivers/staging/dgnc/dgnc_neo.c
> @@ -1306,10 +1306,8 @@ static int neo_drain(struct tty_struct *tty, uint 
> seconds)
>   /*
>* Go to sleep waiting for the tty layer to wake me back up when
>* the empty flag goes away.
> -  *
> -  * NOTE: TODO: Do something with time passed in.
>*/
> - rc = wait_event_interruptible(un->un_flags_wait, ((un->un_flags & 
> UN_EMPTY) == 0));
> + rc = wait_event_interruptible_timeout(un->un_flags_wait, ((un->un_flags 
> & UN_EMPTY) == 0), msecs_to_jiffies(seconds * 1000));

Any reason you didn't properly wrap your line at the 80 column limit?

Please fix and resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Missed patch for hfi1 from Gregs tree.

[gre...@linuxfoundation.org]

On Thu, Jan 28, 2016 at 03:30:23PM -0500, ira.weiny wrote:
> Doug,
> 
> The following patch was not accepted by Greg and does not appear in patchworks
> 
> https://marc.info/?l=linux-rdma=145090416416677=2

I have a whole stack of staging patches I have yet to get through.  Over
1000 at the moment, they will be gotten to eventually...

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

[gre...@linuxfoundation.org]

On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote:
> On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote:
> > On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
> > > On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org 
> > > wrote:
> > > > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> > > > > Greg, Doug,
> > > > > 
> > > > > As mentioned below, these patches depend on the new rdmavt library 
> > > > > submitted to
> > > > > Doug on linux-rdma.
> > > > > 
> > > > > We continue to identify (and rework) patches by our other developers 
> > > > > which can
> > > > > be submitted without conflicts with this series.  Furthermore, We 
> > > > > have, as much
> > > > > as possible, placed fixes directly into rdmavt such that those 
> > > > > changes can be
> > > > > dropped from hfi1.  But at this point, we need to know if and where 
> > > > > these are
> > > > > going to land so that we can start reworking as appropriate.
> > > > > 
> > > > > Therefore, I would like to discuss plans to get hfi1 under the same 
> > > > > maintainer
> > > > > to work through this transitional period.
> > > > > 
> > > > > Basically, At what point should we stop submitting patches to Greg 
> > > > > and start
> > > > > submitting to Doug?
> > > > > 
> > > > > Should we consider the merge window itself as the swap over point and 
> > > > > submit
> > > > > changes to Doug at that point?  If so, should we continue to submit 
> > > > > what we can
> > > > > to Greg until then (and continue rebase'ing the series below on that 
> > > > > work)?  Or
> > > > > given Gregs backlog, should we stop submitting to Greg sometime prior 
> > > > > to the
> > > > > merge window?
> > > > > 
> > > > > That brings up my final question, at the point of swap over I assume 
> > > > > anything
> > > > > not accepted by Greg should be considered rejected and we need to 
> > > > > resubmit to
> > > > > Doug?
> > > > 
> > > > If Doug accepts the library changes, let me know that public git commit
> > > > and I can pull it into the staging-next branch and you can continue to
> > > > send me staging patches that way.
> > > 
> > > Won't this cause a conflict during the merge window?
> > 
> > No, git is good :)
> > 
> > > How do we handle changes which affect both qib and hfi1?
> > 
> > I don't know, now this gets messy...
> > 
> 
> Agreed and this is what we are worried about.
> 
> Can we do what Dan and Doug have proposed in the past and have Doug take over
> the staging/rdma sub-tree?
> 
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html
> 
> I think the upcoming merge window is a reasonable time for him to do that.

Ok, but keeping on top of all of the generic staging patches that come
in is a tough thing to do, that's up to Doug, if he is ready for it...

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

[gre...@linuxfoundation.org]

On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
> On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote:
> > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> > > Greg, Doug,
> > > 
> > > As mentioned below, these patches depend on the new rdmavt library 
> > > submitted to
> > > Doug on linux-rdma.
> > > 
> > > We continue to identify (and rework) patches by our other developers 
> > > which can
> > > be submitted without conflicts with this series.  Furthermore, We have, 
> > > as much
> > > as possible, placed fixes directly into rdmavt such that those changes 
> > > can be
> > > dropped from hfi1.  But at this point, we need to know if and where these 
> > > are
> > > going to land so that we can start reworking as appropriate.
> > > 
> > > Therefore, I would like to discuss plans to get hfi1 under the same 
> > > maintainer
> > > to work through this transitional period.
> > > 
> > > Basically, At what point should we stop submitting patches to Greg and 
> > > start
> > > submitting to Doug?
> > > 
> > > Should we consider the merge window itself as the swap over point and 
> > > submit
> > > changes to Doug at that point?  If so, should we continue to submit what 
> > > we can
> > > to Greg until then (and continue rebase'ing the series below on that 
> > > work)?  Or
> > > given Gregs backlog, should we stop submitting to Greg sometime prior to 
> > > the
> > > merge window?
> > > 
> > > That brings up my final question, at the point of swap over I assume 
> > > anything
> > > not accepted by Greg should be considered rejected and we need to 
> > > resubmit to
> > > Doug?
> > 
> > If Doug accepts the library changes, let me know that public git commit
> > and I can pull it into the staging-next branch and you can continue to
> > send me staging patches that way.
> 
> Won't this cause a conflict during the merge window?

No, git is good :)

> How do we handle changes which affect both qib and hfi1?

I don't know, now this gets messy...

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

[gre...@linuxfoundation.org]

On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
> Greg, Doug,
> 
> As mentioned below, these patches depend on the new rdmavt library submitted 
> to
> Doug on linux-rdma.
> 
> We continue to identify (and rework) patches by our other developers which can
> be submitted without conflicts with this series.  Furthermore, We have, as 
> much
> as possible, placed fixes directly into rdmavt such that those changes can be
> dropped from hfi1.  But at this point, we need to know if and where these are
> going to land so that we can start reworking as appropriate.
> 
> Therefore, I would like to discuss plans to get hfi1 under the same maintainer
> to work through this transitional period.
> 
> Basically, At what point should we stop submitting patches to Greg and start
> submitting to Doug?
> 
> Should we consider the merge window itself as the swap over point and submit
> changes to Doug at that point?  If so, should we continue to submit what we 
> can
> to Greg until then (and continue rebase'ing the series below on that work)?  
> Or
> given Gregs backlog, should we stop submitting to Greg sometime prior to the
> merge window?
> 
> That brings up my final question, at the point of swap over I assume anything
> not accepted by Greg should be considered rejected and we need to resubmit to
> Doug?

If Doug accepts the library changes, let me know that public git commit
and I can pull it into the staging-next branch and you can continue to
send me staging patches that way.

That's the easiest thing to do usually.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [jubin.j...@intel.com: [PATCH] staging/rdma/hfi1: Fix error in hfi1 driver build]

[gre...@linuxfoundation.org]

On Mon, Dec 14, 2015 at 02:36:39PM -0500, ira.weiny wrote:
> Greg,
> 
> It looks like you missed this patch for 4.4-rc5
> 
> Could we get it included for rc6?

I'll try, but again, I'm way behind, give me a few more days...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/2] Fix 4.4 IB merge window regressions

[gre...@linuxfoundation.org]

On Mon, Nov 30, 2015 at 01:05:19PM -0500, ira.weiny wrote:
> On Mon, Nov 30, 2015 at 09:34:15AM -0500, Mike Marciniszyn wrote:
> > This two patch series fixes regressions for qib and hfi1
> > introduced in the 4.4 merge window.
> > 
> > These are critical for 4.4 and for rebasing the qib/hfi1
> > refactoring.
> 
> Doug, Greg,
> 
> It should also be noted that without this change to uverbs_cmd the hfi1 driver
> is at least partially (ib_write_bw test) broken in staging-next.
> 
> Greg, if Linus pulls these from Doug into rc4 will you pull them into
> staging-next?

Yes, I try to always sync up on the -rc releases.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/7] staging/rdma/hfi1: diag.c Correct code style issues

[gre...@linuxfoundation.org]

On Tue, Nov 17, 2015 at 03:30:24PM -0500, ira.weiny wrote:
> On Tue, Nov 17, 2015 at 10:17:26PM +0530, Sudip Mukherjee wrote:
> > On Mon, Nov 16, 2015 at 05:32:34PM -0500, ira.we...@intel.com wrote:
> > > From: Jubin John 
> > > 
> > > Correct the checks on diag.c with the latest checkpatch
> > > 
> > > Reviewed-by: Dennis Dalessandro 
> > > Reviewed-by: Mike Marciniszyn 
> > > Signed-off-by: Jubin John 
> > > Signed-off-by: Ira Weiny 
> > > ---
> > 
> > Different types of changes in a single patch.
> 
> Greg,
> 
> Do you want me to resubmit the entire series for this?

Why wouldn't you?  :)

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 12/13] staging/rdma/hfi1: Read EFI variable for device description

[gre...@linuxfoundation.org]

On Wed, Nov 11, 2015 at 03:03:12PM +, Luick, Dean wrote:
> > -Original Message-
> > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > Sent: Wednesday, November 11, 2015 8:39 AM
> > To: Luick, Dean <dean.lu...@intel.com>
> > Cc: John, Jubin <jubin.j...@intel.com>; de...@driverdev.osuosl.org;
> > gre...@linuxfoundation.org; dledf...@redhat.com; linux-
> > r...@vger.kernel.org
> > Subject: Re: [PATCH 12/13] staging/rdma/hfi1: Read EFI variable for device
> > description
> > 
> > > > > + if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > > >
> > > >
> > > > Flip this around:
> > > >
> > > > if (!efi_enabled(EFI_RUNTIME_SERVICES))
> > > > return -ENOSYS;
> > >
> > > The style here is very deliberate.
> > >
> > > The issue is how efi_enabled() is defined via CONFIG options.
> > >  The function can be turned into a 0 if certain CONFIG variables are
> > > not set.  The code is structured to make all of the dependent
> > > variables disappear if efi_enabled() becomes 0.
> > 
> > This all understand.
> > 
> > >  If the code is shifted as you suggest, we will get builds from the
> > > automatic builders that try all combinations with unused variables.
> > >  This was done to avoid that.
> > 
> > I'm not sure I understand.  You are doing this to try tricking the
> > autobuilders into not testind certain configs?  What?
> 
> Certainly not.  I did not explain this well.
> 
> > I don't
> > understand what you mean by unused variables.  There shouldn't be any
> > unused variable warnings.  If you are getting unused variable warnings
> > can you post one so that I can take a look?
> 
> If you move the variables to the top and have the early return as you 
> suggest, then in some CONFIG cases, there will be all those automatic 
> variables declared but they are never used - the compiler has short-circuited 
> the rest of the function.  Will not the compiler complain about unused 
> variables in those cases?  That is the situation I was trying to avoid.

Try it and see (hint, I don't think so...)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 07/22] staging/rdma/hfi1: Fix sparse error in sdma.h file

[gre...@linuxfoundation.org]

On Thu, Oct 22, 2015 at 01:01:25PM +0300, Dan Carpenter wrote:
> On Wed, Oct 21, 2015 at 04:29:35PM +, Weiny, Ira wrote:
> > > 
> > > On Mon, Oct 19, 2015 at 10:11:22PM -0400, ira.we...@intel.com wrote:
> > > > From: Niranjana Vishwanathapura 
> > > >
> > > > Use NULL instead of 0 for pointer argument to fix the sparse error.
> > > >
> > > > Reviewed-by: Mike Marciniszyn 
> > > > Reviewed-by: Mitko Haralanov 
> > > > Reviewed-by: Dennis Dalessandro 
> > > > Signed-off-by: Niranjana Vishwanathapura
> > > > 
> > > > Signed-off-by: Ira Weiny 
> > > 
> > > This should have just been folded in with the previous patch.  Don't 
> > > introduce
> > > problems and fix them in the patchset.
> > 
> > My bad, I will fix in v3.
> 
> I don't think it's worth redoing the patchset over because it's just a
> Sparse warning, not a bug.  But for the future.

No, please redo, the other problems in this series warrent a new series.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: dgnc: Simplify a trivial if-return sequence\n From: Parshuram Thombare <pthom...@visteon.com>

[gre...@linuxfoundation.org]

On Mon, Sep 21, 2015 at 08:59:30PM +, Thombare, Parshuram (P.) wrote:
> Signed-off-by: Parshuram Thombare 

Your subject is really odd :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: staging drivers

[Greg Kroah-Hartman (gre...@linuxfoundation.org)]

On Thu, Jul 16, 2015 at 07:18:46PM +, Marciniszyn, Mike wrote:
 Greg,
 
 We are in the process of submitting an RDMA driver for the Intel OPA 
 architecture.

I have no idea what OPA is, sorry.

 The current massive patch set is submitted to add the driver to the 
 infiniband tree. 
 
 I'm wondering if the staging area is a better spot to land the driver at 
 first? That way everyone can see it being reworked and participate in that 
 process.
 
 Some considerations:
 - There are today significant comments
   o Use of write instead of some other control.
  (See qib commit 4961772560d2, 
 http://marc.info/?l=linux-rdmam=143455871310614w=2 )
   o Use of sysfs as qib does
   o Duplication of code (ipath, qib, hfi1) (we are removing ipath to 
 eventually help in that respect)
 - Driver is still being developed
   o If we put the driver into staging there will be a lot of patches from the 
 above rework as well as internal development
  
 Given these points (existing flaws, development dynamics), is staging 
 suitable?

It's up to the IB maintainer if they are willing to let it be in stable
as-is.  If so, sure, but it needs to be stand-alone and have a TODO file
listing what needs to be done.  If no forward progress happens on it, I
will delete it from the tree, this isn't a place for dumping code.

You also have to be able to handle other people modifying / cleaning up
the code, so be careful with your internal development that you sync
up very often.

In the end, this is going to take more time and work than you doing all
of what is needed in your own private tree, but it's up to you.

 Is there a better way to get the initial driver into staging (vs. a
 massive patch set)?

What's wrong with a big patch set?

 I'm also interested in any comments you might have on Al's commit
 message and alternatives (write, ioctl, generic netlink).

I have no idea what Al, or commit, you are referring to, sorry.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [HPDD-discuss] [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure

[Greg Kroah-Hartman (gre...@linuxfoundation.org)]

On Mon, Jun 22, 2015 at 05:27:03PM +, Simmons, James A. wrote:
 
 Is this change a hard requirement? Currently the lustre code standard in our 
 development tree is the opposite policy.

Please follow the kernel coding style rules.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/6] Staging: comedi: dmm32at: Simplify a trivial if-return sequence

[gre...@linuxfoundation.org]

On Fri, Jun 19, 2015 at 06:08:04AM +, Abdul, Hussain (H.) wrote:
 On Friday 19 June 2015 04:30 AM, gre...@linuxfoundation.org wrote:
  On Tue, Jun 16, 2015 at 02:03:44PM +, Abdul, Hussain (H.) wrote:
  From: Abdul Hussain hab...@visteon.com
 
  This patch simplify a trivial if-return sequence. Possibly combine with
  a preceding function call.
 
  Signed-off-by: Abdul Hussain hab...@visteon.com
  Always use scripts/get_maintainer.pl to properly cc the maintainers
  responsible for these drivers.
 
  Please fix this up and resend.
 
  thanks,
 
  greg k-h
 
 Greg, I resent the patch set with all the maintainer in the CC.

But you didn't label it as a v2, so now I have a bunch of duplicate
emails in my inbox :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel