diff options
| author | Stefan Richter <stefanr@s5r6.in-berlin.de> | 2010-02-18 01:52:45 +0100 |
|---|---|---|
| committer | Stefan Richter <stefanr@s5r6.in-berlin.de> | 2010-02-24 20:36:54 +0100 |
| commit | 2799d5c5f9d2064c6d1f50ec82e28e3eac5f6954 (patch) | |
| tree | a1a954e92c75793a977c8362ba8d97f700da0fa6 /arch | |
| parent | d54423c62c2f687919d4e5bdd4bb064234ff2d44 (diff) | |
| download | kernel_samsung_aries-2799d5c5f9d2064c6d1f50ec82e28e3eac5f6954.zip kernel_samsung_aries-2799d5c5f9d2064c6d1f50ec82e28e3eac5f6954.tar.gz kernel_samsung_aries-2799d5c5f9d2064c6d1f50ec82e28e3eac5f6954.tar.bz2 | |
firewire: core: don't fail device creation in case of too large config ROM blocks
It never happened yet, but better safe than sorry: If a device's config
ROM contains a block which overlaps the boundary at 0xfffff00007ff, just
ignore that one block instead of refusing to add the device
representation. That way, upper layers (kernelspace or userspace
drivers) might still be able to use the device to some degree.
That's better than total inaccessibility of the device. Worse, the core
would have logged only a generic "giving up on config rom" message which
could only be debugged by feeding a firewire-ohci debug logging session
through a config ROM interpreter, IOW would likely remain undiagnosed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions