Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On Fri, Oct 10, 2014 at 08:49:01AM +0100, Sitsofe Wheeler wrote: Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance even though they implement post SPC-2 features (such as thin provisioning) which means the Linux kernel does not go on to test for those features even though

Re: [PATCH 0/2] Drivers: scsi: storvsc: Fix issues with hot-add/remove of LUNs

On Tue, Oct 07, 2014 at 05:44:38PM +, KY Srinivasan wrote: So can anywayone give me a review for those two patches? Did you get the reviews? No. ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH] staging: android: binder: move to the real part of the kernel

On Mon, Oct 20, 2014 at 06:04:50AM +0800, Greg Kroah-Hartman wrote: There is now work to resolve the interface, it requires someone who has the rights to push to Android userspace. But that is going to be a total rewrite, and until then, this code needs to be used, no matter how much we hate

Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA

On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote: Can't we just export the functions for those arches? Surely lutre isn't the first/only driver that needs this? Lustre is. These are core mm helpers, and lustre uses them to reimplement another core VM function. It then uses

Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA

On Wed, Sep 11, 2013 at 10:51:50AM +0800, Peng Tao wrote: I'm not fighting against removing the piece of code. But if there is a strong reason to keep the functionality, we need to find a way to implement it. The convenience of using environment variables is that job scheduler can set the

Re: lustre: why does cfs_get_random_bytes() exist?

On Sat, Oct 05, 2013 at 10:21:21AM -0400, Theodore Ts'o wrote: add_device_randomness() is called from __dev_open() and dev_set_mac_address() in net/core/dev.c. This is above the ethernet and infiniband level. So as long as it looks like a Linux network device, and they are setting the

Re: [PATCH 1/8] Drivers: scsi: storvsc: Change the limits to reflect the values on the host

On Tue, Jul 08, 2014 at 05:46:45PM -0700, K. Y. Srinivasan wrote: + * In Hyper-V, each port/path/target maps to 1 scsi host adapter. Does it still? The STORVSC_FC_MAX_TARGETS define suggests otherwise. - .cmd_per_lun = 1, + .cmd_per_lun = 255, This looks like an

Re: [PATCH 3/8] Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol version

+ if ((vmbus_proto_version == VERSION_WS2008) || + (vmbus_proto_version == VERSION_WIN7)) { This has superflous braces and doesn't use proper Linux indentation. But I think simply using a switch here might be cleaner anyway. ___ devel

Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16

On Tue, Jul 08, 2014 at 05:46:48PM -0700, K. Y. Srinivasan wrote: Host does not handle WRITE_SAME_16; filter this command out. This patch is required to handle large devices (greater than 2 TB disks). Storvsc already sets the no_write_same flag, where is the command coming from?

Re: [PATCH 5/8] Drivers: scsi: storvsc: Fix a bug in the handling of SRB status flags

Looks good, Reviewed-by: Christoph Hellwig h...@lst.de ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler

On Tue, Jul 08, 2014 at 05:46:50PM -0700, K. Y. Srinivasan wrote: Implement a simple abort handler. The host does not support Abort; just ensure that all inflight I/Os have been accounted for. The abort handler should abort a single command, not wait for all of them. What issue do you see that

Re: [PATCH 7/8] drivers: scsi: storvsc: Set srb_flags in all cases

On Tue, Jul 08, 2014 at 05:46:51PM -0700, K. Y. Srinivasan wrote: Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the Windows host require this. What are IHV drivers? Otherwise looks fine, Reviewed-by: Christoph Hellwig h...@lst.de

Re: [PATCH 8/8] drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure

On Tue, Jul 08, 2014 at 05:46:52PM -0700, K. Y. Srinivasan wrote: --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1023,6 +1023,13 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, case ATA_12: set_host_byte(scmnd,

Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler

On Wed, Jul 09, 2014 at 06:51:38PM +, KY Srinivasan wrote: On Azure, we sometimes have unbounded I/O latencies and some distributions (such as SLES12) based on recent kernels are invoking the Abort Handler. Any kernel will invoke the abort handler if present, and then escalate to the

Re: [PATCH 7/8] drivers: scsi: storvsc: Set srb_flags in all cases

On Wed, Jul 09, 2014 at 06:40:09PM +, KY Srinivasan wrote: On Tue, Jul 08, 2014 at 05:46:51PM -0700, K. Y. Srinivasan wrote: Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the Windows host require this. What are IHV drivers? If the target is a SAN

Re: [PATCH 7/8] drivers: scsi: storvsc: Set srb_flags in all cases

default: vm_srb-data_in = UNKNOWN_TYPE; - vm_srb-win8_extension.srb_flags = 0; + vm_srb-win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN | + SRB_FLAGS_DATA_OUT); This would usually be a command that

Re: [PATCH V2 2/8] Drivers: scsi: storvsc: Set cmd_per_lun to reflect value supported by the Host

- .cmd_per_lun = 1, + .cmd_per_lun = 255, .can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS, slave_configure immediately adjusts this down to STORVSC_MAX_IO_REQUESTS (250), any reson to start out with the magic 255 here?

Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler

On Fri, Jul 11, 2014 at 11:52:55AM +0200, Hannes Reinecke wrote: Something like this should be sufficient: Right. That plus a detailed comment explaining why it's there.. ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH V3 0/7] Drivers: scsi: storvsc: Bug fixes and improvements

The series looks good to me, although I'll probably put the commit message for the timer patch into the comment for the eh_timed_out handler. Can I get another set of reviews? I've seen Olaf has put them into the SLES tree, so I'd expect he's done a review already?

Re: [PATCH V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host

On Mon, Jul 14, 2014 at 08:15:17AM +0200, Hannes Reinecke wrote: Limiting max_lun to 255 will make the driver to _not_ respond to LUNs higher than that; ie Well-known LUN won't work here. Also the SCSI stack will be using REPORT LUNS anyway since you're advertising SPC-2 compliance. So your

Re: [PATCH V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host

On Mon, Jul 14, 2014 at 10:57:53AM +0200, Hannes Reinecke wrote: Okay, that's fine by me. Should I take this as a reviewed-by tag? ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host

On Wed, Jul 16, 2014 at 05:26:48PM +, KY Srinivasan wrote: Christoph, Is this patch-set ready to be checked in. Let me know if you want me to make any further corrections. Hi Ky, I've applied it locally, but I'm still waiting on reviews for two important core fixes before pushing out

Re: [PATCH 1/1] [SCSI] Fix a bug in deriving the FLUSH_TIMEOUT from the basic I/O timeout

. Srinivasan k...@microsoft.com Looks good to me, Reviewed-by: Christoph Hellwig h...@lst.de (it will need some changes to apply to my tree, but I'm happy to do that if I can get another review). James, does this look fine to you? ___ devel mailing list de

Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags

On Sun, Jul 20, 2014 at 08:33:42PM -0700, K. Y. Srinivasan wrote: Add blist flags to permit the reading of the VPD pages even when the target may claim SPC-2 compliance. MSFT targets currently claim SPC-2 compliance while they implement post SPC-2 features. With this patch we can correctly

Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags

On Wed, Jul 23, 2014 at 11:04:48AM +0100, Sitsofe Wheeler wrote: OK I've just seen this as I was about to post a similar patch to get discard going on Hyper-V. Will your patches handle Hyper-V pass through devices that support discard? The SSD I have here reports the following in the Linux

Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags

On Wed, Jul 23, 2014 at 01:54:43PM +0100, Sitsofe Wheeler wrote: That's good to know (I was worried the device would not be detected as supporting discard because it doesn't report lbpme and doesn't declare a conformance version (see below)). Ok, that makes things worse - you might be able to

Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags

On Wed, Jul 23, 2014 at 03:10:28PM +0100, Sitsofe Wheeler wrote: I'm not sure this alone will work - won't sdev_bflags/bflags have already been built at this point? They've been built up, but we can still or new values into it. It looks fine to me from review, but if you can test it on an

Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests

On Thu, Jul 24, 2014 at 09:54:24AM -0400, Martin K. Petersen wrote: I'm very much against short-circuiting the LBP logic in a passthrough driver because then we might end up in the exact situation we were trying to avoid with this patch series. Namely sending down commands unsupported by the

Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests

On Thu, Jul 24, 2014 at 08:34:19AM -0700, Christoph Hellwig wrote: I agree - I'd like to pull in KY's simple fix as soon as I get a second review for it. Ok, looks like I just got that from Hannes. Let's see if there's more to be done for the pass through case, but I'd rather wait for the next

Re: [PATCH 5/5] lustre: add myself to list of people to CC on lustre patches

On Wed, Mar 26, 2014 at 09:44:08AM +0100, Geert Uytterhoeven wrote: Ping? We got a new fix for this in due to https://lkml.org/lkml/2014/2/13/479 Given that lustre maintainers aren't willing to fix even the worst crap like this we really should drop it from the staging tree.

Re: Eudyptula Challenge (Task 10)

Can you folks please stop this challenge Bullshit? More checkpatch fixes is not something we'll need at all. Thanks you! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.

On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote: The host asks the guest to scan when a LUN is removed or added. The only way a guest can identify the removed LUN is when an I/O is attempted on a removed LUN - the SRB status code indicates that the LUN is invalid. We currently

Re: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.

On Tue, Aug 26, 2014 at 10:54:51PM +, KY Srinivasan wrote: This looks pretty reasonable to me, but I wonder if we should move this up to common code so that it happens for any host rescan triggered by sysfs or other drivers as well. Ping. Any decision on if/when this patch may be

Re: [PATCH 1/1] Drivers: scsi: storvsc: Get rid of warning messages

Looks good to me. Olaf, Hannes - can I get another review for this (and the older hyperv scanning patch set)? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] Drivers: scsi: storvsc: Get rid of warning messages

On Wed, Sep 17, 2014 at 09:33:24AM +0200, Olaf Hering wrote: Christoph, what does review of this mean? There are many hv related patches floating around. The removal of the warning in msgid 1409701396-20226-1-git-send-email-...@microsoft.com looks ok to me. Thanks, can you give me a

Re: [PATCH 1/1] Drivers: scsi: storvsc: Get rid of warning messages

On Thu, Sep 18, 2014 at 01:50:17PM +0200, Olaf Hering wrote: On Wed, Sep 17, Christoph Hellwig wrote: Also the two patches at http://thread.gmane.org/gmane.linux.drivers.driver-project.devel/56242/ Wasnt the outcome that this was a bad idea? Or at least doing it globally is bad. In any

Re: [PATCH 0/2] Drivers: scsi: storvsc: Fix issues with hot-add/remove of LUNs

So can anywayone give me a review for those two patches? On Sat, Aug 16, 2014 at 08:09:14PM -0700, K. Y. Srinivasan wrote: This patch-set addresses issues with LUN hot-add and remove. When the host notifies the guest that a scan is needed, scan the host. Also, prior to discovering new

Re: [GIT PULL] Staging driver patches for 3.19-rc1

On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote: I don't understand this kind of logic. a) Binder is considered a piece of shite. b) Google is working on a (hopefully sane) replacement. Why moving it out of staging then? What is the benefit? There is none, and Greg didn't

Re: [GIT PULL] Staging driver patches for 3.19-rc1

On Mon, Dec 15, 2014 at 10:56:38AM -0800, Greg KH wrote: Ok, that was a bit snotty on my part, I apologize. But really, this is self-contained, doesn't touch any core infrastructure, and is really just like any other driver for hardware that people don't use. It shouldn't affect anything

[PATCH] SCSI:STORVSC Use SCSI layer to allocate memory for per-command device request data

data. Reviewed-by: Long Li lon...@microsoft.com Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/scsi/storvsc_drv.c | 119 +++-- 1 file changed, 8 insertions(+), 111 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c

Re: [PATCH 0/4] Drivers: scsi: storvsc: Fix miscellaneous issues

Thanks, applied to scsi-for-3.20. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] SCSI:STORVSC Use SCSI layer to allocate memory for per-command device request data

On Tue, Mar 10, 2015 at 12:42:33PM +0100, Olaf Hering wrote: It would be nice to change .proc_name to KBUILD_MODNAME before v4.0 is released. We carry a patch which adds this field. Of cource we can just change the patch, but if code gets touched upstream anyway... Please send a patch. Would

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Wed, Apr 22, 2015 at 06:27:11AM +, Drokin, Oleg wrote: Nak on exporting symbols for broken staging code. Please get rid of the ioctls looking up path names in horrible ways in the lustre code. For a reference, is there a good example of a non-horrible way to look up a pathname?

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Wed, Apr 22, 2015 at 06:49:08AM +, Drokin, Oleg wrote: I know this is not going to be a popular opinion with you, but sometimes opening a file is just too expensive. 1 RPC roudntrip to open a file and then another one to close it. Use O_PATH to avoid this.

Re: [PATCH 1/1] scsi: storvsc: Set the SRB flags correctly when no data transfer is needed

On Fri, Apr 24, 2015 at 05:23:23PM -0700, K. Y. Srinivasan wrote: Set the SRB flags correctly when there is no data transfer. Looks good, Reviewed-by: Christoph Hellwig h...@lst.de ___ devel mailing list de...@linuxdriverproject.org http

Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant

On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote: SPC-2/3/4 specs state that The standard INQUIRY data (see table ...) shall contain at least 36 bytes. Hyper-V host doesn't always honor this requirement, e.g. when there is no physical device present at a particular LUN host

Re: [PATCH] storvsc: get rid of homegrown copy_{to,from}_bounce_buffer()

On Tue, Sep 22, 2015 at 06:27:50PM +0200, Vitaly Kuznetsov wrote: > Storvsc driver needs to ensure there are no 'holes' in the presented > sg list (all segments in the middle of the list need to be of PAGE_SIZE). I think it should instead set a virt_boundary. That's what we added for the NVMe

Re: HFI1 code duplication todo

Hi Doug, before the drivers stops overloading writev vs write (hfi1_file_ops) it MUST not be moved to the main tree. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch] staging: rdma: shift wrapping bug in c2_get_dma_mr()

Looks fine. Doug: what's the status of the staged out drivers? I thought we were going to delete them for 4.5? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC][PATCH 1/3] staging: ion: Move away from the DMA APIs for cache flushing

On Thu, May 26, 2016 at 11:59:22AM +0100, Russell King - ARM Linux wrote: > I _really_ hate seeing architecture internal functions being abused in > drivers - architecture internal functions are there to implement the > official kernel APIs and are not for drivers to poke about with. Exactly - if

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

On Sat, Mar 12, 2016 at 01:52:48PM -0800, K. Y. Srinivasan wrote: > The default user scan function associated with FC (fc_user_scan) > is not suitable for FC hosts on Hyper-V since we don't have > an rport associated with FC host on Hyper-V . Set it to NULL so we can > support manual scan of FC

Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly

On Sun, Apr 10, 2016 at 03:37:42PM +0100, James Simmons wrote: > > > The lloop driver should be removed entirely - use the loop driver > > instead. > > I talked with Andreas last week at our annual Lustre users group meeting > about this. The reason I was told for existance is that some users

Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly

The lloop driver should be removed entirely - use the loop driver instead. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.

On Thu, Jan 26, 2017 at 08:38:58AM -0500, Cathy Avery wrote: > Included in the current storvsc driver for Hyper-V is the ability > to access luns on an FC fabric via a virtualized fiber channel > adapter exposed by the Hyper-V host. This was done to provide an > interface for existing customer

Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.

On Sun, Jan 29, 2017 at 12:35:32AM +, KY Srinivasan wrote: > Windows has chosen this model for virtualizing FC devices to the guest - > without rports (or vports). As I noted in my earlier email, James came > up with this notion of a lightweight template almost a year ago. We can > certainly

Re: [PATCH v1 1/3] PCI: xilinx: Configure PCIe MPS settings

On Wed, Feb 08, 2017 at 04:49:30PM -0600, Bjorn Helgaas wrote: > + list_for_each_entry(child, >children, node) > + pcie_bus_configure_settings(child); This loop is duplicated in just about every driver, so it it might be a good idea to provide a littler helper for it.

Re: [PATCH 1/2] scsi: scsi_transport_fc: Provide a lightweight option for Virtual FC Hosts.

On Wed, Jan 18, 2017 at 03:28:57PM -0500, Cathy Avery wrote: > The patch provides a means to offer a lightweight option to the > current FC transport class. The new option is selected by a > driver when it indicates it wants the lightweight > transport via fc_function_template. This need some

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

On Thu, Sep 08, 2016 at 09:12:50AM -0700, Todd Kjos wrote: > In Android systems, the display pipeline relies on low > latency binder transactions and is therefore sensitive to > delays caused by contention for the global binder lock. > Jank is siginificantly reduced by disabling preemption > while

Re: [PATCH] staging: lustre: ko2iblbd: handle ib_dereg_mr removal

Hell no. If you had actually read the changelog you'd see that there is a reason the functions went away, and simply calling the underlying methods (which also will go away) will not fix it. Please go back reading the changelogs, and while we're at it read some basic introductions into the RDMA

Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote: > That said, there are precedents in using UAPI this way for PV > interfaces. See for example include/uapi/linux/virtio*.h and > arch/x86/include/uapi/asm/kvm_para.h. We have all kinds of historical examples, but most of them turned

Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On Wed, Dec 21, 2016 at 09:29:39AM +0300, Roman Kagan wrote: > QEMU in particular. We're planning to implement VMBus devices in QEMU > and would like to have the definitions shared with the Linux guest > drivers for Hyper-V. And that's everything but a userspace API. The way to go for protocol

Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote: > That's fine by me. > > I guess the series should then start with a complete move > arch/x86/include/uapi/asm/hyperv.h -> > arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to > change the latter instead of the

Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote: > Lastly, there is licensing issues on headers. It would be good to have any > userspace ABI headers licensed with a more liberal license so that BSD and > DPDK drivers > could use them directly. Right now each one reinvents.

Re: [PATCH v2] scsi: storvsc: Add support for FC rport.

On Mon, Apr 03, 2017 at 09:14:02AM -0400, Cathy Avery wrote: > On 04/03/2017 08:17 AM, Christoph Hellwig wrote: > > > if (host->transportt == fc_transport_template) { > > > + struct fc_rport_identifiers ids = { > > > +

Re: [PATCH v2] scsi: storvsc: Add support for FC rport.

> if (host->transportt == fc_transport_template) { > + struct fc_rport_identifiers ids = { > + .roles = FC_PORT_ROLE_FCP_TARGET, > + }; I don't think storvsc ever acts as FCP target. ___ devel mailing

Re: [PATCH] scsi: storvsc: Allow only one remove lun work item to be issued per lun

Just add a singlethreaded workqueue for storvsc_handle_error and you'll get serialization for all error handling for free. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

On Thu, Apr 20, 2017 at 06:37:35PM +, Haiyang Zhang wrote: > It's Nvidia driver. Which of the many nvidia drivers in the tree? Just fix it instead of coming up with stupid workarounds like this. ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: > This is a straight forward conversion in two places. Should kmap fail, > the code will return an INVALD_DATA error in the completion. It really should be using nvmet_copy_from_sgl to make things safer, as we don't want to rely on

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote: > Or maybe I'll just send a patch for that > separately seeing it doesn't depend on anything and is pretty simple. I > can do that next week. Yes, please just send that patch linux-nvme, we should be able to get it into 4.12.

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: > Convert the kmap and kmap_atomic uses to the sg_map function. We now > store the flags for the kmap instead of a boolean to indicate > atomicitiy. We also propogate a possible kmap error down and create > a new

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: > Very straightforward conversion to the new function in all four spots. I think the right fix here is to switch dm-crypt to the ahash API that takes a scatterlist. ___ devel mailing list

Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 0007b79..b95934b 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -37,6 +37,9 @@ > > #include > > +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */ > +#undef

Re: [PATCH] storvsc: workaround for virtual DVD SCSI version

Thanks Stephen, this looks good to me: Reviewed-by: Christoph Hellwig <h...@lst.de> ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/2] scsi: storvsc: Add support for FC rport.

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de> ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] scsi: scsi_transport_fc: Add dummy initiator role to rport

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de> ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 4/6] vmbus: Switch to use new generic UUID API

On Wed, Jul 19, 2017 at 09:28:55PM +0300, Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. Can you split the uapi changes into a separate patch? I'd love

Re: [PATCH v1 5/6] uuid: Kill uapi/uuid.h

> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > index 29d6699d5a06..1c68709123aa 100644 > --- a/scripts/mod/file2alias.c > +++ b/scripts/mod/file2alias.c > @@ -36,7 +36,7 @@ typedef uint16_t__u16; > typedef unsigned char__u8; > typedef struct { > __u8

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

On Tue, Jul 25, 2017 at 01:40:06PM +0300, Andy Shevchenko wrote: > Christoph, can we apply this one at least to move things forward? Id be happy to pick this up for 4.14. Does everyone involved agree that the uuid tree is the right one? ___ devel

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Tue, Apr 25, 2017 at 12:20:48PM -0600, Logan Gunthorpe wrote: > This patch introduces functions which kmap the pages inside an sgl. > These functions replace a common pattern of kmap(sg_page(sg)) that is > used in more than 50 places within the kernel. > > The motivation for this work is to

Re: [PATCH v2 02/21] libiscsi: Add an internal error code

On Tue, Apr 25, 2017 at 12:20:49PM -0600, Logan Gunthorpe wrote: > This is a prep patch to add a new error code to libiscsi. We want to > rework some kmap calls to be able to fail. When we do, we'd like to > use this error code. The kmap case in iscsi_tcp_segment_map can already fail. Please add

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote: > Ok, well for starters I think you are mistaken about kmap being able to > fail. I'm having a hard time finding many users of that function that > bother to check for an error when calling it. A quick audit of the arch code shows

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

Hi John, please fix your quoting of the previous mails, thanks! What ACPI defines does not matter at all. Linux uses 32-bit domains IDs, and on x86 specifily uses those for non-ACPI enumarated domains (e.g. VMD). You've also not demontrated any issue with any Linux driver yet. > Also...it

Re: [PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

Ok. If the stable maintainers are ok with your small fix I'm not going to complain too loudly. But I'm always worried about stable trees divering too much from mainline. ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

FYI, I've also got another driver in progress that will need domains assigned outside the ACPI range, so it's not just limited to VMD. ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

On Wed, May 24, 2017 at 01:39:15PM -0700, Haiyang Zhang wrote: > From: Haiyang Zhang > > This patch uses the lower 16 bits of the serial number as PCI > domain, otherwise some drivers may not be able to handle it. > > Besides Nvidia drivers, we also found X.org, and DPDK

Re: [patch v2 1/6] tty: export tty_open_by_driver

On Mon, May 15, 2017 at 06:45:32PM +0100, Okash Khawaja wrote: > This exports tty_open_by_driver so that it can be called from other places > inside the kernel. The checks for null file pointer are based on Alan Cox's > patch here: >

Re: [PATCH 1/3] include: linux: visorbus: Add visorbus to include/linux directory

Please don't send any move patches but the actual code added to the kernel proper. And based on what's in linux-next I don't think this giant pile of junk is anywhere near mergeable. ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH 0/3] move visorbus out of staging to drivers/virt/visorbus

On Tue, Jun 06, 2017 at 04:49:09PM +0200, Greg KH wrote: > On Mon, Jun 05, 2017 at 04:07:29PM -0400, David Kershner wrote: > > This patchset moves drivers/staging/unisys/include to > > include/linux/visorbus, and moves drivers/staging/unisys/visorbus to > > drivers/virt/visorbus. > > Um, are you

Re: [PATCH] android: binder: fix type mismatch warning

On Mon, Sep 18, 2017 at 05:53:47PM +0200, Greg Kroah-Hartman wrote: > > It seems like a legitimate use case of the binder modules, but > > now there is a kernel Kconfig option that has to match a user > > space binary. > > So, should we revert that? > > I don't really know what to suggest here,

Re: [PATCH] android: binder: fix type mismatch warning

On Mon, Sep 18, 2017 at 05:35:03PM +0200, Arnd Bergmann wrote: > Probably not on a native Android device or even a Chromebook that > ships a binder user space together with a kernel, but what about > people using "anbox" or similar projects that allow you to run > Android apps in a container? > >

Re: [PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

Wouldn't it make sense to backport the changes to set the virt_boundary (which probably still is the SG_GAPS flag in such an old kernel)? ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wed, Aug 30, 2017 at 03:46:34PM +0200, Rafael J. Wysocki wrote: > 3689d3d69072 ACPI: device property: Switch to use new generic UUID API > > in my linux-next branch. Isn't it this one? Yes, that should be it. Somehow my linux-next tree seems to be a mess through or my git log skills aren't

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote: > Yep! There are so many conflicts that would be better just to push > through your tree. > > I have just sent a v2 of this patch separately. Greg, did you pick that patch up? ___ devel

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote: > > >> > Cc: "Rafael J. Wysocki" > > >> > Cc: Mika Westerberg > > >> > > >> Acked-by: Mika Westerberg > > > > > > OK > > > > > > Andy, do you

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

Thanks, applied to the uuid for-next tree. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] drivers: visorbus: move driver out of staging

Please don' tcreate new subdirectories under include/linux if you don't have to. Also who outside of unisys has reviewed this whole code? Instead of a move please send an actual patchset to add the new files so people can review it just like any other code.

Re: [PATCH v2] drivers: visorbus: move driver out of staging

Hi David, as said before, please submit the actual files as new code to the kernel. The code will need a full review, and a simple move is not going to cut it. Posting the actual code as patches will allow for the proper review that is needed. ___

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

On Fri, May 11, 2018 at 09:57:52AM +0200, Martijn Coenen wrote: > On Sat, May 5, 2018 at 2:10 PM, kbuild test robot wrote: > >drivers/android/binder.o: In function `binder_thread_write': > >>> binder.c:(.text+0x6a16): undefined reference to `__get_user_bad' > > Looks like

Re: [PATCH 34/40] atm: simplify procfs code

On Sat, May 05, 2018 at 07:51:18AM -0500, Eric W. Biederman wrote: > Christoph Hellwig <h...@lst.de> writes: > > > Use remove_proc_subtree to remove the whole subtree on cleanup, and > > unwind the registration loop into individual calls. Switch to use > > pr

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote: > Christoph Hellwig <h...@lst.de> writes: > > > The shole seq_file sequence already operates under a single RCU lock pair, > > so move the pid namespace lookup into it, and stop grabbing a reference

  1   2   3   4   >