RE: About patchwork for linux-usb

[Peter Chen]

 
> > > > > > At some situations, we may need to save reviewing patches from
> > > > > > web, but I can't find linux-usb at
> > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
> > > > > %2Fp
> > > > > atchwork.k
> > > > >
> > >
> ernel.org%2F=02%7C01%7Cpeter.chen%40nxp.com%7Cbef6ada7885641ed5
> > > > >
> > >
> bf408d58b131139%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6365
> > > > >
> > >
> 67836369109099=w8dVZjbsb%2BrboggllBzJbdkxR6r7BQHOEtf7tQ5mCPE%
> > > > > 3D=0,  any there any patchworks for linux-usb mailist at 
> > > > > Internet?
> > > Thanks.
> > > > >
> > > > > I do not know of any, as I do not use patchwork, sorry.  If you
> > > > > feel that we should add it to patchwork.kernel.org, that can easily 
> > > > > be done.
> > > > >
> > > > > thanks,
> > > > >
> > > >
> > > > Some may would like to test the reviewing patches, but they do not
> > > > have the tool like mutt to save patches, it is useful for them.
> > > > It will be great we
> > > would do that, thanks.
> > >
> > > I've asked for it to be included.
> > >
> > > But really, you should use a good email client :)
> > >
> >
> > Thanks, Greg. Company IT policies have changed recently, we are
> > requesting mutt (imap supported) for development.
> 
> linux-usb is now on patchwork.kernel.org.
> 
> But note, I do not use it, so you can't track my acceptance/review of patches 
> using it.
> 

I see, thanks.

And I have tested patch download and apply, it works.

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb-storage: stop using block layer bounce buffers

[Alan Stern]

On Sun, 15 Apr 2018, Christoph Hellwig wrote:

> USB host controllers now must handle highmem, so we can get rid of bounce
> buffering highmem pages in the block layer.

Sorry, I don't quite understand what you are saying.  Do you mean that
all USB host controllers now magically _do_ handle highmem?  Or do you
mean that if they _don't_ handle highmem, we will not support them any
more?

Alan Stern

> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/usb/storage/scsiglue.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index c267f2812a04..4e453d9d45d5 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -130,15 +130,6 @@ static int slave_configure(struct scsi_device *sdev)
>   blk_queue_max_hw_sectors(sdev->request_queue, 2048);
>   }
>  
> - /*
> -  * Some USB host controllers can't do DMA; they have to use PIO.
> -  * They indicate this by setting their dma_mask to NULL.  For
> -  * such controllers we need to make sure the block layer sets
> -  * up bounce buffers in addressable memory.
> -  */
> - if (!us->pusb_dev->bus->controller->dma_mask)
> - blk_queue_bounce_limit(sdev->request_queue, BLK_BOUNCE_HIGH);
> -
>   /*
>* We can't put these settings in slave_alloc() because that gets
>* called before the device type is known.  Consequently these
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb-storage: stop using block layer bounce buffers

[Christoph Hellwig]

USB host controllers now must handle highmem, so we can get rid of bounce
buffering highmem pages in the block layer.

Signed-off-by: Christoph Hellwig 
---
 drivers/usb/storage/scsiglue.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index c267f2812a04..4e453d9d45d5 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -130,15 +130,6 @@ static int slave_configure(struct scsi_device *sdev)
blk_queue_max_hw_sectors(sdev->request_queue, 2048);
}
 
-   /*
-* Some USB host controllers can't do DMA; they have to use PIO.
-* They indicate this by setting their dma_mask to NULL.  For
-* such controllers we need to make sure the block layer sets
-* up bounce buffers in addressable memory.
-*/
-   if (!us->pusb_dev->bus->controller->dma_mask)
-   blk_queue_bounce_limit(sdev->request_queue, BLK_BOUNCE_HIGH);
-
/*
 * We can't put these settings in slave_alloc() because that gets
 * called before the device type is known.  Consequently these
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: mon: Change return type to vm_fault_t

[Matthew Wilcox]

On Sun, Apr 15, 2018 at 07:49:16AM +0200, Greg KH wrote:
> On Sun, Apr 15, 2018 at 12:36:02AM +0530, Souptick Joarder wrote:
> > Use new return type vm_fault_t for fault handler
> > in struct vm_operations_struct.
> 
> Why?

commit 1c8f422059ae5da07db7406ab916203f9417e396
Author: Souptick Joarder 
Date:   Thu Apr 5 16:25:23 2018 -0700

mm: change return type to vm_fault_t

The plan for these patches is to introduce the typedef, initially just
as documentation ("These functions should return a VM_FAULT_ status").
We'll trickle the patches to individual drivers/filesystems in through
the maintainers, as far as possible.  Then we'll change the typedef to
an unsigned int and break the compilation of any unconverted
drivers/filesystems.

vmf_insert_page(), vmf_insert_mixed() and vmf_insert_pfn() are three
newly added functions.  The various drivers/filesystems where return
value of fault(), huge_fault(), page_mkwrite() and pfn_mkwrite() get
converted, will need them.  These functions will return correct
VM_FAULT_ code based on err value.

We've had bugs before where drivers returned -EFOO.  And we have this
silly inefficiency where vm_insert_xxx() return an errno which (afaict)
every driver then converts into a VM_FAULT code.  In many cases drivers
failed to return correct VM_FAULT code value despite of vm_insert_xxx()
fails.  We have indentified and clean up all those existing bugs and
silly inefficiencies in driver/filesystems by adding these three new
inline wrappers.  As mentioned above, we will trickle those patches to
individual drivers/filesystems in through maintainers after these three
wrapper functions are merged.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About patchwork for linux-usb

[Greg Kroah-Hartman]

On Thu, Mar 22, 2018 at 12:57:49AM +, Peter Chen wrote:
>  
> > > > > At some situations, we may need to save reviewing patches from
> > > > > web, but I can't find linux-usb at
> > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > > > atchwork.k
> > > >
> > ernel.org%2F=02%7C01%7Cpeter.chen%40nxp.com%7Cbef6ada7885641ed5
> > > >
> > bf408d58b131139%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6365
> > > >
> > 67836369109099=w8dVZjbsb%2BrboggllBzJbdkxR6r7BQHOEtf7tQ5mCPE%
> > > > 3D=0,  any there any patchworks for linux-usb mailist at 
> > > > Internet?
> > Thanks.
> > > >
> > > > I do not know of any, as I do not use patchwork, sorry.  If you feel
> > > > that we should add it to patchwork.kernel.org, that can easily be done.
> > > >
> > > > thanks,
> > > >
> > >
> > > Some may would like to test the reviewing patches, but they do not
> > > have the tool like mutt to save patches, it is useful for them.  It will 
> > > be great we
> > would do that, thanks.
> > 
> > I've asked for it to be included.
> > 
> > But really, you should use a good email client :)
> > 
> 
> Thanks, Greg. Company IT policies have changed recently, we are requesting
> mutt (imap supported) for development.

linux-usb is now on patchwork.kernel.org.

But note, I do not use it, so you can't track my acceptance/review of
patches using it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: mon: Change return type to vm_fault_t

[Greg KH]

On Sun, Apr 15, 2018 at 12:36:02AM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct.

Why?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html