On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
>
RISC-V ?
(evil grin :-)
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE
ool "Legacy USB Gadget Support"
> + help
> +Legacy USB gadgets are USB gadgets that do not use the USB gadget
> +configfs interface.
> +
> +if USB_GADGET_LEGACY
> +
> config USB_ZERO
> tristate "Gadget Zero (DEVELOPMENT)"
> select USB
--
Dr. Hannes ReineckezSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list
...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
Cc: linux-s...@vger.kernel.org
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries Storage
h...@suse.de
Reinecke h...@suse.de
CC: sta...@vger.kernel.org
That is correct.
Acked-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm
On 04/10/2014 10:36 PM, James Bottomley wrote:
On Thu, 2014-04-10 at 19:52 +0200, Hannes Reinecke wrote:
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes
On 04/07/2014 05:26 PM, Alan Stern wrote:
On Wed, 2 Apr 2014, Hannes Reinecke wrote:
On 04/01/2014 11:28 PM, Alan Stern wrote:
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c b
On 04/01/2014 11:28 PM, Alan Stern wrote:
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 771c16b..0e72374 100644
--- a/drivers/scsi
On 03/31/2014 05:03 PM, James Bottomley wrote:
[lets split the thread]
On Mon, 2014-03-31 at 16:37 +0200, Hannes Reinecke wrote:
On 03/31/2014 03:33 PM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James
On 04/01/2014 12:29 AM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
Ah. Correct. But that's due to the first patch being incorrect.
Cf my response to the original first patch.
See my response to your response. :-)
Okay, So I probably should refrain from issueing
)) {
SCSI_LOG_ERROR_RECOVERY(3,
scmd_printk(KERN_INFO, scmd,
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J
not bother them with a REQUEST_SENSE command. Fix this by
testing to see if we actually got a CHECK_CONDITION return and skip asking for
sense if we don't.
Tested-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: James Bottomley jbottom...@parallels.com
Acked-by: Hannes Reinecke h...@suse.de
result of the previous error
instead of the timeout. Fix this by properly zeroing the scmd-status before
the command is resubmitted.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: James Bottomley jbottom...@parallels.com
grin
Acked-by: Hannes Reinecke h...@suse.de
Cheers
FAILED?
- If it had returned SUCCESS, why did the device_reset_handler
wait for the command to complete?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J
On 03/31/2014 03:33 PM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James Bottomley wrote:
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch
perfect.
Try to disable smartd and check if the issue remains.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG
to me, so I'd rather have it handled via a quirk.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg
tr...@suse.de
Cc: Yinghai Lu ying...@kernel.org
Cc: Frederik Himpe fhi...@vub.ac.be
Cc: David Haerdeman da...@hardeman.nu
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 622b4a4..2647e75
Neukum oneu...@suse.de
Cc: Thomas Renninger tr...@suse.de
Cc: Yinghai Lu ying...@kernel.org
Cc: Frederik Himpe fhi...@vub.ac.be
Cc: David Haerdeman da...@hardeman.nu
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 8e64adf..e583444
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke h...@suse.de wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke h...@suse.de wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_
On 02/26/2013 02:29 PM, David Härdeman wrote:
On Thu, Feb 21, 2013 at 07:53:14AM +0100, Hannes Reinecke wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
it seems you mess pin with interrupt line.
current code:
unsigned char irq;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled Interrupts
On 02/19/2013 08:40 PM, Yinghai Lu wrote:
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke h...@suse.de wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning
@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6186f03..a2db887f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -923,7 +923,8 @@ static void pci_read_irq(struct pci_dev *dev)
dev-pin
26 matches
Mail list logo
