Re: [PATCH 0/5] Bring the BusLogic host bus adapter driver up to Y2021
On Friday 16 April 2021 23:25:18 Maciej W. Rozycki wrote: > On Fri, 16 Apr 2021, Khalid Aziz wrote: > > > > Sadly I didn't get to these resources while they were still there, and > > > neither did archive.org, and now they not appear available from anywhere > > > online. I'm sure Leonard had this all, but, alas, he is long gone too. > > > > These documents were all gone by the time I started working on this > > driver in 2013. > > According to my e-mail archives I got my BT-958 directly from Mylex brand > new as KT-958 back in early 1998 (the rest of the system is a bit older). > It wasn't up until 2003 when I was caught by the issue with the LOG SENSE > command that I got interested in the programming details of the adapter. > > At that time Mylex was in flux already, having been bought by LSI shortly > before. Support advised me what was there at Leonard's www.dandelion.com > site was all that was available (I have a personal copy of the site) and > they would suggest to switch to their current products. So it was too > late already ten years before you got at the driver. > > I'll yet double-check the contents of the KT-958 kit which I have kept, > but if there was any technical documentation supplied there on a CD (which > I doubt), I would have surely discovered it earlier. It's away along with > the server, remotely managed, ~160km/100mi from here, so it'll be some > time before I get at it though. > > Still, maybe one of the SCSI old-timers has that stuff stashed somewhere. > I have plenty of technical documentation going back to early to mid 1990s > (some in the hard copy form), not necessarily readily available nowadays. > Sadly lots of such stuff goes offline or is completely lost to the mist of > time. > > Maciej > Found the 3000763 document here: https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/3000763_PCI_EISA_Wide_SCSI_Tech_Ref_Dec94.pdf There's also 3002593 there: https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/ -- Ondrej Zary
Re: 5.10 LTS Kernel: 2 or 6 years?
On Thursday 18 February 2021 21:55:34 Pavel Machek wrote: > Hi! > > > > For me > > > only way to get properly working WiFi on my laptop computer is to > > > compile that Intel out-of-tree version. Sad, but true. > > > > Why use 4.19.y on a laptop in the firstplace? That feels very wrong and > > is not the recommended thing to use the LTS kernels for. > > Well, that's actually what distributions are doing, for example Debian > 10.8 is on 4.19... There's 5.10 in buster-backports. That's probably the easiest way to get support for new HW. > I expect -stable is what most users are running on their notebooks. > > Best regards, > Pavel -- Ondrej Zary
Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian
On Saturday 10 October 2020 02:02:42 Karol Herbst wrote: > On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin wrote: > > > > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote: > > > > > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote: > > > > > > > > Hello, > > > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > > > > [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian > > > > 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri > > > > Oct 9 22:31:40 CEST 2020 > > > > ... > > > > [ 14.771464] nouveau :01:00.0: GPU not supported on big-endian > > > > [ 14.771782] nouveau: probe of :01:00.0 failed with error -38 > > > > > > > > big-endian? WTF? The machine is x86. > > > > > > > > > > mhh, we reworked the endianess checks a bit and apparently that broke > > > something... I will give it some thoughts, but could you be so kind > > > and create an mmiotrace under 5.9 with nouveau? You won't need to > > > start X or anything while doing it. Just enable the trace and modprobe > > > nouveau and collect the trace. > > > > Looks like nvkm_device_endianness unconditionally reads out 0x4. I > > don't think that reg is there pre-NV11. At least NV4, NV5, NV10 and > > maybe NV15 (which is logically pre-NV11) don't support big-endian > > mode. Not sure about NV1A, which was the IGP of the series and IIRC > > logically pre-NV11 as well (but clearly could only be used with x86 > > chips, since it was part of the motherboard). > > > > Aha, it's documented in rnndb: > > > > https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml > > > > > > ohh, I should have checked there.. yeah, will write a fix for it then. > Before my patch we just always tried to switch it, but never threw an > error. Any progress with the patch? -- Ondrej Zary
Re: [PATCH 1/2] cx82310_eth: re-enable ethernet mode after router reboot
On Monday 12 October 2020, Jakub Kicinski wrote: > On Sat, 10 Oct 2020 16:00:46 +0200 Ondrej Zary wrote: > > When the router is rebooted without a power cycle, the USB device > > remains connected but its configuration is reset. This results in > > a non-working ethernet connection with messages like this in syslog: > > usb 2-2: RX packet too long: 65535 B > > > > Re-enable ethernet mode when receiving a packet with invalid size of > > 0x. > > Patch looks good, but could you explain what's a reboot without a power > cycle in this case? The modem gets reset but USB subsystem doesn't know > it and doesn't go though a unbind() + bind() cycle? The router can be rebooted through the web interface. The reboot does not disconnect the USB device - it remains connected as if nothing happened. Only wrong data starts to come in. -- Ondrej Zary
[PATCH 1/2] cx82310_eth: re-enable ethernet mode after router reboot
When the router is rebooted without a power cycle, the USB device
remains connected but its configuration is reset. This results in
a non-working ethernet connection with messages like this in syslog:
usb 2-2: RX packet too long: 65535 B
Re-enable ethernet mode when receiving a packet with invalid size of
0x.
Signed-off-by: Ondrej Zary
---
drivers/net/usb/cx82310_eth.c | 50 ++-
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 32b08b18e120..043679311399 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -40,6 +40,11 @@ enum cx82310_status {
#define CX82310_MTU1514
#define CMD_EP 0x01
+struct cx82310_priv {
+ struct work_struct reenable_work;
+ struct usbnet *dev;
+};
+
/*
* execute control command
* - optionally send some data (command parameters)
@@ -115,6 +120,23 @@ static int cx82310_cmd(struct usbnet *dev, enum
cx82310_cmd cmd, bool reply,
return ret;
}
+static int cx82310_enable_ethernet(struct usbnet *dev)
+{
+ int ret = cx82310_cmd(dev, CMD_ETHERNET_MODE, true, "\x01", 1, NULL, 0);
+
+ if (ret)
+ netdev_err(dev->net, "unable to enable ethernet mode: %d\n",
+ ret);
+ return ret;
+}
+
+static void cx82310_reenable_work(struct work_struct *work)
+{
+ struct cx82310_priv *priv = container_of(work, struct cx82310_priv,
+reenable_work);
+ cx82310_enable_ethernet(priv->dev);
+}
+
#define partial_lendata[0] /* length of partial packet data */
#define partial_remdata[1] /* remaining (missing) data length */
#define partial_data data[2] /* partial packet data */
@@ -126,6 +148,7 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
struct usb_device *udev = dev->udev;
u8 link[3];
int timeout = 50;
+ struct cx82310_priv *priv;
/* avoid ADSL modems - continue only if iProduct is "USB NET CARD" */
if (usb_string(udev, udev->descriptor.iProduct, buf, sizeof(buf)) > 0
@@ -152,6 +175,15 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
if (!dev->partial_data)
return -ENOMEM;
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto err_partial;
+ }
+ dev->driver_priv = priv;
+ INIT_WORK(>reenable_work, cx82310_reenable_work);
+ priv->dev = dev;
+
/* wait for firmware to become ready (indicated by the link being up) */
while (--timeout) {
ret = cx82310_cmd(dev, CMD_GET_LINK_STATUS, true, NULL, 0,
@@ -168,12 +200,8 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
}
/* enable ethernet mode (?) */
- ret = cx82310_cmd(dev, CMD_ETHERNET_MODE, true, "\x01", 1, NULL, 0);
- if (ret) {
- dev_err(>dev, "unable to enable ethernet mode: %d\n",
- ret);
+ if (cx82310_enable_ethernet(dev))
goto err;
- }
/* get the MAC address */
ret = cx82310_cmd(dev, CMD_GET_MAC_ADDR, true, NULL, 0,
@@ -190,13 +218,19 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
return 0;
err:
+ kfree(dev->driver_priv);
+err_partial:
kfree((void *)dev->partial_data);
return ret;
}
static void cx82310_unbind(struct usbnet *dev, struct usb_interface *intf)
{
+ struct cx82310_priv *priv = dev->driver_priv;
+
kfree((void *)dev->partial_data);
+ cancel_work_sync(>reenable_work);
+ kfree(dev->driver_priv);
}
/*
@@ -211,6 +245,7 @@ static int cx82310_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
{
int len;
struct sk_buff *skb2;
+ struct cx82310_priv *priv = dev->driver_priv;
/*
* If the last skb ended with an incomplete packet, this skb contains
@@ -245,7 +280,10 @@ static int cx82310_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
break;
}
- if (len > CX82310_MTU) {
+ if (len == 0x) {
+ netdev_info(dev->net, "router was rebooted, re-enabling
ethernet mode");
+ schedule_work(>reenable_work);
+ } else if (len > CX82310_MTU) {
dev_err(>udev->dev, "RX packet too long: %d B\n",
len);
return 0;
--
Ondrej Zary
Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian
On Saturday 10 October 2020 00:23:38 Ilia Mirkin wrote: > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote: > > > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote: > > > > > > Hello, > > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > > > [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6) > > > 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 > > > 22:31:40 CEST 2020 > > > ... > > > [ 14.771464] nouveau :01:00.0: GPU not supported on big-endian > > > [ 14.771782] nouveau: probe of :01:00.0 failed with error -38 > > > > > > big-endian? WTF? The machine is x86. > > > > > > > mhh, we reworked the endianess checks a bit and apparently that broke > > something... I will give it some thoughts, but could you be so kind > > and create an mmiotrace under 5.9 with nouveau? You won't need to > > start X or anything while doing it. Just enable the trace and modprobe > > nouveau and collect the trace. > > Looks like nvkm_device_endianness unconditionally reads out 0x4. I > don't think that reg is there pre-NV11. At least NV4, NV5, NV10 and > maybe NV15 (which is logically pre-NV11) don't support big-endian > mode. Not sure about NV1A, which was the IGP of the series and IIRC > logically pre-NV11 as well (but clearly could only be used with x86 > chips, since it was part of the motherboard). Yes, you're right. Forcing nvkm_device_endianness to return true allows 5.9.0-rc8 to work: [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 ... [ 12.311258] nouveau :01:00.0: bios: DCB table not found [ 12.311583] nouveau :01:00.0: bios: DCB table not found [ 12.311834] nouveau :01:00.0: bios: DCB table not found [ 12.311847] nouveau :01:00.0: bios: DCB table not found [ 12.311989] agpgart-intel :00:00.0: AGP 3.0 bridge [ 12.312017] agpgart-intel :00:00.0: bridge is in legacy mode, falling back to 2.x [ 12.312031] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode [ 12.312066] nouveau :01:00.0: putting AGP V2 device into 4x mode [ 12.312162] agpgart-intel :00:00.0: AGP 3.0 bridge [ 12.312182] agpgart-intel :00:00.0: bridge is in legacy mode, falling back to 2.x [ 12.312195] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode [ 12.312230] nouveau :01:00.0: putting AGP V2 device into 4x mode [ 12.312247] nouveau :01:00.0: tmr: unknown input clock freq [ 12.318341] nouveau :01:00.0: fb: 32 MiB SDRAM [ 12.76] [TTM] Zone kernel: Available graphics memory: 385048 KiB [ 12.92] [TTM] Initializing pool allocator [ 12.333434] nouveau :01:00.0: DRM: VRAM: 31 MiB [ 12.333443] nouveau :01:00.0: DRM: GART: 128 MiB [ 12.333453] nouveau :01:00.0: DRM: BMP version 5.6 [ 12.333460] nouveau :01:00.0: DRM: No DCB data found in VBIOS [ 12.335355] nouveau :01:00.0: DRM: MM: using M2MF for buffer copies [ 12.335443] nouveau :01:00.0: bios: DCB table not found [ 12.336033] nouveau :01:00.0: DRM: Saving VGA fonts [ 12.376420] nouveau :01:00.0: DRM: No DCB data found in VBIOS [ 12.410397] nouveau :01:00.0: DRM: allocated 1280x1024 fb: 0x4000, bo b68d2ac4 [ 12.441217] fbcon: nouveaudrmfb (fb0) is primary device [ 12.591964] Console: switching to colour frame buffer device 160x64 [ 12.593876] nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device [ 12.594944] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 BTW. 5.8 kernel (that appeared today in Debian packports) is broken the same way. > Aha, it's documented in rnndb: > > https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml > > > -ilia > -- Ondrej Zary
[PATCH 2/2] cx82310_eth: use netdev_err instead of dev_err
Use netdev_err for better device identification in syslog.
Signed-off-by: Ondrej Zary
---
drivers/net/usb/cx82310_eth.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 043679311399..ca89d8258dd3 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -71,8 +71,8 @@ static int cx82310_cmd(struct usbnet *dev, enum cx82310_cmd
cmd, bool reply,
CMD_PACKET_SIZE, _len, CMD_TIMEOUT);
if (ret < 0) {
if (cmd != CMD_GET_LINK_STATUS)
- dev_err(>udev->dev, "send command %#x: error %d\n",
- cmd, ret);
+ netdev_err(dev->net, "send command %#x: error %d\n",
+ cmd, ret);
goto end;
}
@@ -84,30 +84,27 @@ static int cx82310_cmd(struct usbnet *dev, enum cx82310_cmd
cmd, bool reply,
CMD_TIMEOUT);
if (ret < 0) {
if (cmd != CMD_GET_LINK_STATUS)
- dev_err(>udev->dev,
- "reply receive error %d\n",
- ret);
+ netdev_err(dev->net, "reply receive
error %d\n",
+ ret);
goto end;
}
if (actual_len > 0)
break;
}
if (actual_len == 0) {
- dev_err(>udev->dev, "no reply to command %#x\n",
- cmd);
+ netdev_err(dev->net, "no reply to command %#x\n", cmd);
ret = -EIO;
goto end;
}
if (buf[0] != cmd) {
- dev_err(>udev->dev,
- "got reply to command %#x, expected: %#x\n",
- buf[0], cmd);
+ netdev_err(dev->net, "got reply to command %#x,
expected: %#x\n",
+ buf[0], cmd);
ret = -EIO;
goto end;
}
if (buf[1] != STATUS_SUCCESS) {
- dev_err(>udev->dev, "command %#x failed: %#x\n",
- cmd, buf[1]);
+ netdev_err(dev->net, "command %#x failed: %#x\n", cmd,
+ buf[1]);
ret = -EIO;
goto end;
}
@@ -194,7 +191,7 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
msleep(500);
}
if (!timeout) {
- dev_err(>dev, "firmware not ready in time\n");
+ netdev_err(dev->net, "firmware not ready in time\n");
ret = -ETIMEDOUT;
goto err;
}
@@ -207,7 +204,7 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
ret = cx82310_cmd(dev, CMD_GET_MAC_ADDR, true, NULL, 0,
dev->net->dev_addr, ETH_ALEN);
if (ret) {
- dev_err(>dev, "unable to read MAC address: %d\n", ret);
+ netdev_err(dev->net, "unable to read MAC address: %d\n", ret);
goto err;
}
@@ -284,8 +281,7 @@ static int cx82310_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
netdev_info(dev->net, "router was rebooted, re-enabling
ethernet mode");
schedule_work(>reenable_work);
} else if (len > CX82310_MTU) {
- dev_err(>udev->dev, "RX packet too long: %d B\n",
- len);
+ netdev_err(dev->net, "RX packet too long: %d B\n", len);
return 0;
}
--
Ondrej Zary
nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian
Hello, I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 ... [ 14.771464] nouveau :01:00.0: GPU not supported on big-endian [ 14.771782] nouveau: probe of :01:00.0 failed with error -38 big-endian? WTF? The machine is x86. It works fine with Debian 5.7 kernel (5.7.10-1~bpo10+1): [0.00] Linux version 5.7.0-0.bpo.2-686 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6), GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 5.7.10-1~bpo10+1 (2020-07-30) ... [ 23.266196] nouveau :01:00.0: NVIDIA NV05 (20154000) [ 23.288582] nouveau :01:00.0: bios: version 02.05.20.02.00 [ 23.288869] nouveau :01:00.0: bios: DCB table not found [ 23.289595] nouveau :01:00.0: bios: DCB table not found [ 23.289956] nouveau :01:00.0: bios: DCB table not found [ 23.290015] nouveau :01:00.0: bios: DCB table not found [ 23.290215] agpgart-intel :00:00.0: AGP 3.0 bridge [ 23.290287] agpgart-intel :00:00.0: bridge is in legacy mode, falling back to 2.x [ 23.290351] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode [ 23.290430] nouveau :01:00.0: putting AGP V2 device into 4x mode [ 23.290565] agpgart-intel :00:00.0: AGP 3.0 bridge [ 23.290627] agpgart-intel :00:00.0: bridge is in legacy mode, falling back to 2.x [ 23.290690] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode [ 23.290768] nouveau :01:00.0: putting AGP V2 device into 4x mode [ 23.290830] nouveau :01:00.0: tmr: unknown input clock freq [ 23.293026] nouveau :01:00.0: fb: 32 MiB SDRAM [ 23.301269] [TTM] Zone kernel: Available graphics memory: 382728 KiB [ 23.301327] [TTM] Initializing pool allocator [ 23.301414] nouveau :01:00.0: DRM: VRAM: 31 MiB [ 23.301465] nouveau :01:00.0: DRM: GART: 128 MiB [ 23.301518] nouveau :01:00.0: DRM: BMP version 5.6 [ 23.301570] nouveau :01:00.0: DRM: No DCB data found in VBIOS [ 23.303594] nouveau :01:00.0: DRM: MM: using M2MF for buffer copies [ 23.303719] nouveau :01:00.0: bios: DCB table not found [ 23.304904] nouveau :01:00.0: DRM: Saving VGA fonts [ 23.349089] nouveau :01:00.0: DRM: No DCB data found in VBIOS [ 23.349681] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 23.383066] nouveau :01:00.0: DRM: allocated 1280x1024 fb: 0x4000, bo b10d2f17 [ 23.413903] fbcon: nouveaudrmfb (fb0) is primary device [ 23.569851] Console: switching to colour frame buffer device 160x64 [ 23.571050] nouveau :01:00.0: fb0: nouveaudrmfb frame buffer device -- Ondrej Zary
Re: [PATCH 12/30] net: wireless: cisco: airo: Fix a myriad of coding style issues
On Friday 28 August 2020 10:59:37 Kalle Valo wrote: > Ondrej Zary writes: > > > On Thursday 27 August 2020 09:49:12 Kalle Valo wrote: > >> Ondrej Zary writes: > >> > >> > On Monday 17 August 2020 20:27:06 Jesse Brandeburg wrote: > >> >> On Mon, 17 Aug 2020 16:27:01 +0300 > >> >> Kalle Valo wrote: > >> >> > >> >> > I was surprised to see that someone was using this driver in 2015, so > >> >> > I'm not sure anymore what to do. Of course we could still just remove > >> >> > it and later revert if someone steps up and claims the driver is still > >> >> > usable. Hmm. Does anyone any users of this driver? > >> >> > >> >> What about moving the driver over into staging, which is generally the > >> >> way I understood to move a driver slowly out of the kernel? > >> > > >> > Please don't remove random drivers. > >> > >> We don't want to waste time on obsolete drivers and instead prefer to > >> use our time on more productive tasks. For us wireless maintainers it's > >> really hard to know if old drivers are still in use or if they are just > >> broken. > >> > >> > I still have the Aironet PCMCIA card and can test the driver. > >> > >> Great. Do you know if the airo driver still works with recent kernels? > > > > Yes, it does. > > Nice, I'm very surprised that so old and unmaintained driver still > works. Thanks for testing. Thanks to great work of all kernel maintainers most of the old drivers still work so Linux users aren't forced to throw away hardware just because it stopped working after a software update. -- Ondrej Zary
Re: [PATCH 12/30] net: wireless: cisco: airo: Fix a myriad of coding style issues
On Thursday 27 August 2020 09:49:12 Kalle Valo wrote: > Ondrej Zary writes: > > > On Monday 17 August 2020 20:27:06 Jesse Brandeburg wrote: > >> On Mon, 17 Aug 2020 16:27:01 +0300 > >> Kalle Valo wrote: > >> > >> > I was surprised to see that someone was using this driver in 2015, so > >> > I'm not sure anymore what to do. Of course we could still just remove > >> > it and later revert if someone steps up and claims the driver is still > >> > usable. Hmm. Does anyone any users of this driver? > >> > >> What about moving the driver over into staging, which is generally the > >> way I understood to move a driver slowly out of the kernel? > > > > Please don't remove random drivers. > > We don't want to waste time on obsolete drivers and instead prefer to > use our time on more productive tasks. For us wireless maintainers it's > really hard to know if old drivers are still in use or if they are just > broken. > > > I still have the Aironet PCMCIA card and can test the driver. > > Great. Do you know if the airo driver still works with recent kernels? Yes, it does. $ uname -a Linux test 5.7.0-0.bpo.2-686 #1 SMP Debian 5.7.10-1~bpo10+1 (2020-07-30) i686 GNU/Linux # dmesg | grep airo [ 22.002273] airo(): Probing for PCI adapters [ 22.002422] airo(): Finished probing for PCI adapters [ 23.796853] airo(): cmd:111 status:7f11 rsp0:2 rsp1:0 rsp2:0 [ 23.796879] airo(): Doing fast bap_reads [ 24.021208] airo(eth1): Firmware version 5.60.22 [ 24.021238] airo(eth1): WPA supported. [ 24.021251] airo(eth1): MAC enabled xx:xx:xx:xx:xx:xx [ 24.062695] airo_cs 0.0 eth35: renamed from eth1 [ 50.308100] airo(eth35): Bad MAC enable reason=eaac, rid=e, offset=0 [ 50.332761] airo(eth35): Bad MAC enable reason=eaac, rid=e, offset=0 # wpa_supplicant -Dwext -ieth35 -c/etc/wpa_supplicant/wpa_supplicant.conf & Successfully initialized wpa_supplicant rfkill: Cannot get wiphy information ioctl[SIOCSIWENCODEEXT]: Invalid argument ioctl[SIOCSIWENCODEEXT]: Invalid argument eth35: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='MSI' freq=2462 MHz) Failed to add supported operating classes IE ioctl[SIOCSIWGENIE]: Operation not supported eth35: Association request to the driver failed eth35: Associated with xx:xx:xx:xx:xx:xx eth35: CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=0 id_str=] # dhclient -d eth35 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth35/yy:yy:yy:yy:yy:yy Sending on LPF/eth35/yy:yy:yy:yy:yy:yy Sending on Socket/fallback DHCPDISCOVER on eth35 to 255.255.255.255 port 67 interval 6 DHCPOFFER of 192.168.1.192 from 192.168.1.254 DHCPREQUEST for 192.168.1.192 on eth35 to 255.255.255.255 port 67 DHCPACK of 192.168.1.192 from 192.168.1.254 bound to 192.168.1.192 -- renewal in 40 seconds. -- Ondrej Zary
Re: [PATCH 12/30] net: wireless: cisco: airo: Fix a myriad of coding style issues
On Monday 17 August 2020 20:27:06 Jesse Brandeburg wrote: > On Mon, 17 Aug 2020 16:27:01 +0300 > Kalle Valo wrote: > > > I was surprised to see that someone was using this driver in 2015, so > > I'm not sure anymore what to do. Of course we could still just remove > > it and later revert if someone steps up and claims the driver is still > > usable. Hmm. Does anyone any users of this driver? > > What about moving the driver over into staging, which is generally the > way I understood to move a driver slowly out of the kernel? Please don't remove random drivers. I still have the Aironet PCMCIA card and can test the driver. -- Ondrej Zary
Re: [PATCH v4] watchdog: alim1535: Rewriting of alim1535 driver to use watchdog subsystem
On Friday 02 August 2019, Mark Balantzyan wrote: > This patch rewrites the alim1535_wdt driver to use the watchdog subsystem. > By virtue of this, it also fixes a (theoretical) race condition between the > formerly arranged ali_timeout_bits and ali_settimer() interoperation. Please don't rewrite drivers you can't test. -- Ondrej Zary
Re: Marking legacy watchdog drivers as deprecated / obsolete
On Tuesday 30 July 2019 17:57:37 Guenter Roeck wrote: > On Tue, Jul 30, 2019 at 10:00:36AM +0200, Arnd Bergmann wrote: > > On Tue, Jul 30, 2019 at 12:07 AM Guenter Roeck wrote: > > > > > > Hi, > > > > > > we have recently seen a number of changes to legacy watchdog drivers, > > > mostly surrounding the coding style used some 10+ years ago, but also > > > fixing minor formatting or coding problems found by static analyzers. > > > This slowly rises above the level of background noise. > > > > > > Would it be acceptable to mark all those drivers as deprecated/obsolete, > > > warn users that the driver should be converted to use the watchdog > > > subsystem, and that it will otherwise be removed in a later Linux kernel > > > version ? This would give us an idea which drivers are still in use, > > > and it would enable us to remove the remaining drivers maybe 5 or 6 > > > releases for now. > > > > > > Thoughts ? > > > > I don't think an automated approach across 61 drivers is likely to work > > well. About half of the drivers appear to be for specific SoCs, and > > removing the watchdog driver while keeping the rest of the SoC support > > would not be helpful, it just means we break one of the drivers for the > > last remaining users of an old SoC the next time they try to upgrade to > > a new kernel. > > > > The primary goal would be to identify drivers still in use, and to trigger > efforts to convert those drivers to the new infrastructure. Removal of > obsolete / unused drivers would be a separate decision, to be made at some > point in the future, and individually for each driver. I specifically wasn't > trying to suggest auto-removal. > > Guenter > > > It would probably be helpful to go through the list and see if any of > > the drivers > > are for platforms that are already gone. FWIW, here is the list of drivers > > that > > have their own .ioctl() method, taken from a patch I'm sending soon > > to add a .compat_ioctl handler: > > > > arch/powerpc/platforms/52xx/mpc52xx_gpt.c > > arch/um/drivers/harddog_kern.c > > drivers/char/ipmi/ipmi_watchdog.c > > drivers/hwmon/fschmd.c > > drivers/rtc/rtc-ds1374.c > > drivers/watchdog/acquirewdt.c > > drivers/watchdog/advantechwdt.c > > drivers/watchdog/alim1535_wdt.c > > drivers/watchdog/alim7101_wdt.c > > drivers/watchdog/ar7_wdt.c > > drivers/watchdog/at91rm9200_wdt.c > > drivers/watchdog/ath79_wdt.c > > drivers/watchdog/bcm63xx_wdt.c > > drivers/watchdog/cpu5wdt.c > > drivers/watchdog/eurotechwdt.c > > drivers/watchdog/f71808e_wdt.c > > drivers/watchdog/gef_wdt.c > > drivers/watchdog/geodewdt.c > > drivers/watchdog/ib700wdt.c > > drivers/watchdog/ibmasr.c > > drivers/watchdog/indydog.c > > drivers/watchdog/intel_scu_watchdog.c > > drivers/watchdog/iop_wdt.c > > drivers/watchdog/it8712f_wdt.c > > drivers/watchdog/ixp4xx_wdt.c > > drivers/watchdog/ks8695_wdt.c > > drivers/watchdog/m54xx_wdt.c > > drivers/watchdog/machzwd.c > > drivers/watchdog/mixcomwd.c > > drivers/watchdog/mtx-1_wdt.c > > drivers/watchdog/mv64x60_wdt.c > > drivers/watchdog/nuc900_wdt.c > > drivers/watchdog/nv_tco.c > > drivers/watchdog/pc87413_wdt.c > > drivers/watchdog/pcwd.c > > drivers/watchdog/pcwd_pci.c > > drivers/watchdog/pcwd_usb.c > > drivers/watchdog/pika_wdt.c > > drivers/watchdog/pnx833x_wdt.c > > drivers/watchdog/rc32434_wdt.c > > drivers/watchdog/rdc321x_wdt.c > > drivers/watchdog/riowd.c > > drivers/watchdog/sa1100_wdt.c > > drivers/watchdog/sb_wdog.c > > drivers/watchdog/sbc60xxwdt.c > > drivers/watchdog/sbc7240_wdt.c > > drivers/watchdog/sbc_epx_c3.c > > drivers/watchdog/sbc_fitpc2_wdt.c > > drivers/watchdog/sc1200wdt.c > > drivers/watchdog/sc520_wdt.c > > drivers/watchdog/sch311x_wdt.c > > drivers/watchdog/scx200_wdt.c > > drivers/watchdog/smsc37b787_wdt.c > > drivers/watchdog/w83877f_wdt.c > > drivers/watchdog/w83977f_wdt.c > > drivers/watchdog/wafer5823wdt.c > > drivers/watchdog/wdrtas.c > > drivers/watchdog/wdt.c > > drivers/watchdog/wdt285.c > > drivers/watchdog/wdt977.c > > drivers/watchdog/wdt_pci.c > > > > Arnd > I have some older x86 boards so I probably could test some of them. Likely ALi chipset (alim1535_wdt.c and/or alim7101_wdt.c) and some super I/Os (it8712f_wdt.c, w83877f_wdt.c, w83977f_wdt.c). -- Ondrej Zary
Re: [PATCH] scsi: fdomain: fix building pcmcia front-end
On Wednesday 19 June 2019 05:13:01 Martin K. Petersen wrote: > > Arnd, > > > Move the common support outside of the SCSI_LOWLEVEL section. > > Alternatively, we could move all of SCSI_LOWLEVEL_PCMCIA into > > SCSI_LOWLEVEL. This would be more sensible, but might cause surprises > > for users that have SCSI_LOWLEVEL disabled. > > It seems messy to me that PCMCIA lives outside of the LOWLEVEL section. > > Given that the number of users that rely on PCMCIA for their system disk > is probably pretty low, I think I'm leaning towards cleaning things up > instead of introducing a nonsensical top level option. > > Or even better: Get rid of SCSI_FDOMAIN as a user-visible option and > select it if either of the PCI/ISA/PCMCIA drivers are enabled. SCSI_FDOMAIN is not an user-visible option. PCI/ISA/PCMCIA drivers select it: Symbol: PCMCIA_FDOMAIN [=m] Type : tristate Prompt: Future Domain PCMCIA support Location: -> Device Drivers -> SCSI device support -> PCMCIA SCSI adapter support (SCSI_LOWLEVEL_PCMCIA [=y]) Defined at drivers/scsi/pcmcia/Kconfig:22 Depends on: SCSI_LOWLEVEL_PCMCIA [=y] && SCSI [=y] && PCMCIA [=m] && m && MODULES [=y] Selects: SCSI_FDOMAIN [=m] Symbol: SCSI_FDOMAIN [=m] Type : tristate Defined at drivers/scsi/Kconfig:666 Depends on: SCSI_LOWLEVEL [=y] && SCSI [=y] Selected by [m]: - SCSI_FDOMAIN_PCI [=m] && SCSI_LOWLEVEL [=y] && PCI [=y] && SCSI [=y] - SCSI_FDOMAIN_ISA [=m] && SCSI_LOWLEVEL [=y] && ISA [=y] && SCSI [=y] - PCMCIA_FDOMAIN [=m] && SCSI_LOWLEVEL_PCMCIA [=y] && SCSI [=y] && PCMCIA [=m] && m && MODULES [=y] Symbol: SCSI_FDOMAIN_ISA [=m] Type : tristate Prompt: Future Domain 16xx ISA SCSI support Location: -> Device Drivers -> SCSI device support -> SCSI low-level drivers (SCSI_LOWLEVEL [=y]) Defined at drivers/scsi/Kconfig:687 Depends on: SCSI_LOWLEVEL [=y] && ISA [=y] && SCSI [=y] Selects: CHECK_SIGNATURE [=y] && SCSI_FDOMAIN [=m] Symbol: SCSI_FDOMAIN_PCI [=m] Type : tristate Prompt: Future Domain TMC-3260/AHA-2920A PCI SCSI support Location: -> Device Drivers -> SCSI device support -> SCSI low-level drivers (SCSI_LOWLEVEL [=y]) Defined at drivers/scsi/Kconfig:670 Depends on: SCSI_LOWLEVEL [=y] && PCI [=y] && SCSI [=y] Selects: SCSI_FDOMAIN [=m] -- Ondrej Zary
[PATCH] [resend] wd719x: Fix resets and aborts
Host reset oopses because it calls wd719x_chip_init, which calls
request_firmware, under a spinlock. Stop the RISC first, then flush
active SCBs under a spinlock. Finally call wd719x_chip_init unlocked.
Also found and fixed more bugs during tests:
Affected active SCBs were not flushed during abort, bus and device
reset. This caused problems in a following host reset (hang or oops).
Device and bus reset failed under load because the result of the reset
command is WD719X_SUE_TERM or WD719X_SUE_RESET. Don't treat these codes
as error in wd719x_wait_done.
wd719x_direct_cmd for RESET/ABORT commands didn't work properly,
causing timeouts. Looks like it was caused by the WD719X_DISABLE_INT
bit. Not setting it for RESET/ABORT commands seems to fix the probem.
Also lower the log level of the corresponding "direct command
completed" message to debug.
Unfortunately, my documentation is missing some pages, including page
67 (SPIDER67.gif) about resets :(
Reported-by: Hariprasad Kelam
Signed-off-by: Ondrej Zary
---
drivers/scsi/wd719x.c | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
index e3310e9488d2..2b44b0be2e00 100644
--- a/drivers/scsi/wd719x.c
+++ b/drivers/scsi/wd719x.c
@@ -107,8 +107,15 @@ static inline int wd719x_wait_done(struct wd719x *wd, int
timeout)
}
if (status != WD719X_INT_NOERRORS) {
+ u8 sue = wd719x_readb(wd, WD719X_AMR_SCB_ERROR);
+ /* we get this after wd719x_dev_reset, it's not an error */
+ if (sue == WD719X_SUE_TERM)
+ return 0;
+ /* we get this after wd719x_bus_reset, it's not an error */
+ if (sue == WD719X_SUE_RESET)
+ return 0;
dev_err(>pdev->dev, "direct command failed, status 0x%02x,
SUE 0x%02x\n",
- status, wd719x_readb(wd, WD719X_AMR_SCB_ERROR));
+ status, sue);
return -EIO;
}
@@ -127,8 +134,10 @@ static int wd719x_direct_cmd(struct wd719x *wd, u8 opcode,
u8 dev, u8 lun,
if (wd719x_wait_ready(wd))
return -ETIMEDOUT;
- /* make sure we get NO interrupts */
- dev |= WD719X_DISABLE_INT;
+ /* disable interrupts except for RESET/ABORT (it breaks them) */
+ if (opcode != WD719X_CMD_BUSRESET && opcode != WD719X_CMD_ABORT &&
+ opcode != WD719X_CMD_ABORT_TAG && opcode != WD719X_CMD_RESET)
+ dev |= WD719X_DISABLE_INT;
wd719x_writeb(wd, WD719X_AMR_CMD_PARAM, dev);
wd719x_writeb(wd, WD719X_AMR_CMD_PARAM_2, lun);
wd719x_writeb(wd, WD719X_AMR_CMD_PARAM_3, tag);
@@ -464,6 +473,7 @@ static int wd719x_abort(struct scsi_cmnd *cmd)
spin_lock_irqsave(wd->sh->host_lock, flags);
result = wd719x_direct_cmd(wd, action, cmd->device->id,
cmd->device->lun, cmd->tag, scb->phys, 0);
+ wd719x_finish_cmd(scb, DID_ABORT);
spin_unlock_irqrestore(wd->sh->host_lock, flags);
if (result)
return FAILED;
@@ -476,6 +486,7 @@ static int wd719x_reset(struct scsi_cmnd *cmd, u8 opcode,
u8 device)
int result;
unsigned long flags;
struct wd719x *wd = shost_priv(cmd->device->host);
+ struct wd719x_scb *scb, *tmp;
dev_info(>pdev->dev, "%s reset requested\n",
(opcode == WD719X_CMD_BUSRESET) ? "bus" : "device");
@@ -483,6 +494,12 @@ static int wd719x_reset(struct scsi_cmnd *cmd, u8 opcode,
u8 device)
spin_lock_irqsave(wd->sh->host_lock, flags);
result = wd719x_direct_cmd(wd, opcode, device, 0, 0, 0,
WD719X_WAIT_FOR_SCSI_RESET);
+ /* flush all SCBs (or all for a device if dev_reset) */
+ list_for_each_entry_safe(scb, tmp, >active_scbs, list) {
+ if (opcode == WD719X_CMD_BUSRESET ||
+ scb->cmd->device->id == device)
+ wd719x_finish_cmd(scb, DID_RESET);
+ }
spin_unlock_irqrestore(wd->sh->host_lock, flags);
if (result)
return FAILED;
@@ -505,22 +522,23 @@ static int wd719x_host_reset(struct scsi_cmnd *cmd)
struct wd719x *wd = shost_priv(cmd->device->host);
struct wd719x_scb *scb, *tmp;
unsigned long flags;
- int result;
dev_info(>pdev->dev, "host reset requested\n");
spin_lock_irqsave(wd->sh->host_lock, flags);
- /* Try to reinit the RISC */
- if (wd719x_chip_init(wd) == 0)
- result = SUCCESS;
- else
- result = FAILED;
+ /* stop the RISC */
+ if (wd719x_direct_cmd(wd, WD719X_CMD_SLEEP, 0, 0, 0, 0,
+
[PATCH] wd719x: Fix resets and aborts
Host reset oopses because it calls wd719x_chip_init, which calls
request_firmware, under a spinlock. Stop the RISC first, then flush
active SCBs under a spinlock. Finally call wd719x_chip_init unlocked.
Also found and fixed more bugs during tests:
Affected active SCBs were not flushed during abort, bus and device
reset. This caused problems in a following host reset (hang or oops).
Device and bus reset failed under load because the result of the reset
command is WD719X_SUE_TERM or WD719X_SUE_RESET. Don't treat these codes
as error in wd719x_wait_done.
wd719x_direct_cmd for RESET/ABORT commands didn't work properly,
causing timeouts. Looks like it was caused by the WD719X_DISABLE_INT
bit. Not setting it for RESET/ABORT commands seems to fix the probem.
Also lower the log level of the corresponding "direct command
completed" message to debug.
Unfortunately, my documentation is missing some pages, including page
67 (SPIDER67.gif) about resets :(
Reported-by: Hariprasad Kelam
Signed-off-by: Ondrej Zary
---
drivers/scsi/wd719x.c | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
index e3310e9488d2..2b44b0be2e00 100644
--- a/drivers/scsi/wd719x.c
+++ b/drivers/scsi/wd719x.c
@@ -107,8 +107,15 @@ static inline int wd719x_wait_done(struct wd719x *wd, int
timeout)
}
if (status != WD719X_INT_NOERRORS) {
+ u8 sue = wd719x_readb(wd, WD719X_AMR_SCB_ERROR);
+ /* we get this after wd719x_dev_reset, it's not an error */
+ if (sue == WD719X_SUE_TERM)
+ return 0;
+ /* we get this after wd719x_bus_reset, it's not an error */
+ if (sue == WD719X_SUE_RESET)
+ return 0;
dev_err(>pdev->dev, "direct command failed, status 0x%02x,
SUE 0x%02x\n",
- status, wd719x_readb(wd, WD719X_AMR_SCB_ERROR));
+ status, sue);
return -EIO;
}
@@ -127,8 +134,10 @@ static int wd719x_direct_cmd(struct wd719x *wd, u8 opcode,
u8 dev, u8 lun,
if (wd719x_wait_ready(wd))
return -ETIMEDOUT;
- /* make sure we get NO interrupts */
- dev |= WD719X_DISABLE_INT;
+ /* disable interrupts except for RESET/ABORT (it breaks them) */
+ if (opcode != WD719X_CMD_BUSRESET && opcode != WD719X_CMD_ABORT &&
+ opcode != WD719X_CMD_ABORT_TAG && opcode != WD719X_CMD_RESET)
+ dev |= WD719X_DISABLE_INT;
wd719x_writeb(wd, WD719X_AMR_CMD_PARAM, dev);
wd719x_writeb(wd, WD719X_AMR_CMD_PARAM_2, lun);
wd719x_writeb(wd, WD719X_AMR_CMD_PARAM_3, tag);
@@ -464,6 +473,7 @@ static int wd719x_abort(struct scsi_cmnd *cmd)
spin_lock_irqsave(wd->sh->host_lock, flags);
result = wd719x_direct_cmd(wd, action, cmd->device->id,
cmd->device->lun, cmd->tag, scb->phys, 0);
+ wd719x_finish_cmd(scb, DID_ABORT);
spin_unlock_irqrestore(wd->sh->host_lock, flags);
if (result)
return FAILED;
@@ -476,6 +486,7 @@ static int wd719x_reset(struct scsi_cmnd *cmd, u8 opcode,
u8 device)
int result;
unsigned long flags;
struct wd719x *wd = shost_priv(cmd->device->host);
+ struct wd719x_scb *scb, *tmp;
dev_info(>pdev->dev, "%s reset requested\n",
(opcode == WD719X_CMD_BUSRESET) ? "bus" : "device");
@@ -483,6 +494,12 @@ static int wd719x_reset(struct scsi_cmnd *cmd, u8 opcode,
u8 device)
spin_lock_irqsave(wd->sh->host_lock, flags);
result = wd719x_direct_cmd(wd, opcode, device, 0, 0, 0,
WD719X_WAIT_FOR_SCSI_RESET);
+ /* flush all SCBs (or all for a device if dev_reset) */
+ list_for_each_entry_safe(scb, tmp, >active_scbs, list) {
+ if (opcode == WD719X_CMD_BUSRESET ||
+ scb->cmd->device->id == device)
+ wd719x_finish_cmd(scb, DID_RESET);
+ }
spin_unlock_irqrestore(wd->sh->host_lock, flags);
if (result)
return FAILED;
@@ -505,22 +522,23 @@ static int wd719x_host_reset(struct scsi_cmnd *cmd)
struct wd719x *wd = shost_priv(cmd->device->host);
struct wd719x_scb *scb, *tmp;
unsigned long flags;
- int result;
dev_info(>pdev->dev, "host reset requested\n");
spin_lock_irqsave(wd->sh->host_lock, flags);
- /* Try to reinit the RISC */
- if (wd719x_chip_init(wd) == 0)
- result = SUCCESS;
- else
- result = FAILED;
+ /* stop the RISC */
+ if (wd719x_direct_cmd(wd, WD719X_CMD_SLEEP, 0, 0, 0, 0,
+
[PATCH] fdomain: Add PCMCIA support
Add PCMCIA card support to Future Domain SCSI driver.
Tested with IBM SCSI PCMCIA Adapter 40G1890.
Signed-off-by: Ondrej Zary
---
drivers/scsi/fdomain.c | 7 ++-
drivers/scsi/pcmcia/Kconfig | 10 +
drivers/scsi/pcmcia/Makefile | 1 +
drivers/scsi/pcmcia/fdomain_cs.c | 95
4 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 drivers/scsi/pcmcia/fdomain_cs.c
diff --git a/drivers/scsi/fdomain.c b/drivers/scsi/fdomain.c
index 297ccc799436..b5e66971b6d9 100644
--- a/drivers/scsi/fdomain.c
+++ b/drivers/scsi/fdomain.c
@@ -510,6 +510,7 @@ struct Scsi_Host *fdomain_create(int base, int irq, int
this_id,
static const char * const chip_names[] = {
"Unknown", "TMC-1800", "TMC-18C50", "TMC-18C30"
};
+ unsigned long irq_flags = 0;
chip = fdomain_identify(base);
if (!chip)
@@ -541,8 +542,10 @@ struct Scsi_Host *fdomain_create(int base, int irq, int
this_id,
fd->chip = chip;
INIT_WORK(>work, fdomain_work);
- if (request_irq(irq, fdomain_irq, dev_is_pci(dev) ? IRQF_SHARED : 0,
- "fdomain", fd))
+ if (dev_is_pci(dev) || !strcmp(dev->bus->name, "pcmcia"))
+ irq_flags = IRQF_SHARED;
+
+ if (request_irq(irq, fdomain_irq, irq_flags, "fdomain", fd))
goto fail_put;
shost_printk(KERN_INFO, sh, "%s chip at 0x%x irq %d SCSI ID %d\n",
diff --git a/drivers/scsi/pcmcia/Kconfig b/drivers/scsi/pcmcia/Kconfig
index 2d435f105b16..169d93f90a30 100644
--- a/drivers/scsi/pcmcia/Kconfig
+++ b/drivers/scsi/pcmcia/Kconfig
@@ -19,6 +19,16 @@ config PCMCIA_AHA152X
To compile this driver as a module, choose M here: the
module will be called aha152x_cs.
+config PCMCIA_FDOMAIN
+ tristate "Future Domain PCMCIA support"
+ select SCSI_FDOMAIN
+ help
+ Say Y here if you intend to attach this type of PCMCIA SCSI host
+ adapter to your computer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called fdomain_cs.
+
config PCMCIA_NINJA_SCSI
tristate "NinjaSCSI-3 / NinjaSCSI-32Bi (16bit) PCMCIA support"
depends on !64BIT
diff --git a/drivers/scsi/pcmcia/Makefile b/drivers/scsi/pcmcia/Makefile
index a5a24dd44e7e..02f5b44a2685 100644
--- a/drivers/scsi/pcmcia/Makefile
+++ b/drivers/scsi/pcmcia/Makefile
@@ -4,6 +4,7 @@ ccflags-y := -I $(srctree)/drivers/scsi
# 16-bit client drivers
obj-$(CONFIG_PCMCIA_QLOGIC)+= qlogic_cs.o
+obj-$(CONFIG_PCMCIA_FDOMAIN) += fdomain_cs.o
obj-$(CONFIG_PCMCIA_AHA152X) += aha152x_cs.o
obj-$(CONFIG_PCMCIA_NINJA_SCSI)+= nsp_cs.o
obj-$(CONFIG_PCMCIA_SYM53C500) += sym53c500_cs.o
diff --git a/drivers/scsi/pcmcia/fdomain_cs.c b/drivers/scsi/pcmcia/fdomain_cs.c
new file mode 100644
index ..e42acf314d06
--- /dev/null
+++ b/drivers/scsi/pcmcia/fdomain_cs.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/*
+ * Driver for Future Domain-compatible PCMCIA SCSI cards
+ * Copyright 2019 Ondrej Zary
+ *
+ * The initial developer of the original code is David A. Hinds
+ * . Portions created by David A. Hinds
+ * are Copyright (C) 1999 David A. Hinds. All Rights Reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "fdomain.h"
+
+MODULE_AUTHOR("Ondrej Zary, David Hinds");
+MODULE_DESCRIPTION("Future Domain PCMCIA SCSI driver");
+MODULE_LICENSE("Dual MPL/GPL");
+
+static int fdomain_config_check(struct pcmcia_device *p_dev, void *priv_data)
+{
+ p_dev->io_lines = 10;
+ p_dev->resource[0]->end = FDOMAIN_REGION_SIZE;
+ p_dev->resource[0]->flags &= ~IO_DATA_PATH_WIDTH;
+ p_dev->resource[0]->flags |= IO_DATA_PATH_WIDTH_AUTO;
+ return pcmcia_request_io(p_dev);
+}
+
+static int fdomain_probe(struct pcmcia_device *link)
+{
+ int ret;
+ struct Scsi_Host *sh;
+
+ link->config_flags |= CONF_ENABLE_IRQ | CONF_AUTO_SET_IO;
+ link->config_regs = PRESENT_OPTION;
+
+ ret = pcmcia_loop_config(link, fdomain_config_check, NULL);
+ if (ret)
+ return ret;
+
+ ret = pcmcia_enable_device(link);
+ if (ret)
+ goto fail_disable;
+
+ if (!request_region(link->resource[0]->start, FDOMAIN_REGION_SIZE,
+ "fdomain_cs"))
+ goto fail_disable;
+
+ sh = fdomain_create(link->resource[0]->start, link->irq, 7, >dev);
+ if (!sh) {
+ dev_err(>dev, "Controller initialization failed");
+ ret = -ENODEV;
+ goto fail_release;
+ }
+
+ link->priv = sh;
+
+ return 0;
+
+fail_release:
+ releas
[PATCH] fdomain: Add register definitions
Add register bit definitions from documentation to header file and use
them instead of magic constants. No changes to generated binary.
Signed-off-by: Ondrej Zary
---
drivers/scsi/fdomain.c | 144 -
drivers/scsi/fdomain.h | 117 +++-
drivers/scsi/fdomain_isa.c | 4 +-
3 files changed, 167 insertions(+), 98 deletions(-)
diff --git a/drivers/scsi/fdomain.c b/drivers/scsi/fdomain.c
index 19af1ae608df..297ccc799436 100644
--- a/drivers/scsi/fdomain.c
+++ b/drivers/scsi/fdomain.c
@@ -99,7 +99,7 @@
* up the machine.
*/
#define FIFO_COUNT 2 /* Number of 512 byte blocks before INTR */
-#define PARITY_MASK0x08/* Parity enabled, 0x00 = disabled */
+#define PARITY_MASKACTL_PAREN /* Parity enabled, 0 = disabled */
enum chip_type {
unknown = 0x00,
@@ -117,18 +117,19 @@ struct fdomain {
static inline void fdomain_make_bus_idle(struct fdomain *fd)
{
- outb(0, fd->base + SCSI_Cntl);
- outb(0, fd->base + SCSI_Mode_Cntl);
+ outb(0, fd->base + REG_BCTL);
+ outb(0, fd->base + REG_MCTL);
if (fd->chip == tmc18c50 || fd->chip == tmc18c30)
/* Clear forced intr. */
- outb(0x21 | PARITY_MASK, fd->base + TMC_Cntl);
+ outb(ACTL_RESET | ACTL_CLRFIRQ | PARITY_MASK,
+fd->base + REG_ACTL);
else
- outb(0x01 | PARITY_MASK, fd->base + TMC_Cntl);
+ outb(ACTL_RESET | PARITY_MASK, fd->base + REG_ACTL);
}
static enum chip_type fdomain_identify(int port)
{
- u16 id = inb(port + LSB_ID_Code) | inb(port + MSB_ID_Code) << 8;
+ u16 id = inb(port + REG_ID_LSB) | inb(port + REG_ID_MSB) << 8;
switch (id) {
case 0x6127:
@@ -140,10 +141,10 @@ static enum chip_type fdomain_identify(int port)
}
/* Try to toggle 32-bit mode. This only works on an 18c30 chip. */
- outb(0x80, port + IO_Control);
- if ((inb(port + Configuration2) & 0x80) == 0x80) {
- outb(0x00, port + IO_Control);
- if ((inb(port + Configuration2) & 0x80) == 0x00)
+ outb(CFG2_32BIT, port + REG_CFG2);
+ if ((inb(port + REG_CFG2) & CFG2_32BIT)) {
+ outb(0, port + REG_CFG2);
+ if ((inb(port + REG_CFG2) & CFG2_32BIT) == 0)
return tmc18c30;
}
/* If that failed, we are an 18c50. */
@@ -155,8 +156,8 @@ static int fdomain_test_loopback(int base)
int i;
for (i = 0; i < 255; i++) {
- outb(i, base + Write_Loopback);
- if (inb(base + Read_Loopback) != i)
+ outb(i, base + REG_LOOPBACK);
+ if (inb(base + REG_LOOPBACK) != i)
return 1;
}
@@ -165,12 +166,12 @@ static int fdomain_test_loopback(int base)
static void fdomain_reset(int base)
{
- outb(1, base + SCSI_Cntl);
+ outb(1, base + REG_BCTL);
mdelay(20);
- outb(0, base + SCSI_Cntl);
+ outb(0, base + REG_BCTL);
mdelay(1150);
- outb(0, base + SCSI_Mode_Cntl);
- outb(PARITY_MASK, base + TMC_Cntl);
+ outb(0, base + REG_MCTL);
+ outb(PARITY_MASK, base + REG_ACTL);
}
static int fdomain_select(struct Scsi_Host *sh, int target)
@@ -179,20 +180,20 @@ static int fdomain_select(struct Scsi_Host *sh, int
target)
unsigned long timeout;
struct fdomain *fd = shost_priv(sh);
- outb(0x82, fd->base + SCSI_Cntl); /* Bus Enable + Select */
- outb(BIT(sh->this_id) | BIT(target), fd->base + SCSI_Data_NoACK);
+ outb(BCTL_BUSEN | BCTL_SEL, fd->base + REG_BCTL);
+ outb(BIT(sh->this_id) | BIT(target), fd->base + REG_SCSI_DATA_NOACK);
/* Stop arbitration and enable parity */
- outb(PARITY_MASK, fd->base + TMC_Cntl);
+ outb(PARITY_MASK, fd->base + REG_ACTL);
timeout = 350; /* 350 msec */
do {
- status = inb(fd->base + SCSI_Status); /* Read adapter status */
- if (status & 1) { /* Busy asserted */
+ status = inb(fd->base + REG_BSTAT);
+ if (status & BSTAT_BSY) {
/* Enable SCSI Bus */
/* (on error, should make bus idle with 0) */
- outb(0x80, fd->base + SCSI_Cntl);
+ outb(BCTL_BUSEN, fd->base + REG_BCTL);
return 0;
}
mdelay(1);
@@ -203,7 +204,7 @@ static int fdomain_select(struct Scsi_Host *sh, int target)
static void fdomain_finish_cmd(struct fdomain *fd, int result)
{
- outb(0x00, fd->base + Interrupt_Cntl);
+ outb(0, fd->base + REG_ICTL);
fdomain_make_bus_idle(fd);
fd->cur_cmd->result = result;
fd->cur_cmd->scs
[PATCH v2 2/3] fdomain: Resurrect driver (PCI support)
Future Domain TMC-3260/AHA-2920A PCI card support.
Tested on Adaptec AHA-2920A PCI card.
Signed-off-by: Ondrej Zary
Reviewed-by: Christoph Hellwig
---
drivers/scsi/Kconfig | 17
drivers/scsi/Makefile | 1 +
drivers/scsi/fdomain_pci.c | 68 ++
3 files changed, 86 insertions(+)
create mode 100644 drivers/scsi/fdomain_pci.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 3d6b1f47cbb5..f9d058a07e2a 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -667,6 +667,23 @@ config SCSI_FDOMAIN
tristate
depends on SCSI
+config SCSI_FDOMAIN_PCI
+ tristate "Future Domain TMC-3260/AHA-2920A PCI SCSI support"
+ depends on PCI && SCSI
+ select SCSI_FDOMAIN
+ help
+ This is support for Future Domain's PCI SCSI host adapters (TMC-3260)
+ and other adapters with PCI bus based on the Future Domain chipsets
+ (Adaptec AHA-2920A).
+
+ NOTE: Newer Adaptec AHA-2920C boards use the Adaptec AIC-7850 chip
+ and should use the aic7xxx driver ("Adaptec AIC7xxx chipset SCSI
+ controller support"). This Future Domain driver works with the older
+ Adaptec AHA-2920A boards with a Future Domain chip on them.
+
+ To compile this driver as a module, choose M here: the
+ module will be called fdomain_pci.
+
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
depends on PCI && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index b8fbc6d2de54..f6cc4fbe6957 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_SCSI_PM8001) += pm8001/
obj-$(CONFIG_SCSI_ISCI)+= isci/
obj-$(CONFIG_SCSI_IPS) += ips.o
obj-$(CONFIG_SCSI_FDOMAIN) += fdomain.o
+obj-$(CONFIG_SCSI_FDOMAIN_PCI) += fdomain_pci.o
obj-$(CONFIG_SCSI_GENERIC_NCR5380) += g_NCR5380.o
obj-$(CONFIG_SCSI_QLOGIC_FAS) += qlogicfas408.o qlogicfas.o
obj-$(CONFIG_PCMCIA_QLOGIC)+= qlogicfas408.o
diff --git a/drivers/scsi/fdomain_pci.c b/drivers/scsi/fdomain_pci.c
new file mode 100644
index ..3e05ce7b89e5
--- /dev/null
+++ b/drivers/scsi/fdomain_pci.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include "fdomain.h"
+
+static int fdomain_pci_probe(struct pci_dev *pdev,
+const struct pci_device_id *d)
+{
+ int err;
+ struct Scsi_Host *sh;
+
+ err = pci_enable_device(pdev);
+ if (err)
+ goto fail;
+
+ err = pci_request_regions(pdev, "fdomain_pci");
+ if (err)
+ goto disable_device;
+
+ err = -ENODEV;
+ if (pci_resource_len(pdev, 0) == 0)
+ goto release_region;
+
+ sh = fdomain_create(pci_resource_start(pdev, 0), pdev->irq, 7,
+ >dev);
+ if (!sh)
+ goto release_region;
+
+ pci_set_drvdata(pdev, sh);
+ return 0;
+
+release_region:
+ pci_release_regions(pdev);
+disable_device:
+ pci_disable_device(pdev);
+fail:
+ return err;
+}
+
+static void fdomain_pci_remove(struct pci_dev *pdev)
+{
+ struct Scsi_Host *sh = pci_get_drvdata(pdev);
+
+ fdomain_destroy(sh);
+ pci_release_regions(pdev);
+ pci_disable_device(pdev);
+}
+
+static struct pci_device_id fdomain_pci_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_FD, PCI_DEVICE_ID_FD_36C70) },
+ {}
+};
+MODULE_DEVICE_TABLE(pci, fdomain_pci_table);
+
+static struct pci_driver fdomain_pci_driver = {
+ .name = "fdomain_pci",
+ .id_table = fdomain_pci_table,
+ .probe = fdomain_pci_probe,
+ .remove = fdomain_pci_remove,
+ .driver.pm = FDOMAIN_PM_OPS,
+};
+
+module_pci_driver(fdomain_pci_driver);
+
+MODULE_AUTHOR("Ondrej Zary, Rickard E. Faith");
+MODULE_DESCRIPTION("Future Domain TMC-3260 PCI SCSI driver");
+MODULE_LICENSE("GPL");
--
Ondrej Zary
[PATCH v2 1/3] fdomain: Resurrect driver (core)
Future Domain TMC-16xx/TMC-3260 SCSI driver. This is the core driver, common for PCI, ISA and PCMCIA cards. Signed-off-by: Ondrej Zary Reviewed-by: Christoph Hellwig --- drivers/scsi/Kconfig | 4 + drivers/scsi/Makefile | 1 + drivers/scsi/fdomain.c | 586 + drivers/scsi/fdomain.h | 53 + 4 files changed, 644 insertions(+) create mode 100644 drivers/scsi/fdomain.c create mode 100644 drivers/scsi/fdomain.h diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index d528018e6fa8..3d6b1f47cbb5 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -663,6 +663,10 @@ config SCSI_DMX3191D To compile this driver as a module, choose M here: the module will be called dmx3191d. +config SCSI_FDOMAIN + tristate + depends on SCSI + config SCSI_GDTH tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller support" depends on PCI && SCSI diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 8826111fdf4a..b8fbc6d2de54 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_SCSI_AIC94XX)+= aic94xx/ obj-$(CONFIG_SCSI_PM8001) += pm8001/ obj-$(CONFIG_SCSI_ISCI)+= isci/ obj-$(CONFIG_SCSI_IPS) += ips.o +obj-$(CONFIG_SCSI_FDOMAIN) += fdomain.o obj-$(CONFIG_SCSI_GENERIC_NCR5380) += g_NCR5380.o obj-$(CONFIG_SCSI_QLOGIC_FAS) += qlogicfas408.o qlogicfas.o obj-$(CONFIG_PCMCIA_QLOGIC)+= qlogicfas408.o diff --git a/drivers/scsi/fdomain.c b/drivers/scsi/fdomain.c new file mode 100644 index ..19af1ae608df --- /dev/null +++ b/drivers/scsi/fdomain.c @@ -0,0 +1,586 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for Future Domain TMC-16x0 and TMC-3260 SCSI host adapters + * Copyright 2019 Ondrej Zary + * + * Original driver by + * Rickard E. Faith, fa...@cs.unc.edu + * + * Future Domain BIOS versions supported for autodetect: + *2.0, 3.0, 3.2, 3.4 (1.0), 3.5 (2.0), 3.6, 3.61 + * Chips supported: + *TMC-1800, TMC-18C50, TMC-18C30, TMC-36C70 + * Boards supported: + *Future Domain TMC-1650, TMC-1660, TMC-1670, TMC-1680, TMC-1610M/MER/MEX + *Future Domain TMC-3260 (PCI) + *Quantum ISA-200S, ISA-250MG + *Adaptec AHA-2920A (PCI) [BUT *NOT* AHA-2920C -- use aic7xxx instead] + *IBM ? + * + * NOTE: + * + * The Adaptec AHA-2920C has an Adaptec AIC-7850 chip on it. + * Use the aic7xxx driver for this board. + * + * The Adaptec AHA-2920A has a Future Domain chip on it, so this is the right + * driver for that card. Unfortunately, the boxes will probably just say + * "2920", so you'll have to look on the card for a Future Domain logo, or a + * letter after the 2920. + * + * If you have a TMC-8xx or TMC-9xx board, then this is not the driver for + * your board. + * + * DESCRIPTION: + * + * This is the Linux low-level SCSI driver for Future Domain TMC-1660/1680 + * TMC-1650/1670, and TMC-3260 SCSI host adapters. The 1650 and 1670 have a + * 25-pin external connector, whereas the 1660 and 1680 have a SCSI-2 50-pin + * high-density external connector. The 1670 and 1680 have floppy disk + * controllers built in. The TMC-3260 is a PCI bus card. + * + * Future Domain's older boards are based on the TMC-1800 chip, and this + * driver was originally written for a TMC-1680 board with the TMC-1800 chip. + * More recently, boards are being produced with the TMC-18C50 and TMC-18C30 + * chips. + * + * Please note that the drive ordering that Future Domain implemented in BIOS + * versions 3.4 and 3.5 is the opposite of the order (currently) used by the + * rest of the SCSI industry. + * + * + * REFERENCES USED: + * + * "TMC-1800 SCSI Chip Specification (FDC-1800T)", Future Domain Corporation, + * 1990. + * + * "Technical Reference Manual: 18C50 SCSI Host Adapter Chip", Future Domain + * Corporation, January 1992. + * + * "LXT SCSI Products: Specifications and OEM Technical Manual (Revision + * B/September 1991)", Maxtor Corporation, 1991. + * + * "7213S product Manual (Revision P3)", Maxtor Corporation, 1992. + * + * "Draft Proposed American National Standard: Small Computer System + * Interface - 2 (SCSI-2)", Global Engineering Documents. (X3T9.2/86-109, + * revision 10h, October 17, 1991) + * + * Private communications, Drew Eckhardt (d...@cs.colorado.edu) and Eric + * Youngdale (er...@cais.com), 1992. + * + * Private communication, Tuong Le (Future Domain Engineering department), + * 1994. (Disk geometry computations for Future Domain BIOS version 3.4, and + * TMC-18C30 detection.) + * + * Hogan, Thom. The Programmer's PC Sourcebook. Microsoft Press, 1988. Page + * 60 (2.39: Disk Partition Table Layout). + * + * "18C30 Technical Reference Manual", Future Domain Corporation, 1993, page + * 6-1. + */ + +#include +#include +#include +#include +#include +#include +#include +#include
[PATCH v2 0/3] fdomain: Resurrect driver
Resurrect previously removed fdomain driver, in modern style. Initialization is rewritten completely, with support for multiple cards, no more global state variables. Most of the code from interrupt handler is moved to a workqueue. This is a modularized version with core separated from bus-specific drivers (PCI, ISA and PCMCIA). Only PCI and ISA drivers are submitted for now. Changes in v2: - BIOS-related code moved to ISA driver and simplified - fixed (un)locking in fdomain_host_reset -- Ondrej Zary
[PATCH v2 3/3] fdomain: Resurrect driver (ISA support)
Future Domain 16xx ISA SCSI support card support.
Tested on IBM 92F0330 card (18C50 chip) with v1.00 BIOS.
Signed-off-by: Ondrej Zary
Reviewed-by: Christoph Hellwig
---
drivers/scsi/Kconfig | 14 +++
drivers/scsi/Makefile | 1 +
drivers/scsi/fdomain_isa.c | 222 +
3 files changed, 237 insertions(+)
create mode 100644 drivers/scsi/fdomain_isa.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index f9d058a07e2a..2ea77dafbc00 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -684,6 +684,20 @@ config SCSI_FDOMAIN_PCI
To compile this driver as a module, choose M here: the
module will be called fdomain_pci.
+config SCSI_FDOMAIN_ISA
+ tristate "Future Domain 16xx ISA SCSI support"
+ depends on ISA && SCSI
+ select CHECK_SIGNATURE
+ select SCSI_FDOMAIN
+ help
+ This is support for Future Domain's 16-bit SCSI host adapters
+ (TMC-1660/1680, TMC-1650/1670, TMC-1610M/MER/MEX) and other adapters
+ with ISA bus based on the Future Domain chipsets (Quantum ISA-200S,
+ ISA-250MG; and at least one IBM board).
+
+ To compile this driver as a module, choose M here: the
+ module will be called fdomain_isa.
+
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
depends on PCI && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index f6cc4fbe6957..2e2c777d 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -78,6 +78,7 @@ obj-$(CONFIG_SCSI_ISCI) += isci/
obj-$(CONFIG_SCSI_IPS) += ips.o
obj-$(CONFIG_SCSI_FDOMAIN) += fdomain.o
obj-$(CONFIG_SCSI_FDOMAIN_PCI) += fdomain_pci.o
+obj-$(CONFIG_SCSI_FDOMAIN_ISA) += fdomain_isa.o
obj-$(CONFIG_SCSI_GENERIC_NCR5380) += g_NCR5380.o
obj-$(CONFIG_SCSI_QLOGIC_FAS) += qlogicfas408.o qlogicfas.o
obj-$(CONFIG_PCMCIA_QLOGIC)+= qlogicfas408.o
diff --git a/drivers/scsi/fdomain_isa.c b/drivers/scsi/fdomain_isa.c
new file mode 100644
index ..bca5d56f12aa
--- /dev/null
+++ b/drivers/scsi/fdomain_isa.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include "fdomain.h"
+
+#define MAXBOARDS_PARAM 4
+static int io[MAXBOARDS_PARAM] = { 0, 0, 0, 0 };
+module_param_hw_array(io, int, ioport, NULL, 0);
+MODULE_PARM_DESC(io, "base I/O address of controller (0x140, 0x150, 0x160,
0x170)");
+
+static int irq[MAXBOARDS_PARAM] = { 0, 0, 0, 0 };
+module_param_hw_array(irq, int, irq, NULL, 0);
+MODULE_PARM_DESC(irq, "IRQ of controller (0=auto [default])");
+
+static int scsi_id[MAXBOARDS_PARAM] = { 0, 0, 0, 0 };
+module_param_hw_array(scsi_id, int, other, NULL, 0);
+MODULE_PARM_DESC(scsi_id, "SCSI ID of controller (default = 7)");
+
+static unsigned long addresses[] = {
+ 0xc8000,
+ 0xca000,
+ 0xce000,
+ 0xde000,
+};
+#define ADDRESS_COUNT ARRAY_SIZE(addresses)
+
+static unsigned short ports[] = { 0x140, 0x150, 0x160, 0x170 };
+#define PORT_COUNT ARRAY_SIZE(ports)
+
+static unsigned short irqs[] = { 3, 5, 10, 11, 12, 14, 15, 0 };
+
+/* This driver works *ONLY* for Future Domain cards using the TMC-1800,
+ * TMC-18C50, or TMC-18C30 chip. This includes models TMC-1650, 1660, 1670,
+ * and 1680. These are all 16-bit cards.
+ * BIOS versions prior to 3.2 assigned SCSI ID 6 to SCSI adapter.
+ *
+ * The following BIOS signature signatures are for boards which do *NOT*
+ * work with this driver (these TMC-8xx and TMC-9xx boards may work with the
+ * Seagate driver):
+ *
+ * FUTURE DOMAIN CORP. (C) 1986-1988 V4.0I 03/16/88
+ * FUTURE DOMAIN CORP. (C) 1986-1989 V5.0C2/14/89
+ * FUTURE DOMAIN CORP. (C) 1986-1989 V6.0A7/28/89
+ * FUTURE DOMAIN CORP. (C) 1986-1990 V6.0105/31/90
+ * FUTURE DOMAIN CORP. (C) 1986-1990 V6.0209/18/90
+ * FUTURE DOMAIN CORP. (C) 1986-1990 V7.009/18/90
+ * FUTURE DOMAIN CORP. (C) 1992 V8.00.004/02/92
+ *
+ * (The cards which do *NOT* work are all 8-bit cards -- although some of
+ * them have a 16-bit form-factor, the upper 8-bits are used only for IRQs
+ * and are *NOT* used for data. You can tell the difference by following
+ * the tracings on the circuit board -- if only the IRQ lines are involved,
+ * you have a "8-bit" card, and should *NOT* use this driver.)
+ */
+
+static struct signature {
+ const char *signature;
+ int offset;
+ int length;
+ int this_id;
+ int base_offset;
+} signatures[] = {
+/* 1 2 3 4 5 6 */
+/* 123456789012345678901234567890123456789012345678901234567890 */
+{ "FUTURE DOMAIN CORP. (C) 1986-1990 1800-V2.07/28/89", 5, 50, 6,
0x1fcc },
+{ "FUTURE DOMAIN CORP. (C) 1986-1990 1800-V1.07/28/89", 5, 50, 6,
0x1fcc },
+{ "FUTURE DOMAIN CORP. (C) 1986-1990 1800
Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels
On Tuesday 14 May 2019, Arthur Marsh wrote: > Apologies, I had forgotten to > > got bisect - - hard origin/master > > I am still seeing the corruption leading to the invalid block error on 5.1.0+ > kernels on both my machines. > > Arthur. I've been probably hit by the same bug. ext3 filesystem on my test machine was corrupted twice with 5.1.0+. Only the corruption was heavier. Some files that were open (e.g. logs) became cros-linked with files that were not used for ages. -- Ondrej Zary
Re: [PATCH 2/2] fdomain: Add ISA bus support
On Monday 13 May 2019 09:09:04 Christoph Hellwig wrote: > On Fri, May 10, 2019 at 11:23:35PM +0200, Ondrej Zary wrote: > > Add Future Domain 16xx ISA SCSI support card support. > > > > Tested on IBM 92F0330 card (18C50 chip) with v1.00 BIOS. > > Where did you find that thing? :) eBay :) There are also some PCMCIA cards there. > > > > Signed-off-by: Ondrej Zary > > The driver looks fine to me: > > Reviewed-by: Christoph Hellwig > -- Ondrej Zary
[PATCH 2/2] fdomain: Add ISA bus support
Add Future Domain 16xx ISA SCSI support card support.
Tested on IBM 92F0330 card (18C50 chip) with v1.00 BIOS.
Signed-off-by: Ondrej Zary
---
drivers/scsi/Kconfig | 14 +++
drivers/scsi/Makefile | 1 +
drivers/scsi/fdomain_isa.c | 222 +
3 files changed, 237 insertions(+)
create mode 100644 drivers/scsi/fdomain_isa.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index f9d058a07e2a..2ea77dafbc00 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -684,6 +684,20 @@ config SCSI_FDOMAIN_PCI
To compile this driver as a module, choose M here: the
module will be called fdomain_pci.
+config SCSI_FDOMAIN_ISA
+ tristate "Future Domain 16xx ISA SCSI support"
+ depends on ISA && SCSI
+ select CHECK_SIGNATURE
+ select SCSI_FDOMAIN
+ help
+ This is support for Future Domain's 16-bit SCSI host adapters
+ (TMC-1660/1680, TMC-1650/1670, TMC-1610M/MER/MEX) and other adapters
+ with ISA bus based on the Future Domain chipsets (Quantum ISA-200S,
+ ISA-250MG; and at least one IBM board).
+
+ To compile this driver as a module, choose M here: the
+ module will be called fdomain_isa.
+
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
depends on PCI && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index f6cc4fbe6957..2e2c777d 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -78,6 +78,7 @@ obj-$(CONFIG_SCSI_ISCI) += isci/
obj-$(CONFIG_SCSI_IPS) += ips.o
obj-$(CONFIG_SCSI_FDOMAIN) += fdomain.o
obj-$(CONFIG_SCSI_FDOMAIN_PCI) += fdomain_pci.o
+obj-$(CONFIG_SCSI_FDOMAIN_ISA) += fdomain_isa.o
obj-$(CONFIG_SCSI_GENERIC_NCR5380) += g_NCR5380.o
obj-$(CONFIG_SCSI_QLOGIC_FAS) += qlogicfas408.o qlogicfas.o
obj-$(CONFIG_PCMCIA_QLOGIC)+= qlogicfas408.o
diff --git a/drivers/scsi/fdomain_isa.c b/drivers/scsi/fdomain_isa.c
new file mode 100644
index ..bca5d56f12aa
--- /dev/null
+++ b/drivers/scsi/fdomain_isa.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include "fdomain.h"
+
+#define MAXBOARDS_PARAM 4
+static int io[MAXBOARDS_PARAM] = { 0, 0, 0, 0 };
+module_param_hw_array(io, int, ioport, NULL, 0);
+MODULE_PARM_DESC(io, "base I/O address of controller (0x140, 0x150, 0x160,
0x170)");
+
+static int irq[MAXBOARDS_PARAM] = { 0, 0, 0, 0 };
+module_param_hw_array(irq, int, irq, NULL, 0);
+MODULE_PARM_DESC(irq, "IRQ of controller (0=auto [default])");
+
+static int scsi_id[MAXBOARDS_PARAM] = { 0, 0, 0, 0 };
+module_param_hw_array(scsi_id, int, other, NULL, 0);
+MODULE_PARM_DESC(scsi_id, "SCSI ID of controller (default = 7)");
+
+static unsigned long addresses[] = {
+ 0xc8000,
+ 0xca000,
+ 0xce000,
+ 0xde000,
+};
+#define ADDRESS_COUNT ARRAY_SIZE(addresses)
+
+static unsigned short ports[] = { 0x140, 0x150, 0x160, 0x170 };
+#define PORT_COUNT ARRAY_SIZE(ports)
+
+static unsigned short irqs[] = { 3, 5, 10, 11, 12, 14, 15, 0 };
+
+/* This driver works *ONLY* for Future Domain cards using the TMC-1800,
+ * TMC-18C50, or TMC-18C30 chip. This includes models TMC-1650, 1660, 1670,
+ * and 1680. These are all 16-bit cards.
+ * BIOS versions prior to 3.2 assigned SCSI ID 6 to SCSI adapter.
+ *
+ * The following BIOS signature signatures are for boards which do *NOT*
+ * work with this driver (these TMC-8xx and TMC-9xx boards may work with the
+ * Seagate driver):
+ *
+ * FUTURE DOMAIN CORP. (C) 1986-1988 V4.0I 03/16/88
+ * FUTURE DOMAIN CORP. (C) 1986-1989 V5.0C2/14/89
+ * FUTURE DOMAIN CORP. (C) 1986-1989 V6.0A7/28/89
+ * FUTURE DOMAIN CORP. (C) 1986-1990 V6.0105/31/90
+ * FUTURE DOMAIN CORP. (C) 1986-1990 V6.0209/18/90
+ * FUTURE DOMAIN CORP. (C) 1986-1990 V7.009/18/90
+ * FUTURE DOMAIN CORP. (C) 1992 V8.00.004/02/92
+ *
+ * (The cards which do *NOT* work are all 8-bit cards -- although some of
+ * them have a 16-bit form-factor, the upper 8-bits are used only for IRQs
+ * and are *NOT* used for data. You can tell the difference by following
+ * the tracings on the circuit board -- if only the IRQ lines are involved,
+ * you have a "8-bit" card, and should *NOT* use this driver.)
+ */
+
+static struct signature {
+ const char *signature;
+ int offset;
+ int length;
+ int this_id;
+ int base_offset;
+} signatures[] = {
+/* 1 2 3 4 5 6 */
+/* 123456789012345678901234567890123456789012345678901234567890 */
+{ "FUTURE DOMAIN CORP. (C) 1986-1990 1800-V2.07/28/89", 5, 50, 6,
0x1fcc },
+{ "FUTURE DOMAIN CORP. (C) 1986-1990 1800-V1.07/28/89", 5, 50, 6,
0x1fcc },
+{ "FUTURE DOMAIN CORP. (C) 1986-1990 1800-V2.07/28/89", 72, 50, 6, 0x1f
[PATCH 1/2] fdomain: Remove BIOS-related code from core
Move all BIOS signature and base handling to (currently not merged) ISA bus
driver.
Signed-off-by: Ondrej Zary
---
drivers/scsi/fdomain.c | 18 ++
drivers/scsi/fdomain.h | 10 --
drivers/scsi/fdomain_pci.c | 2 +-
3 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/scsi/fdomain.c b/drivers/scsi/fdomain.c
index e43fdd1ab3a8..f0fda2ad1c7d 100644
--- a/drivers/scsi/fdomain.c
+++ b/drivers/scsi/fdomain.c
@@ -494,7 +494,6 @@ static struct scsi_host_template fdomain_template = {
};
struct Scsi_Host *fdomain_create(int base, int irq, int this_id,
-unsigned long bios_base, struct signature *sig,
struct device *dev)
{
struct Scsi_Host *sh;
@@ -524,9 +523,6 @@ struct Scsi_Host *fdomain_create(int base, int irq, int
this_id,
if (this_id)
sh->this_id = this_id & 0x07;
- else if (sig && sig->bios_major > 0 &&
- (sig->bios_major < 3 || sig->bios_minor < 2))
- sh->this_id = 6;
sh->irq = irq;
sh->io_port = base;
@@ -541,19 +537,9 @@ struct Scsi_Host *fdomain_create(int base, int irq, int
this_id,
"fdomain", fd))
goto fail_put;
- if (!sig || (sig->bios_major < 0 && sig->bios_minor < 0))
- shost_printk(KERN_INFO, sh, "No BIOS; using SCSI ID %d\n",
-sh->this_id);
- else {
- char v1 = (sig->bios_major >= 0) ? '0' + sig->bios_major : '?';
- char v2 = (sig->bios_minor >= 0) ? '0' + sig->bios_minor : '?';
-
- shost_printk(KERN_INFO, sh, "BIOS version %c.%c at 0x%lx using
SCSI ID %d\n",
-v1, v2, bios_base, sh->this_id);
- }
- shost_printk(KERN_INFO, sh, "%s chip at 0x%x irq %d\n",
+ shost_printk(KERN_INFO, sh, "%s chip at 0x%x irq %d SCSI ID %d\n",
dev_is_pci(dev) ? "TMC-36C70 (PCI bus)" : chip_names[chip],
-base, irq);
+base, irq, sh->this_id);
if (scsi_add_host(sh, dev))
goto fail_free_irq;
diff --git a/drivers/scsi/fdomain.h b/drivers/scsi/fdomain.h
index a124a95764d6..fabb2e49461f 100644
--- a/drivers/scsi/fdomain.h
+++ b/drivers/scsi/fdomain.h
@@ -41,15 +41,6 @@ enum out_port_type {
Write_FIFO = 12
};
-struct signature {
- const char *signature;
- int offset;
- int length;
- int bios_major;
- int bios_minor;
- int flag; /* 1 = PCI_bus, 2 = ISA_200S, 3 = ISA_250MG, 4 = ISA_200S */
-};
-
#ifdef CONFIG_PM_SLEEP
static const struct dev_pm_ops fdomain_pm_ops;
#define FDOMAIN_PM_OPS (_pm_ops)
@@ -58,6 +49,5 @@ static const struct dev_pm_ops fdomain_pm_ops;
#endif /* CONFIG_PM_SLEEP */
struct Scsi_Host *fdomain_create(int base, int irq, int this_id,
-unsigned long bios_base, struct signature *sig,
struct device *dev);
int fdomain_destroy(struct Scsi_Host *sh);
diff --git a/drivers/scsi/fdomain_pci.c b/drivers/scsi/fdomain_pci.c
index 381a7157c078..3e05ce7b89e5 100644
--- a/drivers/scsi/fdomain_pci.c
+++ b/drivers/scsi/fdomain_pci.c
@@ -22,7 +22,7 @@ static int fdomain_pci_probe(struct pci_dev *pdev,
if (pci_resource_len(pdev, 0) == 0)
goto release_region;
- sh = fdomain_create(pci_resource_start(pdev, 0), pdev->irq, 7, 0, NULL,
+ sh = fdomain_create(pci_resource_start(pdev, 0), pdev->irq, 7,
>dev);
if (!sh)
goto release_region;
--
Ondrej Zary
[RFC PATCH 3/2] fdomain: Use SCSI host private data instead of global variables
Move global variables into SCSI host private data in order to support
multiple cards.
Signed-off-by: Ondrej Zary
---
drivers/scsi/fdomain.c | 593 +
1 file changed, 307 insertions(+), 286 deletions(-)
diff --git a/drivers/scsi/fdomain.c b/drivers/scsi/fdomain.c
index fe9e373c27a8..83294cf6b668 100644
--- a/drivers/scsi/fdomain.c
+++ b/drivers/scsi/fdomain.c
@@ -384,29 +384,32 @@ enum out_port_type {
/* .bss will zero all the static variables below */
static int port_base;
-static unsigned long bios_base;
-static void __iomem *bios_mem;
-static int bios_major;
-static int bios_minor;
-static int PCI_bus;
-#ifdef CONFIG_PCI
-static struct pci_dev *PCI_dev;
-#endif
-static int Quantum; /* Quantum board variant */
static int interrupt_level;
-static volatile int in_command;
-static struct scsi_cmnd *current_SC;
-static enum chip_typechip = unknown;
-static int adapter_mask;
static int this_id;
static int setup_called;
+struct fdomain {
+ int port_base;
+ unsigned long bios_base;
+ void __iomem *bios_mem;
+ int bios_major;
+ int bios_minor;
+ int PCI_bus;
+#ifdef CONFIG_PCI
+ struct pci_dev *PCI_dev;
+#endif
+ int Quantum;/* Quantum board variant */
+ int interrupt_level;
+ volatile int in_command;
+ struct scsi_cmnd *current_SC;
+ enum chip_type chip;
+ int adapter_mask;
+ int this_id;
#if DEBUG_RACE
-static volatile int in_interrupt_flag;
+ volatile int in_interrupt_flag;
#endif
-
-static int FIFO_Size = 0x2000; /* 8k FIFO for
- pre-tmc18c30 chips */
+ int FIFO_Size;
+};
static irqreturn_t do_fdomain_16x0_intr( int irq, void *dev_id );
/* Allow insmod parameters to be like LILO parameters. For example:
@@ -518,22 +521,22 @@ static struct signature {
static void print_banner( struct Scsi_Host *shpnt )
{
- if (!shpnt) return; /* This won't ever happen */
+ struct fdomain *fd = shost_priv(shpnt);
- if (bios_major < 0 && bios_minor < 0) {
+ if (fd->bios_major < 0 && fd->bios_minor < 0) {
printk(KERN_INFO "scsi%d: No BIOS; using scsi id %d\n",
shpnt->host_no, shpnt->this_id);
} else {
printk(KERN_INFO "scsi%d: BIOS version ", shpnt->host_no);
- if (bios_major >= 0) printk("%d.", bios_major);
+ if (fd->bios_major >= 0) printk("%d.", fd->bios_major);
else printk("?.");
- if (bios_minor >= 0) printk("%d", bios_minor);
+ if (fd->bios_minor >= 0) printk("%d", fd->bios_minor);
else printk("?.");
printk( " at 0x%lx using scsi id %d\n",
- bios_base, shpnt->this_id );
+ fd->bios_base, shpnt->this_id );
}
/* If this driver works for later FD PCI
@@ -542,11 +545,11 @@ static void print_banner( struct Scsi_Host *shpnt )
it's PCI it's a TMC-3260 - JTM */
printk(KERN_INFO "scsi%d: %s chip at 0x%x irq ",
shpnt->host_no,
- chip == tmc1800 ? "TMC-1800" : (chip == tmc18c50 ? "TMC-18C50" :
(chip == tmc18c30 ? (PCI_bus ? "TMC-36C70 (PCI bus)" : "TMC-18C30") :
"Unknown")),
- port_base);
+ fd->chip == tmc1800 ? "TMC-1800" : (fd->chip == tmc18c50 ?
"TMC-18C50" : (fd->chip == tmc18c30 ? (fd->PCI_bus ? "TMC-36C70 (PCI bus)" :
"TMC-18C30") : "Unknown")),
+ fd->port_base);
- if (interrupt_level)
- printk("%d", interrupt_level);
+ if (fd->interrupt_level)
+ printk("%d", fd->interrupt_level);
else
printk("");
@@ -568,8 +571,7 @@ int fdomain_setup(char *str)
port_base = ints[0] >= 1 ? ints[1] : 0;
interrupt_level = ints[0] >= 2 ? ints[2] : 0;
this_id = ints[0] >= 3 ? ints[3] : 0;
-
- bios_major = bios_minor = -1; /* Use geometry for BIOS version >= 3.4 */
+
++setup_called;
return 1;
}
@@ -582,22 +584,24 @@ static void do_pause(unsigned amount) /* Pause for
amount*10 milliseconds */
mdelay(10*amount);
}
-static inline void fdomain_make_bus_idle( void )
+static inline void fdomain_make_bus_idle(struct fdomain *fd)
{
- outb(0, port_base + SCSI_Cntl);
- outb(0, port_base + SCSI_Mode_Cntl);
- if (chip == tmc18c50 || chip == tmc18c30)
-outb(0x21 | PARITY_MASK, port_base + TMC_Cntl); /* Clear forced intr.
bnxt_en: NIC Link is Up, 100 Mbps full duplex - but no data
Hello, I have a new Dell R740 server with BCM57416: Ethernet controller [0200]: Broadcom Limited BCM57416 NetXtreme-E 10GBase-T RDMA Ethernet Controller [14e4:16d8] (rev 01) Subsystem: Broadcom Limited BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet Controller [14e4:4160] When I connect a cable from 100Mbps switch, everything looks good - the link LED lights up orange, data LED flashes green as when data is sent/received, this appears in log: [ 3791.655357] bnxt_en :17:00.0 eno1np0: NIC Link is Up, 100 Mbps full duplex, Flow control: ON - receive & transmit [ 3791.655361] bnxt_en :17:00.0 eno1np0: EEE is not active [ 3791.655364] bnxt_en :17:00.0 eno1np0: FEC autoneg off encodings: None But no data comes in or out. tcpdump shows only outgoing packets and they're not transmitted in real (not seen by other machines). It works fine after connecting through a gigabit switch. Currently running 4.18.0-2-amd64 kernel (Debian testing). Any ideas? -- Ondrej Zary
bnxt_en: NIC Link is Up, 100 Mbps full duplex - but no data
Hello, I have a new Dell R740 server with BCM57416: Ethernet controller [0200]: Broadcom Limited BCM57416 NetXtreme-E 10GBase-T RDMA Ethernet Controller [14e4:16d8] (rev 01) Subsystem: Broadcom Limited BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet Controller [14e4:4160] When I connect a cable from 100Mbps switch, everything looks good - the link LED lights up orange, data LED flashes green as when data is sent/received, this appears in log: [ 3791.655357] bnxt_en :17:00.0 eno1np0: NIC Link is Up, 100 Mbps full duplex, Flow control: ON - receive & transmit [ 3791.655361] bnxt_en :17:00.0 eno1np0: EEE is not active [ 3791.655364] bnxt_en :17:00.0 eno1np0: FEC autoneg off encodings: None But no data comes in or out. tcpdump shows only outgoing packets and they're not transmitted in real (not seen by other machines). It works fine after connecting through a gigabit switch. Currently running 4.18.0-2-amd64 kernel (Debian testing). Any ideas? -- Ondrej Zary
Re: bioset changes in 4.18 broke aha1542
On Thursday 18 October 2018 20:58:57 Jens Axboe wrote: > On 10/18/18 12:34 PM, Ondrej Zary wrote: > > Hello, > > aha1542 works fine in 4.17 but crashes in 4.18. It's hard to bisect because > > of many commits that don't compile. > > # only skipped commits left to test > > # possible first bad commit: [52190f8abe7f2bf2b4e5f9760cbcc1427ca2136b] fs: > > convert block_dev.c to bioset_init() > > # possible first bad commit: [a47a28b74a5c7c27bf621276b85ad6c124651236] > > target: convert to bioset_init()/mempool_init() > > # possible first bad commit: [6f1c819c219f7841079f0f43ab62727a55b0d849] dm: > > convert to bioset_init()/mempool_init() > > # possible first bad commit: [afeee514ce7f4cab605beedd03be71ebaf0c5fc8] md: > > convert to bioset_init()/mempool_init() > > # possible first bad commit: [d19936a26658a7a53edd5619d631ee2c2c3151a2] > > bcache: convert to bioset_init()/mempool_init() > > # possible first bad commit: [b906bbb6997785d9ea0bd3f5585537afa6257c43] > > lightnvm: convert to bioset_init()/mempool_init() > > > > Testing manually, a47a28b74a5c7c27bf621276b85ad6c124651236 works. > > 52190f8abe7f2bf2b4e5f9760cbcc1427ca2136b does not compile > > 8ac9f7c1fd1d342e82ddf078425423b050652ba0 does not compile > > e292d7bc63c8f2adb3dfda27910e805f1b6557f9 does not compile > > dad08527525f9a8ac9c7f278864c65f94bc5e9b3 does not compile > > 943cf9f3ca16133dbd00f9a4cbfea46512fcb0e8 works > > .. > > fedc3abe7bd2dcc4c80bcf3cff8708a3908d8219 works > > 04c4950d5b373ba712d928592e05e73510785bca crashes > > It looks like the ISA bioset pool isn't being initialized. You should > have messages like this in your dmesg: > > isa pool size: 16 pages > > (which you do), but also something on the bioset section. Do you have > this one: > > pool size: 64 pages > > as well? > No, it's not there. -- Ondrej Zary
Re: bioset changes in 4.18 broke aha1542
On Thursday 18 October 2018 20:58:57 Jens Axboe wrote: > On 10/18/18 12:34 PM, Ondrej Zary wrote: > > Hello, > > aha1542 works fine in 4.17 but crashes in 4.18. It's hard to bisect because > > of many commits that don't compile. > > # only skipped commits left to test > > # possible first bad commit: [52190f8abe7f2bf2b4e5f9760cbcc1427ca2136b] fs: > > convert block_dev.c to bioset_init() > > # possible first bad commit: [a47a28b74a5c7c27bf621276b85ad6c124651236] > > target: convert to bioset_init()/mempool_init() > > # possible first bad commit: [6f1c819c219f7841079f0f43ab62727a55b0d849] dm: > > convert to bioset_init()/mempool_init() > > # possible first bad commit: [afeee514ce7f4cab605beedd03be71ebaf0c5fc8] md: > > convert to bioset_init()/mempool_init() > > # possible first bad commit: [d19936a26658a7a53edd5619d631ee2c2c3151a2] > > bcache: convert to bioset_init()/mempool_init() > > # possible first bad commit: [b906bbb6997785d9ea0bd3f5585537afa6257c43] > > lightnvm: convert to bioset_init()/mempool_init() > > > > Testing manually, a47a28b74a5c7c27bf621276b85ad6c124651236 works. > > 52190f8abe7f2bf2b4e5f9760cbcc1427ca2136b does not compile > > 8ac9f7c1fd1d342e82ddf078425423b050652ba0 does not compile > > e292d7bc63c8f2adb3dfda27910e805f1b6557f9 does not compile > > dad08527525f9a8ac9c7f278864c65f94bc5e9b3 does not compile > > 943cf9f3ca16133dbd00f9a4cbfea46512fcb0e8 works > > .. > > fedc3abe7bd2dcc4c80bcf3cff8708a3908d8219 works > > 04c4950d5b373ba712d928592e05e73510785bca crashes > > It looks like the ISA bioset pool isn't being initialized. You should > have messages like this in your dmesg: > > isa pool size: 16 pages > > (which you do), but also something on the bioset section. Do you have > this one: > > pool size: 64 pages > > as well? > No, it's not there. -- Ondrej Zary
[PATCH 1/3] gspca_zc3xx: Implement proper autogain and exposure control for OV7648
The ZS0211 internal autogain causes pumping and flickering with OV7648
sensor on 0ac8:307b webcam.
Implement OV7648 autogain and exposure control and use that instead.
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/media/usb/gspca/zc3xx.c | 42 +
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 25b4dbe8e049..992918b3ad0c 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -5778,16 +5778,34 @@ static void setcontrast(struct gspca_dev *gspca_dev,
static s32 getexposure(struct gspca_dev *gspca_dev)
{
- return (i2c_read(gspca_dev, 0x25) << 9)
- | (i2c_read(gspca_dev, 0x26) << 1)
- | (i2c_read(gspca_dev, 0x27) >> 7);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ return (i2c_read(gspca_dev, 0x25) << 9)
+ | (i2c_read(gspca_dev, 0x26) << 1)
+ | (i2c_read(gspca_dev, 0x27) >> 7);
+ case SENSOR_OV7620:
+ return i2c_read(gspca_dev, 0x10);
+ default:
+ return -1;
+ }
}
static void setexposure(struct gspca_dev *gspca_dev, s32 val)
{
- i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
- i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
- i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
+ i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
+ i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ break;
+ case SENSOR_OV7620:
+ i2c_write(gspca_dev, 0x10, val, 0x00);
+ break;
+ }
}
static void setquality(struct gspca_dev *gspca_dev)
@@ -5918,7 +5936,12 @@ static void setlightfreq(struct gspca_dev *gspca_dev,
s32 val)
static void setautogain(struct gspca_dev *gspca_dev, s32 val)
{
- reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ if (sd->sensor == SENSOR_OV7620)
+ i2c_write(gspca_dev, 0x13, val ? 0xa3 : 0x80, 0x00);
+ else
+ reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
}
/*
@@ -6439,6 +6462,9 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
if (sd->sensor == SENSOR_HV7131R)
sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_EXPOSURE, 0x30d, 0x493e, 1, 0x927);
+ else if (sd->sensor == SENSOR_OV7620)
+ sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
+ V4L2_CID_EXPOSURE, 0, 255, 1, 0x41);
sd->autogain = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
if (sd->sensor != SENSOR_OV7630C)
@@ -6458,7 +6484,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
return hdl->error;
}
v4l2_ctrl_cluster(3, >gamma);
- if (sd->sensor == SENSOR_HV7131R)
+ if (sd->sensor == SENSOR_HV7131R || sd->sensor == SENSOR_OV7620)
v4l2_ctrl_auto_cluster(2, >autogain, 0, true);
return 0;
}
--
Ondrej Zary
[PATCH 1/3] gspca_zc3xx: Implement proper autogain and exposure control for OV7648
The ZS0211 internal autogain causes pumping and flickering with OV7648
sensor on 0ac8:307b webcam.
Implement OV7648 autogain and exposure control and use that instead.
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 42 +
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 25b4dbe8e049..992918b3ad0c 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -5778,16 +5778,34 @@ static void setcontrast(struct gspca_dev *gspca_dev,
static s32 getexposure(struct gspca_dev *gspca_dev)
{
- return (i2c_read(gspca_dev, 0x25) << 9)
- | (i2c_read(gspca_dev, 0x26) << 1)
- | (i2c_read(gspca_dev, 0x27) >> 7);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ return (i2c_read(gspca_dev, 0x25) << 9)
+ | (i2c_read(gspca_dev, 0x26) << 1)
+ | (i2c_read(gspca_dev, 0x27) >> 7);
+ case SENSOR_OV7620:
+ return i2c_read(gspca_dev, 0x10);
+ default:
+ return -1;
+ }
}
static void setexposure(struct gspca_dev *gspca_dev, s32 val)
{
- i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
- i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
- i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
+ i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
+ i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ break;
+ case SENSOR_OV7620:
+ i2c_write(gspca_dev, 0x10, val, 0x00);
+ break;
+ }
}
static void setquality(struct gspca_dev *gspca_dev)
@@ -5918,7 +5936,12 @@ static void setlightfreq(struct gspca_dev *gspca_dev,
s32 val)
static void setautogain(struct gspca_dev *gspca_dev, s32 val)
{
- reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ if (sd->sensor == SENSOR_OV7620)
+ i2c_write(gspca_dev, 0x13, val ? 0xa3 : 0x80, 0x00);
+ else
+ reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
}
/*
@@ -6439,6 +6462,9 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
if (sd->sensor == SENSOR_HV7131R)
sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_EXPOSURE, 0x30d, 0x493e, 1, 0x927);
+ else if (sd->sensor == SENSOR_OV7620)
+ sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
+ V4L2_CID_EXPOSURE, 0, 255, 1, 0x41);
sd->autogain = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
if (sd->sensor != SENSOR_OV7630C)
@@ -6458,7 +6484,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
return hdl->error;
}
v4l2_ctrl_cluster(3, >gamma);
- if (sd->sensor == SENSOR_HV7131R)
+ if (sd->sensor == SENSOR_HV7131R || sd->sensor == SENSOR_OV7620)
v4l2_ctrl_auto_cluster(2, >autogain, 0, true);
return 0;
}
--
Ondrej Zary
[PATCH 2/3 v2] gspca_zc3xx: Fix power line frequency settings for OV7648
Power line frequency settings for OV7648 sensor contain autogain
and exposure commands, affecting unrelated controls. Remove them.
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/media/usb/gspca/zc3xx.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 992918b3ad0c..c72f2d9167d9 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3184,7 +3184,6 @@ static const struct usb_action ov7620_InitialScale[] = {
/* 320x240 */
{}
};
static const struct usb_action ov7620_50HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3195,15 +3194,12 @@ static const struct usb_action ov7620_50HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID},/* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW},/* 01,97,83,cc */
- {0xaa, 0x10, 0x0082}, /* 00,10,82,aa */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
{}
};
static const struct usb_action ov7620_60HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3214,7 +3210,6 @@ static const struct usb_action ov7620_60HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID}, /* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW}, /* 01,97,83,cc */
- {0xaa, 0x10, 0x0020}, /* 00,10,20,aa */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
@@ -3224,8 +3219,6 @@ static const struct usb_action ov7620_60HZ[] = {
{}
};
static const struct usb_action ov7620_NoFliker[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
--
Ondrej Zary
[PATCH 2/3 v2] gspca_zc3xx: Fix power line frequency settings for OV7648
Power line frequency settings for OV7648 sensor contain autogain
and exposure commands, affecting unrelated controls. Remove them.
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 992918b3ad0c..c72f2d9167d9 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3184,7 +3184,6 @@ static const struct usb_action ov7620_InitialScale[] = {
/* 320x240 */
{}
};
static const struct usb_action ov7620_50HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3195,15 +3194,12 @@ static const struct usb_action ov7620_50HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID},/* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW},/* 01,97,83,cc */
- {0xaa, 0x10, 0x0082}, /* 00,10,82,aa */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
{}
};
static const struct usb_action ov7620_60HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3214,7 +3210,6 @@ static const struct usb_action ov7620_60HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID}, /* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW}, /* 01,97,83,cc */
- {0xaa, 0x10, 0x0020}, /* 00,10,20,aa */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
@@ -3224,8 +3219,6 @@ static const struct usb_action ov7620_60HZ[] = {
{}
};
static const struct usb_action ov7620_NoFliker[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
--
Ondrej Zary
[PATCH 3/3 v2] gspca_zc3xx: Enable short exposure times for OV7648
The 50Hz and 60Hz power line frequency settings disable short (1/120s
and 1/100s) exposure times for banding filter (causing overexposed
image near lamps). No flicker setting enables them (when banding
filter is disabled and they're not used).
Seems that the logic is just the wrong way around.
(This bug came from the Windows driver.)
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/media/usb/gspca/zc3xx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index c72f2d9167d9..cf21991e3d99 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3186,7 +3186,8 @@ static const struct usb_action ov7620_InitialScale[] = {
/* 320x240 */
static const struct usb_action ov7620_50HZ[] = {
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3202,7 +3203,8 @@ static const struct usb_action ov7620_50HZ[] = {
static const struct usb_action ov7620_60HZ[] = {
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3221,7 +3223,8 @@ static const struct usb_action ov7620_60HZ[] = {
static const struct usb_action ov7620_NoFliker[] = {
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
+ /* disable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008a},
{0xaa, 0x2d, 0x0001}, /* 00,2d,01,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
--
Ondrej Zary
[PATCH 3/3 v2] gspca_zc3xx: Enable short exposure times for OV7648
The 50Hz and 60Hz power line frequency settings disable short (1/120s
and 1/100s) exposure times for banding filter (causing overexposed
image near lamps). No flicker setting enables them (when banding
filter is disabled and they're not used).
Seems that the logic is just the wrong way around.
(This bug came from the Windows driver.)
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index c72f2d9167d9..cf21991e3d99 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3186,7 +3186,8 @@ static const struct usb_action ov7620_InitialScale[] = {
/* 320x240 */
static const struct usb_action ov7620_50HZ[] = {
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3202,7 +3203,8 @@ static const struct usb_action ov7620_50HZ[] = {
static const struct usb_action ov7620_60HZ[] = {
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3221,7 +3223,8 @@ static const struct usb_action ov7620_60HZ[] = {
static const struct usb_action ov7620_NoFliker[] = {
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
+ /* disable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008a},
{0xaa, 0x2d, 0x0001}, /* 00,2d,01,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
--
Ondrej Zary
[PATCH 1/3] gspca_zc3xx: Implement proper autogain and exposure control for OV7648
The ZS0211 internal autogain causes pumping and flickering with OV7648
sensor on 0ac8:307b webcam.
Implement OV7648 autogain and exposure control and use that instead.
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/media/usb/gspca/zc3xx.c | 42 +
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 25b4dbe8e049..992918b3ad0c 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -5778,16 +5778,34 @@ static void setcontrast(struct gspca_dev *gspca_dev,
static s32 getexposure(struct gspca_dev *gspca_dev)
{
- return (i2c_read(gspca_dev, 0x25) << 9)
- | (i2c_read(gspca_dev, 0x26) << 1)
- | (i2c_read(gspca_dev, 0x27) >> 7);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ return (i2c_read(gspca_dev, 0x25) << 9)
+ | (i2c_read(gspca_dev, 0x26) << 1)
+ | (i2c_read(gspca_dev, 0x27) >> 7);
+ case SENSOR_OV7620:
+ return i2c_read(gspca_dev, 0x10);
+ default:
+ return -1;
+ }
}
static void setexposure(struct gspca_dev *gspca_dev, s32 val)
{
- i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
- i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
- i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
+ i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
+ i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ break;
+ case SENSOR_OV7620:
+ i2c_write(gspca_dev, 0x10, val, 0x00);
+ break;
+ }
}
static void setquality(struct gspca_dev *gspca_dev)
@@ -5918,7 +5936,12 @@ static void setlightfreq(struct gspca_dev *gspca_dev,
s32 val)
static void setautogain(struct gspca_dev *gspca_dev, s32 val)
{
- reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ if (sd->sensor == SENSOR_OV7620)
+ i2c_write(gspca_dev, 0x13, val ? 0xa3 : 0x80, 0x00);
+ else
+ reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
}
/*
@@ -6439,6 +6462,9 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
if (sd->sensor == SENSOR_HV7131R)
sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_EXPOSURE, 0x30d, 0x493e, 1, 0x927);
+ else if (sd->sensor == SENSOR_OV7620)
+ sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
+ V4L2_CID_EXPOSURE, 0, 255, 1, 0x41);
sd->autogain = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
if (sd->sensor != SENSOR_OV7630C)
@@ -6458,7 +6484,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
return hdl->error;
}
v4l2_ctrl_cluster(3, >gamma);
- if (sd->sensor == SENSOR_HV7131R)
+ if (sd->sensor == SENSOR_HV7131R || sd->sensor == SENSOR_OV7620)
v4l2_ctrl_auto_cluster(2, >autogain, 0, true);
return 0;
}
--
Ondrej Zary
[PATCH 1/3] gspca_zc3xx: Implement proper autogain and exposure control for OV7648
The ZS0211 internal autogain causes pumping and flickering with OV7648
sensor on 0ac8:307b webcam.
Implement OV7648 autogain and exposure control and use that instead.
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 42 +
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 25b4dbe8e049..992918b3ad0c 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -5778,16 +5778,34 @@ static void setcontrast(struct gspca_dev *gspca_dev,
static s32 getexposure(struct gspca_dev *gspca_dev)
{
- return (i2c_read(gspca_dev, 0x25) << 9)
- | (i2c_read(gspca_dev, 0x26) << 1)
- | (i2c_read(gspca_dev, 0x27) >> 7);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ return (i2c_read(gspca_dev, 0x25) << 9)
+ | (i2c_read(gspca_dev, 0x26) << 1)
+ | (i2c_read(gspca_dev, 0x27) >> 7);
+ case SENSOR_OV7620:
+ return i2c_read(gspca_dev, 0x10);
+ default:
+ return -1;
+ }
}
static void setexposure(struct gspca_dev *gspca_dev, s32 val)
{
- i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
- i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
- i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ i2c_write(gspca_dev, 0x25, val >> 9, 0x00);
+ i2c_write(gspca_dev, 0x26, val >> 1, 0x00);
+ i2c_write(gspca_dev, 0x27, val << 7, 0x00);
+ break;
+ case SENSOR_OV7620:
+ i2c_write(gspca_dev, 0x10, val, 0x00);
+ break;
+ }
}
static void setquality(struct gspca_dev *gspca_dev)
@@ -5918,7 +5936,12 @@ static void setlightfreq(struct gspca_dev *gspca_dev,
s32 val)
static void setautogain(struct gspca_dev *gspca_dev, s32 val)
{
- reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ if (sd->sensor == SENSOR_OV7620)
+ i2c_write(gspca_dev, 0x13, val ? 0xa3 : 0x80, 0x00);
+ else
+ reg_w(gspca_dev, val ? 0x42 : 0x02, 0x0180);
}
/*
@@ -6439,6 +6462,9 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
if (sd->sensor == SENSOR_HV7131R)
sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_EXPOSURE, 0x30d, 0x493e, 1, 0x927);
+ else if (sd->sensor == SENSOR_OV7620)
+ sd->exposure = v4l2_ctrl_new_std(hdl, _ctrl_ops,
+ V4L2_CID_EXPOSURE, 0, 255, 1, 0x41);
sd->autogain = v4l2_ctrl_new_std(hdl, _ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
if (sd->sensor != SENSOR_OV7630C)
@@ -6458,7 +6484,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
return hdl->error;
}
v4l2_ctrl_cluster(3, >gamma);
- if (sd->sensor == SENSOR_HV7131R)
+ if (sd->sensor == SENSOR_HV7131R || sd->sensor == SENSOR_OV7620)
v4l2_ctrl_auto_cluster(2, >autogain, 0, true);
return 0;
}
--
Ondrej Zary
[PATCH 3/3] gspca_zc3xx: Fix exposure with power line frequency for OV7648
The 50Hz and 60Hz power line frequency settings disable short (1/120s
and 1/100s) exposure times for banding filter, causing overexposed
image near lamps. No flicker setting enables them (when banding
filter is disabled and they're not used).
Seems that the logic is just the wrong way around. Fix it.
(This bug came from the Windows driver.)
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/media/usb/gspca/zc3xx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 9a78420e8ad8..299ea70bfb67 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3188,7 +3188,9 @@ static const struct usb_action ov7620_50HZ[] = {
* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+/* {0xaa, 0x75, 0x008a},* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3208,7 +3210,9 @@ static const struct usb_action ov7620_60HZ[] = {
* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+/* {0xaa, 0x75, 0x008a},* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3231,7 +3235,9 @@ static const struct usb_action ov7620_NoFliker[] = {
* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
+/* {0xaa, 0x75, 0x008e},* 00,75,8e,aa */
+ /* disable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008a},
{0xaa, 0x2d, 0x0001}, /* 00,2d,01,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
--
Ondrej Zary
[PATCH 3/3] gspca_zc3xx: Fix exposure with power line frequency for OV7648
The 50Hz and 60Hz power line frequency settings disable short (1/120s
and 1/100s) exposure times for banding filter, causing overexposed
image near lamps. No flicker setting enables them (when banding
filter is disabled and they're not used).
Seems that the logic is just the wrong way around. Fix it.
(This bug came from the Windows driver.)
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 9a78420e8ad8..299ea70bfb67 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3188,7 +3188,9 @@ static const struct usb_action ov7620_50HZ[] = {
* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+/* {0xaa, 0x75, 0x008a},* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3208,7 +3210,9 @@ static const struct usb_action ov7620_60HZ[] = {
* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
+/* {0xaa, 0x75, 0x008a},* 00,75,8a,aa */
+ /* enable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008e},
{0xaa, 0x2d, 0x0005}, /* 00,2d,05,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
@@ -3231,7 +3235,9 @@ static const struct usb_action ov7620_NoFliker[] = {
* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
- {0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
+/* {0xaa, 0x75, 0x008e},* 00,75,8e,aa */
+ /* disable 1/120s & 1/100s exposures for banding filter */
+ {0xaa, 0x75, 0x008a},
{0xaa, 0x2d, 0x0001}, /* 00,2d,01,aa */
{0xa0, 0x00, ZC3XX_R190_EXPOSURELIMITHIGH}, /* 01,90,00,cc */
{0xa0, 0x04, ZC3XX_R191_EXPOSURELIMITMID}, /* 01,91,04,cc */
--
Ondrej Zary
[PATCH 2/3] gspca_zc3xx: Fix power line frequency settings for OV7648
Power line frequency settings for OV7648 sensor contain autogain
and exposure commands, affecting unrelated controls. Remove them.
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/media/usb/gspca/zc3xx.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 992918b3ad0c..9a78420e8ad8 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3184,7 +3184,8 @@ static const struct usb_action ov7620_InitialScale[] = {
/* 320x240 */
{}
};
static const struct usb_action ov7620_50HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
+/* {0xaa, 0x13, 0x00a3},* 00,13,a3,aa
+* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3195,15 +3196,16 @@ static const struct usb_action ov7620_50HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID},/* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW},/* 01,97,83,cc */
- {0xaa, 0x10, 0x0082}, /* 00,10,82,aa */
+/* {0xaa, 0x10, 0x0082},* 00,10,82,aa
+* don't change exposure */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
{}
};
static const struct usb_action ov7620_60HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
+/* {0xaa, 0x13, 0x00a3},* 00,13,a3,aa
+* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3214,7 +3216,8 @@ static const struct usb_action ov7620_60HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID}, /* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW}, /* 01,97,83,cc */
- {0xaa, 0x10, 0x0020}, /* 00,10,20,aa */
+/* {0xaa, 0x10, 0x0020},* 00,10,20,aa
+* don't change exposure */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
@@ -3224,8 +3227,8 @@ static const struct usb_action ov7620_60HZ[] = {
{}
};
static const struct usb_action ov7620_NoFliker[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
+/* {0xaa, 0x13, 0x00a3},* 00,13,a3,aa
+* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
--
Ondrej Zary
[PATCH 2/3] gspca_zc3xx: Fix power line frequency settings for OV7648
Power line frequency settings for OV7648 sensor contain autogain
and exposure commands, affecting unrelated controls. Remove them.
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index 992918b3ad0c..9a78420e8ad8 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -3184,7 +3184,8 @@ static const struct usb_action ov7620_InitialScale[] = {
/* 320x240 */
{}
};
static const struct usb_action ov7620_50HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
+/* {0xaa, 0x13, 0x00a3},* 00,13,a3,aa
+* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x0096}, /* 00,2b,96,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3195,15 +3196,16 @@ static const struct usb_action ov7620_50HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID},/* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW},/* 01,97,83,cc */
- {0xaa, 0x10, 0x0082}, /* 00,10,82,aa */
+/* {0xaa, 0x10, 0x0082},* 00,10,82,aa
+* don't change exposure */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
{}
};
static const struct usb_action ov7620_60HZ[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
+/* {0xaa, 0x13, 0x00a3},* 00,13,a3,aa
+* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008a}, /* 00,75,8a,aa */
@@ -3214,7 +3216,8 @@ static const struct usb_action ov7620_60HZ[] = {
{0xa0, 0x00, ZC3XX_R195_ANTIFLICKERHIGH}, /* 01,95,00,cc */
{0xa0, 0x00, ZC3XX_R196_ANTIFLICKERMID}, /* 01,96,00,cc */
{0xa0, 0x83, ZC3XX_R197_ANTIFLICKERLOW}, /* 01,97,83,cc */
- {0xaa, 0x10, 0x0020}, /* 00,10,20,aa */
+/* {0xaa, 0x10, 0x0020},* 00,10,20,aa
+* don't change exposure */
{0xaa, 0x76, 0x0003}, /* 00,76,03,aa */
/* {0xa0, 0x40, ZC3XX_R002_CLOCKSELECT},* 00,02,40,cc
* if mode0 (640x480) */
@@ -3224,8 +3227,8 @@ static const struct usb_action ov7620_60HZ[] = {
{}
};
static const struct usb_action ov7620_NoFliker[] = {
- {0xaa, 0x13, 0x00a3}, /* 00,13,a3,aa */
- /* (bug in zs211.inf) */
+/* {0xaa, 0x13, 0x00a3},* 00,13,a3,aa
+* don't change autoexposure */
{0xdd, 0x00, 0x0100}, /* 00,01,00,dd */
{0xaa, 0x2b, 0x}, /* 00,2b,00,aa */
{0xaa, 0x75, 0x008e}, /* 00,75,8e,aa */
--
Ondrej Zary
Re: Moving unmaintained filesystems to staging
On Sunday 29 April 2018 14:07:05 Greg KH wrote: > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote: > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote: > > > Recently ncpfs got moved to staging. Also recently, we had some fuzzer > > > developers report bugs in hfs, which they deem a security hole because > > > Ubuntu attempts to automount an inserted USB device as hfs. > > > > We promise "no-regressions" for code in main repository, no such > > promise for staging. We have quite a lot of code without maintainer. > > > > Moving code to staging means it will get broken -- staging was not > > designed for this. I believe moving anything there is bad idea. > > > > Staging is for ugly code, not for code that needs new maintainter. > > Staging is used for getting code _out_ of the kernel tree as well as > _in_. We use it all the time to move code there, see if anyone shows up > in 6-8 months to say "I will fix this!", and if not, we delete it. > > Look at what just happened to IRDA in the 4.17-rc1 release as an example > of this. Really a "great" example of deleting working code :( -- Ondrej Zary
Re: Moving unmaintained filesystems to staging
On Sunday 29 April 2018 14:07:05 Greg KH wrote: > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote: > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote: > > > Recently ncpfs got moved to staging. Also recently, we had some fuzzer > > > developers report bugs in hfs, which they deem a security hole because > > > Ubuntu attempts to automount an inserted USB device as hfs. > > > > We promise "no-regressions" for code in main repository, no such > > promise for staging. We have quite a lot of code without maintainer. > > > > Moving code to staging means it will get broken -- staging was not > > designed for this. I believe moving anything there is bad idea. > > > > Staging is for ugly code, not for code that needs new maintainter. > > Staging is used for getting code _out_ of the kernel tree as well as > _in_. We use it all the time to move code there, see if anyone shows up > in 6-8 months to say "I will fix this!", and if not, we delete it. > > Look at what just happened to IRDA in the 4.17-rc1 release as an example > of this. Really a "great" example of deleting working code :( -- Ondrej Zary
[PATCH] Input: i8042 - Never reset on Sony VAIO VGN-CS series
Resetting i8042 breaks MUX on Sony VAIO VGN-CS. Never reset i8042 on
these machines to fix MUX after suspend.
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/input/serio/i8042-x86ia64io.h | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 56644c74828c..34793e8bf636 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -544,16 +544,23 @@ static const struct dmi_system_id __initconst
i8042_dmi_forcemux_table[] = {
{ }
};
-/*
- * On some Asus laptops, just running self tests cause problems.
- */
static const struct dmi_system_id i8042_dmi_noselftest_table[] = {
{
+ /*
+* On some Asus laptops, just running self tests cause problems.
+*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
},
},
+ {
+ /* reset breaks MUX on Sony Vaio VGN-CS series */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-CS"),
+ },
+ },
{ }
};
static const struct dmi_system_id __initconst i8042_dmi_reset_table[] = {
--
Ondrej Zary
[PATCH] Input: i8042 - Never reset on Sony VAIO VGN-CS series
Resetting i8042 breaks MUX on Sony VAIO VGN-CS. Never reset i8042 on
these machines to fix MUX after suspend.
Signed-off-by: Ondrej Zary
---
drivers/input/serio/i8042-x86ia64io.h | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 56644c74828c..34793e8bf636 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -544,16 +544,23 @@ static const struct dmi_system_id __initconst
i8042_dmi_forcemux_table[] = {
{ }
};
-/*
- * On some Asus laptops, just running self tests cause problems.
- */
static const struct dmi_system_id i8042_dmi_noselftest_table[] = {
{
+ /*
+* On some Asus laptops, just running self tests cause problems.
+*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
},
},
+ {
+ /* reset breaks MUX on Sony Vaio VGN-CS series */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-CS"),
+ },
+ },
{ }
};
static const struct dmi_system_id __initconst i8042_dmi_reset_table[] = {
--
Ondrej Zary
Re: [PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
On Friday 06 April 2018 22:05:59 Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed by the -stable helper bot and determined > to be a high probability candidate for -stable trees. (score: 24.5527) > > The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, > v4.4.126. > > v4.16: Build OK! > v4.15.15: Build OK! > v4.14.32: Build OK! > v4.9.92: Build OK! > v4.4.126: Build OK! > > Please let us know if you'd like to have this patch included in a stable > tree. AFAIK, it was already included in various stable trees. -- Ondrej Zary
Re: [PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
On Friday 06 April 2018 22:05:59 Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed by the -stable helper bot and determined > to be a high probability candidate for -stable trees. (score: 24.5527) > > The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, > v4.4.126. > > v4.16: Build OK! > v4.15.15: Build OK! > v4.14.32: Build OK! > v4.9.92: Build OK! > v4.4.126: Build OK! > > Please let us know if you'd like to have this patch included in a stable > tree. AFAIK, it was already included in various stable trees. -- Ondrej Zary
Re: Sony Vaio VGN-CS31S touch sensor buttons breaking touchpad
On Monday 02 April 2018 22:39:59 Ondrej Zary wrote:
> On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> > Hello,
> > I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that exhibits
> > weird behavior. It seems to work until I touch the "Touch Sensor Buttons"
> > bar above the keyboard - then the buttons start to act weirdly: click or
> > remain pressed (sometimes it breaks even without touching the bar).
> >
> > It seems to be a known problem with VGN-CS series:
> > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+b
> >ug /774877
> > https://wiki.freegeekvancouver.org/article/Laptop_Troubleshooting
> > (mentions nasty partial workaround: psmouse.resetafter=1)
> >
> > Many models of the VGN-CS series have the Touch Sensor Buttons:
> > ftp://124.40.41.224/PUB/MANUALS/SWT/Z009/Z009690111.PDF
> >
> > From the hardware side (can be found in MBX-196 Quanta GD2 schematic),
> > the touch bar is a separate PS/2 device connected to third PS/2 port of
> > the EC (Embedded Controller) WPC775L. The touchpad is on the 1st PS/2
> > port, 2nd port is unused. However, the i8042 does not seem to support
> > multiplexing, the firmware probably combines the data internally somehow.
>
> Good news: it supports multiplexing but i8042_nomux is set because of:
> /*
> * Most (all?) VAIOs do not have external PS/2 ports nor
> * they implement active multiplexing properly, and
> * MUX discovery usually messes up keyboard/touchpad.
> */
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
> DMI_MATCH(DMI_BOARD_NAME, "VAIO"),
> },
> in drivers/input/serio/i8042-x86ia64io.h
> (How can this be modified to exclude VGN-CS series?)
>
> Now only to write the touchbar driver... (seems to be detected at serio2 as
> PS/2 Generic Mouse)
The device acts almost as a synaptics touchpad. The 0x47 magic number (used in
detection) is replaced by 0x43.
The absolute packet format is simple:
BYTE BIT 7 6 5 4 3 2 1 0
1 1 0 Z Z Z Z Z Z pressure (left)
2 0 0 0 0 L L L L position (left:11-8)
3 L L L L L L L L position (left:7-0)
4 1 1 Z Z Z Z Z Z pressure (right)
5 0 0 0 A R R R R position (right:11-8), A = AV MODE (center "button")
6 R R R R R R R R position (right:7-0)
(left = media player part, right = volume part)
maximum observed pressure was 0x38
Now find the command(s) to control the LEDs...
What's the best way to present these controls to user space?
Process the touch/drag actions in kernel. light up corresponding LEDs and
emit key presses?
--
Ondrej Zary
Re: Sony Vaio VGN-CS31S touch sensor buttons breaking touchpad
On Monday 02 April 2018 22:39:59 Ondrej Zary wrote:
> On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> > Hello,
> > I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that exhibits
> > weird behavior. It seems to work until I touch the "Touch Sensor Buttons"
> > bar above the keyboard - then the buttons start to act weirdly: click or
> > remain pressed (sometimes it breaks even without touching the bar).
> >
> > It seems to be a known problem with VGN-CS series:
> > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+b
> >ug /774877
> > https://wiki.freegeekvancouver.org/article/Laptop_Troubleshooting
> > (mentions nasty partial workaround: psmouse.resetafter=1)
> >
> > Many models of the VGN-CS series have the Touch Sensor Buttons:
> > ftp://124.40.41.224/PUB/MANUALS/SWT/Z009/Z009690111.PDF
> >
> > From the hardware side (can be found in MBX-196 Quanta GD2 schematic),
> > the touch bar is a separate PS/2 device connected to third PS/2 port of
> > the EC (Embedded Controller) WPC775L. The touchpad is on the 1st PS/2
> > port, 2nd port is unused. However, the i8042 does not seem to support
> > multiplexing, the firmware probably combines the data internally somehow.
>
> Good news: it supports multiplexing but i8042_nomux is set because of:
> /*
> * Most (all?) VAIOs do not have external PS/2 ports nor
> * they implement active multiplexing properly, and
> * MUX discovery usually messes up keyboard/touchpad.
> */
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
> DMI_MATCH(DMI_BOARD_NAME, "VAIO"),
> },
> in drivers/input/serio/i8042-x86ia64io.h
> (How can this be modified to exclude VGN-CS series?)
>
> Now only to write the touchbar driver... (seems to be detected at serio2 as
> PS/2 Generic Mouse)
The device acts almost as a synaptics touchpad. The 0x47 magic number (used in
detection) is replaced by 0x43.
The absolute packet format is simple:
BYTE BIT 7 6 5 4 3 2 1 0
1 1 0 Z Z Z Z Z Z pressure (left)
2 0 0 0 0 L L L L position (left:11-8)
3 L L L L L L L L position (left:7-0)
4 1 1 Z Z Z Z Z Z pressure (right)
5 0 0 0 A R R R R position (right:11-8), A = AV MODE (center "button")
6 R R R R R R R R position (right:7-0)
(left = media player part, right = volume part)
maximum observed pressure was 0x38
Now find the command(s) to control the LEDs...
What's the best way to present these controls to user space?
Process the touch/drag actions in kernel. light up corresponding LEDs and
emit key presses?
--
Ondrej Zary
[PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
VAIO machines by the nomux blacklist, the data from touch sensor
buttons and touchpad are combined. The protocol used by the buttons is
probably similar to the touchpad protocol (both are Synaptics) so both
devices get enabled. The controller combines the data, creating a mess
which results in random button clicks, touchpad stopping working and
lost sync error messages:
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: issuing reconnect request
Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
With MUX enabled, touch sensor buttons are detected as separate device
(and left disabled as there's currently no driver), fixing all touchpad
problems.
Signed-off-by: Ondrej Zary <li...@rainbow-software.org>
---
drivers/input/serio/i8042-x86ia64io.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 6cbbdc6e9687..56644c74828c 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -530,6 +530,20 @@ static const struct dmi_system_id __initconst
i8042_dmi_nomux_table[] = {
{ }
};
+static const struct dmi_system_id __initconst i8042_dmi_forcemux_table[] = {
+ {
+ /*
+* Sony Vaio VGN-CS series require MUX or the touch sensor
+* buttons will disturb touchpad operation
+*/
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-CS"),
+ },
+ },
+ { }
+};
+
/*
* On some Asus laptops, just running self tests cause problems.
*/
@@ -1163,6 +1177,9 @@ static int __init i8042_platform_init(void)
if (dmi_check_system(i8042_dmi_nomux_table))
i8042_nomux = true;
+ if (dmi_check_system(i8042_dmi_forcemux_table))
+ i8042_nomux = false;
+
if (dmi_check_system(i8042_dmi_notimeout_table))
i8042_notimeout = true;
--
Ondrej Zary
[PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
VAIO machines by the nomux blacklist, the data from touch sensor
buttons and touchpad are combined. The protocol used by the buttons is
probably similar to the touchpad protocol (both are Synaptics) so both
devices get enabled. The controller combines the data, creating a mess
which results in random button clicks, touchpad stopping working and
lost sync error messages:
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: issuing reconnect request
Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
With MUX enabled, touch sensor buttons are detected as separate device
(and left disabled as there's currently no driver), fixing all touchpad
problems.
Signed-off-by: Ondrej Zary
---
drivers/input/serio/i8042-x86ia64io.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 6cbbdc6e9687..56644c74828c 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -530,6 +530,20 @@ static const struct dmi_system_id __initconst
i8042_dmi_nomux_table[] = {
{ }
};
+static const struct dmi_system_id __initconst i8042_dmi_forcemux_table[] = {
+ {
+ /*
+* Sony Vaio VGN-CS series require MUX or the touch sensor
+* buttons will disturb touchpad operation
+*/
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-CS"),
+ },
+ },
+ { }
+};
+
/*
* On some Asus laptops, just running self tests cause problems.
*/
@@ -1163,6 +1177,9 @@ static int __init i8042_platform_init(void)
if (dmi_check_system(i8042_dmi_nomux_table))
i8042_nomux = true;
+ if (dmi_check_system(i8042_dmi_forcemux_table))
+ i8042_nomux = false;
+
if (dmi_check_system(i8042_dmi_notimeout_table))
i8042_notimeout = true;
--
Ondrej Zary
Re: Sony Vaio VGN-CS31S touch sensor buttons breaking touchpad
On Monday 02 April 2018 23:05:29 Dmitry Torokhov wrote:
> On Mon, Apr 02, 2018 at 10:39:59PM +0200, Ondrej Zary wrote:
> > On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> > > Hello,
> > > I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that
> > > exhibits weird behavior. It seems to work until I touch the "Touch
> > > Sensor Buttons" bar above the keyboard - then the buttons start to act
> > > weirdly: click or remain pressed (sometimes it breaks even without
> > > touching the bar).
> > >
> > > It seems to be a known problem with VGN-CS series:
> > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/
> > >+bug /774877
> > > https://wiki.freegeekvancouver.org/article/Laptop_Troubleshooting
> > > (mentions nasty partial workaround: psmouse.resetafter=1)
> > >
> > > Many models of the VGN-CS series have the Touch Sensor Buttons:
> > > ftp://124.40.41.224/PUB/MANUALS/SWT/Z009/Z009690111.PDF
> > >
> > > From the hardware side (can be found in MBX-196 Quanta GD2 schematic),
> > > the touch bar is a separate PS/2 device connected to third PS/2 port of
> > > the EC (Embedded Controller) WPC775L. The touchpad is on the 1st PS/2
> > > port, 2nd port is unused. However, the i8042 does not seem to support
> > > multiplexing, the firmware probably combines the data internally
> > > somehow.
> >
> > Good news: it supports multiplexing but i8042_nomux is set because of:
> > /*
> > * Most (all?) VAIOs do not have external PS/2 ports nor
> > * they implement active multiplexing properly, and
> > * MUX discovery usually messes up keyboard/touchpad.
> > */
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
> > DMI_MATCH(DMI_BOARD_NAME, "VAIO"),
> > },
> > in drivers/input/serio/i8042-x86ia64io.h
> > (How can this be modified to exclude VGN-CS series?)
>
> I guess we'd need a whitelist for MUXes, because older VAIOs would
> behave really really badly when one tried to probe for active
> multiplexing...
>
> If you enable MUX, does it survive suspend/resume?
Yes, suspends and resumes fine.
(Suspend takes 20-25 seconds after the HDD stops but it's the same regardless
of MUX.)
--
Ondrej Zary
Re: Sony Vaio VGN-CS31S touch sensor buttons breaking touchpad
On Monday 02 April 2018 23:05:29 Dmitry Torokhov wrote:
> On Mon, Apr 02, 2018 at 10:39:59PM +0200, Ondrej Zary wrote:
> > On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> > > Hello,
> > > I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that
> > > exhibits weird behavior. It seems to work until I touch the "Touch
> > > Sensor Buttons" bar above the keyboard - then the buttons start to act
> > > weirdly: click or remain pressed (sometimes it breaks even without
> > > touching the bar).
> > >
> > > It seems to be a known problem with VGN-CS series:
> > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/
> > >+bug /774877
> > > https://wiki.freegeekvancouver.org/article/Laptop_Troubleshooting
> > > (mentions nasty partial workaround: psmouse.resetafter=1)
> > >
> > > Many models of the VGN-CS series have the Touch Sensor Buttons:
> > > ftp://124.40.41.224/PUB/MANUALS/SWT/Z009/Z009690111.PDF
> > >
> > > From the hardware side (can be found in MBX-196 Quanta GD2 schematic),
> > > the touch bar is a separate PS/2 device connected to third PS/2 port of
> > > the EC (Embedded Controller) WPC775L. The touchpad is on the 1st PS/2
> > > port, 2nd port is unused. However, the i8042 does not seem to support
> > > multiplexing, the firmware probably combines the data internally
> > > somehow.
> >
> > Good news: it supports multiplexing but i8042_nomux is set because of:
> > /*
> > * Most (all?) VAIOs do not have external PS/2 ports nor
> > * they implement active multiplexing properly, and
> > * MUX discovery usually messes up keyboard/touchpad.
> > */
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
> > DMI_MATCH(DMI_BOARD_NAME, "VAIO"),
> > },
> > in drivers/input/serio/i8042-x86ia64io.h
> > (How can this be modified to exclude VGN-CS series?)
>
> I guess we'd need a whitelist for MUXes, because older VAIOs would
> behave really really badly when one tried to probe for active
> multiplexing...
>
> If you enable MUX, does it survive suspend/resume?
Yes, suspends and resumes fine.
(Suspend takes 20-25 seconds after the HDD stops but it's the same regardless
of MUX.)
--
Ondrej Zary
Re: Sony Vaio VGN-CS31S touch sensor buttons breaking touchpad
On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> Hello,
> I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that exhibits
> weird behavior. It seems to work until I touch the "Touch Sensor Buttons"
> bar above the keyboard - then the buttons start to act weirdly: click or
> remain pressed (sometimes it breaks even without touching the bar).
>
> It seems to be a known problem with VGN-CS series:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug
>/774877 https://wiki.freegeekvancouver.org/article/Laptop_Troubleshooting
> (mentions nasty partial workaround: psmouse.resetafter=1)
>
> Many models of the VGN-CS series have the Touch Sensor Buttons:
> ftp://124.40.41.224/PUB/MANUALS/SWT/Z009/Z009690111.PDF
>
> From the hardware side (can be found in MBX-196 Quanta GD2 schematic), the
> touch bar is a separate PS/2 device connected to third PS/2 port of the EC
> (Embedded Controller) WPC775L. The touchpad is on the 1st PS/2 port, 2nd
> port is unused. However, the i8042 does not seem to support multiplexing,
> the firmware probably combines the data internally somehow.
Good news: it supports multiplexing but i8042_nomux is set because of:
/*
* Most (all?) VAIOs do not have external PS/2 ports nor
* they implement active multiplexing properly, and
* MUX discovery usually messes up keyboard/touchpad.
*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_BOARD_NAME, "VAIO"),
},
in drivers/input/serio/i8042-x86ia64io.h
(How can this be modified to exclude VGN-CS series?)
dmidecode:
BIOS Information
Vendor: INSYDE
Version: R2060Q2
Release Date: 09/01/2009
ROM Size: 1024 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 20.60
Firmware Revision: 20.60
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Sony Corporation
Product Name: VGN-CS31S_P
Version: C103LR65
Wake-up Type: Power Switch
SKU Number: N/A
Family: N/A
Handle 0x0002, DMI type 2, 10 bytes
Base Board Information
Manufacturer: Sony Corporation
Product Name: VAIO
Version: N/A
Serial Number: N/A
Asset Tag: N/A
Features:
Board is a hosting board
Disabling that allows mux to work! Touchpad now works fine no matter how the
touch bar is touched.
Now only to write the touchbar driver... (seems to be detected at serio2 as
PS/2 Generic Mouse)
Apr 2 22:07:02 test kernel: [0.599056] i8042: PNP: PS/2 Controller
[PNP0303:KBC,PNP0f13:MOUE] at 0x60,0x64 irq 1,12
Apr 2 22:07:02 test kernel: [0.599233] i8042: [0] d1 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599290] i8042: [0] df -> i8042 (parameter)
Apr 2 22:07:02 test kernel: [0.599295] i8042: [0] ff -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599338] i8042: [0] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599449] i8042: [0] ef <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.599502] i8042: [0] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599767] i8042: [0] ef <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.599772] i8042: [0] 60 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599829] i8042: [0] fe -> i8042 (parameter)
Apr 2 22:07:02 test kernel: [0.599942] i8042: [0] d3 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600051] i8042: [0] 5a -> i8042 (parameter)
Apr 2 22:07:02 test kernel: [0.600163] i8042: [0] 5a <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.600166] i8042: [0] a7 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600376] i8042: [0] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600487] i8042: [0] fe <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.600490] i8042: [0] a8 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600545] i8042: [1] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600707] i8042: [1] de <- i8042 (return)
Apr 2 22:07:02 test kernel: [0
Re: Sony Vaio VGN-CS31S touch sensor buttons breaking touchpad
On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> Hello,
> I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that exhibits
> weird behavior. It seems to work until I touch the "Touch Sensor Buttons"
> bar above the keyboard - then the buttons start to act weirdly: click or
> remain pressed (sometimes it breaks even without touching the bar).
>
> It seems to be a known problem with VGN-CS series:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug
>/774877 https://wiki.freegeekvancouver.org/article/Laptop_Troubleshooting
> (mentions nasty partial workaround: psmouse.resetafter=1)
>
> Many models of the VGN-CS series have the Touch Sensor Buttons:
> ftp://124.40.41.224/PUB/MANUALS/SWT/Z009/Z009690111.PDF
>
> From the hardware side (can be found in MBX-196 Quanta GD2 schematic), the
> touch bar is a separate PS/2 device connected to third PS/2 port of the EC
> (Embedded Controller) WPC775L. The touchpad is on the 1st PS/2 port, 2nd
> port is unused. However, the i8042 does not seem to support multiplexing,
> the firmware probably combines the data internally somehow.
Good news: it supports multiplexing but i8042_nomux is set because of:
/*
* Most (all?) VAIOs do not have external PS/2 ports nor
* they implement active multiplexing properly, and
* MUX discovery usually messes up keyboard/touchpad.
*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_BOARD_NAME, "VAIO"),
},
in drivers/input/serio/i8042-x86ia64io.h
(How can this be modified to exclude VGN-CS series?)
dmidecode:
BIOS Information
Vendor: INSYDE
Version: R2060Q2
Release Date: 09/01/2009
ROM Size: 1024 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 20.60
Firmware Revision: 20.60
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Sony Corporation
Product Name: VGN-CS31S_P
Version: C103LR65
Wake-up Type: Power Switch
SKU Number: N/A
Family: N/A
Handle 0x0002, DMI type 2, 10 bytes
Base Board Information
Manufacturer: Sony Corporation
Product Name: VAIO
Version: N/A
Serial Number: N/A
Asset Tag: N/A
Features:
Board is a hosting board
Disabling that allows mux to work! Touchpad now works fine no matter how the
touch bar is touched.
Now only to write the touchbar driver... (seems to be detected at serio2 as
PS/2 Generic Mouse)
Apr 2 22:07:02 test kernel: [0.599056] i8042: PNP: PS/2 Controller
[PNP0303:KBC,PNP0f13:MOUE] at 0x60,0x64 irq 1,12
Apr 2 22:07:02 test kernel: [0.599233] i8042: [0] d1 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599290] i8042: [0] df -> i8042 (parameter)
Apr 2 22:07:02 test kernel: [0.599295] i8042: [0] ff -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599338] i8042: [0] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599449] i8042: [0] ef <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.599502] i8042: [0] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599767] i8042: [0] ef <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.599772] i8042: [0] 60 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.599829] i8042: [0] fe -> i8042 (parameter)
Apr 2 22:07:02 test kernel: [0.599942] i8042: [0] d3 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600051] i8042: [0] 5a -> i8042 (parameter)
Apr 2 22:07:02 test kernel: [0.600163] i8042: [0] 5a <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.600166] i8042: [0] a7 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600376] i8042: [0] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600487] i8042: [0] fe <- i8042 (return)
Apr 2 22:07:02 test kernel: [0.600490] i8042: [0] a8 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600545] i8042: [1] 20 -> i8042 (command)
Apr 2 22:07:02 test kernel: [0.600707] i8042: [1] de <- i8042 (return)
Apr 2 22:07:02 test kernel: [0
Re: [PATCH v3] Fix modifier keys for Redragon Asura Keyboard
On Wednesday 21 March 2018 11:43:31 Robert Munteanu wrote: > +#define USB_VENDOR_ID_MICRODIA 0x0c45 > +#define USB_DEVICE_ID_REDRAGON_ASURA0x760b Microdia is most probably an incorrect name. The 0c45 id probably belongs to "Sonix Technology Co., Ltd." -- Ondrej Zary
Re: [PATCH v3] Fix modifier keys for Redragon Asura Keyboard
On Wednesday 21 March 2018 11:43:31 Robert Munteanu wrote: > +#define USB_VENDOR_ID_MICRODIA 0x0c45 > +#define USB_DEVICE_ID_REDRAGON_ASURA0x760b Microdia is most probably an incorrect name. The 0c45 id probably belongs to "Sonix Technology Co., Ltd." -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018 23:04:40 Ondrej Zary wrote: > On Thursday 15 March 2018 09:04:55 Christoph Hellwig wrote: > > On Thu, Mar 15, 2018 at 09:04:24AM +0100, Ondrej Zary wrote: > > > On Thursday 15 March 2018, Christoph Hellwig wrote: > > > > The paride drivers are some of the cruftiest, grottiest block drivers > > > > (besides drivers/ide and floppy.c) and have seen one single targeted > > > > commit since the dawn of git in 2007. Drop them to make block layer > > > > improvements easier. > > > > > > This will make my parallel port ZIP and LS-120 drives useless :( > > > > So you are still using them and the code actually works properly? > > I don't use them daily, only occasionally. Last time they worked. > Checked now and it seems to work: Forgot that my ZIP drive uses the PPA driver, which seems to work too: # modprobe ppa [ 816.690602] ppa: Version 2.07 (for Linux 2.4.x) [ 816.762167] ppa: Found device at ID 6, Attempting to use EPP 32 bit [ 816.763037] ppa: Communication established with ID 6 using EPP 32 bit [ 816.807658] scsi host4: Iomega VPI0 (ppa) interface [ 816.926616] scsi 4:0:6:0: Direct-Access IOMEGA ZIP 100 D.08 PQ: 0 ANSI: 2 [ 816.987969] sd 4:0:6:0: Attached scsi generic sg1 type 0 [ 817.054564] sd 4:0:6:0: Power-on or device reset occurred [ 817.158623] sd 4:0:6:0: [sdb] Attached SCSI removable disk [ 817.742723] sd 4:0:6:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK [ 817.745168] sd 4:0:6:0: [sdb] tag#0 CDB: ATA command pass through(16) 85 06 20 00 05 00 fe 00 00 00 00 00 00 40 ef 00 [ 839.268575] sd 4:0:6:0: [sdb] Spinning up disk... [ 840.320383] ..ready [ 841.596371] sd 4:0:6:0: [sdb] 196608 512-byte logical blocks: (101 MB/96.0 MiB) [ 842.088415] sdb: sdb4 -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018 23:04:40 Ondrej Zary wrote: > On Thursday 15 March 2018 09:04:55 Christoph Hellwig wrote: > > On Thu, Mar 15, 2018 at 09:04:24AM +0100, Ondrej Zary wrote: > > > On Thursday 15 March 2018, Christoph Hellwig wrote: > > > > The paride drivers are some of the cruftiest, grottiest block drivers > > > > (besides drivers/ide and floppy.c) and have seen one single targeted > > > > commit since the dawn of git in 2007. Drop them to make block layer > > > > improvements easier. > > > > > > This will make my parallel port ZIP and LS-120 drives useless :( > > > > So you are still using them and the code actually works properly? > > I don't use them daily, only occasionally. Last time they worked. > Checked now and it seems to work: Forgot that my ZIP drive uses the PPA driver, which seems to work too: # modprobe ppa [ 816.690602] ppa: Version 2.07 (for Linux 2.4.x) [ 816.762167] ppa: Found device at ID 6, Attempting to use EPP 32 bit [ 816.763037] ppa: Communication established with ID 6 using EPP 32 bit [ 816.807658] scsi host4: Iomega VPI0 (ppa) interface [ 816.926616] scsi 4:0:6:0: Direct-Access IOMEGA ZIP 100 D.08 PQ: 0 ANSI: 2 [ 816.987969] sd 4:0:6:0: Attached scsi generic sg1 type 0 [ 817.054564] sd 4:0:6:0: Power-on or device reset occurred [ 817.158623] sd 4:0:6:0: [sdb] Attached SCSI removable disk [ 817.742723] sd 4:0:6:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK [ 817.745168] sd 4:0:6:0: [sdb] tag#0 CDB: ATA command pass through(16) 85 06 20 00 05 00 fe 00 00 00 00 00 00 40 ef 00 [ 839.268575] sd 4:0:6:0: [sdb] Spinning up disk... [ 840.320383] ..ready [ 841.596371] sd 4:0:6:0: [sdb] 196608 512-byte logical blocks: (101 MB/96.0 MiB) [ 842.088415] sdb: sdb4 -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018 23:04:40 Ondrej Zary wrote: > On Thursday 15 March 2018 09:04:55 Christoph Hellwig wrote: > > On Thu, Mar 15, 2018 at 09:04:24AM +0100, Ondrej Zary wrote: > > > On Thursday 15 March 2018, Christoph Hellwig wrote: > > > > The paride drivers are some of the cruftiest, grottiest block drivers > > > > (besides drivers/ide and floppy.c) and have seen one single targeted > > > > commit since the dawn of git in 2007. Drop them to make block layer > > > > improvements easier. > > > > > > This will make my parallel port ZIP and LS-120 drives useless :( > > > > So you are still using them and the code actually works properly? > > I don't use them daily, only occasionally. Last time they worked. > Checked now and it seems to work: Also found an old CD-ROM drive mounted in a HP C4381A box instead of the long-dead CD Writer 7200. Not as good as the pf driver :) # modprobe epat [ 50.446246] paride: epat registered as protocol 0 # modprobe pcd drive0=0x378,0 [ 56.694140] pcd: pcd version 1.07, major 46, nice 0 [ 56.803399] pcd0: Sharing parport0 at 0x378 [ 56.804336] pcd0: epat 1.02, Shuttle EPAT chip c6 at 0x378, [ 56.804339] mode 5 (EPP-32), delay 1 [ 56.837419] pcd0: Master: 8X CD-ROM V1.0 [ 56.839420] pcd0: mode sense capabilities completion: alt=0x51 stat=0x51 err=0x60 loop=0 phase=3 [ 56.842259] pcd0: mode sense capabilities: Sense key: 6, ASC: 29, ASQ: 0 [ 56.843149] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 56.843757] BUG: unable to handle kernel paging request at f0b6a334 [ 56.844371] IP: register_cdrom+0x85/0x185 [cdrom] [ 56.844971] *pde = 2f564067 *pte = 2c343161 [ 56.845692] Oops: 0003 [#1] SMP [ 56.846564] Modules linked in: pcd(+) cdrom epat paride i2c_dev nouveau sg parport_pc 8139cp wmi hwmon ttm parport intel_agp [ 56.847467] CPU: 0 PID: 1790 Comm: modprobe Not tainted 4.16.0-rc4+ #217 [ 56.848340] Hardware name: /848P-ICH5, BIOS 6.00 PG 02/03/2005 [ 56.849275] EIP: register_cdrom+0x85/0x185 [cdrom] [ 56.850190] EFLAGS: 00010246 CPU: 0 [ 56.851104] EAX: f0b61155 EBX: f0b6a300 ECX: ef992164 EDX: ef98c9cc [ 56.852029] ESI: f0b6bb80 EDI: ec351dfc EBP: ec351de4 ESP: ec351dd8 [ 56.852961] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 56.853895] CR0: 80050033 CR2: f0b6a334 CR3: 2c22d000 CR4: 0690 [ 56.854832] Call Trace: [ 56.855764] pcd_init+0x37e/0x1000 [pcd] [ 56.856692] ? _raw_spin_trylock_bh+0x1d/0x3a [ 56.857615] ? __switch_to_asm+0x26/0x40 [ 56.858541] ? __switch_to_asm+0x1a/0x40 [ 56.859442] ? __switch_to_asm+0x26/0x40 [ 56.860334] ? 0xf0b6e000 [ 56.861172] do_one_initcall+0x84/0x111 [ 56.862074] ? __schedule+0x38f/0x3dd [ 56.862990] ? virt_to_head_page+0x19/0x1b [ 56.863883] ? virt_to_head_page+0x19/0x1b [ 56.864768] ? _cond_resched+0x1e/0x22 [ 56.865626] ? kmem_cache_alloc+0x86/0xa9 [ 56.866486] ? do_init_module+0x17/0x1ad [ 56.867333] do_init_module+0x46/0x1ad [ 56.868164] load_module+0x1708/0x1b23 [ 56.868997] ? kernel_read_file+0x116/0x143 [ 56.869820] SyS_finit_module+0x62/0x67 [ 56.870648] do_int80_syscall_32+0x50/0x62 [ 56.871477] entry_INT80_32+0x2a/0x2a [ 56.872308] EIP: 0xb7fd6a02 [ 56.873134] EFLAGS: 0292 CPU: 0 [ 56.873951] EAX: ffda EBX: 0004 ECX: 007aff18 EDX: [ 56.874749] ESI: 007b0278 EDI: 007aff90 EBP: ESP: bffbbac8 [ 56.875590] DS: 007b ES: 007b FS: GS: 0033 SS: 007b [ 56.876431] Code: 0c 00 75 0d 83 7b 10 00 75 07 c7 43 34 6f ff ff ff 83 7b 14 00 75 04 83 63 34 fc 83 7b 18 00 75 04 83 63 34 fb 83 7b 1c 00 75 04 <83> 63 34 f7 83 7b 24 00 75 04 83 63 34 df 83 7b 28 00 75 04 83 [ 56.878264] EIP: register_cdrom+0x85/0x185 [cdrom] SS:ESP: 0068:ec351dd8 [ 56.879220] CR2: f0b6a334 [ 56.880193] ---[ end trace 596e4157e238f0e3 ]--- -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018 23:04:40 Ondrej Zary wrote: > On Thursday 15 March 2018 09:04:55 Christoph Hellwig wrote: > > On Thu, Mar 15, 2018 at 09:04:24AM +0100, Ondrej Zary wrote: > > > On Thursday 15 March 2018, Christoph Hellwig wrote: > > > > The paride drivers are some of the cruftiest, grottiest block drivers > > > > (besides drivers/ide and floppy.c) and have seen one single targeted > > > > commit since the dawn of git in 2007. Drop them to make block layer > > > > improvements easier. > > > > > > This will make my parallel port ZIP and LS-120 drives useless :( > > > > So you are still using them and the code actually works properly? > > I don't use them daily, only occasionally. Last time they worked. > Checked now and it seems to work: Also found an old CD-ROM drive mounted in a HP C4381A box instead of the long-dead CD Writer 7200. Not as good as the pf driver :) # modprobe epat [ 50.446246] paride: epat registered as protocol 0 # modprobe pcd drive0=0x378,0 [ 56.694140] pcd: pcd version 1.07, major 46, nice 0 [ 56.803399] pcd0: Sharing parport0 at 0x378 [ 56.804336] pcd0: epat 1.02, Shuttle EPAT chip c6 at 0x378, [ 56.804339] mode 5 (EPP-32), delay 1 [ 56.837419] pcd0: Master: 8X CD-ROM V1.0 [ 56.839420] pcd0: mode sense capabilities completion: alt=0x51 stat=0x51 err=0x60 loop=0 phase=3 [ 56.842259] pcd0: mode sense capabilities: Sense key: 6, ASC: 29, ASQ: 0 [ 56.843149] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 56.843757] BUG: unable to handle kernel paging request at f0b6a334 [ 56.844371] IP: register_cdrom+0x85/0x185 [cdrom] [ 56.844971] *pde = 2f564067 *pte = 2c343161 [ 56.845692] Oops: 0003 [#1] SMP [ 56.846564] Modules linked in: pcd(+) cdrom epat paride i2c_dev nouveau sg parport_pc 8139cp wmi hwmon ttm parport intel_agp [ 56.847467] CPU: 0 PID: 1790 Comm: modprobe Not tainted 4.16.0-rc4+ #217 [ 56.848340] Hardware name: /848P-ICH5, BIOS 6.00 PG 02/03/2005 [ 56.849275] EIP: register_cdrom+0x85/0x185 [cdrom] [ 56.850190] EFLAGS: 00010246 CPU: 0 [ 56.851104] EAX: f0b61155 EBX: f0b6a300 ECX: ef992164 EDX: ef98c9cc [ 56.852029] ESI: f0b6bb80 EDI: ec351dfc EBP: ec351de4 ESP: ec351dd8 [ 56.852961] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 56.853895] CR0: 80050033 CR2: f0b6a334 CR3: 2c22d000 CR4: 0690 [ 56.854832] Call Trace: [ 56.855764] pcd_init+0x37e/0x1000 [pcd] [ 56.856692] ? _raw_spin_trylock_bh+0x1d/0x3a [ 56.857615] ? __switch_to_asm+0x26/0x40 [ 56.858541] ? __switch_to_asm+0x1a/0x40 [ 56.859442] ? __switch_to_asm+0x26/0x40 [ 56.860334] ? 0xf0b6e000 [ 56.861172] do_one_initcall+0x84/0x111 [ 56.862074] ? __schedule+0x38f/0x3dd [ 56.862990] ? virt_to_head_page+0x19/0x1b [ 56.863883] ? virt_to_head_page+0x19/0x1b [ 56.864768] ? _cond_resched+0x1e/0x22 [ 56.865626] ? kmem_cache_alloc+0x86/0xa9 [ 56.866486] ? do_init_module+0x17/0x1ad [ 56.867333] do_init_module+0x46/0x1ad [ 56.868164] load_module+0x1708/0x1b23 [ 56.868997] ? kernel_read_file+0x116/0x143 [ 56.869820] SyS_finit_module+0x62/0x67 [ 56.870648] do_int80_syscall_32+0x50/0x62 [ 56.871477] entry_INT80_32+0x2a/0x2a [ 56.872308] EIP: 0xb7fd6a02 [ 56.873134] EFLAGS: 0292 CPU: 0 [ 56.873951] EAX: ffda EBX: 0004 ECX: 007aff18 EDX: [ 56.874749] ESI: 007b0278 EDI: 007aff90 EBP: ESP: bffbbac8 [ 56.875590] DS: 007b ES: 007b FS: GS: 0033 SS: 007b [ 56.876431] Code: 0c 00 75 0d 83 7b 10 00 75 07 c7 43 34 6f ff ff ff 83 7b 14 00 75 04 83 63 34 fc 83 7b 18 00 75 04 83 63 34 fb 83 7b 1c 00 75 04 <83> 63 34 f7 83 7b 24 00 75 04 83 63 34 df 83 7b 28 00 75 04 83 [ 56.878264] EIP: register_cdrom+0x85/0x185 [cdrom] SS:ESP: 0068:ec351dd8 [ 56.879220] CR2: f0b6a334 [ 56.880193] ---[ end trace 596e4157e238f0e3 ]--- -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018 09:04:55 Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 09:04:24AM +0100, Ondrej Zary wrote: > > On Thursday 15 March 2018, Christoph Hellwig wrote: > > > The paride drivers are some of the cruftiest, grottiest block drivers > > > (besides drivers/ide and floppy.c) and have seen one single targeted > > > commit since the dawn of git in 2007. Drop them to make block layer > > > improvements easier. > > > > This will make my parallel port ZIP and LS-120 drives useless :( > > So you are still using them and the code actually works properly? I don't use them daily, only occasionally. Last time they worked. Checked now and it seems to work: [0.00] Linux version 4.16.0-rc4+ (zary@gsql) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #217 SMP Tue Mar 13 00:08:16 CET 2018 ... # modprobe epat [ 47.376762] paride: epat registered as protocol 0 # modprobe pf drive0=0x378,0 [ 59.048408] pf: pf version 1.04, major 47, cluster 64, nice 0 [ 59.156038] pf0: Sharing parport0 at 0x378 [ 59.157017] pf0: epat 1.02, Shuttle EPAT chip c6 at 0x378, [ 59.157020] mode 5 (EPP-32), delay 1 [ 59.187400] pf0: mode sense completion: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 59.188080] pf0: mode sense data done: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 59.190648] pf0: Sense key: 6, ASC: 29, ASQ: 0 [ 59.196326] pf0: get capacity completion: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.197038] pf0: get capacity data done: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.199499] pf0: Sense key: 2, ASC: 3a, ASQ: 0 [ 59.200108] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 59.200109] , removable [ 59.200745] , no media [ 59.219353] pf0: get capacity completion: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.220078] pf0: get capacity data done: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.222777] pf0: Sense key: 2, ASC: 3a, ASQ: 0 [ 59.223419] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 59.223420] , removable [ 59.224042] , no media # mount /dev/pf0 /media/floppy [ 89.255905] pf0: mode sense completion: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 89.256657] pf0: mode sense data done: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 89.259415] pf0: Sense key: 6, ASC: 28, ASQ: 0 [ 89.265571] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 89.265573] , removable [ 89.266228] , RO [ 89.266871] , 246528 blocks [ 96.871316] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 96.871319] , removable [ 96.871998] , RO [ 96.872653] , 246528 blocks [ 96.888131] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 96.888134] , removable [ 96.08] , RO [ 96.889479] , 246528 blocks mount: /dev/pf0 is write-protected, mounting read-only # ls -la /media/floppy/ total 356 drwxr-xr-x 9 root root 2048 Jun 11 2002 drwxr-xr-x 6 root root 16384 Jan 1 1970 . drwxr-xr-x 6 root root 4096 Sep 16 2015 .. -rwxr-xr-x 1 root root750 Nov 8 2007 auditsc-move-name-to-end-of-record.patch -rwxr-xr-x 1 root root638 Nov 8 2007 audit-send-netlink-sync.patch -rwxr-xr-x 1 root root 5557 Nov 8 2007 cdu31a_interrupt_handling_new.patch -rwxr-xr-x 1 root root 4317 Nov 8 2007 cdu31a_interrupt_handling.patch -rwxr-xr-x 1 root root 51440 Nov 8 2007 cdu31a-locking-dd.patch -rwxr-xr-x 1 root root 48769 Nov 8 2007 cdu31a-locking.patch -rwxr-xr-x 1 root root 19470 Nov 8 2007 cdu31a-make-working.patch -rwxr-xr-x 1 root root899 Nov 8 2007 cdu31a-timeouts-fix.patch -rwxr-xr-x 1 root root 36067 Nov 8 2007 cdu31a_trivial_cleanups.patch -rwxr-xr-x 1 root root 19278 Nov 8 2007 cdu31a_use_semaphores.patch -rwxr-xr-x 1 root root462 Nov 8 2007 cyrix-math-new.patch -rwxr-xr-x 1 root root530 Nov 8 2007 cyrix-math.patch -rwxr-xr-x 1 root root391 Nov 8 2007 cyrix-new.patch -rwxr-xr-x 1 root root 1468 Nov 8 2007 cyrix-test.patch drwxr-xr-x 2 root root 2048 Jun 5 2002 DEUTSCH drwxr-xr-x 2 root root 2048 Jun 5 2002 ENGLISH drwxr-xr-x 2 root root 2048 Jun 5 2002 FRAN?AIS -rwxr-xr-x 1 root root490 Nov 8 2007 hz100.patch -rwxr-xr-x 1 root root796 Nov 8 2007 ide-floppy-eject.patch -rwxr-xr-x 1 root root 1655 Nov 8 2007 pf-fix-excess-reconnects.patch -rwxr-xr-x 1 root root561 Nov 8 2007 sata_via_pata_dma_fix.patch -rwxr-xr-x 1 root root 04 Sep 26 1997 SETUP.EXE -rwxr-xr-x 1 root root643 Nov 8 2007 uncompressed-kernel-boot.patch -rwxr-xr-x 1 root root455 Nov 8 2007 uncompressed-kernel-make.patch -rwxr-xr-x 1 root root 1098 Nov 8 2007 uncompressed-kernel.patch -rwxr-xr-x 1 root root 1558 Nov 8 2007 usbtouchscreen-invert.patch -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018 09:04:55 Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 09:04:24AM +0100, Ondrej Zary wrote: > > On Thursday 15 March 2018, Christoph Hellwig wrote: > > > The paride drivers are some of the cruftiest, grottiest block drivers > > > (besides drivers/ide and floppy.c) and have seen one single targeted > > > commit since the dawn of git in 2007. Drop them to make block layer > > > improvements easier. > > > > This will make my parallel port ZIP and LS-120 drives useless :( > > So you are still using them and the code actually works properly? I don't use them daily, only occasionally. Last time they worked. Checked now and it seems to work: [0.00] Linux version 4.16.0-rc4+ (zary@gsql) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #217 SMP Tue Mar 13 00:08:16 CET 2018 ... # modprobe epat [ 47.376762] paride: epat registered as protocol 0 # modprobe pf drive0=0x378,0 [ 59.048408] pf: pf version 1.04, major 47, cluster 64, nice 0 [ 59.156038] pf0: Sharing parport0 at 0x378 [ 59.157017] pf0: epat 1.02, Shuttle EPAT chip c6 at 0x378, [ 59.157020] mode 5 (EPP-32), delay 1 [ 59.187400] pf0: mode sense completion: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 59.188080] pf0: mode sense data done: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 59.190648] pf0: Sense key: 6, ASC: 29, ASQ: 0 [ 59.196326] pf0: get capacity completion: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.197038] pf0: get capacity data done: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.199499] pf0: Sense key: 2, ASC: 3a, ASQ: 0 [ 59.200108] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 59.200109] , removable [ 59.200745] , no media [ 59.219353] pf0: get capacity completion: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.220078] pf0: get capacity data done: alt=0x51 stat=0x51 err=0x24 loop=0 phase=3 [ 59.222777] pf0: Sense key: 2, ASC: 3a, ASQ: 0 [ 59.223419] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 59.223420] , removable [ 59.224042] , no media # mount /dev/pf0 /media/floppy [ 89.255905] pf0: mode sense completion: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 89.256657] pf0: mode sense data done: alt=0x51 stat=0x51 err=0x64 loop=0 phase=3 [ 89.259415] pf0: Sense key: 6, ASC: 28, ASQ: 0 [ 89.265571] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 89.265573] , removable [ 89.266228] , RO [ 89.266871] , 246528 blocks [ 96.871316] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 96.871319] , removable [ 96.871998] , RO [ 96.872653] , 246528 blocks [ 96.888131] pf0: MATSHITA LS-120 COSM 04, master LUN 0, type 0 [ 96.888134] , removable [ 96.08] , RO [ 96.889479] , 246528 blocks mount: /dev/pf0 is write-protected, mounting read-only # ls -la /media/floppy/ total 356 drwxr-xr-x 9 root root 2048 Jun 11 2002 drwxr-xr-x 6 root root 16384 Jan 1 1970 . drwxr-xr-x 6 root root 4096 Sep 16 2015 .. -rwxr-xr-x 1 root root750 Nov 8 2007 auditsc-move-name-to-end-of-record.patch -rwxr-xr-x 1 root root638 Nov 8 2007 audit-send-netlink-sync.patch -rwxr-xr-x 1 root root 5557 Nov 8 2007 cdu31a_interrupt_handling_new.patch -rwxr-xr-x 1 root root 4317 Nov 8 2007 cdu31a_interrupt_handling.patch -rwxr-xr-x 1 root root 51440 Nov 8 2007 cdu31a-locking-dd.patch -rwxr-xr-x 1 root root 48769 Nov 8 2007 cdu31a-locking.patch -rwxr-xr-x 1 root root 19470 Nov 8 2007 cdu31a-make-working.patch -rwxr-xr-x 1 root root899 Nov 8 2007 cdu31a-timeouts-fix.patch -rwxr-xr-x 1 root root 36067 Nov 8 2007 cdu31a_trivial_cleanups.patch -rwxr-xr-x 1 root root 19278 Nov 8 2007 cdu31a_use_semaphores.patch -rwxr-xr-x 1 root root462 Nov 8 2007 cyrix-math-new.patch -rwxr-xr-x 1 root root530 Nov 8 2007 cyrix-math.patch -rwxr-xr-x 1 root root391 Nov 8 2007 cyrix-new.patch -rwxr-xr-x 1 root root 1468 Nov 8 2007 cyrix-test.patch drwxr-xr-x 2 root root 2048 Jun 5 2002 DEUTSCH drwxr-xr-x 2 root root 2048 Jun 5 2002 ENGLISH drwxr-xr-x 2 root root 2048 Jun 5 2002 FRAN?AIS -rwxr-xr-x 1 root root490 Nov 8 2007 hz100.patch -rwxr-xr-x 1 root root796 Nov 8 2007 ide-floppy-eject.patch -rwxr-xr-x 1 root root 1655 Nov 8 2007 pf-fix-excess-reconnects.patch -rwxr-xr-x 1 root root561 Nov 8 2007 sata_via_pata_dma_fix.patch -rwxr-xr-x 1 root root 04 Sep 26 1997 SETUP.EXE -rwxr-xr-x 1 root root643 Nov 8 2007 uncompressed-kernel-boot.patch -rwxr-xr-x 1 root root455 Nov 8 2007 uncompressed-kernel-make.patch -rwxr-xr-x 1 root root 1098 Nov 8 2007 uncompressed-kernel.patch -rwxr-xr-x 1 root root 1558 Nov 8 2007 usbtouchscreen-invert.patch -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018, Christoph Hellwig wrote: > The paride drivers are some of the cruftiest, grottiest block drivers > (besides drivers/ide and floppy.c) and have seen one single targeted > commit since the dawn of git in 2007. Drop them to make block layer > improvements easier. This will make my parallel port ZIP and LS-120 drives useless :( -- Ondrej Zary
Re: [PATCH, RFC] block: remove the paride drivers
On Thursday 15 March 2018, Christoph Hellwig wrote: > The paride drivers are some of the cruftiest, grottiest block drivers > (besides drivers/ide and floppy.c) and have seen one single targeted > commit since the dawn of git in 2007. Drop them to make block layer > improvements easier. This will make my parallel port ZIP and LS-120 drives useless :( -- Ondrej Zary
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Thursday 08 February 2018, tedheadster wrote: > On Thu, Feb 8, 2018 at 12:02 PM, David Laight <david.lai...@aculab.com> wrote: > > From: Arnd Bergmann > > > >> Sent: 08 February 2018 15:23 > > > > ... > > > >> The Winchip is what eventually turned into the VIA Nano, which does > >> have speculative execution, but I don't think the earlier C3 and C7 did, > >> they are much closer to the original Winchip design. > > > > We had terrible trouble getting (IIRC) the C7 to execute functions > > that were called in 16bit mode and returned in 32bit mode and v.v. > > (for boot code bios calls). > > The problems seemed to imply that it was caching return addresses > > and the translation (to uops) of the instructions that followed. > > So it would effectively decode the first few bytes in the wrong mode. > > So there might be scope for one of these attacks. > > > > OTOH these devices were so slow that I doubt any are used for anything > > serious - and certainly won't get a kernel update even if they are. > > > > Also worth nothing that the difference between the cpu and memory > > speeds is much lower - so far fewer instructions could be speculatively > > executed while waiting a cache miss. > > > > Tempting to disable everything. > > > > David > > You might think this absolutely crazy, but I would be willing to test > such systems if I can get my hands on the needed hardware that I lack. > I am already doing sanity testing on Intel > i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the > clone cpus (Cyrix, etc). > > While few people are using the 32bit kernel, I don't think we want to > kill it completely just yet. > > - Matthew I have a working Cyrix MII (was actively using it last year, now upgraded to a P3-based Celeron). Some AMD CPUs too - K6(maybe -2 or -3?), not sure about K5 and also a Rise mP6. But never got a WinChip. So the question is: what to test? BTW. Kernel was not able to identify mP6 CPU 6 years ago, patches were ignored. -- Ondrej Zary
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Thursday 08 February 2018, tedheadster wrote: > On Thu, Feb 8, 2018 at 12:02 PM, David Laight wrote: > > From: Arnd Bergmann > > > >> Sent: 08 February 2018 15:23 > > > > ... > > > >> The Winchip is what eventually turned into the VIA Nano, which does > >> have speculative execution, but I don't think the earlier C3 and C7 did, > >> they are much closer to the original Winchip design. > > > > We had terrible trouble getting (IIRC) the C7 to execute functions > > that were called in 16bit mode and returned in 32bit mode and v.v. > > (for boot code bios calls). > > The problems seemed to imply that it was caching return addresses > > and the translation (to uops) of the instructions that followed. > > So it would effectively decode the first few bytes in the wrong mode. > > So there might be scope for one of these attacks. > > > > OTOH these devices were so slow that I doubt any are used for anything > > serious - and certainly won't get a kernel update even if they are. > > > > Also worth nothing that the difference between the cpu and memory > > speeds is much lower - so far fewer instructions could be speculatively > > executed while waiting a cache miss. > > > > Tempting to disable everything. > > > > David > > You might think this absolutely crazy, but I would be willing to test > such systems if I can get my hands on the needed hardware that I lack. > I am already doing sanity testing on Intel > i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the > clone cpus (Cyrix, etc). > > While few people are using the 32bit kernel, I don't think we want to > kill it completely just yet. > > - Matthew I have a working Cyrix MII (was actively using it last year, now upgraded to a P3-based Celeron). Some AMD CPUs too - K6(maybe -2 or -3?), not sure about K5 and also a Rise mP6. But never got a WinChip. So the question is: what to test? BTW. Kernel was not able to identify mP6 CPU 6 years ago, patches were ignored. -- Ondrej Zary
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Tuesday 06 February 2018, tedheadster wrote:
> On Tue, Feb 6, 2018 at 3:54 PM, David Woodhouse <dw...@infradead.org> wrote:
> > On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
> >> If that is correct (and I might be wrong), then I am up to date and I
> >> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
> >>
> >> bugs : cpu_meltdown spectre_v1 spectre_v2
> >
> > That's expected for now. The CPUs we exempt are as follows:
> >
> > static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
> > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL,
> >X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6,
> > INTEL_FAM6_ATOM_PINEVIEW,X86_FEATURE_ANY }, { X86_VENDOR_CENTAUR, 5
> > },
> > { X86_VENDOR_INTEL, 5 },
> > { X86_VENDOR_NSC, 5 },
> > { X86_VENDOR_ANY, 4 },
> > {}
> > };
> >
> > Alan is going to improve that list, but your Pentium 4 isn't on it yet.
> >
> > The bugs went away on the 486 though, right?
>
> Okay, recompiled for the i486 and it reports no bugs.
>
> As for the i686, it is really a "Mobile Pentium 4 HT" Prescott series
> (https://ark.intel.com/products/27368/Mobile-Intel-Pentium-4-Processor-532-
>supporting-HT-Technology-1M-Cache-3_06-GHz-533-MHz-FSB). Does that make it a
> 'speculative execution' processor?
>
> Thank you for the help and I'll test more of the museum pieces.
>
> - Matthew
What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
MMX). I've tried a spectre test before and it wasn't reading anything useful.
Don't know about meltdown. Is there a complete test program? (The web is so
full of crap that even google can't find anything useful.)
--
Ondrej Zary
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Tuesday 06 February 2018, tedheadster wrote:
> On Tue, Feb 6, 2018 at 3:54 PM, David Woodhouse wrote:
> > On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
> >> If that is correct (and I might be wrong), then I am up to date and I
> >> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
> >>
> >> bugs : cpu_meltdown spectre_v1 spectre_v2
> >
> > That's expected for now. The CPUs we exempt are as follows:
> >
> > static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
> > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL,
> >X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6,
> > INTEL_FAM6_ATOM_PINEVIEW,X86_FEATURE_ANY }, { X86_VENDOR_CENTAUR, 5
> > },
> > { X86_VENDOR_INTEL, 5 },
> > { X86_VENDOR_NSC, 5 },
> > { X86_VENDOR_ANY, 4 },
> > {}
> > };
> >
> > Alan is going to improve that list, but your Pentium 4 isn't on it yet.
> >
> > The bugs went away on the 486 though, right?
>
> Okay, recompiled for the i486 and it reports no bugs.
>
> As for the i686, it is really a "Mobile Pentium 4 HT" Prescott series
> (https://ark.intel.com/products/27368/Mobile-Intel-Pentium-4-Processor-532-
>supporting-HT-Technology-1M-Cache-3_06-GHz-533-MHz-FSB). Does that make it a
> 'speculative execution' processor?
>
> Thank you for the help and I'll test more of the museum pieces.
>
> - Matthew
What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
MMX). I've tried a spectre test before and it wasn't reading anything useful.
Don't know about meltdown. Is there a complete test program? (The web is so
full of crap that even google can't find anything useful.)
--
Ondrej Zary
Re: [alsa-devel] ALSA: nm256: Fine-tuning for three function implementations
On Tuesday 28 November 2017, SF Markus Elfring wrote: > >>>> There is a general source code transformation pattern involved. > >>>> So I find that it is systematic. > >>>> > >>>> But I did not dare to develop a script variant for the semantic patch > >>>> language (Coccinelle software) which can handle all special use cases > >>>> as a few of them are already demonstrated in this tiny patch series. > >>> > >>> Then you're doing everything by hands, > >> > >> I am navigating through possible changes around the pattern > >> “Use common error handling code” mostly manually so far. > >> > >>> and can be wrong > >> > >> Such a possibility remains as usual. > > > > "As usual" doesn't suffice. > > There can be additional means be used to reduce the probability > of undesired side effects. > > > It must be "almost perfect" for such a code refactoring. > > Can you get the impression that the shown transformation patterns were > correctly applied for the source file “sound/pci/nm256/nm256.c”? Have you tested the driver? Probably not. Please don't "improve" working drivers unless you have the hardware to test your changes. Patches like this are known to cause regressions. If the hardware is rare (like the NM256), the regression can hit years later when someone with such HW upgrades distro (e.g. Debian stable). -- Ondrej Zary
Re: [alsa-devel] ALSA: nm256: Fine-tuning for three function implementations
On Tuesday 28 November 2017, SF Markus Elfring wrote: > >>>> There is a general source code transformation pattern involved. > >>>> So I find that it is systematic. > >>>> > >>>> But I did not dare to develop a script variant for the semantic patch > >>>> language (Coccinelle software) which can handle all special use cases > >>>> as a few of them are already demonstrated in this tiny patch series. > >>> > >>> Then you're doing everything by hands, > >> > >> I am navigating through possible changes around the pattern > >> “Use common error handling code” mostly manually so far. > >> > >>> and can be wrong > >> > >> Such a possibility remains as usual. > > > > "As usual" doesn't suffice. > > There can be additional means be used to reduce the probability > of undesired side effects. > > > It must be "almost perfect" for such a code refactoring. > > Can you get the impression that the shown transformation patterns were > correctly applied for the source file “sound/pci/nm256/nm256.c”? Have you tested the driver? Probably not. Please don't "improve" working drivers unless you have the hardware to test your changes. Patches like this are known to cause regressions. If the hardware is rare (like the NM256), the regression can hit years later when someone with such HW upgrades distro (e.g. Debian stable). -- Ondrej Zary
Re: Blank console but X11 works on MCP79 - old regression since 3.8
On Friday 17 November 2017 20:52:45 Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> wrote: > >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: > >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary > >>> > >>> <li...@rainbow-software.org> wrote: > >>> > @@ -483,8 +483,8 @@ > >>> > nouveau :02:00.0: disp:0860: -> 0500 > >>> > nouveau :02:00.0: disp:0864: > >>> > nouveau :02:00.0: disp:0868: -> 04000500 > >>> > -nouveau :02:00.0: disp:086c: -> 00100500 > >>> > -nouveau :02:00.0: disp:0870: e900 -> 1e00 > >>> > +nouveau :02:00.0: disp:086c: -> 00100a00 > >>> > +nouveau :02:00.0: disp:0870: e900 -> e800 > >>> > nouveau :02:00.0: disp:0874: -> > >>> > nouveau :02:00.0: disp:0878: > >>> > nouveau :02:00.0: disp:0880: 0500 > >>> > > >>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) > >>> > in 64MB case. Why? > >>> > > >>> > I get blank screen even with 64MB with video=1280x1024-8 kernel > >>> > parameter. Console works with video=1280x1024-16 even with 32MB > >>> > stolen memory. > >>> > > >>> > Conclusions: 8-bit support is broken and bpp reduction is weird. > >>> > >>> OK, well that makes a *ton* of sense (8bpp being broken). > >>> > >>> I think the idea of bpp reduction is that when you're on your shiny > >>> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating > >>> all that to a pinned fbcon - almost half of that would go to a single > >>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to > >>> have at least a few fb-sized buffers for backbuffer rendering, etc. > >>> > >>> The specific limits could probably use tweaking - I think they only > >>> consider VRAM size, not the fb size. > >>> > >>> I guess 8bpp worked prior to the change you bisected though, so we > >>> should figure out what we did wrong in the new code. > >> > >> Yes, booted 3.7 (last working kernel) and it's running in 8bpp. > > > > By the way, instead of booting $kernel, you can use modetest from > > libdrm/tests. Not sure if it supports C8 though =/ > > > > I think the issue is this: > > > > - OUT_RING(evo, nv_crtc->lut.depth == 8 ? > > - NV50_EVO_CRTC_CLUT_MODE_OFF : > > - NV50_EVO_CRTC_CLUT_MODE_ON); > > > > Whereas now we always set 0xC000 (aka "ON"). > Changing that to 0x8000 does not help :( > In case I was being unclear, I'm talking about > > https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L >1808 > > and surrounding items. Looks like lut_clr sets 0x4000 which was > previously not used. Not sure what the difference between that and > 0x is. This is what we have in rnndb for it: lut_clr is not called during boot so we can ignore it for now. > https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml >#L408 > > So bit 30 is mode, set is "high res", unset is "low res". So really > what we want is 0x8000 which leaves the LUT enabled but uses the > low-res mode? > > All this could use some playing-around with. > > -ilia -- Ondrej Zary
Re: Blank console but X11 works on MCP79 - old regression since 3.8
On Friday 17 November 2017 20:52:45 Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote: > > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary wrote: > >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: > >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary > >>> > >>> wrote: > >>> > @@ -483,8 +483,8 @@ > >>> > nouveau :02:00.0: disp:0860: -> 0500 > >>> > nouveau :02:00.0: disp:0864: > >>> > nouveau :02:00.0: disp:0868: -> 04000500 > >>> > -nouveau :02:00.0: disp:086c: -> 00100500 > >>> > -nouveau :02:00.0: disp:0870: e900 -> 1e00 > >>> > +nouveau :02:00.0: disp:086c: -> 00100a00 > >>> > +nouveau :02:00.0: disp:0870: e900 -> e800 > >>> > nouveau :02:00.0: disp:0874: -> > >>> > nouveau :02:00.0: disp:0878: > >>> > nouveau :02:00.0: disp:0880: 0500 > >>> > > >>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) > >>> > in 64MB case. Why? > >>> > > >>> > I get blank screen even with 64MB with video=1280x1024-8 kernel > >>> > parameter. Console works with video=1280x1024-16 even with 32MB > >>> > stolen memory. > >>> > > >>> > Conclusions: 8-bit support is broken and bpp reduction is weird. > >>> > >>> OK, well that makes a *ton* of sense (8bpp being broken). > >>> > >>> I think the idea of bpp reduction is that when you're on your shiny > >>> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating > >>> all that to a pinned fbcon - almost half of that would go to a single > >>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to > >>> have at least a few fb-sized buffers for backbuffer rendering, etc. > >>> > >>> The specific limits could probably use tweaking - I think they only > >>> consider VRAM size, not the fb size. > >>> > >>> I guess 8bpp worked prior to the change you bisected though, so we > >>> should figure out what we did wrong in the new code. > >> > >> Yes, booted 3.7 (last working kernel) and it's running in 8bpp. > > > > By the way, instead of booting $kernel, you can use modetest from > > libdrm/tests. Not sure if it supports C8 though =/ > > > > I think the issue is this: > > > > - OUT_RING(evo, nv_crtc->lut.depth == 8 ? > > - NV50_EVO_CRTC_CLUT_MODE_OFF : > > - NV50_EVO_CRTC_CLUT_MODE_ON); > > > > Whereas now we always set 0xC000 (aka "ON"). > Changing that to 0x8000 does not help :( > In case I was being unclear, I'm talking about > > https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L >1808 > > and surrounding items. Looks like lut_clr sets 0x4000 which was > previously not used. Not sure what the difference between that and > 0x is. This is what we have in rnndb for it: lut_clr is not called during boot so we can ignore it for now. > https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml >#L408 > > So bit 30 is mode, set is "high res", unset is "low res". So really > what we want is 0x8000 which leaves the LUT enabled but uses the > low-res mode? > > All this could use some playing-around with. > > -ilia -- Ondrej Zary
Re: Blank console but X11 works on MCP79 - old regression since 3.8
On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>
> <li...@rainbow-software.org> wrote:
> > @@ -483,8 +483,8 @@
> > nouveau :02:00.0: disp:0860: -> 0500
> > nouveau :02:00.0: disp:0864:
> > nouveau :02:00.0: disp:0868: -> 04000500
> > -nouveau :02:00.0: disp:086c: -> 00100500
> > -nouveau :02:00.0: disp:0870: e900 -> 1e00
> > +nouveau :02:00.0: disp:086c: -> 00100a00
> > +nouveau :02:00.0: disp:0870: e900 -> e800
> > nouveau :02:00.0: disp:0874: ->
> > nouveau :02:00.0: disp:0878:
> > nouveau :02:00.0: disp:0880: 0500
> >
> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in
> > 64MB case. Why?
> >
> > I get blank screen even with 64MB with video=1280x1024-8 kernel
> > parameter. Console works with video=1280x1024-16 even with 32MB stolen
> > memory.
> >
> > Conclusions: 8-bit support is broken and bpp reduction is weird.
>
> OK, well that makes a *ton* of sense (8bpp being broken).
>
> I think the idea of bpp reduction is that when you're on your shiny
> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating
> all that to a pinned fbcon - almost half of that would go to a single
> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
> have at least a few fb-sized buffers for backbuffer rendering, etc.
>
> The specific limits could probably use tweaking - I think they only
> consider VRAM size, not the fb size.
>
> I guess 8bpp worked prior to the change you bisected though, so we
> should figure out what we did wrong in the new code.
Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
I guess that nv50_head_gamma_set() is missing something like this (from
nv_crtc_gamma_set()):
/* We need to know the depth before we upload, but it's possible to
* get called before a framebuffer is bound. If this is the case,
* mark the lut values as dirty by setting depth==0, and it'll be
* uploaded on the first mode_set_base()
*/
if (!nv_crtc->base.primary->fb) {
nv_crtc->lut.depth = 0;
return 0;
}
That's easy to add but there's no mode_set_base() for nv50 so there's no place
to add code like this:
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
nv_crtc_gamma_load(crtc);
}
--
Ondrej Zary
Re: Blank console but X11 works on MCP79 - old regression since 3.8
On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>
> wrote:
> > @@ -483,8 +483,8 @@
> > nouveau :02:00.0: disp:0860: -> 0500
> > nouveau :02:00.0: disp:0864:
> > nouveau :02:00.0: disp:0868: -> 04000500
> > -nouveau :02:00.0: disp:086c: -> 00100500
> > -nouveau :02:00.0: disp:0870: e900 -> 1e00
> > +nouveau :02:00.0: disp:086c: -> 00100a00
> > +nouveau :02:00.0: disp:0870: e900 -> e800
> > nouveau :02:00.0: disp:0874: ->
> > nouveau :02:00.0: disp:0878:
> > nouveau :02:00.0: disp:0880: 0500
> >
> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in
> > 64MB case. Why?
> >
> > I get blank screen even with 64MB with video=1280x1024-8 kernel
> > parameter. Console works with video=1280x1024-16 even with 32MB stolen
> > memory.
> >
> > Conclusions: 8-bit support is broken and bpp reduction is weird.
>
> OK, well that makes a *ton* of sense (8bpp being broken).
>
> I think the idea of bpp reduction is that when you're on your shiny
> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating
> all that to a pinned fbcon - almost half of that would go to a single
> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
> have at least a few fb-sized buffers for backbuffer rendering, etc.
>
> The specific limits could probably use tweaking - I think they only
> consider VRAM size, not the fb size.
>
> I guess 8bpp worked prior to the change you bisected though, so we
> should figure out what we did wrong in the new code.
Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
I guess that nv50_head_gamma_set() is missing something like this (from
nv_crtc_gamma_set()):
/* We need to know the depth before we upload, but it's possible to
* get called before a framebuffer is bound. If this is the case,
* mark the lut values as dirty by setting depth==0, and it'll be
* uploaded on the first mode_set_base()
*/
if (!nv_crtc->base.primary->fb) {
nv_crtc->lut.depth = 0;
return 0;
}
That's easy to add but there's no mode_set_base() for nv50 so there's no place
to add code like this:
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
nv_crtc_gamma_load(crtc);
}
--
Ondrej Zary
Re: Blank console but X11 works on MCP79 - old regression since 3.8
::003d: init running... nouveau: DRM::003d: init children... nouveau: DRM::003d: init completed in 67us @@ -415,7 +415,7 @@ nouveau: DRM:502d:502d: init running... nouveau: DRM:502d:502d: init children... nouveau: DRM:502d:502d: init completed in 67us -nouveau :02:00.0: DRM: allocated 1280x1024 fb: 0x5, bo f667ac00 +nouveau :02:00.0: DRM: allocated 1280x1024 fb: 0x5, bo f6afa000 fbcon: nouveaufb (fb0) is primary device [drm:drm_crtc_helper_set_config [drm_kms_helper]] [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CRTC:34:crtc-0] [FB:61] #connectors=1 (x y) (0 0) @@ -483,8 +483,8 @@ nouveau :02:00.0: disp:0860: -> 0500 nouveau :02:00.0: disp:0864: nouveau :02:00.0: disp:0868: -> 04000500 -nouveau :02:00.0: disp:086c: -> 00100500 -nouveau :02:00.0: disp:0870: e900 -> 1e00 +nouveau :02:00.0: disp:086c: -> 00100a00 +nouveau :02:00.0: disp:0870: e900 -> e800 nouveau :02:00.0: disp:0874: -> nouveau :02:00.0: disp:0878: nouveau :02:00.0: disp:0880: 0500 Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in 64MB case. Why? I get blank screen even with 64MB with video=1280x1024-8 kernel parameter. Console works with video=1280x1024-16 even with 32MB stolen memory. Conclusions: 8-bit support is broken and bpp reduction is weird. > Sounds like things are generally working, just the fbcon -> nouveaufb > path seems somehow buggered. > > Another thing to try would be nouveau.atomic=1 > > On Fri, Nov 17, 2017 at 9:26 AM, Ondrej Zary <li...@rainbow-software.org> > wrote: > > Hello, > > I've just been hit by this old bug which is still present in 4.14: > > https://bugs.freedesktop.org/show_bug.cgi?id=80675 > > > > On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is > > blank but X11 works. When the stolen memory is increased to 64MB, console > > works fine. > > > > Bisected it to this: > > > > 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit > > commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f > > Author: Ben Skeggs <bske...@redhat.com> > > Date: Fri Nov 16 11:54:31 2012 +1000 > > > > drm/nv50-nvc0: switch to common disp impl, removing previous version > > > > Signed-off-by: Ben Skeggs <bske...@redhat.com> > > > > It's a big change so I'm not able to do more debugging. > > > > -- > > Ondrej Zary -- Ondrej Zary
Re: Blank console but X11 works on MCP79 - old regression since 3.8
::003d: init running... nouveau: DRM::003d: init children... nouveau: DRM::003d: init completed in 67us @@ -415,7 +415,7 @@ nouveau: DRM:502d:502d: init running... nouveau: DRM:502d:502d: init children... nouveau: DRM:502d:502d: init completed in 67us -nouveau :02:00.0: DRM: allocated 1280x1024 fb: 0x5, bo f667ac00 +nouveau :02:00.0: DRM: allocated 1280x1024 fb: 0x5, bo f6afa000 fbcon: nouveaufb (fb0) is primary device [drm:drm_crtc_helper_set_config [drm_kms_helper]] [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CRTC:34:crtc-0] [FB:61] #connectors=1 (x y) (0 0) @@ -483,8 +483,8 @@ nouveau :02:00.0: disp:0860: -> 0500 nouveau :02:00.0: disp:0864: nouveau :02:00.0: disp:0868: -> 04000500 -nouveau :02:00.0: disp:086c: -> 00100500 -nouveau :02:00.0: disp:0870: e900 -> 1e00 +nouveau :02:00.0: disp:086c: -> 00100a00 +nouveau :02:00.0: disp:0870: e900 -> e800 nouveau :02:00.0: disp:0874: -> nouveau :02:00.0: disp:0878: nouveau :02:00.0: disp:0880: 0500 Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in 64MB case. Why? I get blank screen even with 64MB with video=1280x1024-8 kernel parameter. Console works with video=1280x1024-16 even with 32MB stolen memory. Conclusions: 8-bit support is broken and bpp reduction is weird. > Sounds like things are generally working, just the fbcon -> nouveaufb > path seems somehow buggered. > > Another thing to try would be nouveau.atomic=1 > > On Fri, Nov 17, 2017 at 9:26 AM, Ondrej Zary > wrote: > > Hello, > > I've just been hit by this old bug which is still present in 4.14: > > https://bugs.freedesktop.org/show_bug.cgi?id=80675 > > > > On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is > > blank but X11 works. When the stolen memory is increased to 64MB, console > > works fine. > > > > Bisected it to this: > > > > 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit > > commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f > > Author: Ben Skeggs > > Date: Fri Nov 16 11:54:31 2012 +1000 > > > > drm/nv50-nvc0: switch to common disp impl, removing previous version > > > > Signed-off-by: Ben Skeggs > > > > It's a big change so I'm not able to do more debugging. > > > > -- > > Ondrej Zary -- Ondrej Zary
Blank console but X11 works on MCP79 - old regression since 3.8
Hello, I've just been hit by this old bug which is still present in 4.14: https://bugs.freedesktop.org/show_bug.cgi?id=80675 On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank but X11 works. When the stolen memory is increased to 64MB, console works fine. Bisected it to this: 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f Author: Ben Skeggs <bske...@redhat.com> Date: Fri Nov 16 11:54:31 2012 +1000 drm/nv50-nvc0: switch to common disp impl, removing previous version Signed-off-by: Ben Skeggs <bske...@redhat.com> It's a big change so I'm not able to do more debugging. -- Ondrej Zary
Blank console but X11 works on MCP79 - old regression since 3.8
Hello, I've just been hit by this old bug which is still present in 4.14: https://bugs.freedesktop.org/show_bug.cgi?id=80675 On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank but X11 works. When the stolen memory is increased to 64MB, console works fine. Bisected it to this: 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f Author: Ben Skeggs Date: Fri Nov 16 11:54:31 2012 +1000 drm/nv50-nvc0: switch to common disp impl, removing previous version Signed-off-by: Ben Skeggs It's a big change so I'm not able to do more debugging. -- Ondrej Zary
Re: [PATCH] video: fbdev: remove dead igafb driver
On Wednesday 18 October 2017, David Miller wrote:
> From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
> Date: Wed, 18 Oct 2017 15:14:27 +0200
>
> > Hi Bartlomiej!
> >
> > On 10/18/2017 02:56 PM, Bartlomiej Zolnierkiewicz wrote:
> >> igafb driver hasn't compiled since at least kernel v2.6.34 as
> >> commit 6016a363f6b5 ("of: unify phandle name in struct device_node")
> >> missed updating igafb.c to use dp->phandle instead of dp->node.
> >
> > Would it take a lot of work to port the driver to the new interface?
> >
> > I'm not sure which SPARC machines use this particular framebuffer, but
> > my plans are to fix up all these old framebuffer drivers. I have
> > already
> > received several Amiga (Zorro) graphics cards for testing the updated
> > drivers on Amiga.
> >
> > It could be that I actually have this particular SPARC framebuffer in
> > my hardware collection.
>
> Unless you have a 32-bit sparc laptop, you don't have a machine that
> will use this driver.
There are also some x86 PCI cards using this chip.
--
Ondrej Zary
Re: [PATCH] video: fbdev: remove dead igafb driver
On Wednesday 18 October 2017, David Miller wrote:
> From: John Paul Adrian Glaubitz
> Date: Wed, 18 Oct 2017 15:14:27 +0200
>
> > Hi Bartlomiej!
> >
> > On 10/18/2017 02:56 PM, Bartlomiej Zolnierkiewicz wrote:
> >> igafb driver hasn't compiled since at least kernel v2.6.34 as
> >> commit 6016a363f6b5 ("of: unify phandle name in struct device_node")
> >> missed updating igafb.c to use dp->phandle instead of dp->node.
> >
> > Would it take a lot of work to port the driver to the new interface?
> >
> > I'm not sure which SPARC machines use this particular framebuffer, but
> > my plans are to fix up all these old framebuffer drivers. I have
> > already
> > received several Amiga (Zorro) graphics cards for testing the updated
> > drivers on Amiga.
> >
> > It could be that I actually have this particular SPARC framebuffer in
> > my hardware collection.
>
> Unless you have a 32-bit sparc laptop, you don't have a machine that
> will use this driver.
There are also some x86 PCI cards using this chip.
--
Ondrej Zary
Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
On Thursday 31 August 2017, Greg KH wrote: > On Tue, Aug 29, 2017 at 11:32:58PM +0200, Ondrej Zary wrote: > > On Tuesday 29 August 2017 01:42:08 David Miller wrote: > > > From: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > > Date: Sun, 27 Aug 2017 17:03:30 +0200 > > > > > > > The IRDA code has long been obsolete and broken. So, to keep people > > > > from trying to use it, and to prevent people from having to maintain > > > > it, let's move it to drivers/staging/ so that we can delete it > > > > entirely from the kernel in a few releases. > > > > > > No objection, I'll apply this to net-next, thanks Greg. > > > > IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file > > transfer. Hope I'm not the only one... > > > > # irattach /dev/ttyS0 -d tekram -s > > # irdadump > > 21:28:52.830350 xid:cmd aed8eb79 > S=6 s=0 (14) > > 21:28:52.922368 xid:cmd aed8eb79 > S=6 s=1 (14) > > 21:28:53.014350 xid:cmd aed8eb79 > S=6 s=2 (14) > > 21:28:53.106338 xid:cmd aed8eb79 > S=6 s=3 (14) > > 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 > > [ PnP Modem Fax Telephony IrCOMM IrOBEX ] (28) > > 21:28:53.198384 xid:cmd aed8eb79 > S=6 s=4 (14) > > 21:28:53.290382 xid:cmd aed8eb79 > S=6 s=5 (14) > > 21:28:53.382341 xid:cmd aed8eb79 > S=6 s=* pentium hint=0400 [ > > Computer ] (23) > > ^C > > 8 packets received by filter > > > > $ obexftp -i -l MMC > > Connecting..\done > > Receiving "MMC".../ > > > [ ]> > > > > > > > user-perm="RWD"/> > > > user-perm="RWD"/> > > > user-perm="RWD"/> > > > > $ obexftp -i -c MMC -g Image004.jpg > > Connecting..\done > > Sending "MMC"...|done > > Receiving "Image004.jpg"...-done > > Disconnecting..\done > > Odd, and is this just a ir device connected to a "real" serial port, or > a specific IRDA device? > > thanks, > > greg k-h Yes, it's an external IrDA dongle connected to a real serial port. I also have an ARK3116-based USB IrDA dongle and some laptops with integrated IrDA ports that used to work fine but haven't tested them recently (i.e. Debian 9). -- Ondrej Zary
Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
On Thursday 31 August 2017, Greg KH wrote: > On Tue, Aug 29, 2017 at 11:32:58PM +0200, Ondrej Zary wrote: > > On Tuesday 29 August 2017 01:42:08 David Miller wrote: > > > From: Greg Kroah-Hartman > > > Date: Sun, 27 Aug 2017 17:03:30 +0200 > > > > > > > The IRDA code has long been obsolete and broken. So, to keep people > > > > from trying to use it, and to prevent people from having to maintain > > > > it, let's move it to drivers/staging/ so that we can delete it > > > > entirely from the kernel in a few releases. > > > > > > No objection, I'll apply this to net-next, thanks Greg. > > > > IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file > > transfer. Hope I'm not the only one... > > > > # irattach /dev/ttyS0 -d tekram -s > > # irdadump > > 21:28:52.830350 xid:cmd aed8eb79 > S=6 s=0 (14) > > 21:28:52.922368 xid:cmd aed8eb79 > S=6 s=1 (14) > > 21:28:53.014350 xid:cmd aed8eb79 > S=6 s=2 (14) > > 21:28:53.106338 xid:cmd aed8eb79 > S=6 s=3 (14) > > 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 > > [ PnP Modem Fax Telephony IrCOMM IrOBEX ] (28) > > 21:28:53.198384 xid:cmd aed8eb79 > S=6 s=4 (14) > > 21:28:53.290382 xid:cmd aed8eb79 > S=6 s=5 (14) > > 21:28:53.382341 xid:cmd aed8eb79 > S=6 s=* pentium hint=0400 [ > > Computer ] (23) > > ^C > > 8 packets received by filter > > > > $ obexftp -i -l MMC > > Connecting..\done > > Receiving "MMC".../ > > > [ ]> > > > > > > > user-perm="RWD"/> > > > user-perm="RWD"/> > > > user-perm="RWD"/> > > > > $ obexftp -i -c MMC -g Image004.jpg > > Connecting..\done > > Sending "MMC"...|done > > Receiving "Image004.jpg"...-done > > Disconnecting..\done > > Odd, and is this just a ir device connected to a "real" serial port, or > a specific IRDA device? > > thanks, > > greg k-h Yes, it's an external IrDA dongle connected to a real serial port. I also have an ARK3116-based USB IrDA dongle and some laptops with integrated IrDA ports that used to work fine but haven't tested them recently (i.e. Debian 9). -- Ondrej Zary
Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
On Tuesday 29 August 2017 01:42:08 David Miller wrote: > From: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Date: Sun, 27 Aug 2017 17:03:30 +0200 > > > The IRDA code has long been obsolete and broken. So, to keep people > > from trying to use it, and to prevent people from having to maintain it, > > let's move it to drivers/staging/ so that we can delete it entirely from > > the kernel in a few releases. > > No objection, I'll apply this to net-next, thanks Greg. IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file transfer. Hope I'm not the only one... # irattach /dev/ttyS0 -d tekram -s # irdadump 21:28:52.830350 xid:cmd aed8eb79 > S=6 s=0 (14) 21:28:52.922368 xid:cmd aed8eb79 > S=6 s=1 (14) 21:28:53.014350 xid:cmd aed8eb79 > S=6 s=2 (14) 21:28:53.106338 xid:cmd aed8eb79 > S=6 s=3 (14) 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 [ PnP Modem Fax Telephony IrCOMM IrOBEX ] (28) 21:28:53.198384 xid:cmd aed8eb79 > S=6 s=4 (14) 21:28:53.290382 xid:cmd aed8eb79 > S=6 s=5 (14) 21:28:53.382341 xid:cmd aed8eb79 > S=6 s=* pentium hint=0400 [ Computer ] (23) ^C 8 packets received by filter $ obexftp -i -l MMC Connecting..\done Receiving "MMC".../ ]> $ obexftp -i -c MMC -g Image004.jpg Connecting..\done Sending "MMC"...|done Receiving "Image004.jpg"...-done Disconnecting..\done -- Ondrej Zary
Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
On Tuesday 29 August 2017 01:42:08 David Miller wrote: > From: Greg Kroah-Hartman > Date: Sun, 27 Aug 2017 17:03:30 +0200 > > > The IRDA code has long been obsolete and broken. So, to keep people > > from trying to use it, and to prevent people from having to maintain it, > > let's move it to drivers/staging/ so that we can delete it entirely from > > the kernel in a few releases. > > No objection, I'll apply this to net-next, thanks Greg. IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file transfer. Hope I'm not the only one... # irattach /dev/ttyS0 -d tekram -s # irdadump 21:28:52.830350 xid:cmd aed8eb79 > S=6 s=0 (14) 21:28:52.922368 xid:cmd aed8eb79 > S=6 s=1 (14) 21:28:53.014350 xid:cmd aed8eb79 > S=6 s=2 (14) 21:28:53.106338 xid:cmd aed8eb79 > S=6 s=3 (14) 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 [ PnP Modem Fax Telephony IrCOMM IrOBEX ] (28) 21:28:53.198384 xid:cmd aed8eb79 > S=6 s=4 (14) 21:28:53.290382 xid:cmd aed8eb79 > S=6 s=5 (14) 21:28:53.382341 xid:cmd aed8eb79 > S=6 s=* pentium hint=0400 [ Computer ] (23) ^C 8 packets received by filter $ obexftp -i -l MMC Connecting..\done Receiving "MMC".../ ]> $ obexftp -i -c MMC -g Image004.jpg Connecting..\done Sending "MMC"...|done Receiving "Image004.jpg"...-done Disconnecting..\done -- Ondrej Zary
Re: [PATCH v7 0/6] g_NCR5380: PDMA fixes and cleanup
On Monday 03 July 2017 09:59:05 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when Gated IRQ gets asserted. > - Make udelay conditional on board type. > - Drop sg_tablesize patch due to performance regression. > > Changed since v3: > - Add Ondrej's workaround for corrupt WRITE commands on DTC boards. > - Reset the 53c400 logic after any short PDMA transfer. > - Don't fail the transfer if the 53c400 logic got a reset. > > Changed since v4: > - Bail out of transfer loops when Gated IRQ gets asserted. (Again.) > - Always call wait_for_53c80_registers() at end of transfer. > - Drain chip buffers after PDMA receive is interrupted. > - Rework residual calculation. > - Add new patch to correct DMA terminology. > > Changed since v5: > - Rework residual calculation to account for on-chip buffer swap. > - Attempt to retain the disconnect/IRQ detection in the DTC436 workaround. > - Move all DTC436 workarounds to final patch. > > Changed since v6: > - Fix residual calculation for the buffer timeout case. > - Iterate after sending final 128 bytes to check for buffer timeout. > - Don't log the residual value when it is known to be zero. > > > Finn Thain (2): > g_NCR5380: Cleanup comments and whitespace > g_NCR5380: Use unambiguous terminology for PDMA send and receive > > Ondrej Zary (4): > g_NCR5380: Fix PDMA transfer size > g_NCR5380: End PDMA transfer correctly on target disconnection > g_NCR5380: Re-work PDMA loops > g_NCR5380: Two DTC436 PDMA workarounds > > drivers/scsi/g_NCR5380.c | 277 > ++- 1 file changed, 155 > insertions(+), 122 deletions(-) Everything works fine! No corruption, no hangs, rescan-scsi-bus works. Tested cards: Canon FG2-5202 (53C400 chip, MMIO) DTC-3181L (DTCT-436P chip, PIO) HP C2502 (53C400A chip, PIO) Tested devices: QUANTUM LP240S GM240S01X 4.6 IBM DORS-32160 WA0A SONY CD-ROM CDU-415 1.1g SONY CD-ROM CDU-55S 1.0t Tested-by: Ondrej Zary <li...@rainbow-software.org> -- Ondrej Zary
Re: [PATCH v7 0/6] g_NCR5380: PDMA fixes and cleanup
On Monday 03 July 2017 09:59:05 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when Gated IRQ gets asserted. > - Make udelay conditional on board type. > - Drop sg_tablesize patch due to performance regression. > > Changed since v3: > - Add Ondrej's workaround for corrupt WRITE commands on DTC boards. > - Reset the 53c400 logic after any short PDMA transfer. > - Don't fail the transfer if the 53c400 logic got a reset. > > Changed since v4: > - Bail out of transfer loops when Gated IRQ gets asserted. (Again.) > - Always call wait_for_53c80_registers() at end of transfer. > - Drain chip buffers after PDMA receive is interrupted. > - Rework residual calculation. > - Add new patch to correct DMA terminology. > > Changed since v5: > - Rework residual calculation to account for on-chip buffer swap. > - Attempt to retain the disconnect/IRQ detection in the DTC436 workaround. > - Move all DTC436 workarounds to final patch. > > Changed since v6: > - Fix residual calculation for the buffer timeout case. > - Iterate after sending final 128 bytes to check for buffer timeout. > - Don't log the residual value when it is known to be zero. > > > Finn Thain (2): > g_NCR5380: Cleanup comments and whitespace > g_NCR5380: Use unambiguous terminology for PDMA send and receive > > Ondrej Zary (4): > g_NCR5380: Fix PDMA transfer size > g_NCR5380: End PDMA transfer correctly on target disconnection > g_NCR5380: Re-work PDMA loops > g_NCR5380: Two DTC436 PDMA workarounds > > drivers/scsi/g_NCR5380.c | 277 > ++- 1 file changed, 155 > insertions(+), 122 deletions(-) Everything works fine! No corruption, no hangs, rescan-scsi-bus works. Tested cards: Canon FG2-5202 (53C400 chip, MMIO) DTC-3181L (DTCT-436P chip, PIO) HP C2502 (53C400A chip, PIO) Tested devices: QUANTUM LP240S GM240S01X 4.6 IBM DORS-32160 WA0A SONY CD-ROM CDU-415 1.1g SONY CD-ROM CDU-55S 1.0t Tested-by: Ondrej Zary -- Ondrej Zary
Re: [PATCH v6 0/6] g_NCR5380: PDMA fixes and cleanup
On Sunday 02 July 2017 05:11:27 Finn Thain wrote:
> On Sat, 1 Jul 2017, Ondrej Zary wrote:
> > The write corruption is still present - "start" must be rolled back in
> > both IRQ and timeout cases.
>
> Your original algorithm aborts the transfer for a timeout. Same with mine.
I do "start -= 2 * 128" even after timeout.
> The bug must be a elsewhere.
>
> > And 128 B is not enough , 256 is OK (why did it work last time?).
>
> When I get contradictory results it usually means I booted the wrong build
> or built the wrong branch.
I've just retested PATCHv5, it really misses 128 bytes and works if I
add "residual += 128;".
> Actually, I think that adding 128 to the residual is correct in some
> sitations, and 256 is correct in other situations.
>
> > We just wrote a buffer to the chip but the chip is writing the previous
> > one to the drive - so if a problem arises, both buffers are lost.
>
> I see. I guess we have to take buffer swaps into account.
>
> > This fixes the corruption (although the "start > 0" check seems wrong
> > now): --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -598,23 +598,17 @@ static inline int generic_NCR5380_psend(struct
> > NCR5380_hostdata *hostdata, CSR_HOST_BUF_NOT_RDY, 0,
> >hostdata->c400_ctl_status,
> >CSR_GATED_53C80_IRQ,
> > - CSR_GATED_53C80_IRQ, HZ / 64) < 0)
> > - break;
> > -
> > - if (NCR5380_read(hostdata->c400_ctl_status) &
> > - CSR_HOST_BUF_NOT_RDY) {
> > + CSR_GATED_53C80_IRQ, HZ / 64) < 0 ||
> > + (NCR5380_read(hostdata->c400_ctl_status) &
> > +(CSR_HOST_BUF_NOT_RDY | CSR_GATED_53C80_IRQ))) {
>
> You could add a printk to the timeout branch. If it executes, something is
> seriously wrong. E.g.
>
> - break;
> + { pr_err("send timeout %02x, %d/%d\n",
> NCR5380_read(hostdata->c400_ctl_status), start, len); break; }
Yes, timeouts do happen:
[ 9671.909223] send timeout 14, 3840/4096
[ 9672.978079] send timeout 14, 2816/4096
[ 9675.323751] send timeout 14, 1280/4096
> > /* The chip has done a 128 B buffer swap but the first
> > * buffer still has not reached the SCSI bus.
> > */
> > if (start > 0)
> > - start -= 128;
> > + start -= 256;
> > break;
> > }
>
> BTW, that change carries the risk of 'start' going negative and the
> residual exceeding the length of the original transfer.
>
> But I agree with you that there's a problem with the residual.
>
> If I understand correctly, the 53c400 can't do a buffer swap until the
> disk acknowledges each of the 128 bytes from the buffer. But I guess the
> first buffer is special because the disk will not see the first byte of
> the transfer until after the first buffer swap.
>
> And it appears that the last buffer is also special: we have to wait for
> CSR_HOST_BUF_NOT_RDY even after start == len otherwise we may not detect a
> failure and fix the residual. So I think the datasheet is right; we have
> to iterate until the block counter goes to zero.
>
> I think it is safe to say that when CSR_HOST_BUF_NOT_RDY, 'start' is
> between 128 and 256 B ahead of the disk. Otherwise, the host buffer is
> empty and 'start' is no more than 128 B ahead of the disk.
>
> > - if (NCR5380_read(hostdata->c400_ctl_status) &
> > - CSR_GATED_53C80_IRQ)
> > - break;
> > -
> > if (hostdata->io_port && hostdata->io_width == 2)
> > outsw(hostdata->io_port + hostdata->c400_host_buf,
> > src + start, 64);
> >
> >
> > DTC seems to work too.
>
> OK. Thanks for testing. Please try the patch below on top of v6.
It misses 256B blocks. It's caused by the timeouts, this patch fixes it:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -598,11 +598,9 @@ static inline int generic_NCR5380_psend(struct
NCR5380_hostdata *hostdata,
CSR_HOST_BUF_NOT_RDY, 0,
hostdata->c400_ctl_status,
CSR_GATED_53C80_IRQ,
- CSR_GATED_53C80_IRQ, HZ / 64) < 0)
- break;
-
- if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_HOST_BUF_NOT_RDY) {
+ CSR_GATED_53C80_IRQ, HZ / 64) < 0 ||
+ (NCR5380_read(hostdata->c400_ctl_status) &
+CSR_HOST_BUF_NOT_RDY)) {
/* Both 128 B buffers are in use */
if (start >= 128)
start -= 128;
--
Ondrej Zary
Re: [PATCH v6 0/6] g_NCR5380: PDMA fixes and cleanup
On Sunday 02 July 2017 05:11:27 Finn Thain wrote:
> On Sat, 1 Jul 2017, Ondrej Zary wrote:
> > The write corruption is still present - "start" must be rolled back in
> > both IRQ and timeout cases.
>
> Your original algorithm aborts the transfer for a timeout. Same with mine.
I do "start -= 2 * 128" even after timeout.
> The bug must be a elsewhere.
>
> > And 128 B is not enough , 256 is OK (why did it work last time?).
>
> When I get contradictory results it usually means I booted the wrong build
> or built the wrong branch.
I've just retested PATCHv5, it really misses 128 bytes and works if I
add "residual += 128;".
> Actually, I think that adding 128 to the residual is correct in some
> sitations, and 256 is correct in other situations.
>
> > We just wrote a buffer to the chip but the chip is writing the previous
> > one to the drive - so if a problem arises, both buffers are lost.
>
> I see. I guess we have to take buffer swaps into account.
>
> > This fixes the corruption (although the "start > 0" check seems wrong
> > now): --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -598,23 +598,17 @@ static inline int generic_NCR5380_psend(struct
> > NCR5380_hostdata *hostdata, CSR_HOST_BUF_NOT_RDY, 0,
> >hostdata->c400_ctl_status,
> >CSR_GATED_53C80_IRQ,
> > - CSR_GATED_53C80_IRQ, HZ / 64) < 0)
> > - break;
> > -
> > - if (NCR5380_read(hostdata->c400_ctl_status) &
> > - CSR_HOST_BUF_NOT_RDY) {
> > + CSR_GATED_53C80_IRQ, HZ / 64) < 0 ||
> > + (NCR5380_read(hostdata->c400_ctl_status) &
> > +(CSR_HOST_BUF_NOT_RDY | CSR_GATED_53C80_IRQ))) {
>
> You could add a printk to the timeout branch. If it executes, something is
> seriously wrong. E.g.
>
> - break;
> + { pr_err("send timeout %02x, %d/%d\n",
> NCR5380_read(hostdata->c400_ctl_status), start, len); break; }
Yes, timeouts do happen:
[ 9671.909223] send timeout 14, 3840/4096
[ 9672.978079] send timeout 14, 2816/4096
[ 9675.323751] send timeout 14, 1280/4096
> > /* The chip has done a 128 B buffer swap but the first
> > * buffer still has not reached the SCSI bus.
> > */
> > if (start > 0)
> > - start -= 128;
> > + start -= 256;
> > break;
> > }
>
> BTW, that change carries the risk of 'start' going negative and the
> residual exceeding the length of the original transfer.
>
> But I agree with you that there's a problem with the residual.
>
> If I understand correctly, the 53c400 can't do a buffer swap until the
> disk acknowledges each of the 128 bytes from the buffer. But I guess the
> first buffer is special because the disk will not see the first byte of
> the transfer until after the first buffer swap.
>
> And it appears that the last buffer is also special: we have to wait for
> CSR_HOST_BUF_NOT_RDY even after start == len otherwise we may not detect a
> failure and fix the residual. So I think the datasheet is right; we have
> to iterate until the block counter goes to zero.
>
> I think it is safe to say that when CSR_HOST_BUF_NOT_RDY, 'start' is
> between 128 and 256 B ahead of the disk. Otherwise, the host buffer is
> empty and 'start' is no more than 128 B ahead of the disk.
>
> > - if (NCR5380_read(hostdata->c400_ctl_status) &
> > - CSR_GATED_53C80_IRQ)
> > - break;
> > -
> > if (hostdata->io_port && hostdata->io_width == 2)
> > outsw(hostdata->io_port + hostdata->c400_host_buf,
> > src + start, 64);
> >
> >
> > DTC seems to work too.
>
> OK. Thanks for testing. Please try the patch below on top of v6.
It misses 256B blocks. It's caused by the timeouts, this patch fixes it:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -598,11 +598,9 @@ static inline int generic_NCR5380_psend(struct
NCR5380_hostdata *hostdata,
CSR_HOST_BUF_NOT_RDY, 0,
hostdata->c400_ctl_status,
CSR_GATED_53C80_IRQ,
- CSR_GATED_53C80_IRQ, HZ / 64) < 0)
- break;
-
- if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_HOST_BUF_NOT_RDY) {
+ CSR_GATED_53C80_IRQ, HZ / 64) < 0 ||
+ (NCR5380_read(hostdata->c400_ctl_status) &
+CSR_HOST_BUF_NOT_RDY)) {
/* Both 128 B buffers are in use */
if (start >= 128)
start -= 128;
--
Ondrej Zary
Re: [PATCH v6 0/6] g_NCR5380: PDMA fixes and cleanup
On Saturday 01 July 2017 04:40:53 Finn Thain wrote:
> Ondrej, would you please test this new series?
>
> Changed since v1:
> - PDMA transfer residual is calculated earlier.
> - End of DMA flag check is now polled (if there is any residual).
>
> Changed since v2:
> - Bail out of transfer loops when Gated IRQ gets asserted.
> - Make udelay conditional on board type.
> - Drop sg_tablesize patch due to performance regression.
>
> Changed since v3:
> - Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
> - Reset the 53c400 logic after any short PDMA transfer.
> - Don't fail the transfer if the 53c400 logic got a reset.
>
> Changed since v4:
> - Bail out of transfer loops when Gated IRQ gets asserted. (Again.)
> - Always call wait_for_53c80_registers() at end of transfer.
> - Drain chip buffers after PDMA receive is interrupted.
> - Rework residual calculation.
> - Add new patch to correct DMA terminology.
>
> Changed since v5:
> - Rework residual calculation to account for on-chip buffer swap.
> - Attempt to retain the disconnect/IRQ detection in the DTC436 workaround.
> - Move all DTC436 workarounds to final patch.
>
>
> Finn Thain (2):
> g_NCR5380: Cleanup comments and whitespace
> g_NCR5380: Use unambiguous terminology for PDMA send and receive
>
> Ondrej Zary (4):
> g_NCR5380: Fix PDMA transfer size
> g_NCR5380: End PDMA transfer correctly on target disconnection
> g_NCR5380: Re-work PDMA loops
> g_NCR5380: Various DTC436 workarounds
>
> drivers/scsi/g_NCR5380.c | 273
> ++- 1 file changed, 151
> insertions(+), 122 deletions(-)
The write corruption is still present - "start" must be rolled back in both
IRQ and timeout cases. And 128 B is not enough , 256 is OK (why did it work
last time?). We just wrote a buffer to the chip but the chip is writing the
previous one to the drive - so if a problem arises, both buffers are lost.
This fixes the corruption (although the "start > 0" check seems wrong now):
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -598,23 +598,17 @@ static inline int generic_NCR5380_psend(struct
NCR5380_hostdata *hostdata,
CSR_HOST_BUF_NOT_RDY, 0,
hostdata->c400_ctl_status,
CSR_GATED_53C80_IRQ,
- CSR_GATED_53C80_IRQ, HZ / 64) < 0)
- break;
-
- if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_HOST_BUF_NOT_RDY) {
+ CSR_GATED_53C80_IRQ, HZ / 64) < 0 ||
+ (NCR5380_read(hostdata->c400_ctl_status) &
+(CSR_HOST_BUF_NOT_RDY | CSR_GATED_53C80_IRQ))) {
/* The chip has done a 128 B buffer swap but the first
* buffer still has not reached the SCSI bus.
*/
if (start > 0)
- start -= 128;
+ start -= 256;
break;
}
- if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_GATED_53C80_IRQ)
- break;
-
if (hostdata->io_port && hostdata->io_width == 2)
outsw(hostdata->io_port + hostdata->c400_host_buf,
src + start, 64);
DTC seems to work too.
--
Ondrej Zary
Re: [PATCH v6 0/6] g_NCR5380: PDMA fixes and cleanup
On Saturday 01 July 2017 04:40:53 Finn Thain wrote:
> Ondrej, would you please test this new series?
>
> Changed since v1:
> - PDMA transfer residual is calculated earlier.
> - End of DMA flag check is now polled (if there is any residual).
>
> Changed since v2:
> - Bail out of transfer loops when Gated IRQ gets asserted.
> - Make udelay conditional on board type.
> - Drop sg_tablesize patch due to performance regression.
>
> Changed since v3:
> - Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
> - Reset the 53c400 logic after any short PDMA transfer.
> - Don't fail the transfer if the 53c400 logic got a reset.
>
> Changed since v4:
> - Bail out of transfer loops when Gated IRQ gets asserted. (Again.)
> - Always call wait_for_53c80_registers() at end of transfer.
> - Drain chip buffers after PDMA receive is interrupted.
> - Rework residual calculation.
> - Add new patch to correct DMA terminology.
>
> Changed since v5:
> - Rework residual calculation to account for on-chip buffer swap.
> - Attempt to retain the disconnect/IRQ detection in the DTC436 workaround.
> - Move all DTC436 workarounds to final patch.
>
>
> Finn Thain (2):
> g_NCR5380: Cleanup comments and whitespace
> g_NCR5380: Use unambiguous terminology for PDMA send and receive
>
> Ondrej Zary (4):
> g_NCR5380: Fix PDMA transfer size
> g_NCR5380: End PDMA transfer correctly on target disconnection
> g_NCR5380: Re-work PDMA loops
> g_NCR5380: Various DTC436 workarounds
>
> drivers/scsi/g_NCR5380.c | 273
> ++- 1 file changed, 151
> insertions(+), 122 deletions(-)
The write corruption is still present - "start" must be rolled back in both
IRQ and timeout cases. And 128 B is not enough , 256 is OK (why did it work
last time?). We just wrote a buffer to the chip but the chip is writing the
previous one to the drive - so if a problem arises, both buffers are lost.
This fixes the corruption (although the "start > 0" check seems wrong now):
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -598,23 +598,17 @@ static inline int generic_NCR5380_psend(struct
NCR5380_hostdata *hostdata,
CSR_HOST_BUF_NOT_RDY, 0,
hostdata->c400_ctl_status,
CSR_GATED_53C80_IRQ,
- CSR_GATED_53C80_IRQ, HZ / 64) < 0)
- break;
-
- if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_HOST_BUF_NOT_RDY) {
+ CSR_GATED_53C80_IRQ, HZ / 64) < 0 ||
+ (NCR5380_read(hostdata->c400_ctl_status) &
+(CSR_HOST_BUF_NOT_RDY | CSR_GATED_53C80_IRQ))) {
/* The chip has done a 128 B buffer swap but the first
* buffer still has not reached the SCSI bus.
*/
if (start > 0)
- start -= 128;
+ start -= 256;
break;
}
- if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_GATED_53C80_IRQ)
- break;
-
if (hostdata->io_port && hostdata->io_width == 2)
outsw(hostdata->io_port + hostdata->c400_host_buf,
src + start, 64);
DTC seems to work too.
--
Ondrej Zary
Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup
On Friday 30 June 2017 09:12:37 Finn Thain wrote:
> On Thu, 29 Jun 2017, Ondrej Zary wrote:
> > The write corruption is still there. I'm afraid it can't be fixed
> > without rolling "start" back (or inceasing residual) if an error
> > occured, something like this:
> >
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -619,6 +621,9 @@ static inline int generic_NCR5380_psend(struct
> >(int)NCR5380_read(hostdata->c400_blk_cnt) * 128);
> >
> > if (residual != 0) {
> > + residual += 128;
> > /* 53c80 interrupt or transfer timeout. Reset 53c400 logic. */
> > NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
> > NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> >
> > (seems to work - wrote 230MB and read it back with no differences)
> >
> > The corruption mechanism is:
> > 1. Host buffer is ready so we write 128 B of data there and increment
> >"start".
> > 2. Chip swaps the buffers, decrements the block counter and starts
> >writing the data to drive.
> > 3. Drive does not like it (e.g. its buffer is full) so it disconnects.
> > 4. Chip stops writing and asserts an IRQ.
> > 5. We detect the IRQ. The block counter is already decremented, "start"
> >is already incremented but the data was not written to the drive.
>
> OK. Thanks for that analysis.
>
> It sounds like the c400_blk_cnt value gives the number of buffer swaps
> remaining. If so, that value isn't useful for calculating a residual. I'll
> rework that calculation again.
>
> In your patch, the residual gets increased regardless of the actual cause
> of the short transfer. Nothing prevents the residual from being increased
> beyond the original length of the transfer (due to a flaky target or bus).
> Therefore I've taken a slightly different approach in my patch (below).
Yes, that's wrong. My original patch had "start -= 128" and then check for
negative value.
> > No more log spamming on DTC but reads are corrupted even more than
> > before. The IRQ check after data transfer increases the chance of
> > catching an IRQ before the buffer could become ready.
>
> If we delay the IRQ check, that just means that CSR_GATED_53C80_IRQ will
> be detected a bit later (128 bytes later)... so not much difference.
The main difference is that my original patch read the CSR once and then:
- transfer data if the buffer is ready, ignoring any IRQ
- if the buffer is not ready, check for an IRQ
- if neither buffer is ready nor IRQ was asserted, check for timeout
So yes, the IRQ will be detected 128 bytes later - but the IRQ is asserted at
3968 bytes which means the transfer will then be complete.
> > This patch:
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -548,8 +548,10 @@ static inline int generic_NCR5380_precv(struct
> > start += 128;
> >
> > if (NCR5380_read(hostdata->c400_ctl_status) &
> > - CSR_GATED_53C80_IRQ)
> > + CSR_GATED_53C80_IRQ) {
> > + printk("r irq at start=%d basr=0x%02x\n", start,
> > NCR5380_read(BUS_AND_STATUS_REG)); break;
> > + }
> > }
> >
> > residual = len - start;
> >
> > produces lots of these lines:
> > [ 896.194054] r irq at start=128 basr=0x98
> > [ 896.197758] r irq at start=3968 basr=0x98
>
> Assuming that the registers are available and valid, the value 0x98 means
> BASR_END_DMA_TRANSFER | BASR_IRQ | BASR_PHASE_MATCH. There is no
> BASR_BUSY_ERROR here, so the cause of the CSR_GATED_53C80_IRQ must be that
> the 53c400 has terminated the transfer by asserting /EOP. That shouldn't
> happen before before the counters run down.
>
> It doesn't make sense. So maybe the 53c80 registers are not valid at this
> point? That means a phase mismatch can't be excluded... unlikely at 128
> bytes into the transfer. Busy error? Also unlikely.
>
> I have to conclude that CSR_GATED_53C80_IRQ and BASR_END_DMA_TRANSFER
> can't be trusted on this board. I guess that's why you examine the BASR
> directly in your original algorithm but ignore BASR_END_DMA_TRANSFER.
Exactly, BASR_END_DMA_TRANSFER causes problems on DTC.
> It does look like some kind of timing issue: the "start" value above
> changes from one log message to the next. Who knows?
Only that two values (128 and 3968) appeared. 3968 = 4096-128, one block
before the end of transfer. So probably BASR_END_DMA_TRANSFER is asserted one
block earlier (i.e. when the last block of data is transferred from the dri
Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup
On Friday 30 June 2017 09:12:37 Finn Thain wrote:
> On Thu, 29 Jun 2017, Ondrej Zary wrote:
> > The write corruption is still there. I'm afraid it can't be fixed
> > without rolling "start" back (or inceasing residual) if an error
> > occured, something like this:
> >
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -619,6 +621,9 @@ static inline int generic_NCR5380_psend(struct
> >(int)NCR5380_read(hostdata->c400_blk_cnt) * 128);
> >
> > if (residual != 0) {
> > + residual += 128;
> > /* 53c80 interrupt or transfer timeout. Reset 53c400 logic. */
> > NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
> > NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> >
> > (seems to work - wrote 230MB and read it back with no differences)
> >
> > The corruption mechanism is:
> > 1. Host buffer is ready so we write 128 B of data there and increment
> >"start".
> > 2. Chip swaps the buffers, decrements the block counter and starts
> >writing the data to drive.
> > 3. Drive does not like it (e.g. its buffer is full) so it disconnects.
> > 4. Chip stops writing and asserts an IRQ.
> > 5. We detect the IRQ. The block counter is already decremented, "start"
> >is already incremented but the data was not written to the drive.
>
> OK. Thanks for that analysis.
>
> It sounds like the c400_blk_cnt value gives the number of buffer swaps
> remaining. If so, that value isn't useful for calculating a residual. I'll
> rework that calculation again.
>
> In your patch, the residual gets increased regardless of the actual cause
> of the short transfer. Nothing prevents the residual from being increased
> beyond the original length of the transfer (due to a flaky target or bus).
> Therefore I've taken a slightly different approach in my patch (below).
Yes, that's wrong. My original patch had "start -= 128" and then check for
negative value.
> > No more log spamming on DTC but reads are corrupted even more than
> > before. The IRQ check after data transfer increases the chance of
> > catching an IRQ before the buffer could become ready.
>
> If we delay the IRQ check, that just means that CSR_GATED_53C80_IRQ will
> be detected a bit later (128 bytes later)... so not much difference.
The main difference is that my original patch read the CSR once and then:
- transfer data if the buffer is ready, ignoring any IRQ
- if the buffer is not ready, check for an IRQ
- if neither buffer is ready nor IRQ was asserted, check for timeout
So yes, the IRQ will be detected 128 bytes later - but the IRQ is asserted at
3968 bytes which means the transfer will then be complete.
> > This patch:
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -548,8 +548,10 @@ static inline int generic_NCR5380_precv(struct
> > start += 128;
> >
> > if (NCR5380_read(hostdata->c400_ctl_status) &
> > - CSR_GATED_53C80_IRQ)
> > + CSR_GATED_53C80_IRQ) {
> > + printk("r irq at start=%d basr=0x%02x\n", start,
> > NCR5380_read(BUS_AND_STATUS_REG)); break;
> > + }
> > }
> >
> > residual = len - start;
> >
> > produces lots of these lines:
> > [ 896.194054] r irq at start=128 basr=0x98
> > [ 896.197758] r irq at start=3968 basr=0x98
>
> Assuming that the registers are available and valid, the value 0x98 means
> BASR_END_DMA_TRANSFER | BASR_IRQ | BASR_PHASE_MATCH. There is no
> BASR_BUSY_ERROR here, so the cause of the CSR_GATED_53C80_IRQ must be that
> the 53c400 has terminated the transfer by asserting /EOP. That shouldn't
> happen before before the counters run down.
>
> It doesn't make sense. So maybe the 53c80 registers are not valid at this
> point? That means a phase mismatch can't be excluded... unlikely at 128
> bytes into the transfer. Busy error? Also unlikely.
>
> I have to conclude that CSR_GATED_53C80_IRQ and BASR_END_DMA_TRANSFER
> can't be trusted on this board. I guess that's why you examine the BASR
> directly in your original algorithm but ignore BASR_END_DMA_TRANSFER.
Exactly, BASR_END_DMA_TRANSFER causes problems on DTC.
> It does look like some kind of timing issue: the "start" value above
> changes from one log message to the next. Who knows?
Only that two values (128 and 3968) appeared. 3968 = 4096-128, one block
before the end of transfer. So probably BASR_END_DMA_TRANSFER is asserted one
block earlier (i.e. when the last block of data is transferred from the dri
Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup
On Thursday 29 June 2017 07:24:18 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when Gated IRQ gets asserted. > - Make udelay conditional on board type. > - Drop sg_tablesize patch due to performance regression. > > Changed since v3: > - Add Ondrej's workaround for corrupt WRITE commands on DTC boards. > - Reset the 53c400 logic after any short PDMA transfer. > - Don't fail the transfer if the 53c400 logic got a reset. > > Changed since v4: > - Bail out of transfer loops when Gated IRQ gets asserted. (Again.) > - Always call wait_for_53c80_registers() at end of transfer. > - Drain chip buffers after PDMA receive is interrupted. > - Rework residual calculation. > - Add new patch to correct DMA terminology. > > > Finn Thain (2): > g_NCR5380: Cleanup comments and whitespace > g_NCR5380: Use unambiguous terminology for PDMA send and receive > > Ondrej Zary (4): > g_NCR5380: Fix PDMA transfer size > g_NCR5380: End PDMA transfer correctly on target disconnection > g_NCR5380: Limit PDMA send to 512 B to avoid data corruption on > DTC3181E > g_NCR5380: Re-work PDMA loops > > drivers/scsi/g_NCR5380.c | 260 > +-- 1 file changed, 139 > insertions(+), 121 deletions(-) This fixes the DTC read corruption, although I don't like the repeated ctl_status register reads: --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -533,7 +533,7 @@ static inline int generic_NCR5380_precv(struct NCR5380_hostdata *hostdata, break; if (NCR5380_read(hostdata->c400_ctl_status) & - CSR_HOST_BUF_NOT_RDY) + CSR_GATED_53C80_IRQ && (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)) break; if (hostdata->io_port && hostdata->io_width == 2) @@ -546,10 +546,6 @@ static inline int generic_NCR5380_precv(struct NCR5380_hostdata *hostdata, memcpy_fromio(dst + start, hostdata->io + NCR53C400_host_buffer, 128); start += 128; - - if (NCR5380_read(hostdata->c400_ctl_status) & - CSR_GATED_53C80_IRQ) - break; } residual = len - start; Writes seem to work correctly. -- Ondrej Zary
Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup
On Thursday 29 June 2017 07:24:18 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when Gated IRQ gets asserted. > - Make udelay conditional on board type. > - Drop sg_tablesize patch due to performance regression. > > Changed since v3: > - Add Ondrej's workaround for corrupt WRITE commands on DTC boards. > - Reset the 53c400 logic after any short PDMA transfer. > - Don't fail the transfer if the 53c400 logic got a reset. > > Changed since v4: > - Bail out of transfer loops when Gated IRQ gets asserted. (Again.) > - Always call wait_for_53c80_registers() at end of transfer. > - Drain chip buffers after PDMA receive is interrupted. > - Rework residual calculation. > - Add new patch to correct DMA terminology. > > > Finn Thain (2): > g_NCR5380: Cleanup comments and whitespace > g_NCR5380: Use unambiguous terminology for PDMA send and receive > > Ondrej Zary (4): > g_NCR5380: Fix PDMA transfer size > g_NCR5380: End PDMA transfer correctly on target disconnection > g_NCR5380: Limit PDMA send to 512 B to avoid data corruption on > DTC3181E > g_NCR5380: Re-work PDMA loops > > drivers/scsi/g_NCR5380.c | 260 > +-- 1 file changed, 139 > insertions(+), 121 deletions(-) This fixes the DTC read corruption, although I don't like the repeated ctl_status register reads: --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -533,7 +533,7 @@ static inline int generic_NCR5380_precv(struct NCR5380_hostdata *hostdata, break; if (NCR5380_read(hostdata->c400_ctl_status) & - CSR_HOST_BUF_NOT_RDY) + CSR_GATED_53C80_IRQ && (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)) break; if (hostdata->io_port && hostdata->io_width == 2) @@ -546,10 +546,6 @@ static inline int generic_NCR5380_precv(struct NCR5380_hostdata *hostdata, memcpy_fromio(dst + start, hostdata->io + NCR53C400_host_buffer, 128); start += 128; - - if (NCR5380_read(hostdata->c400_ctl_status) & - CSR_GATED_53C80_IRQ) - break; } residual = len - start; Writes seem to work correctly. -- Ondrej Zary
Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup
On Thursday 29 June 2017 07:24:18 Finn Thain wrote:
> Ondrej, would you please test this new series?
>
> Changed since v1:
> - PDMA transfer residual is calculated earlier.
> - End of DMA flag check is now polled (if there is any residual).
>
> Changed since v2:
> - Bail out of transfer loops when Gated IRQ gets asserted.
> - Make udelay conditional on board type.
> - Drop sg_tablesize patch due to performance regression.
>
> Changed since v3:
> - Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
> - Reset the 53c400 logic after any short PDMA transfer.
> - Don't fail the transfer if the 53c400 logic got a reset.
>
> Changed since v4:
> - Bail out of transfer loops when Gated IRQ gets asserted. (Again.)
> - Always call wait_for_53c80_registers() at end of transfer.
> - Drain chip buffers after PDMA receive is interrupted.
> - Rework residual calculation.
> - Add new patch to correct DMA terminology.
>
>
> Finn Thain (2):
> g_NCR5380: Cleanup comments and whitespace
> g_NCR5380: Use unambiguous terminology for PDMA send and receive
>
> Ondrej Zary (4):
> g_NCR5380: Fix PDMA transfer size
> g_NCR5380: End PDMA transfer correctly on target disconnection
> g_NCR5380: Limit PDMA send to 512 B to avoid data corruption on
> DTC3181E
> g_NCR5380: Re-work PDMA loops
>
> drivers/scsi/g_NCR5380.c | 260
> +-- 1 file changed, 139
> insertions(+), 121 deletions(-)
The write corruption is still there. I'm afraid it can't be fixed without
rolling "start" back (or inceasing residual) if an error occured, something
like this:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -619,6 +621,9 @@ static inline int generic_NCR5380_psend(struct
NCR5380_hostdata *hostdata,
(int)NCR5380_read(hostdata->c400_blk_cnt) * 128);
if (residual != 0) {
+ residual += 128;
/* 53c80 interrupt or transfer timeout. Reset 53c400 logic. */
NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
(seems to work - wrote 230MB and read it back with no differences)
The corruption mechanism is:
1. Host buffer is ready so we write 128 B of data there and increment "start".
2. Chip swaps the buffers, decrements the block counter and starts writing the
data to drive.
3. Drive does not like it (e.g. its buffer is full) so it disconnects.
4. Chip stops writing and asserts an IRQ.
5. We detect the IRQ. The block counter is already decremented, "start" is
already incremented but the data was not written to the drive.
No more log spamming on DTC but reads are corrupted even more than before.
The IRQ check after data transfer increases the chance of catching an IRQ
before the buffer could become ready. This patch:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -548,8 +548,10 @@ static inline int generic_NCR5380_precv(struct
NCR5380_hostdata *hostdata,
start += 128;
if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_GATED_53C80_IRQ)
+ CSR_GATED_53C80_IRQ) {
+ printk("r irq at start=%d basr=0x%02x\n", start,
NCR5380_read(BUS_AND_STATUS_REG));
break;
+ }
}
residual = len - start;
produces lots of these lines:
[ 896.194054] r irq at start=128 basr=0x98
[ 896.197758] r irq at start=3968 basr=0x98
--
Ondrej Zary
Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup
On Thursday 29 June 2017 07:24:18 Finn Thain wrote:
> Ondrej, would you please test this new series?
>
> Changed since v1:
> - PDMA transfer residual is calculated earlier.
> - End of DMA flag check is now polled (if there is any residual).
>
> Changed since v2:
> - Bail out of transfer loops when Gated IRQ gets asserted.
> - Make udelay conditional on board type.
> - Drop sg_tablesize patch due to performance regression.
>
> Changed since v3:
> - Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
> - Reset the 53c400 logic after any short PDMA transfer.
> - Don't fail the transfer if the 53c400 logic got a reset.
>
> Changed since v4:
> - Bail out of transfer loops when Gated IRQ gets asserted. (Again.)
> - Always call wait_for_53c80_registers() at end of transfer.
> - Drain chip buffers after PDMA receive is interrupted.
> - Rework residual calculation.
> - Add new patch to correct DMA terminology.
>
>
> Finn Thain (2):
> g_NCR5380: Cleanup comments and whitespace
> g_NCR5380: Use unambiguous terminology for PDMA send and receive
>
> Ondrej Zary (4):
> g_NCR5380: Fix PDMA transfer size
> g_NCR5380: End PDMA transfer correctly on target disconnection
> g_NCR5380: Limit PDMA send to 512 B to avoid data corruption on
> DTC3181E
> g_NCR5380: Re-work PDMA loops
>
> drivers/scsi/g_NCR5380.c | 260
> +-- 1 file changed, 139
> insertions(+), 121 deletions(-)
The write corruption is still there. I'm afraid it can't be fixed without
rolling "start" back (or inceasing residual) if an error occured, something
like this:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -619,6 +621,9 @@ static inline int generic_NCR5380_psend(struct
NCR5380_hostdata *hostdata,
(int)NCR5380_read(hostdata->c400_blk_cnt) * 128);
if (residual != 0) {
+ residual += 128;
/* 53c80 interrupt or transfer timeout. Reset 53c400 logic. */
NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
(seems to work - wrote 230MB and read it back with no differences)
The corruption mechanism is:
1. Host buffer is ready so we write 128 B of data there and increment "start".
2. Chip swaps the buffers, decrements the block counter and starts writing the
data to drive.
3. Drive does not like it (e.g. its buffer is full) so it disconnects.
4. Chip stops writing and asserts an IRQ.
5. We detect the IRQ. The block counter is already decremented, "start" is
already incremented but the data was not written to the drive.
No more log spamming on DTC but reads are corrupted even more than before.
The IRQ check after data transfer increases the chance of catching an IRQ
before the buffer could become ready. This patch:
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -548,8 +548,10 @@ static inline int generic_NCR5380_precv(struct
NCR5380_hostdata *hostdata,
start += 128;
if (NCR5380_read(hostdata->c400_ctl_status) &
- CSR_GATED_53C80_IRQ)
+ CSR_GATED_53C80_IRQ) {
+ printk("r irq at start=%d basr=0x%02x\n", start,
NCR5380_read(BUS_AND_STATUS_REG));
break;
+ }
}
residual = len - start;
produces lots of these lines:
[ 896.194054] r irq at start=128 basr=0x98
[ 896.197758] r irq at start=3968 basr=0x98
--
Ondrej Zary
Re: [PATCH v4 0/5] g_NCR5380: PDMA fixes and cleanup
On Wednesday 28 June 2017 06:04:36 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when Gated IRQ gets asserted. > - Make udelay conditional on board type. > - Drop sg_tablesize patch due to performance regression. > > Changed since v3: > - Add Ondrej's workaround for corrupt WRITE commands on DTC boards. > - Reset the 53c400 logic after any short PDMA transfer. > - Don't fail the transfer if the 53c400 logic got a reset. > > > Finn Thain (1): > g_NCR5380: Cleanup comments and whitespace > > Ondrej Zary (4): > g_NCR5380: Fix PDMA transfer size > g_NCR5380: End PDMA transfer correctly on target disconnection > g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on > DTC3181E > g_NCR5380: Re-work PDMA loops > > drivers/scsi/g_NCR5380.c | 239 > --- 1 file changed, 120 > insertions(+), 119 deletions(-) Now read seems to work on non-DTC chips. Writes continue in PDMA after disconnect but there's a corruption - one 128 B block missing on disconnect. On DTC, the log is spammed with errors like this: sd 2:0:1:0: [sdb] tag#0 generic_NCR5380_pread: End of DMA timeout (0) They're cause by read corruption on DTC: pread() is breaking at start=3968 because of an end-of-DMA IRQ (BASR=0x98) but pdma_residual is set to zero (block counter is zero because the data was read into the buffer but we did not read it from there). So we lose one buffer of data on each 4 KB read. The PDMA is then reset which probably means BASR_END_DMA_TRANSFER will not be asserted. -- Ondrej Zary
