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.
___
> 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 kunmap_at
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 ISCSI_TCP_INTERNAL_ER
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
d
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
Looks good,
Reviewed-by: Christoph Hellwig
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Looks good,
Reviewed-by: Christoph Hellwig
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
ht
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 wou
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 eve
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
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 yo
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:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg12
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 handle
> only 16 bit PCI
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
http://driverdev.li
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 t
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
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-d
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
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
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 tar
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
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 we
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
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 hos
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
c
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 former
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
i
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.
Micr
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 real
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 tool
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 pi
On Wed, Feb 08, 2017 at 04:49:30PM -0600, Bjorn Helgaas wrote:
> + list_for_each_entry(child, &bus->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.
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. Woul
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
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 p
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
> 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 b[16];
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 mailin
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
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverde
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
http://driverdev.linuxdriverpro
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 ma
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 want me to apply this?
> >
> > If you would like to.
> >
> > The patch is now pretty
Thanks,
applied to the uuid for-next tree.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 w
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 har
On Tue, Oct 08, 2013 at 10:43:07AM +1100, Dave Chinner wrote:
> > Maybe, writeboost should disable deferring barriers
> > if barrier_deadline_ms parameter is especially 0.
> > Linux kernel's layered architecture is obviously not always perfect
> > so there are similar cases in other boundaries
> >
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
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
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 m
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 do
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 devi
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 thoug
On Thu, Oct 16, 2014 at 02:47:41PM +0200, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman
>
> The Android binder code has been "stable" for many years now. No matter
> what comes in the future, we are going to have to support this API, so
> might as well move it to the "real" part of the ke
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
http://driverdev.linuxdriverproject.org/mai
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
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 dri
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
On Tue, Jul 08, 2014 at 05:46:46PM -0700, K. Y. Srinivasan wrote:
> Going forward it is possible that some of the commands that are not currently
> implemented will be implemented on future Windows hosts. Make command
> filtering
> depend on the host version.
> + if (vmstor_current_major <= V
> + 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
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?
_
Looks good,
Reviewed-by: Christoph Hellwig
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 t
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 H
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(scmn
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 var
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
> 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
> - .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?
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
http://driverdev.linuxdriver
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?
__
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
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
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-d
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
ed-off-by: K. Y. Srinivasan
Looks good to me,
Reviewed-by: Christoph Hellwig
(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?
___
d
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
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
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 t
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 act
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 th
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, b
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
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 curren
I someone seem to get just this patch instead of the full series for
review again..
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Thu, Jul 09, 2020 at 09:27:06AM -0400, Jim Quinlan wrote:
> Hi Christoph,
>
> I'm sending all commits to since most of
> them are PCI related. I don't send all patches to
> linux-ker...@vger.kernel.org since I've read it is overused. The --cc
> list is generated by get_maintainer.pl.
>
> II
On Wed, Jul 15, 2020 at 10:35:11AM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable o
A few tiny nitpicks:
The subject should have the dma-mapping prefix, this doesn't
really touch the device core.
> - rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + rc = of_dma_get_range(np, &map);
> + rc = PTR_ERR_OR_ZERO(map);
I don't think you need the PTR_ERR_OR_ZERO line
On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> I started using devm_kcalloc() but at least two reviewers convinced me
> to just use kcalloc(). In addition, when I was using devm_kcalloc()
> it was awkward because 'dev' is not available to this function.
>
> It comes down to whethe
You can't modify non-staging core code just for staging code.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Mon, Aug 17, 2020 at 09:49:59AM +0200, Mauro Carvalho Chehab wrote:
> Add a driver for the Kirin 960/970 iommu.
>
> As on the past series, this starts from the original 4.9 driver from
> the 96boards tree:
>
> https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
>
> The remaining
On Mon, Aug 17, 2020 at 11:27:25AM +0200, Mauro Carvalho Chehab wrote:
> I need to start from the original patch in order to preserve its
> authorship.
Nom you don't. We have plenty of example where people submit code
written by other, especially when it is significantly reworked,
> My plan is t
On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote:
> Remove BUG/BUG_ON from androind/ion
Please just remove ion. It has been rejected and we have developed
proper kernel subsystens to replace it. Don't waste your time on it.
___
devel mailin
On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> Hi,
>
> On 8/24/2020 12:30 PM, Jim Quinlan wrote:
>>
>> Patchset Summary:
>>Enhance a PCIe host controller driver. Because of its unusual design
>>we are foced to change dev->dma_pfn_offset into a more general role
>>a
On Tue, Aug 25, 2020 at 08:52:29AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 25, 2020 at 07:47:29AM +0100, Christoph Hellwig wrote:
> > On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote:
> > > Remove BUG/BUG_ON from androind/ion
> >
> > Please
I've applied this to the dma-mapping tree.
I had to resolve a conflict in drivers/of/address.c with a recent
mainline commit. I also applied the minor tweaks Andy pointed out
plus a few more style changes. A real change is that I changed the
prototype for dma_copy_dma_range_map to require less b
On Tue, Jul 30, 2013 at 08:29:51AM +0800, Xiong Zhou wrote:
> From: Xiong Zhou
>
> In the lustre client driver, lloop depends on BLOCK. Add an
> option for this dependence. Last version of this patch makes
> LUSTRE_FS depends on BLOCK.
> Remove unnecessary jdb head files which depends on BLOCK.
On Thu, Aug 01, 2013 at 07:57:22PM +, Dilger, Andreas wrote:
> It provides significant performance improvement for network IO on Lustre.
> It bypasses DLM locking in Lustre and the VFS layer on the client, copying
> in the loop driver, and page-by-page IO submission in the normal IO path.
Part
On Wed, Aug 07, 2013 at 07:45:17AM +, Dilger, Andreas wrote:
> The problem still remains that the kernel loop driver eventually depends on
> a local block device for the pages/bios to be written. The Lustre lloop
> driver bypasses the VFS and block layer to generate RPCs from the submitted
> p
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
On Wed, Sep 11, 2013 at 01:14:11AM +0800, Peng Tao wrote:
> The problem is access_process_vm() is not exported since certain
> version of kernel including the latest. According to Christoph in the
> other mail, access_process_vm() is also a core mm function that is not
> supposed to be exported. Th
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 e
301 - 400 of 402 matches
Mail list logo
