ohci:  Break out of the retry loop if too many attempts were necessary.
This may theoretically happen if the chip is fatally defective or if the
get_cycle_timer ioctl was performed after a CardBus controller was
ejected.

Also micro-optimize the loop by re-using the last two register reads in
the next iteration, remove a questionable inline keyword, and shuffle a
comment around.

core:  ioctl_get_cycle_timer() is always called with interrupts on,
therefore local_irq_save() can be replaced by local_irq_disable().
Disabled local IRQs imply disabled preemption, hence preempt_disable()
can be removed.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Discussed in "read_cycle_timer backwards for sub-cycle 0000, 0001",
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13704

Known bad controllers:
  ALi M5271, listed by lspci as M5253 [10b9:5253]
  NEC OrangeLink [1033:00cd] (rev 03)
  NEC uPD72874 [1033:00f2] (rev 01)
  VIA VT6306 [1106:3044] (rev 46)
  VIA VT6308P, listed by lspci as rev c0
Reported-by: NPieter Palmers <pieterp@joow.be>
Reported-by: NHåkan Johansson <f96hajo@chalmers.se>
Reported-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

VIA controllers sometimes return an inconsistent value when reading the
isochronous cycle timer register.  To work around this, read the
register multiple times and add consistency checks.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Reported-by: NPieter Palmers <pieterp@joow.be>
Reported-by: NHåkan Johansson <f96hajo@chalmers.se>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The id_table field of the struct pci_driver is constant in <linux/pci.h>
so it is worth to make pci_table also constant.  Found with Coccinelle.
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: Stefan Richter stefanr@s5r6.in-berlin.de> (changelog)

Several config ROM related functions only peek at the ROM cache; mark
their arguments as const pointers.  Ditto fw_device.config_rom and
fw_unit.directory, as the memory behind them is meant to be write-once.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Witespace and comment changes, and a different way to say i + 1 < end.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The core (sysfs attributes), the firedtv driver, and possible future
drivers all read strings from some configuration ROM directory.  Factor
out the generic code from show_text_leaf() into a new helper function,
modified slightly to handle arbitrary buffer sizes.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Update the Kconfig help texts of both stacks to encourage a general move
from the older to the newer drivers.  However, do not label ieee1394 as
"Obsolete" yet, as the newer drivers have not been deployed as default
stack in the majority of Linux distributions yet, and those who start
doing so now may still want to install the old drivers as fallback for
unforeseen issues.

Since Linux 2.6.32, FireWire audio devices can be driven by the newer
firewire driver stack too, hence remove an outdated comment about audio
devices.  Also remove comments about library versions since the 2nd
generation of libraw1394 and libdc1394 is now in common use; details on
library versions can be read at the wiki link from the help texts.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This is a minimal change meant for the short term:  Never set the
ohci->use_dualbuffer flag to true.

There are two reasons to do so:

  - Packet-per-buffer mode and dual-buffer mode do not behave the same
    under certain circumstances, notably if several packets are covered
    by a single fw_cdev_iso_packet descriptor.
    http://marc.info/?l=linux1394-devel&m=124965653718313
    Therefore the driver stack should not silently choose one or the
    other mode but should leave the choice to the high-level driver
    (regardless if kernel driver or userspace driver).  Or simply always
    only offer packet-per-buffer mode, since a considerable number of
    controllers, even current ones, does not offer dual-buffer support.

  - Even under circumstances where packet-per-buffer mode and
    dual-buffer mode behave exactly the same --- notably when used
    through libraw1394, libdc1394, as well as the current two kernel
    drivers which use isochronous reception (firewire-net and firedtv)
    --- we are still faced with the problem that several OHCI 1.1
    controllers have bugs in dual-buffer mode.  Although it looks like
    we have identified most of those buggy controllers by now, we
    cannot be quite sure about that.

So, use packet-per-buffer by default from now on.  This change should
be followed up by a more complete solution:  Either extend the
in-kernel API and the userspace ABI by a choice between the two IR modes
or remove all dual-buffer related code from firewire-ohci.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

If copy_from_user in an FW_CDEV_IOC_SEND_RESPONSE ioctl failed, the
fw_request pointed to by the inbound_transaction_resource is no
longer referenced and needs to be freed.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Control of more than one AV/C device at once --- e.g. camcorders, tape
decks, audio devices, TV tuners --- failed or worked only unreliably,
depending on driver implementation.  This affected kernelspace and
userspace drivers alike and was caused by firewire-core's inability to
accept multiple registrations of FCP listeners.

The fix allows multiple address handlers to be registered for the FCP
command and response registers.  When a request for these registers is
received, all handlers are invoked, and the Firewire response is
generated by the core and not by any handler.

The cdev API does not change, i.e., userspace is still expected to send
a response for FCP requests; this response is silently ignored.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)

Don't pass a name pointer from the kernel stack, it will not survive
and will result in corrupted /proc/iomem output.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Do not spam the logs needlessly with the sole info that
edac_pci_dev_parity_clear is being called.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Do not access F2x19[0,4] on K8 since they're undefined there.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Clear the override flag after force-loading the module.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Currently, the module does not initialize fully when the DIMMs aren't
ECC but remains still loaded. Propagate the error when no instance of
the driver is properly initialized and prevent further loading.

Reorganize and polish error handling in amd64_edac_init() while at it.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Fix use-after-free errors by pushing all memory-freeing calls to the end
of amd64_remove_one_instance().
Reported-by: NDarren Jenkins <darrenrjenkins@gmail.com>
LKML-Reference: <1261370306.11354.52.camel@ICE-BOX>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Fix the case when amd64_debug_display_dimm_sizes() reports only half the
amount of DRAM on it because it doesn't account for when the single DCT
operates in 128-bit mode and merges chip selects from different DIMMs.
Reported-by: NJohannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
LKML-Reference: <200912112202.48173.johannes.hirte@fem.tu-ilmenau.de>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This add supports for devices like keyboard, backlight, tablet and
accelerometer.

This work is supported by International Syst S/A.

[randy.dunlap@oracle.com: cmpc_acpi: depends on ACPI]
[akpm@linux-foundation.org: readability tweaks]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

ctrl_xxx() is an antiquated SH interface, while __raw_xxx is the standard
API that accomplishes the same thing. As such, this converts the
remaining sh-sci straggles over, which enables the driver to be wired up
for ARM SH-Mobile CPUs as well.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This establishes a sensible max baud rate for the earlyprintk cases where
the port's uartclk has not yet been determined.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Now that we have WMI autoloading
the DMI matching is not needed anymore.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Acked-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Acked-by: NAnisse Astier <anisse@astier.eu>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is no point in having the driver loaded in memory if we fail
to locate particular WMI GUID.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

These function allocate an acpi object by calling wmi_get_event_data, which
then calls acpi_evaluate_object, and it is not freed afterwards.

And kernel doc is fixed for parameters of wmi_get_event_data.
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

BIOS information is now checked whether it begins with the strings stored
in the BIOS table.  Previous method did a strcmp, what lead to problems if
BIOS information has appended whitespaces.
Signed-off-by: NPeter Feuerer <peter@piie.net>
Cc: Borislav Petkov <petkovbb@gmail.com>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add new BIOS versions for following netbooks: Aspire 1810xx, Packard Bell
DOTMU.
Signed-off-by: NPeter Feuerer <peter@piie.net>
Cc: Borislav Petkov <petkovbb@gmail.com>
Cc: Andreas Mohr <andi@lisas.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

BugLink: https://bugs.launchpad.net/ubuntu/+bug/435958

The module alias currently matches any Acer computer but when loaded the
BIOS checks will only succeed on Aspire One models.  This causes a invalid
BIOS warning for all other models (seen on Aspire 4810T).  This is not
fatal but worries users that see this message.  Limiting the moule alias
to models starting with AOA or DOA for Packard Bell.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Acked-by: NBorislav Petkov <petkovbb@gmail.com>
Acked-by: NPeter Feuerer <peter@piie.net>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Karol Kozimor <sziwan@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

In March 2008 commit 0ac4a3c2 ("ACPI: fix
ATA_ACPI build") made CONFIG_ACPI_DOCK be selected by CONFIG_ATA_ACPI because
of a build error when CONFIG_ATA_ACPI=y and CONFIG_ACPI_DOCK=m.

However, in September 2008 commit 898b054f
("dock: make dock driver not a module") removed the possibility of having
CONFIG_ACPI_DOCK=m and therefore there is no need for selecting it when
CONFIG_ATA_ACPI=y.

This makes the kernel ~5 Kb smaller for people who don't have a dock by
allowing them to not have ACPI_DOCK compiled-in because of ATA_ACPI=y.
Signed-off-by: NCarlos R. Mafra <crmafra@aei.mpg.de>
Cc: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

SN06 makes sure we get back a longer buffer which seems to be necessary
going forward as the SNC devices describes more and more devices (or
features more precisely). Moreover SN06 should be called with only the
descriptor offset to make sure we hit the rfkill controlling function
(F124 or F135) with a 0 argument to get a full list of features.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Tested-by: NMiguel Rodríguez Pérez <miguelrp@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Vaio Type X and possibly other new models use F135 as the radio
frequency controlling function attached to the SNC device. In the
indexed table this corresponds to 0x0135 (surpise!).
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

Current OMAP3 I2C driver code does not follow the correct sequence for soft
reset. Due to this, lock up issues are reported during timeout/error cases.

This patch fixes above issue by disabling I2C controller as per OMAP3430 TRM
for soft reset. As per TRM, I2C controller needs to be disabled as a first
step during soft reset.

Here is correct soft reset sequence:
a. Ensure that the module is disabled
(clear the I2Ci.I2C_CON[15] I2C_EN bit to 0).
b. Set the I2Ci.I2C_SYSC[1] SRST bit to 1.
c. Enable the module by setting I2Ci.I2C_CON[15] I2C_EN bit to 1.
d. Check the I2Ci.I2C_SYSS[0] RDONE bit until it is set to 1 to
indicate the software reset is complete.

Tested on Zoom2, Zoom3, 3430SDP and 3630SDP
Signed-off-by: NManjunatha GK <manjugk@ti.com>
Signed-off-by: George, Harith<harith@ti.com>
Acked-by: Varadarajan, Charu Latha<charu@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Commit ef871432... (i2c-omap: OMAP3: PM: (re)init for every transfer
to support off-mode) introduced a change which make the dev->iestate
contents be written to the OMAP_I2C_IE_REG every time omap_i2c_unidle
is called.  Previously, the state was only written if it wasn't equal
to zero.

In omap_i2c_probe, omap_i2c_unidle() is called prior to omap_i2c_init(),
in which case dev->iestate has not yet been initialized and will be set
to zero.  Having this value written to the registers causes deadlock
while booting.

As such, this change restores the original functionality.
Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Calculation of the CLKDIV speed setting should be done using base 10 math
rather than base 2.  We also avoid exceeding the spec due to integer
truncation and a 50% duty cycle.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Executing _OSC returns a buffer, which has an acpi object in it.
Don't directly returns the buffer, instead, we return the acpi object's
buffer. This fixes a regression since caller of acpi_run_osc expects
an acpi object's buffer returned.
Tested-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use resource_size().
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Kevin Hilman <khilman@ti.deeprootsystems.com>
Cc: Ulrik Bech Hald <ubh@ti.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Vincent Sanders <support@simtec.co.uk>
Acked-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

add PCI ID for the Intel EP80579 (Tolapai) SoC
Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

brightness status is reported by the Apple Cinema Displays as an
'unsigned char' (u8) value, but the code used 'char' instead.

Note that he driver was developed on the PowerPC architecture,
where the two types are synonymous, which is not always the case.

Fixed that.  Otherwise the driver will interpret brightness
levels > 127 as negative, and fail to load.
Signed-off-by: Npancho horrillo <pancho@pancho.name>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>