00763_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
way to get
support for new HW.
> I expect -stable is what most users are running on their notebooks.
>
> Best regards,
> Pavel
--
Ondrej Zary
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:
> > > >
> >
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 con
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
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 stop
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
60x64
[ 23.571050] nouveau :01:00.0: fb0: nouveaudrmfb frame buffer device
--
Ondrej Zary
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 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
27;t remove random drivers. I still have the Aironet PCMCIA card and
can test the driver.
--
Ondrej Zary
#x27;t rewrite drivers you can't test.
--
Ondrej Zary
og/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
&& 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
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/wd7
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/wd7
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
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
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
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
-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
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
bly 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
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 th
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
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
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
a gigabit switch.
Currently running 4.18.0-2-amd64 kernel (Debian testing).
Any ideas?
--
Ondrej Zary
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
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
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
round.
(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
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
. 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 1
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
he 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
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
e 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
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&q
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
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
> > &g
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 weir
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
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 dri
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 dri
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
> > > (besid
asier.
This will make my parallel port ZIP and LS-120 drives useless :(
--
Ondrej Zary
l, 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
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
d 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
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,
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:
> >
mehow 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
27;s a big change so I'm not able to do more debugging.
--
Ondrej Zary
t; > 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
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
> > >
> > &g
f 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
(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
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. Sa
ll 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 corr
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, someth
A 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):
>
A 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):
>
ter 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 Tuesday 27 June 2017 03:49:16 Finn Thain wrote:
> On Mon, 26 Jun 2017, Ondrej Zary wrote:
> > No apparent change in behavior, the first write test resulted in:
> > [ 842.830802] sd 2:0:1:0: [sdb] tag#0 53c80 registers not accessible,
> > device will be reset [ 842.830
On Tuesday 27 June 2017 14:42:29 Finn Thain wrote:
> On Tue, 27 Jun 2017, Ondrej Zary wrote:
> > BTW. I've probably found the DTC write corruption. Added the following
> > check (13 is host buffer index register) -
>
> That register is not mentioned in my 53c400 datas
On Monday 26 June 2017, Ondrej Zary wrote:
> On Monday 26 June 2017 09:30:33 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
t of transfer loops when Gated IRQ gets asserted.
> - Make udelay conditional on board type.
> - Drop sg_tablesize patch due to performance regression.
>
>
> Finn Thain (1):
> g_NCR5380: Cleanup comments and whitespace
>
> Ondrej Zary (3):
> g_NCR5380: Fix PDMA transfer
On Monday 26 June 2017, Finn Thain wrote:
> On Sun, 25 Jun 2017, Ondrej Zary wrote:
> > It mostly works, but there are some problems:
> >
> > It's not reliable - we continue the data transfer after poll_politely2
> > returns zero but we don't know if it retu
VT6420 seems to have the same hotplug capability as VT6421.
However, enabling hotplug needs to expose SCR registers which can cause
problems. It works for me but might break elsewhere. So add a module
parameter vt6420_hotplug to enable this feature.
Signed-off-by: Ondrej Zary
---
drivers/ata
NCR5380: Limit sg_tablesize to avoid PDMA read overruns on DTC436
> g_NCR5380: Cleanup comments and whitespace
>
> Ondrej Zary (3):
> g_NCR5380: Fix PDMA transfer size
> g_NCR5380: End PDMA transfer correctly on target disconnection
> g_NCR5380: Re-work P
on DTC and non-DTC
chips. I get many of these messages with CD-ROM:
[ 912.397076] generic_NCR5380_pread: No end dma signal (4096/4096)
[ 913.141225] generic_NCR5380_pread: No end dma signal (4096/4096)
Maybe just remove this error message as in my original patch?
--
Ondrej Zary
to be fixed.
--
Ondrej Zary
, vt642x_interrupt,
IRQF_SHARED, &svia_sht);
else
return ata_host_activate(host, pdev->irq, ata_bmdma_interrupt,
--
Ondrej Zary
ess (required for detecting hotplug
events) can cause problems on these chips.
For now, just keep hotplug disabled on anything other than VT6421.
Signed-off-by: Ondrej Zary
---
drivers/ata/sata_via.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/d
On Sunday 19 February 2017 00:27:55 Finn Thain wrote:
> On Sat, 18 Feb 2017, Ondrej Zary wrote:
> > On Friday 17 February 2017 23:38:12 Finn Thain wrote:
> > > On Thu, 16 Feb 2017, Ondrej Zary wrote:
> > > > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
>
On Friday 17 February 2017 23:38:12 Finn Thain wrote:
> On Thu, 16 Feb 2017, Ondrej Zary wrote:
> > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> > [...]
> >
> > > Are you trying to figure out which commands are going to disconnect
> > > during a
g" stops after a while. I get
gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
When I enable interrupts during PDMA (like the removed UNSAFE macro did), the
problems go away. I see an IRQ after each pread call.
(had to disable "no 53C80 gated irq after transfer" and "no end dma
On Tuesday 14 February 2017 20:28:56 David Miller wrote:
> From: Ondrej Zary
> Date: Mon, 13 Feb 2017 23:45:47 +0100
>
> > Even though the port autoselection is enabled by default on AM79C970A,
> > BNC/AUI port does not work because the link is always reported to be
>
Move the code to clear SUSPEND flag to a separate function to simplify
code.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/amd/pcnet32.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet
ected. When the
port autoselection is enabled or AUI port is selected, report the link
as always up.
Move pcnet32_suspend() and pcnet32_clr_suspend() functions to avoid
forward declarations.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/amd/pcnet32.c | 177 +-
On Sunday 29 January 2017 02:05:02 Finn Thain wrote:
> On Sat, 28 Jan 2017, Ondrej Zary wrote:
> > On Monday 16 January 2017 00:50:57 Finn Thain wrote:
> > > This series removes some unused code and related comments, addresses
> > > the warnings generated by 'make
?
Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip), DTC-3181L
(DTCT-436P chip) and MS-PNR (53C400A chip) ISA cards - everything works fine!
Targets tested:
QUANTUM LP240S GM240S01X
IBM DORS-32160
IBM 0663L12
Thanks.
Tested-by: Ondrej Zary
--
Ondrej Zary
On Monday 05 December 2016 07:07:19 Finn Thain wrote:
> This patch series is based on the one submitted recently by Ondrej Zary.
>
> This version has a different irq probing fix for HP C2502 boards and
> a more comprehensive patch to change the default irq parameter.
>
> It needs
> > sees the Logitech RX250 as being a BYD TouchPad and thus alters the
> > vendor and model names.
> >
> > I do not know if it is also desirable to add an entry for a Logitech
> > model 115 in get_model_info in logips2pp.c
> > (drivers/input/mouse/logips2pp.c). But if so, I would be willing to
> > test any such new code. Even as an unknown Logitech model, it does
> > work just fine. I am curious as to how the tilt feature buttons would
> > be declared in the model info (would these be PS2PP_EXTRA_BTN,
> > or PS2PP_NAV_BTN, etc.?)
> >
> >
> >
> > Cheers and thanks in advance,
> >
> > Mike Shell
The BYD detection is broken. I've seen at least 3 different mice detected as
BYD touchpad.
--
Ondrej Zary
On Thursday 03 November 2016, Finn Thain wrote:
> On Wed, 2 Nov 2016, Ondrej Zary wrote:
> > > Also, you've ignored the irq module parameters. From the user's point
> > > of view, surely the least surprising thing is to attempt to configure
> > > the
On Wednesday 02 November 2016 08:45:26 Finn Thain wrote:
> On Mon, 31 Oct 2016, Ondrej Zary wrote:
> > Trigger an IRQ first with a test IRQ handler to find out if it really
> > works. Disable the IRQ if not.
> >
> > This prevents hang when incorrect IRQ was specified b
On Wednesday 02 November 2016, Finn Thain wrote:
> On Mon, 31 Oct 2016, Ondrej Zary wrote:
> > Find free and working IRQ automatically on HP C2502 cards.
> > Also allow IRQ 9 to work (aliases to IRQ 2 on the card).
> >
> > Signed-off-by: Ondrej Zary
> > ---
>
On Wednesday 02 November 2016, Finn Thain wrote:
> On Mon, 31 Oct 2016, Ondrej Zary wrote:
> > Use standard probe_irq_on() and probe_irq_off() functions instead of own
> > implementation. This prevents warning messages like this in the kernel
> > log: genirq: Flags mismatch
When a SW-configurable card is specified but not found, the driver
releases wrong region, causing the following message in kernel log:
Trying to free nonexistent resource <-000f>
Fix it by assigning base earlier.
Signed-off-by: Ondrej Zary
---
drivers/scsi/g_N
Hello,
this patch series improves IRQ probing and moves it from NCR5380 to
g_NCR5380, adds IRQ auto-configuration for HP C2502 and enables all
this by default. It also adds IRQ and base address checks to prevent
hangs when wrong values are specified by user. There's also a small
release region fix
purposes (testing if the IRQ works) and move the code from
NCR5380 to g_NCR5380.
Also add missing IRQ reset before and after the probe.
Signed-off-by: Ondrej Zary
---
drivers/scsi/NCR5380.c | 77 +-
drivers/scsi/NCR5380.h |1 -
drivers/scsi
Write and read back MODE_REG to check if the chip is really there
before doing more initialization.
This prevents hang when incorrect I/O address was specified by user (in
the most common case where no device is present there so all reads
result in 0xff).
Signed-off-by: Ondrej Zary
---
drivers
Trigger an IRQ first with a test IRQ handler to find out if it really
works. Disable the IRQ if not.
This prevents hang when incorrect IRQ was specified by user.
Signed-off-by: Ondrej Zary
---
drivers/scsi/g_NCR5380.c | 44 +---
1 file changed, 41
IRQ probing seems to work fine now. Default to autoprobe for IRQ instead
of disabling it.
Signed-off-by: Ondrej Zary
---
drivers/scsi/g_NCR5380.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 27fc499..6a08d3e
Find free and working IRQ automatically on HP C2502 cards.
Also allow IRQ 9 to work (aliases to IRQ 2 on the card).
Signed-off-by: Ondrej Zary
---
drivers/scsi/g_NCR5380.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/g_NCR5380
On Monday 31 October 2016, Finn Thain wrote:
> On Sun, 30 Oct 2016, Ondrej Zary wrote:
> > Trigger an IRQ first with a test IRQ handler to find out if it really
> > works. Disable the IRQ if not.
> >
> > This prevents hang when incorrect IRQ was specified by user.
&g
On Monday 31 October 2016, Finn Thain wrote:
> On Sun, 30 Oct 2016, Ondrej Zary wrote:
> > Use standard probe_irq_on() and probe_irq_off() functions instead of own
> > implementation.
>
> Thanks for doing this.
>
> > This prevents warning messages like this in the
On Monday 31 October 2016, Finn Thain wrote:
> On Sun, 30 Oct 2016, Ondrej Zary wrote:
> > Read back MODE_REG after writing it in NCR5380_init() to check if the
> > chip is really there.
> >
> > This prevents hang when incorrect I/O address was specified by user.
> &g
Read back MODE_REG after writing it in NCR5380_init() to check if the
chip is really there.
This prevents hang when incorrect I/O address was specified by user.
Signed-off-by: Ondrej Zary
---
drivers/scsi/NCR5380.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi
1 - 100 of 605 matches
Mail list logo
