Bug#411696: linux-2.6: r8169
Package: linux-2.6 Severity: important When attempting to install with d-i daily builds (or hand built d-i images) via the network I find that I am unable to use r8189 network controllers which had ethernet cables connected at modprobe time. The system detects the three r8169 controllers that are present and detects link state on them correctly (as reported in dmesg). ifconfig reports that an ethernet controller which had the cable connected at modprobe time has dropped a small number of transmitted packets and 0x (roughly) received packets with no successful traffic. Controllers not cabled at modprobe time appear to work with no ill effects. uname -r reports this as version 2.6.18-4-486. This appeared to work fine with 2.6.18-3-486. Severity important since this has a major effect on d-i usability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415476: natsemi: Fix for interrupt sharing issue
Package: linux-image-2.6.18-4
Severity: important
Tags: patch
Kernel 2.6.18 contains a version of the natsemi driver which supports
NAPI but has buggy handling of shared interrupts. The patch below
(which is a slightly cut down version of one which has been accepted
upstream, omitting reversion of another change which worked around this
problem) fixes this. The active part of the patch is the very first
chnage.
Severity important since this can cause the driver to hang on machines
where a natsemi device shares an interrupt.
Subject: natsemi: Fix NAPI for interrupt sharing
The interrupt status register for the natsemi chips is clear on read and
was read unconditionally from both the interrupt and from the NAPI poll
routine, meaning that if the interrupt service routine was called (for
example, due to a shared interrupt) while a NAPI poll was scheduled
interrupts could be missed. This patch fixes that by ensuring that the
interrupt status register is only read by the interrupt handler when
interrupts are enabled from the chip.
Thanks to Sergei Shtylyov [EMAIL PROTECTED] for spotting the
issue, Mark Huth [EMAIL PROTECTED] for a simpler method and Simon
Blake [EMAIL PROTECTED] for testing resources.
Index: linux-2.6/drivers/net/natsemi.c
===
--- linux-2.6.orig/drivers/net/natsemi.c2007-03-11 02:32:43.0
+
+++ linux-2.6/drivers/net/natsemi.c 2007-03-13 19:38:31.0 +
@@ -2119,28 +2119,35 @@
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
- if (np-hands_off)
+ /* Reading IntrStatus automatically acknowledges so don't do
+* that while interrupts are disabled, (for example, while a
+* poll is scheduled). */
+ if (np-hands_off || !readl(ioaddr + IntrEnable))
return IRQ_NONE;
- /* Reading automatically acknowledges. */
np-intr_status = readl(ioaddr + IntrStatus);
+ if (!np-intr_status)
+ return IRQ_NONE;
+
if (netif_msg_intr(np))
printk(KERN_DEBUG
%s: Interrupt, status %#08x, mask %#08x.\n,
dev-name, np-intr_status,
readl(ioaddr + IntrMask));
- if (!np-intr_status)
- return IRQ_NONE;
-
prefetch(np-rx_skbuff[np-cur_rx % RX_RING_SIZE]);
if (netif_rx_schedule_prep(dev)) {
/* Disable interrupts and register for poll */
natsemi_irq_disable(dev);
__netif_rx_schedule(dev);
- }
+ } else
+ printk(KERN_WARNING
+ %s: Ignoring interrupt, status %#08x, mask %#08x.\n,
+ dev-name, np-intr_status,
+ readl(ioaddr + IntrMask));
+
return IRQ_HANDLED;
}
@@ -2156,6 +2163,12 @@
int work_done = 0;
do {
+ if (netif_msg_intr(np))
+ printk(KERN_DEBUG
+ %s: Poll, status %#08x, mask %#08x.\n,
+ dev-name, np-intr_status,
+ readl(ioaddr + IntrMask));
+
if (np-intr_status
(IntrTxDone | IntrTxIntr | IntrTxIdle | IntrTxErr)) {
spin_lock(np-lock);
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429662: linux-image-2.6.21-1-powerpc: Suspend fails on PowerBook
Package: linux-image-2.6.21-1-powerpc Version: 2.6.21-4 Severity: important Since upgrading to this kernel version any attempt to suspend my laptop has failed. The machine begins to suspend, complains that it cannot suspend and then attempts to abort the suspend but fails to do so, forcing a manual reset. Both aspects of this are a problem - the failure to abort is a more serious issue for me since it can cause data loss. When I have access to something I can use to capture the console output I will provie that, unfortunately I don't have anything right now. The machine is: processor : 0 cpu : 7447A, altivec supported clock : 749.999000MHz revision: 0.1 (pvr 8003 0101) bogomips: 36.73 timebase: 18432000 platform: PowerMac machine : PowerBook5,4 motherboard : PowerBook5,4 MacRISC3 Power Macintosh detected as : 287 (PowerBook G4 15) pmac flags : 001b L2 cache: 512K unified pmac-generation : NewWorld -- Package-specific info: ** Version: Linux version 2.6.21-1-powerpc (Debian 2.6.21-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070518 (prerelease) (Debian 4.1.2-8)) #1 Sat May 26 14:30:26 CEST 2007 ** Not tainted ** Kernel log: Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0001:10:13.0, mfunc 0x1002, devctl 0x60 Yenta: ISA IRQ mask 0x, PCI irq 53 Socket status: 3087 pcmcia: parent PCI bridge I/O window: 0x0 - 0x7f pcmcia: parent PCI bridge Memory window: 0xf300 - 0xf3ff pcmcia: parent PCI bridge Memory window: 0x8000 - 0xafff bcm43xx driver PCI: Enabling device 0001:10:12.0 (0004 - 0006) bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Number of cores: 5 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243 bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243 bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243 bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Analog: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off ieee1394: Initialized config rom entry `ip1394' PCI: Enabling device 0001:10:1b.2 (0004 - 0006) ehci_hcd 0001:10:1b.2: EHCI Host Controller ehci_hcd 0001:10:1b.2: new USB bus registered, assigned bus number 4 ehci_hcd 0001:10:1b.2: irq 63, io mem 0xa000 ehci_hcd 0001:10:1b.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized PowerMac i2c bus pmu 2 registered PowerMac i2c bus pmu 1 registered PowerMac i2c bus mac-io 0 registered PowerMac i2c bus uni-n 1 registered PowerMac i2c bus uni-n 0 registered sungem.c:v0.98 8/24/03 David S. Miller ([EMAIL PROTECTED]) PHY ID: 1410cc1, addr: 0 eth1: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:0d:93:c1:97:b6 eth1: Found Marvell 88E PHY PCI: Enabling device 0002:24:0e.0 ( - 0002) ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[40] MMIO=[f500-f50007ff] Max Packet=[4096] IR/IT contexts=[8/8] Bluetooth: HCI USB driver ver 2.9 hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, (U)DMA Uniform CD-ROM driver Revision: 3.20 usbcore: registered new interface driver hci_usb snd-aoa-fabric-layout: found bus with layout 51 snd-aoa-fabric-layout: Using direct GPIOs snd-aoa-codec-tas: found 'deq' node snd-aoa-fabric-layout: can use this codec snd-aoa-codec-tas: tas found, addr 0x35 on /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] ieee1394: Host added: ID:BUS[0-00:1023] GUID[000d93fffec197b6] eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) Adding 500644k swap on /dev/hda6. Priority:-1 extents:1 across:500644k EXT3 FS on hda3, internal journal SCSI subsystem initialized snd-powermac no longer handles any machines with a layout-id property in the device-tree, use snd-aoa. apm_emu: APM Emulation 0.5 initialized. device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. audit(1182253431.182:2): audit_pid=1937 old=0 by auid=4294967295 NET: Registered protocol family 10 lo: Disabled Privacy Extensions Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8
Bug#429662: Acknowledgement (linux-image-2.6.21-1-powerpc: Suspend fails on PowerBook)
reassign 429662 linux-image-2.6.22-1-powerpc found 429662 2.6.22-3 thanks On Thu, Jul 05, 2007 at 12:39:16PM +0100, Mark Brown wrote: Suspending via closing the laptop lid appears to have been fixed by 2.6.21-2-powerpc but if I try to initiate a suspend from the GNOME power manager GUI then that still fails (although it does not hang the The problem has reverted to the previous unrecoverable crash with the above versions. If I blacklist the hci_usb module then the system appears to resume just fine without the suspicious failure to suspend in the logging that I reported with 2.6.21. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Bug#436260: linux-support-2.6.22-1: Support for exernal module packages broken
Package: linux-support-2.6.22-1 Version: 2.6.22-3 Severity: important Attempting to build a module module package such as linux-modules-extra-2.6 which uses gencontrol.py fails even when using the copy of gencontrol.py included in the package as /usr/src/linux-support-2.6.22-1/modules/gencontrol.py since the interface provided by lib/python/debian_linux has changed but gencontrol.py has not been updated to match the new interface. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.22-1-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-support-2.6.22-1 depends on: ii python2.4-minimal 2.4.4-5A minimal subset of the Python lan linux-support-2.6.22-1 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436260: Acknowledgement (linux-support-2.6.22-1: Support for exernal module packages broken)
tag 436260 + patch
thanks
The enclosed gencontrol.py for use in module packages probably fixes
interoperation with module packages for current kernel versions. It
appears to work for me but I have relatively little confidence in my
changes given that I don't particularly understand the changes that I'm
adapting for.
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
#!/usr/bin/env python2.4
import sys
sys.path.append(sys.argv[1] + /lib/python)
from debian_linux.gencontrol import Gencontrol
from debian_linux.gencontrol import PackagesList
from debian_linux.config import *
from debian_linux.debian import *
from debian_linux.config import ConfigParser
class gencontrol(Gencontrol):
def __init__(self, config):
Gencontrol.__init__(self, config)
self.process_config_version(ConfigParser({}, [sys.argv[1] + /version]))
def __call__(self):
packages = PackagesList()
makefile = [('.NOTPARALLEL:', ())]
self.do_source(packages)
self.do_main(packages, makefile)
self.do_extra(packages, makefile)
self.write_control(packages.itervalues())
self.write_makefile(makefile)
def do_main_packages(self, packages, extra):
vars = self.vars
main = self.templates[control.main]
packages.extend(self.process_packages(main, vars))
packages['source']['Build-Depends'].extend(
['linux-support-%s%s' % (self.version.upstream, self.abiname)]
)
packages['source']['Build-Depends'].extend(
['linux-headers-%s%s-all-%s [%s]' % (self.version.upstream, self.abiname, arch, arch)
for arch in self.config['base',]['arches']],
)
def do_flavour(self, packages, makefile, arch, subarch, flavour, vars, makeflags, extra):
config_entry = self.config.merge('base', arch, subarch, flavour)
if config_entry.get('modules', True) is False:
return
Gencontrol.do_flavour(self, packages, makefile, arch, subarch, flavour, vars, makeflags, extra)
def do_flavour_packages(self, packages, makefile, arch, subarch, flavour, vars, makeflags, extra):
modules = self.templates[control.modules]
modules = self.process_packages(modules, vars)
for package in modules:
name = package['Package']
if packages.has_key(name):
package = packages.get(name)
package['Architecture'].append(arch)
else:
package['Architecture'] = [arch]
packages.append(package)
makeflags_string = ' '.join([%s='%s' % i for i in makeflags.iteritems()])
cmds_binary_arch = []
cmds_binary_arch.append(($(MAKE) -f debian/rules.real binary-arch-flavour %s % makeflags_string,))
cmds_build = []
cmds_build.append(($(MAKE) -f debian/rules.real build %s % makeflags_string,))
cmds_setup = []
cmds_setup.append(($(MAKE) -f debian/rules.real setup-flavour %s % makeflags_string,))
makefile.append((binary-arch-%s-%s-%s-real: % (arch, subarch, flavour), cmds_binary_arch))
makefile.append((build-%s-%s-%s-real: % (arch, subarch, flavour), cmds_build))
makefile.append((setup-%s-%s-%s-real: % (arch, subarch, flavour), cmds_setup))
def process_config_version(self, config):
entry = config['version',]
self.version = VersionLinux(entry['source'])
self.abiname = entry['abiname']
self.vars = self.process_version_linux(self.version, self.abiname)
if __name__ == '__main__':
gencontrol(sys.argv[1] + /arch)()
signature.asc
Description: Digital signature
Bug#436260: Acknowledgement (linux-support-2.6.22-1: Support for exernal module packages broken)
tag 436260 + patch
kthxbye
On Tue, Aug 07, 2007 at 06:41:56PM +0200, Bastian Blank wrote:
severity 436260 normal
I don't understand why you have lowered the severity here - currently it
appears to be impossible to build out of tree modules which use the
build infrastructure provided by the kernel team.
On Mon, Aug 06, 2007 at 08:03:13PM +0100, Mark Brown wrote:
tag 436260 + patch
There is no patch attached.
Sorry, here's the updated gencontrol.py. I've not generated a patch
since I don't really know what to generate it against.
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
#!/usr/bin/env python2.4
import sys
sys.path.append(sys.argv[1] + /lib/python)
from debian_linux.gencontrol import Gencontrol
from debian_linux.gencontrol import PackagesList
from debian_linux.config import *
from debian_linux.debian import *
from debian_linux.config import ConfigParser
class gencontrol(Gencontrol):
def __init__(self, config):
Gencontrol.__init__(self, config)
self.process_config_version(ConfigParser({}, [sys.argv[1] + /version]))
def __call__(self):
packages = PackagesList()
makefile = [('.NOTPARALLEL:', ())]
self.do_source(packages)
self.do_main(packages, makefile)
self.do_extra(packages, makefile)
self.write_control(packages.itervalues())
self.write_makefile(makefile)
def do_main_packages(self, packages, extra):
vars = self.vars
main = self.templates[control.main]
packages.extend(self.process_packages(main, vars))
packages['source']['Build-Depends'].extend(
['linux-support-%s%s' % (self.version.upstream, self.abiname)]
)
packages['source']['Build-Depends'].extend(
['linux-headers-%s%s-all-%s [%s]' % (self.version.upstream, self.abiname, arch, arch)
for arch in self.config['base',]['arches']],
)
def do_flavour(self, packages, makefile, arch, subarch, flavour, vars, makeflags, extra):
config_entry = self.config.merge('base', arch, subarch, flavour)
if config_entry.get('modules', True) is False:
return
Gencontrol.do_flavour(self, packages, makefile, arch, subarch, flavour, vars, makeflags, extra)
def do_flavour_packages(self, packages, makefile, arch, subarch, flavour, vars, makeflags, extra):
modules = self.templates[control.modules]
modules = self.process_packages(modules, vars)
for package in modules:
name = package['Package']
if packages.has_key(name):
package = packages.get(name)
package['Architecture'].append(arch)
else:
package['Architecture'] = [arch]
packages.append(package)
makeflags_string = ' '.join([%s='%s' % i for i in makeflags.iteritems()])
cmds_binary_arch = []
cmds_binary_arch.append(($(MAKE) -f debian/rules.real binary-arch-flavour %s % makeflags_string,))
cmds_build = []
cmds_build.append(($(MAKE) -f debian/rules.real build %s % makeflags_string,))
cmds_setup = []
cmds_setup.append(($(MAKE) -f debian/rules.real setup-flavour %s % makeflags_string,))
makefile.append((binary-arch-%s-%s-%s-real: % (arch, subarch, flavour), cmds_binary_arch))
makefile.append((build-%s-%s-%s-real: % (arch, subarch, flavour), cmds_build))
makefile.append((setup-%s-%s-%s-real: % (arch, subarch, flavour), cmds_setup))
def process_config_version(self, config):
entry = config['version',]
self.version = VersionLinux(entry['source'])
self.abiname = entry['abiname']
self.vars = self.process_version_linux(self.version, self.abiname)
if __name__ == '__main__':
gencontrol(sys.argv[1] + /arch)()
signature.asc
Description: Digital signature
Bug#411696: r8169: Fails on interfaces cabled at modprobe
On Tue, May 13, 2008 at 01:46:51AM +0200, maximilian attems wrote: humm is that reproducible with a recent Lenny kernel? thanks for update. I left the job where I had access to the hardware about seven months ago. I seem to remember we were able to avoid the issue by using 2.6.22 or so so I'd guess it's OK with 2.6.24 but can't test. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429662: linux-image-2.6.21-1-powerpc: Suspend fails on PowerBook
On Wed, May 21, 2008 at 08:59:23PM +0200, maximilian attems wrote: can we have an update on a recent linux image aka 2.6.25 from sid installs just fine in testing. thanks I do not currently run Linux on the affected machine. I could test with a d-i image? -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436260: closed by maximilian attems m...@stro.at (Re: linux-support-2.6.22-1: Support for exernal module packages broken)
On Wed, Nov 12, 2008 at 11:03:55PM +0100, Moritz Muehlenhoff wrote: On Mon, Jun 30, 2008 at 02:13:33PM +0200, maximilian attems wrote: if you can reproduce it with 2.6.25 or newer snapshots. i'm all ears unless so it is assumed fixed. Mark, does the problem still exist for you with the current Lenny packages? Given that it took until six months after I'd left the job where I encountered the bug for the patch to get looked at you may as well close it - I don't really have the combination of time and enthusiam required to do so myself. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436260: closed by maximilian attems [EMAIL PROTECTED] (Re: linux-support-2.6.22-1: Support for exernal module packages broken)
reopen 436260 thanks On Sun, Jun 29, 2008 at 03:48:07PM +, Debian Bug Tracking System wrote: closing as this general assumption seems not true quite a bunch of external modules is build. As far as I remember (this was all quite some time ago) the external module packages were all using forked copies of this code; IIRC the patch I have provided largely merged these in. also report against old version. That's because I've not seen any response to this report in the intervening period of time. It's possible that you've provided a suitable interface in the meantime but it's possible that this was resolved - I seem to remember that many of the packages didn't build at the time. I'd at least like to see some sort of response to the patch I've provided and discussion as to how this has been resolved. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436260: closed by maximilian attems [EMAIL PROTECTED] (Re: linux-support-2.6.22-1: Support for exernal module packages broken)
On Sun, Jun 29, 2008 at 11:01:43PM +0200, maximilian attems wrote: there was no patch provided nor any proof of any trouble by your side, so tagging with moreinfo and willl close in 10 days unless something substantial comes up. Uh, message 10 of the bug report contains the updated version of gencontrol.py that I provided and I wasn't exactly overburdened with requests for additional information... 2.6.22 is really old and keeping cruft lying around helps noone. On the other hand, ignoring bugs for the best part of a year and then closing them on the basis that you haven't done anything about them doesn't exactly help either. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#576564: linux-image-2.6.32-3-686: ali5451 - no sound after resuming from suspend
On Mon, Apr 05, 2010 at 07:49:23PM +0100, Ben Hutchings wrote: On Mon, 2010-04-05 at 20:00 +0300, Rami Autiom??ki wrote: My laptop suspends and resumes find, but sound is not working after computer is suspended and resumed. I compiled vanilla kernel 2.6.33.2 from kernel.org, after suspending sound fails similarly with this kernel also. I can fix sound by running as root alsa force-reload . This bug has apparently been known to the ALSA project for nearly 3 years, but no-one is working on it: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=959 (note, the SSL certificate for this site has expired; you will need to accept it temporarily) You can try adding your information there in case this get some attention from ALSA developers. Unfortunately we will not be able to fix this without their help. For ALSA bugs it's much more likely to be useful to report them upstream by sending them to alsa-de...@alsa-project.org with a CC Takashi Iwai ti...@suse.de - the ALSA bug tracker is pretty much ignored by both desktop and embedded ALSA developers these days (and we really should shut it down, I'll try to remember to bring that up on the list soon). -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405213421.gb22...@sirena.org.uk
Re: RFC: Bug handling policy
On Wed, Oct 21, 2009 at 01:21:20PM +0100, Martin Michlmayr wrote: Another exception that should be added here is for devices which have well-defined hardware components. For example, I don't need hardware information for a QNAP TS-209 because it's a consumer NAS machine and you cannot change internal components. Of course having the output of the bug script won't help, but we shouldn't close such bugs just because it's not included. Though even there there's often things like USB devices which result in variation in the hardware configuration. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: s3c24xx kernel flavour
On Tue, Jun 08, 2010 at 02:02:48PM +0200, Bastian Blank wrote: On Tue, Jun 08, 2010 at 11:31:41AM +0200, Thibaut Girka wrote: X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=470379585be3e2e116e9412e114698debb02eb9e MFD: pcf50633: Fix bitfield logic in interrupt handler Those constants are alreay bitfields. This is a different to the commit done in Linux (0aeee5d4f6aa9bd28373907727937b7935d0434c). Why was this not fixed via stable? Sending stuff to stable is a bit intermittet for embedded devices, especially when the people running into problems are already carrying large patch sets for basic device functionality. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100608134040.gc7...@sirena.org.uk
Bug#618319: linux-image-2.6.37-2-amd64: Framebuffer issues with RV620
Package: linux-2.6 Version: 2.6.37-2 Severity: normal As soon as the kernel switches to framebuffer mode on 2.6.37-2-amd64 the display becomes unrecoverably corrupted though everything appears to continue to run fine and a reboot can be initiated. With 2.6.32-5-amd64 the display appears fine. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Precision WorkStation T7500 product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: A07 board_vendor: Dell Inc. board_name: 06FW8P board_version: A00 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 5520 I/O Hub to ESI Port [8086:3406] (rev 22) Subsystem: Dell Device [1028:026d] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 11 Capabilities: access denied 00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 [8086:3408] (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 Memory behind bridge: f7a0-f7af Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 [8086:340a] (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f7d0-f7ef Prefetchable memory behind bridge: d000-dfff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:07.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 [8086:340e] (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: f7b0-f7cf Prefetchable memory behind bridge: e000-efff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:14.0 PIC [0800]: Intel Corporation 5520/5500/X58 I/O Hub System Management Registers [8086:342e] (rev 22) (prog-if 00 [8259]) Subsystem: Device [0028:006d] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Capabilities: access denied 00:14.1 PIC [0800]: Intel Corporation 5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers [8086:3422] (rev 22) (prog-if 00 [8259]) Subsystem: Device [0028:006d] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Capabilities: access denied 00:14.2 PIC [0800]: Intel Corporation 5520/5500/X58 I/O Hub Control Status and RAS Registers [8086:3423] (rev 22) (prog-if 00 [8259]) Subsystem: Device [0028:006d] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
Bug#618319: Acknowledgement (linux-image-2.6.37-2-amd64: Framebuffer issues with RV620)
On Mon, Mar 14, 2011 at 11:15:04AM +, Debian Bug Tracking System wrote: If you wish to submit further information on this problem, please send it to 618...@bugs.debian.org. This appears to be resolved by 2.6.38-rc7. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314131339.gb2...@opensource.wolfsonmicro.com
Bug#618319: linux-image-2.6.37-2-amd64: Framebuffer issues with RV620
On Mon, Mar 14, 2011 at 01:24:26PM +, Ben Hutchings wrote: I notice that this system is using the radeon driver but does not have the Radeon firmware installed. On older hardware the firmware is only needed for 3D acceleration, but I suspect that other functions also depend on it now. (And I've also seen some weird display glitches on a fairly old Mac when the firmware was not installed.) So, try installing firmware-linux-nonfree, if it doesn't offend your sensibilities. As well as upgrading to the new kernel I installed the firmware (since the new kernel prompted for firmware for the video card which hadn't been mentioned previously). Some combination of the two has resolved the issue for me. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314132716.gc2...@opensource.wolfsonmicro.com
Re: Bits from the kernel team
On Mon, Dec 21, 2009 at 01:56:05AM +, Ben Hutchings wrote: On Mon, 2009-12-21 at 09:24 +0800, Paul Wise wrote: I guess oss4-dkms will be enough to take care of these users, hopefully it will reach squeeze in time. Hopefully not. OSS4 on Linux is part of the problem, not part of the solution. Linux applications should not use /dev/dsp any more. Those that do may be handled by some kind of bridge to ALSA, which was what Something CUSE based, for example, or one of the existing LD_PRELOAD hacks. Replacing the OSS emulation with something that throws the data back out to userspace would also work, I guess. this item refers to. (The existing snd-pcm-oss and snd-mixer-oss don't seem to be good enough.) Specifically since they are in kernel they don't (and can't really) play at all with any userspace ALSA stuff such as DSP, PulseAudio or the various network and wireless I/O drivers that are implemented in userspace. They also cause pain for the standard ALSA drivers since the mismatch between the OSS and ALSA configuration APIs results in ALSA drivers having to jump through hoops for the benefit of the OSS emulation, and the OSS configuration model is just too limited to express the control available on many modern systems. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 07, 2011 at 05:15:07PM -0500, Michael Gilbert wrote: On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote: What does that buy us? ??It means instead of dealing with bugs on an ongoing basis, you get them all at the same time and get to bisect along many kernel versions at once instead of just one. ??It means problems don't get reported (and fixed) upstream until it's too late. ??It means any package that could use a newer kernel interface doesn't get any testing. ??I'm sure there's plenty of others. Bugs can be submitted and dealt with in experimental just as well as in unstable. Realistically people don't generally go randomly installing things from experimental so the testing coverage we get from having unstable and testing is substantially reduced - we get to deal with everything in the freeze instead, plus all the effects of running an old kernel which isn't being actively developed. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208130359.gc29...@sirena.org.uk
Re: ARM kernel config for Linux 3.11
On Mon, Sep 16, 2013 at 10:11:47AM +0200, Arnaud Patard wrote: exynos in armmp won't happen anytime soon unless you bug upstream about multiplatform support. iirc, even in -next, it's still not possible to enable exynos in multiplatform builds. It does mostly work with mainline, audio still needs doing but other than that it should be good now. Older Samsung SoCs still have work needed but the newer ones should be multiplatform safe. signature.asc Description: Digital signature
Re: Build failure for armhf/armmp, linux 3.11-rc4
On 16 August 2013 09:42, Ben Hutchings b...@decadent.org.uk wrote: Please use the advertised e-mail addresses for maintainers. On Thu, 2013-08-15 at 19:16 -0500, Robert Nelson wrote: This is fixed in the sound next branch: https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=for-nextid=3f1a91aa25579ba5e7268a47a73d2a83e4802c62 The explanation doesn't make sense to me. And if these files are built and then loaded as modules, they will taint the kernel as they have no MODULE_LICENSE. I doubt many people are actually building them as modules except for compile testing or with another reason for the kernel to be tainted. CONFIG_SND_SOC_IMX_AUDMUX=m CONFIG_SND_SOC_EUKREA_TLV320=m # CONFIG_SND_SOC_IMX_WM8962 is not set There seem to be a reasonable number of boards out there using that driver.
Re: Build failure for armhf/armmp, linux 3.11-rc4
On Sat, Aug 17, 2013 at 06:25:44PM +0200, Ben Hutchings wrote: On Fri, 2013-08-16 at 11:34 +0100, Mark Brown wrote: Please use the advertised e-mail addresses for maintainers. Expand, please? I took your address from the commit that Robert pointed out. You're better off with MAINTAINERS - several people advertise and use non-work e-mail addresses but sign off with a work one. I doubt many people are actually building them as modules except for compile testing or with another reason for the kernel to be tainted. In a multi-platform config I think this will now be the *normal* state, as the dependent drivers should be modules. The point is that I rather doubt anyone working on the drivers cares so long as they build in modular configurations. I'm still failing to see *how* that fix works, anyway. Seems like a workaround for some other problem. Could you be more specific as to what you believe the problem that exists is? You mentioned that the kernel would be tainted but that doesn't seem like a not working thing... signature.asc Description: Digital signature
Re: Build failure for armhf/armmp, linux 3.11-rc4
On Tue, Aug 20, 2013 at 01:39:40AM +0200, Ben Hutchings wrote:
On Mon, 2013-08-19 at 11:41 +0100, Mark Brown wrote:
Could you be more specific as to what you believe the problem that
exists is? You mentioned that the kernel would be tainted but that
doesn't seem like a not working thing...
The problem explained in the commit message for commit
3f1a91aa25579ba5e7268a47a73d2a83e4802c62.
That's ASoC: fsl: Fix module build.
imx-pcm-{dma,fiq}.o are exporting various symbols used by
snd-soc-{fsl,imx}-ssi.o. Obviously, a module can use symbols exported
from both built-in and modular code. And yet for some reason this
didn't work when the exports were built-in and did work when they were
built as modules.
I'm afraid I still lack the context to understand what the issue you're
trying to report here is, possibly because I've forgotten some of the
context from earlier on in the thread. That commit is fixing the fact
that the relevant functions were ifdefed with CONFIG_FOO but not
CONFIG_FOO_MODULE but it seems to fix that fairly directly?
signature.asc
Description: Digital signature
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 06, 2013 at 02:01:14AM +0200, Tomasz Figa wrote: I don't see any other solution here than moving all the Allwinner code to DT (as it has been suggested in this thread several times already), as this is the only hardware description method supported by ARM Linux. Well, the server guys are working on ACPI - people could contribute to that effort instead if they preferred (though I can see that they might not!). signature.asc Description: Digital signature
Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
On Sun, Sep 14, 2014 at 06:10:24PM +0100, Ben Hutchings wrote: The first patch in the series restores the module aliases to m25p80, but it does so by duplicating the list of names. This should be suitable for stable, but it isn't viable in the longer term. Please don't CC patches not for the SPI subsystem to linux-spi, they just clog up patchwork for no benefit. signature.asc Description: Digital signature
Re: [PATCH 1/2] mtd: m25p80: get rid of spi_get_device_id
On Mon, Sep 29, 2014 at 11:47:53AM +0200, Rafał Miłecki wrote: This simplifies the way we use spi_nor framework and will allow us to drop spi_nor_match_id. Please don't CC linux-spi on spi-nor patches that don't have SPI level changes, it just clogs up patchwork. signature.asc Description: Digital signature
Bug#765685: linux-image-3.16-2-amd64: Kernel lockups with r8723au
Package: src:linux Version: 3.16.3-2 Severity: serious The staging driver r8723au is enabled in the kernel but there appear to be very good reasons why it's in staging - when it loads it routinely locks up my system (hard with no output unfortunately). It seems to make sense to disable the driver. -- Package-specific info: ** Version: Linux version 3.16-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1 SMP Debian 3.16.3-2 (2014-09-20) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16-2-amd64 root=UUID=1c8b372e-5478-46fe-84d9-efc496b4a0ce ro init=/bin/systemd quiet ** Tainted: WC (1536) * Taint on warning. * Module from drivers/staging has been loaded. ** Kernel log: [ 557.489458] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 557.489463] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 557.494527] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 557.494530] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 558.501325] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 558.501338] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 558.506380] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 558.506383] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 559.515171] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 559.515183] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 559.520204] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 559.520206] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 560.527936] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 560.527939] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 560.532991] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 560.532994] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 561.543521] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 561.543525] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 561.548556] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 561.548560] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 562.557183] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 562.557188] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 562.562215] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 562.562220] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 563.571309] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 563.571314] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 563.576374] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 563.576377] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 564.585412] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 564.585424] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 564.590447] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 564.590450] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 565.599700] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 565.599703] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 565.604736] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 565.604740] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 566.613028] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 566.613033] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 566.618109] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 566.618116] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 567.627585] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 567.627588] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 567.632636] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 567.632640] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 568.640977] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on isa0060/serio0). [ 568.640981] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 568.646030] atkbd serio0: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). [ 568.646034] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known. [ 569.656338] atkbd
Bug#765685: Acknowledgement (linux-image-3.16-2-amd64: Kernel lockups with r8723au)
I've tested this with v3.17 from experimental and the driver seems vastly more stable with that kernel version so this probably only applies to v3.16, Ben did point out to me that there had been a lot of work on the driver between the two versions. signature.asc Description: Digital signature
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 04:40:47PM +0200, Steinar H. Gunderson wrote: > On Mon, May 23, 2016 at 03:47:37PM +0200, Steinar H. Gunderson wrote: > > In this case, it's not just an annoyance, though; they're so many that they > > keep the system from booting unless loglevel is turned down. Cc-ing Mark in > > case he has any insights (I hope I have the right email address). But nobody who works on probe deferral or made any of the suggestions I mentioned in the message you linked to, nor anyone who works on the driver you've identified a bug in... :( > > I don't understand entirely why it tries 2000+ times before it succeeds > Now I do; the initramfs doesn't include i2c-exynos5, and before that is > loaded, s2mps11 (the regulator) can't come up either. > So fixing initramfs-tools to include the driver will seemingly fix (or maybe > more work around) the huge amounts of spam, but this is still a larger issue > that needs resolving. Not really, the issue you're seeing is just a plain resource leak in the driver that happens to blow up worse than normal in your particular configuration. This isn't even something related to probe deferral at the regulator level, the core is complaining that your system description is buggy as it has omitted some of the supplies for the device (notice how it says "using dummy regulator"...). This is happening a lot as the DWC3 driver is leaking, it is happening at all because when the Exynos DWC3 integration creates it PHYs it doesn't map the supplies through to them (it should be registering a supply alias to do this). The patch you linked to was for a completely different error message which is at least related to probe deferral, though fundamentally unless we just stop printing diagnostics (which is getting more and more tempting to be honest) I'm not sure anything is going to fully resolve leaks like this, the best chance you've got is something that explicitly looks at the dependencies like Raphael was proposing. signature.asc Description: PGP signature
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:26:38PM +0200, Steinar H. Gunderson wrote: > On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > > Please send an appropriate separate patch for fixing this. Your email > > did not reach people, I think. > I only sent one patch so far, namely the leak fix. You buried it in the middle of another mail and didn't CC any of the maintainers - he's asking you to submit it using the process in SubmittingPatches, the USB maintainers won't have seen this discussion and may not notice a patch buried in the middle of a message in the middle of a thread even if they see it. signature.asc Description: PGP signature
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > What other problems exactly do you have? Late binding of S2MPS11 > regulator driver? That does not look like a problem. If it is built as > a module then it should be loaded, probably from initramfs because > these are regulators. AFAICT the fact that every time the dwc3-exynos driver probes it creates a new child device which successfully instantiates means that we end up constantly running deferred probes. It should only create the child devices if it managed to get the other resources, that way we don't get the constant deferred probe retries. signature.asc Description: PGP signature
Bug#918113: linux-image-4.19.0-1-amd64: Fails to initalize DisplayPort displays with rx560
On Thu, Jan 03, 2019 at 01:49:49PM +, Mark Brown wrote: > Even with only one monitor connected the system is unable to do anything > useful with the display, it has trouble setting up a valid clock > configuration though there is no oops: > > Dec 29 17:57:14 debutante kernel: [3.561312] amdgpu :01:00.0: > firmware: direct-loading firmware amdgpu/polaris11_k_smc.bin > Dec 29 17:57:14 debutante kernel: [3.622018] EXT4-fs (sdb1): mounted > filesystem with ordered data mode. Opts: errors=remount-ro > Dec 29 18:14:17 debutante kernel: [3.482651] amdgpu: [powerplay] Failed > to retrieve minimum clocks. > Dec 29 18:14:17 debutante kernel: [3.482652] amdgpu: [powerplay] Error in > phm_get_clock_info I've confirmed that this part of the issue is fixed with the 4.20 packages in experimental, the problems with a dual monitor setup oopsing and generally failing to work that were the main focus of the report remain. signature.asc Description: PGP signature
Bug#918113: linux-image-4.19.0-1-amd64: Fails to initalize DisplayPort displays with rx560
Package: src:linux Version: 4.19.13-1 Severity: important As covered in the kernel log below the amdgpu driver fails to initialize a multi-monitor DisplayPort chain connected to a and AMD RX560 (Polaris11), rendering the system unusable in desktop configurations. There is an oops earlier in the kernel output: Jan 3 12:44:01 debutante kernel: [7.630953] WARNING: CPU: 2 PID: 69 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2293 core_link_enable_stream+0x4b3/0xb90 [am dgpu] Jan 3 12:44:01 debutante kernel: [7.630954] Modules linked in: fuse binfmt_misc nls_ascii nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp amdk fd kvm_intel kvm irqbypass crct10dif_pclmul amdgpu crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 chash gpu_sched ghash_clmulni_intel snd_hda_ intel ttm snd_hda_codec intel_cstate cp210x mei_me snd_hda_core sr_mod cdrom drm_kms_helper snd_hwdep iTCO_wdt efi_pstore intel_uncore snd_pcm usbserial intel_rapl_perf cdc_acm joydev efivars sg evdev pcspkr mei parport_serial iTCO_vendor_support snd_timer drm snd i2c_algo_bit soundcore video pcc_cpufreq button ipmi_devintf ipmi_msghandler loop nfsd parport_pc auth_rpcgss ppdev nfs_acl lp lockd parport grace sunrpc efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto btrfs Jan 3 12:44:01 debutante kernel: [7.630978] zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor usb_storage raid6_pq libcrc32c raid1 raid0 multipath linear md_mod hid_generic usbhid hid sd_mod crc32c_intel ahci libahci xhci_pci libata aesni_intel xhci_hcd ehci_pci realtek ehci_hcd a es_x86_64 i2c_i801 scsi_mod crypto_simd r8169 cryptd usbcore glue_helper libphy natsemi lpc_ich usb_common thermal fan Jan 3 12:44:01 debutante kernel: [7.630993] CPU: 2 PID: 69 Comm: kworker/2:1 Tainted: P OE 4.19.0-1-amd64 #1 Debian 4.19.12-1 Jan 3 12:44:01 debutante kernel: [7.630994] Hardware name: Gigabyte Technology Co., Ltd. H87-HD3/H87-HD3, BIOS F3 05/09/2013 Jan 3 12:44:01 debutante kernel: [7.631002] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] Jan 3 12:44:01 debutante kernel: [7.631043] RIP: 0010:core_link_enable_stream+0x4b3/0xb90 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631044] Code: ff 48 89 ef be 01 00 00 00 e8 b9 86 00 00 4c 89 ef 48 89 de e8 fe df ff ff bf c8 00 00 00 89 c5 e8 62 67 26 fb e9 ea fd ff ff <0f> 0b e9 de fe ff ff 48 8b 82 50 02 00 00 48 8b 40 50 48 8b 40 30 Jan 3 12:44:01 debutante kernel: [7.631045] RSP: 0018:a57081dd7668 EFLAGS: 00010246 Jan 3 12:44:01 debutante kernel: [7.631046] RAX: RBX: 901ca62a4188 RCX: Jan 3 12:44:01 debutante kernel: [7.631046] RDX: 0005 RSI: c2349588 RDI: 0004 Jan 3 12:44:01 debutante kernel: [7.631047] RBP: 901cb7dede00 R08: 0005 R09: Jan 3 12:44:01 debutante kernel: [7.631047] R10: R11: a57081dd75c0 R12: 901ca89ed000 Jan 3 12:44:01 debutante kernel: [7.631048] R13: 901cb7dedf90 R14: 901cb77f0400 R15: 0006 Jan 3 12:44:01 debutante kernel: [7.631048] FS: () GS:901cbe08() knlGS: Jan 3 12:44:01 debutante kernel: [7.631049] CS: 0010 DS: ES: CR0: 80050033 Jan 3 12:44:01 debutante kernel: [7.631050] CR2: 7f586f069e20 CR3: 4f20a002 CR4: 001606e0 Jan 3 12:44:01 debutante kernel: [7.631050] Call Trace: Jan 3 12:44:01 debutante kernel: [7.631095] ? dce110_stream_encoder_update_dp_info_packets+0x14c/0x200 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631133] dce110_apply_ctx_to_hw+0x63f/0x650 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631171] dc_commit_state+0x2c6/0x520 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631207] ? set_freesync_on_streams.part.6+0x4d/0x250 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631241] ? mod_freesync_set_user_enable+0x11f/0x150 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631277] amdgpu_dm_atomic_commit_tail+0x388/0xdb0 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631280] ? _cond_resched+0x15/0x30 Jan 3 12:44:01 debutante kernel: [7.631282] ? wait_for_completion_timeout+0x3b/0x1a0 Jan 3 12:44:01 debutante kernel: [7.631318] ? amdgpu_dm_atomic_commit_tail+0xdb0/0xdb0 [amdgpu] Jan 3 12:44:01 debutante kernel: [7.631325] commit_tail+0x3d/0x70 [drm_kms_helper] Jan 3 12:44:01 debutante kernel: [7.631329] drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper] Jan 3 12:44:01 debutante kernel: [7.631333] restore_fbdev_mode_atomic+0x170/0x1d0 [drm_kms_helper] Jan 3 12:44:01 debutante kernel: [7.631337] drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90 [drm_kms_helper] Jan 3 12:44:01 debutante kernel:
Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye
On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote: > On Sat, Sep 04, 2021 at 06:50:16PM +0100, Steve McIntyre wrote: > > > >I have a synquacer here still and I'll take a look. I noticed on > >bullseye release day that USB stuff didn't seem to work in the > >installer on the synquacer either. Maybe there's been a regression in > >config. :-/ > > > >I'll take a look... > > Hmmm, booting 5.10.0-0.bpo.8-arm64 here does not work at all. I'm > seeing a lot of errors around DMA setup, e.g.: I bisected this to 7a8b64d17e35810dc3176fe61208b45c15d25402 is the first bad commit commit 7a8b64d17e35810dc3176fe61208b45c15d25402 Author: Rob Herring Date: Thu Feb 6 14:02:30 2020 + of/address: use range parser for of_dma_get_range on what appears to have been a DT system with a built in DT from the firmware, using upstream's defconfig. I dimly recall seeing some discussion of issues here in the past, though I don't have one of these boxes myself so wasn't paying huge attention. I'd guess there's some bug in the DT which given that this is in the firmware the kernel ought to fix up during early init, if someone with better access to one of these systems could supply a DT for inspection that might help people figure things out. I suspect the machines might work fine when booted with ACPI firmware. The bisect log: git bisect start # bad: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7 git bisect bad 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 # good: [7111951b8d4973bda27ff663f2cf18b663d15b48] Linux 5.6 git bisect good 0ad2c0e5fc7bd5c5a60f88be1174271410254e32 # skip: [50a5de895dbe5df947b3a695777db5b2c313e065] Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma git bisect skip 50a5de895dbe5df947b3a695777db5b2c313e065 # good: [422c032afcf57d5e8109a54912e22ffc53d99068] netfilter: flowtable: Use rw sem as flow block lock git bisect good 422c032afcf57d5e8109a54912e22ffc53d99068 # skip: [8c1b724ddb218f221612d4c649bc9c7819d8d7a6] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect skip 8c1b724ddb218f221612d4c649bc9c7819d8d7a6 # bad: [88d7fcfa3b1fe670f0412b95be785aafca63352b] net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* git bisect bad 88d7fcfa3b1fe670f0412b95be785aafca63352b # skip: [6cad420cc695867b4ca710bac21fde21a4102e4b] Merge branch 'akpm' (patches from Andrew) git bisect skip 6cad420cc695867b4ca710bac21fde21a4102e4b # good: [77a36a3ab4ff17fad23831192e3694a3c5a1750d] HID: Add driver fixing Glorious PC Gaming Race mouse report descriptor git bisect good 77a36a3ab4ff17fad23831192e3694a3c5a1750d # bad: [8ec91c0fce1500306a858d0c35d1383fd9eb6ba6] Merge tag 'gpio-v5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio git bisect bad 8ec91c0fce1500306a858d0c35d1383fd9eb6ba6 # skip: [7be97138e7276c71cc9ad1752dcb502d28f4400d] Merge tag 'xfs-5.7-merge-8' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux git bisect skip 7be97138e7276c71cc9ad1752dcb502d28f4400d # bad: [f5637d3b42ab0465ef71d5fb8461bce97fba95e8] mm/memory_hotplug: rename mhp_restrictions to mhp_params git bisect bad f5637d3b42ab0465ef71d5fb8461bce97fba95e8 # skip: [f365ab31efacb70bed1e821f7435626e0b2528a6] Merge tag 'drm-next-2020-04-01' of git://anongit.freedesktop.org/drm/drm git bisect skip f365ab31efacb70bed1e821f7435626e0b2528a6 # skip: [c101e9bbce4ae2947b35a660f17d617fc3827595] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid git bisect skip c101e9bbce4ae2947b35a660f17d617fc3827595 # good: [dc8c609bd31d2b410fd47a82a7b259f68056b244] drm/rcar-du: Plug atomic state hooks to the default implementation git bisect good dc8c609bd31d2b410fd47a82a7b259f68056b244 # skip: [ccfc569347f870830e7c7cf854679a06cf9c45b5] mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE git bisect skip ccfc569347f870830e7c7cf854679a06cf9c45b5 # skip: [e964f1e04a1ce562f0d748b29326244d3cb35ba4] Merge tag 'dmaengine-5.7-rc1' of git://git.infradead.org/users/vkoul/slave-dma git bisect skip e964f1e04a1ce562f0d748b29326244d3cb35ba4 # good: [1fd34184aab0fe04c5d50af01a37fe1bb8bd6595] drm/meson: dw-hdmi: stop enforcing input_bus_format git bisect good 1fd34184aab0fe04c5d50af01a37fe1bb8bd6595 # skip: [ff2ae607c6f329d11a3b0528801ea7474be8c3e9] Merge tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx git bisect skip ff2ae607c6f329d11a3b0528801ea7474be8c3e9 # good: [cc674ef252f4750bdcea1560ff491081bb960954] KVM: s390: introduce module parameter kvm.use_gisa git bisect good cc674ef252f4750bdcea1560ff491081bb960954 # good: [b17350e4037257d25f1ca9772ba5daced9f1bf07] soundwire: cadence: commit changes in the exit_reset() sequence git bisect good b17350e4037257d25f1ca9772ba5daced9f1bf07 # bad: [aa1a8ce533324d12696a9f4b71dbc5eb561a2e04] Merge tag 'trace-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace git bisect bad aa1a8ce533324d12696a9f4b71dbc5eb561a2e04 # skip:
Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye
On Tue, Mar 29, 2022 at 01:02:34AM +0100, Mark Brown wrote: > On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote: > I bisected this to > > commit 7a8b64d17e35810dc3176fe61208b45c15d25402 > > of/address: use range parser for of_dma_get_range > > on what appears to have been a DT system with a built in DT from > the firmware, using upstream's defconfig. I dimly recall seeing Oh, and probably worth pointing out that current mainline handles the failures with ATA a lot more gracefully, still failing to bring up ATA but just printing: [2.652674] ahci :02:00.0: SSS flag set, parallel bus scan disabled [2.659364] ahci :02:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode [2.667474] ahci :02:00.0: flags: 64bit ncq sntf stag led clo pmp pio slum part ccc sxs [2.676825] ahci :02:00.0: failed to start port 0 (errno=-12) [2.682955] ahci: probe of :02:00.0 failed with error -12 and MMC still also fails but this time with an identified oops rather than just timeouts: [2.987953] [ cut here ] [2.994834] usbcore: registered new interface driver usbhid [2.998370] f_sdh30 5230.sdhci: swiotlb addr 0x+65536 overflow (mask , bus limit 0). [2.998395] WARNING: CPU: 2 PID: 8 at kernel/dma/swiotlb.c:740 swiotlb_map+0x1e4/0x1f8 [3.003981] usbhid: USB HID core driver [3.014149] Modules linked in: [3.014159] CPU: 2 PID: 8 Comm: kworker/u48:0 Not tainted 5.17.0-11137-gb953c6822375 #1 [3.026681] NET: Registered PF_PACKET protocol family [3.028964] Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS build #54 Mar 6 2019 [3.028973] Workqueue: events_unbound async_run_entry_fn [3.028987] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [3.037169] 9pnet: Installing 9P2000 support [3.042056] pc : swiotlb_map+0x1e4/0x1f8 [3.042068] lr : swiotlb_map+0x1e4/0x1f8 [3.042078] sp : 8818bb80 [3.050930] Key type dns_resolver registered [3.056180] x29: 8818bb80 x28: x27: [3.063504] registered taskstats version 1 [3.067423] [3.067427] x26: 0001 x25: 0080 x24: 000801787010 [3.067439] x23: x22: [3.071388] Loading compiled-in X.509 certificates [3.075292] x21: 0001 [3.075299] x20: 898c3998 x19: 000801787010 [3.079127] pstore: Using crash dump compression: deflate [3.082890] x18: 0020 [3.082897] x17: x16: 206f74206b636162 x15: [3.082909] x14: 0001 [3.097298] OF: translation of DMA address(0) to CPU address failed node() [3.102762] x13: 000f7bf76556 x12: 000f7bf76551 [3.102773] x11: 0720072007200720 x10: 000a x9 : 8818bb80 [3.102785] x8 : 8a331198 x7 : 8818b980 [3.108037] gpio-keys gpio-keys: Invalid size 0x1 for dma-range(s) [3.112816] x6 : 000f7bf3ef80 [3.112823] x5 : x4 : [3.116564] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [3.121457] x3 : [3.121464] x2 : 8a0125a0 x1 : fbd95b9fae668f00 x0 : [3.197275] Call trace: [3.199721] swiotlb_map+0x1e4/0x1f8 [3.203305] dma_map_page_attrs+0xec/0x228 [3.207408] sdhci_setup_host+0x8f0/0xd30 [3.211430] sdhci_add_host+0x18/0x50 [3.215098] sdhci_f_sdh30_probe+0x2a0/0x378 [3.219373] platform_probe+0x68/0xd8 [3.223043] really_probe+0xb8/0x300 [3.226622] __driver_probe_device+0x78/0xe0 [3.230896] driver_probe_device+0x3c/0xe8 [3.234997] __driver_attach_async_helper+0x2c/0x50 [3.239880] async_run_entry_fn+0x34/0xd0 [3.243896] process_one_work+0x1ec/0x330 [3.247912] worker_thread+0x44/0x420 [3.251579] kthread+0x110/0x120 [3.254815] ret_from_fork+0x10/0x20 [3.258397] ---[ end trace ]--- followed by more in sdhci_send_command(). [ 23.661522] WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:1151 sdhci_send_command+0x954/0xde8 I'm guessing these are going to be the same underlying issue with the firmware but manifesting a bit differently, the network device does still complain about the 1 byte dma-range. The system gets to a ramdisk but has no useful I/O. signature.asc Description: PGP signature
Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found
Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.
This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
drivers/of/address.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index c34ac33b7338..21342223b8e5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -975,10 +975,12 @@ int of_dma_get_range(struct device_node *np, const struct
bus_dma_region **map)
}
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
*/
*map = r;
of_dma_range_parser_init(, node);
+ ret = -EINVAL;
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
@@ -992,6 +994,7 @@ int of_dma_get_range(struct device_node *np, const struct
bus_dma_region **map)
r->size = range.size;
r->offset = range.cpu_addr - range.bus_addr;
r++;
+ ret = 0;
}
out:
of_node_put(node);
---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20230126-synquacer-boot-243bd1b87f64
Best regards,
--
Mark Brown
Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found
On Fri, Jan 27, 2023 at 12:37:35PM -0600, Rob Herring wrote:
> Looks to me like we are leaking 'r' with this change.
Oh, probably now that you mention it. Usually the OF code keeps
track of more things than I expect...
> Wouldn't this change work:
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index c34ac33b7338..f43311f01c32 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -968,6 +968,11 @@ int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map)
> for_each_of_range(, )
> num_ranges++;
>
> + if (!num_ranges) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
Not as-is, there is a range counted by that first loop but it's
then rejected by the check in the second loop for cpu_addr ==
OF_BAD_ADDR. We'd need to add a similar check in the first loop.
It should work otherwise though and avoids doing the allocation
in this case.
signature.asc
Description: PGP signature
Bug#993612: [PATCH v2] of/address: Return an error when no valid dma-ranges are found
Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.
This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
Changes in v2:
- Don't leak parsed resources.
- Link to v1:
https://lore.kernel.org/r/20230126-synquacer-boot-v1-1-94ed0eb10...@kernel.org
---
drivers/of/address.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index c34ac33b7338..67763e5b8c0e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -965,8 +965,19 @@ int of_dma_get_range(struct device_node *np, const struct
bus_dma_region **map)
}
of_dma_range_parser_init(, node);
- for_each_of_range(, )
+ for_each_of_range(, ) {
+ if (range.cpu_addr == OF_BAD_ADDR) {
+ pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
+ range.bus_addr, node);
+ continue;
+ }
num_ranges++;
+ }
+
+ if (!num_ranges) {
+ ret = -EINVAL;
+ goto out;
+ }
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -975,18 +986,16 @@ int of_dma_get_range(struct device_node *np, const struct
bus_dma_region **map)
}
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
*/
*map = r;
of_dma_range_parser_init(, node);
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
- if (range.cpu_addr == OF_BAD_ADDR) {
- pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
- range.bus_addr, node);
+ if (range.cpu_addr == OF_BAD_ADDR)
continue;
- }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;
---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20230126-synquacer-boot-243bd1b87f64
Best regards,
--
Mark Brown
