Having switched over to the newly introduced cpdma layer, this patch now
removes a whole bunch of code that is now unused. This patch has been
maintained separate strictly for reasons of readability.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Caglar Akyuz <caglarakyuz@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch hooks up the emac driver with the newly separated cpdma driver.
Key differences introduced here:
- The old buffer list scheme is no longer required
- The original code maintained mac address per rx channel, even if only one
rx channel was being used. With this change, mac address is maintained
device wide. If support for multiple rx channels is added in future, this
will need to be reworked a bit.
- The new CPDMA code handles short packets better than before. The
earlier code was adjusting the length up, without ensuring that the tail
end of the padding was cleared - a possible security issue. This has been
fixed to use skb_padto().
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Caglar Akyuz <caglarakyuz@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
In addition to being embedded into the EMAC controller, the CPDMA hardware
block is used in TI's CPSW switch controller. Fortunately, the programming
interface to this hardware block remains pretty nicely consistent across these
devices.
This patch adds a new CPDMA services layer, which can then be reused across
EMAC and CPSW drivers.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Caglar Akyuz <caglarakyuz@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch removes code that has been rendered useless by the previous patches
in this series.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Caglar Akyuz <caglarakyuz@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch switches the emac implementation over to the newly separated
MDIO driver.
With this, the mdio bus frequency defaults to a safe 2.2MHz. Boards may
optionally specify a bus frequency via platform data.
The phy identification scheme has been modified to use a phy bus id instead
of a mask. This largely serves to eliminate the "phy search" code in emac
init.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Caglar Akyuz <caglarakyuz@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Davinci's MDIO controller is present on other TI devices, without an
accompanying EMAC. For example, on tnetv107x, the same MDIO module is used in
conjunction with a 3-port switch hardware.
By separating the MDIO controller code into its own platform driver, this
patch allows common logic to be reused on such platforms.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Caglar Akyuz <caglarakyuz@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch modifies the DaVinci NAND driver to use the
new AEMIF timing setup API to configure the NAND access
timings.
Earlier, AEMIF configuration was being done as a special
case for DM644x board, but now more boards emerge which have
capability to boot for other media (SPI flash, NOR flash) and
have the kernel access NAND flash. This means that kernel cannot
always depend on the bootloader to setup the NAND.
Also, on platforms such as da850/omap-l138, the aemif input
frequency changes as cpu frequency changes; necessiating
re-calculation of timimg values as part of cpufreq transtitions.
This patch forms the basis for adding that support.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This patch adds support to configure the AEMIF interface
with supplied timing values.
Since this capability is useful both from NOR and NAND
flashes, it is provided as a new interface and in a file
of its own.
AEMIF timing configuration is required in cases:
1) Where the AEMIF clock rate can change at runtime (a side
affect of cpu frequency change).
2) Where U-Boot does not support NAND/NOR but supports other
media like SPI Flash or MMC/SD and thus does not care about
setting up the AEMIF timing for kernel to use.
3) Where U-Boot just hasn't configured the timing values and
cannot be upgraded because the box is already in the field.
Since there is now a header file for AEMIF interface, the
common (non-NAND specific) defines for AEMIF registers have
been moved from nand.h into the newly created aemif.h
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
"param->u.wpa_associate.wpa_ie_len" comes from the user. We should
check it so that the copy_from_user() doesn't overflow the buffer.
Also further down in the function, we assume that if
"param->u.wpa_associate.wpa_ie_len" is set then "abyWPAIE[0]" is
initialized. To make that work, I changed the test here to say that if
"wpa_ie_len" is set then "wpa_ie" has to be a valid pointer or we return
-EINVAL.
Oddly, we only use the first element of the abyWPAIE[] array. So I
suspect there may be some other issues in this function.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts commit 96d592ed59.
The netfilter hook seems to be misused and may leak skbs in situations
when NF_HOOK returns NF_STOLEN. It may not filter everything as
expected. Also the ethernet bridge tables are not yet capable to
understand batman-adv packet correctly.
It was only added for testing purposes and can be removed again.
Reported-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit d87d9b7d1 ("tty: serial - fix tty referencing in set_ldisc") changed
set_ldisc to take ldisc number as parameter. This patch fixes AMBA PL010 driver
according the new prototype.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The TIOCGICOUNT device ioctl in both mos7720.c and mos7840.c allows
unprivileged users to read uninitialized stack memory, because the
"reserved" member of the serial_icounter_struct struct declared on the
stack is not altered or zeroed before being copied back to the user.
This patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 461c317705eca5cac09a360f488715927fd0a927(into 2.6.36-v3)
is put forward to power down phy if no usb cable is connected,
but does introduce the two issues below:
1), phy is not into work state if usb cable is connected
with PC during poweron, so musb device mode is not usable
in such case, follows the reasons:
-twl4030_phy_resume is not called, so
regulators are not enabled
i2c access are not enabled
usb mode not configurated
2), The kernel warings[1] of regulators 'unbalanced disables'
is caused if poweron without usb cable connected
with PC or b-device.
This patch fixes the two issues above:
-power down phy only if no usb cable is connected with PC
and b-device
-do phy initialization(via __twl4030_phy_resume) if usb cable
is connected with PC(vbus event) or another b-device(ID event) in
twl4030_usb_probe.
This patch also doesn't put VUSB3V1 LDO into active mode in
twl4030_usb_ldo_init until VBUS/ID change detected, so we can
save more power consumption than before.
This patch is verified OK on Beagle board either connected with
usb cable or not when poweron.
[1]. warnings of 'unbalanced disables' of regulators.
[root@OMAP3EVM /]# dmesg
------------[ cut here ]------------
WARNING: at drivers/regulator/core.c:1357 _regulator_disable+0x38/0x128()
unbalanced disables for VUSB1V8
Modules linked in:
Backtrace:
[<c0030c48>] (dump_backtrace+0x0/0x110) from [<c034f5a8>] (dump_stack+0x18/0x1c)
r7:c78179d8 r6:c01ed6b8 r5:c0410822 r4:0000054d
[<c034f590>] (dump_stack+0x0/0x1c) from [<c0057da8>] (warn_slowpath_common+0x54/0x6c)
[<c0057d54>] (warn_slowpath_common+0x0/0x6c) from [<c0057e64>] (warn_slowpath_fmt+0x38/0x40)
r9:00000000 r8:00000000 r7:c78e6608 r6:00000000 r5:fffffffb
r4:c78e6c00
[<c0057e2c>] (warn_slowpath_fmt+0x0/0x40) from [<c01ed6b8>] (_regulator_disable+0x38/0x128)
r3:c0410e53 r2:c0410ad5
[<c01ed680>] (_regulator_disable+0x0/0x128) from [<c01ed87c>] (regulator_disable+0x24/0x38)
r7:c78e6608 r6:00000000 r5:c78e6c40 r4:c78e6c00
[<c01ed858>] (regulator_disable+0x0/0x38) from [<c02382dc>] (twl4030_phy_power+0x15c/0x17c)
r5:c78595c0 r4:00000000
[<c0238180>] (twl4030_phy_power+0x0/0x17c) from [<c023831c>] (twl4030_phy_suspend+0x20/0x2c)
r6:00000000 r5:c78595c0 r4:c78595c0
[<c02382fc>] (twl4030_phy_suspend+0x0/0x2c) from [<c0238638>] (twl4030_usb_irq+0x11c/0x16c)
r5:c78595c0 r4:00000040
[<c023851c>] (twl4030_usb_irq+0x0/0x16c) from [<c034ec18>] (twl4030_usb_probe+0x2c4/0x32c)
r6:00000000 r5:00000000 r4:c78595c0
[<c034e954>] (twl4030_usb_probe+0x0/0x32c) from [<c02152a0>] (platform_drv_probe+0x20/0x24)
r7:00000000 r6:c047d49c r5:c78e6608 r4:c047d49c
[<c0215280>] (platform_drv_probe+0x0/0x24) from [<c0214244>] (driver_probe_device+0xd0/0x190)
[<c0214174>] (driver_probe_device+0x0/0x190) from [<c02143d4>] (__device_attach+0x44/0x48)
r7:00000000 r6:c78e6608 r5:c78e6608 r4:c047d49c
[<c0214390>] (__device_attach+0x0/0x48) from [<c0213694>] (bus_for_each_drv+0x50/0x90)
r5:c0214390 r4:00000000
[<c0213644>] (bus_for_each_drv+0x0/0x90) from [<c0214474>] (device_attach+0x70/0x94)
r6:c78e663c r5:c78e6608 r4:c78e6608
[<c0214404>] (device_attach+0x0/0x94) from [<c02134fc>] (bus_probe_device+0x2c/0x48)
r7:00000000 r6:00000002 r5:c78e6608 r4:c78e6600
[<c02134d0>] (bus_probe_device+0x0/0x48) from [<c0211e48>] (device_add+0x340/0x4b4)
[<c0211b08>] (device_add+0x0/0x4b4) from [<c021597c>] (platform_device_add+0x110/0x16c)
[<c021586c>] (platform_device_add+0x0/0x16c) from [<c0220cb0>] (add_numbered_child+0xd8/0x118)
r7:00000000 r6:c045f15c r5:c78e6600 r4:00000000
[<c0220bd8>] (add_numbered_child+0x0/0x118) from [<c001c618>] (twl_probe+0x3a4/0x72c)
[<c001c274>] (twl_probe+0x0/0x72c) from [<c02601ac>] (i2c_device_probe+0x7c/0xa4)
[<c0260130>] (i2c_device_probe+0x0/0xa4) from [<c0214244>] (driver_probe_device+0xd0/0x190)
r5:c7856e20 r4:c047c860
[<c0214174>] (driver_probe_device+0x0/0x190) from [<c02143d4>] (__device_attach+0x44/0x48)
r7:c7856e04 r6:c7856e20 r5:c7856e20 r4:c047c860
[<c0214390>] (__device_attach+0x0/0x48) from [<c0213694>] (bus_for_each_drv+0x50/0x90)
r5:c0214390 r4:00000000
[<c0213644>] (bus_for_each_drv+0x0/0x90) from [<c0214474>] (device_attach+0x70/0x94)
r6:c7856e54 r5:c7856e20 r4:c7856e20
[<c0214404>] (device_attach+0x0/0x94) from [<c02134fc>] (bus_probe_device+0x2c/0x48)
r7:c7856e04 r6:c78fd048 r5:c7856e20 r4:c7856e20
[<c02134d0>] (bus_probe_device+0x0/0x48) from [<c0211e48>] (device_add+0x340/0x4b4)
[<c0211b08>] (device_add+0x0/0x4b4) from [<c0211fd8>] (device_register+0x1c/0x20)
[<c0211fbc>] (device_register+0x0/0x20) from [<c0260aa8>] (i2c_new_device+0xec/0x150)
r5:c7856e00 r4:c7856e20
[<c02609bc>] (i2c_new_device+0x0/0x150) from [<c0260dc0>] (i2c_register_adapter+0xa0/0x1c4)
r7:00000000 r6:c78fd078 r5:c78fd048 r4:c781d5c0
[<c0260d20>] (i2c_register_adapter+0x0/0x1c4) from [<c0260f80>] (i2c_add_numbered_adapter+0x9c/0xb4)
r7:00000a28 r6:c04600a8 r5:c78fd048 r4:00000000
[<c0260ee4>] (i2c_add_numbered_adapter+0x0/0xb4) from [<c034efa4>] (omap_i2c_probe+0x324/0x3e8)
r5:00000000 r4:c78fd000
[<c034ec80>] (omap_i2c_probe+0x0/0x3e8) from [<c02152a0>] (platform_drv_probe+0x20/0x24)
[<c0215280>] (platform_drv_probe+0x0/0x24) from [<c0214244>] (driver_probe_device+0xd0/0x190)
[<c0214174>] (driver_probe_device+0x0/0x190) from [<c021436c>] (__driver_attach+0x68/0x8c)
r7:c78b2140 r6:c047e214 r5:c04600e4 r4:c04600b0
[<c0214304>] (__driver_attach+0x0/0x8c) from [<c021399c>] (bus_for_each_dev+0x50/0x84)
r7:c78b2140 r6:c047e214 r5:c0214304 r4:00000000
[<c021394c>] (bus_for_each_dev+0x0/0x84) from [<c0214068>] (driver_attach+0x20/0x28)
r6:c047e214 r5:c047e214 r4:c00270d0
[<c0214048>] (driver_attach+0x0/0x28) from [<c0213274>] (bus_add_driver+0xa8/0x228)
[<c02131cc>] (bus_add_driver+0x0/0x228) from [<c02146a4>] (driver_register+0xb0/0x13c)
[<c02145f4>] (driver_register+0x0/0x13c) from [<c0215744>] (platform_driver_register+0x4c/0x60)
r9:00000000 r8:c001f688 r7:00000013 r6:c005b6fc r5:c00083dc
r4:c00270d0
[<c02156f8>] (platform_driver_register+0x0/0x60) from [<c001f69c>] (omap_i2c_init_driver+0x14/0x1c)
[<c001f688>] (omap_i2c_init_driver+0x0/0x1c) from [<c002c460>] (do_one_initcall+0xd0/0x1a4)
[<c002c390>] (do_one_initcall+0x0/0x1a4) from [<c0008478>] (kernel_init+0x9c/0x154)
[<c00083dc>] (kernel_init+0x0/0x154) from [<c005b6fc>] (do_exit+0x0/0x688)
r5:c00083dc r4:00000000
---[ end trace 1b75b31a2719ed1d ]---
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Felipe Balbi <me@felipebalbi.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We have to do so due to HW limitation.
Signed-off-by: Alek Du <alek.du@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
seq_files use the private_data field of a file struct for storing a seq_file structure,
data should be stored in seq_file's own private field (e.g. file->private_data->private)
Otherwise seq_release() will free the private data when the file is closed.
Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Direct Cache Access is not supported on IOAT ver.3.0 multiple-IOH platforms.
This patch blocks registering of dca providers when multiple IOH detected with IOAT ver.3.0.
Signed-off-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
update_interval is the matching attribute defined in the hwmon sysfs ABI.
Use it.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The attribute reflects an interval, not a rate.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
According to the datasheet for Winbond W83627DHG the proper way to exit
the Extended Function Mode is to write 0xaa to the EFER(0x2e or 0x4e).
Signed-off-by: Jonas Jonsson <jonas@ludd.ltu.se>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
It is unnecessary and wrong to call hwmon_device_unregister in error
handling before hwmon_device_register is called.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Reviewed-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: stable@kernel.org
Signed-off-by: Jean Delvare <khali@linux-fr.org>
All bits in the values read from registers to be used for the next
write were getting overwritten, avoid doing so to not mess with the
current configuration.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: stable@kernel.org
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The spec notes that fan0 and fan1 control mode bits are located in bits
7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the
bits shift by 5 instead of by 4.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: stable@kernel.org
Signed-off-by: Jean Delvare <khali@linux-fr.org>
If CONFIG_PM was selected and lis3lv02d_platform_data was NULL,
the kernel will be panic when halt command run.
Reported-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Samu Onkalo <samu.p.onkalo@nokia.com>
Sigend-off-by: Jean Delvare <khali@linux-fr.org>
Fixed formatting (tabs and line breaks).
The CHELSIO_GET_QSET_NUM device ioctl allows unprivileged users to read
4 bytes of uninitialized stack memory, because the "addr" member of the
ch_reg struct declared on the stack in cxgb_extension_ioctl() is not
altered or zeroed before being copied back to the user. This patch
takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixed formatting (tabs and line breaks).
The EQL_GETMASTRCFG device ioctl allows unprivileged users to read 16
bytes of uninitialized stack memory, because the "master_name" member of
the master_config_t struct declared on the stack in eql_g_master_cfg()
is not altered or zeroed before being copied back to the user. This
patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixed formatting (tabs and line breaks).
The TIOCGICOUNT device ioctl allows unprivileged users to read
uninitialized stack memory, because the "reserved" member of the
serial_icounter_struct struct declared on the stack in hso_get_count()
is not altered or zeroed before being copied back to the user. This
patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If an array with 1.x metadata is assembled with the last disk missing,
md doesn't properly record the fact that the disk was missing.
This is unlikely to cause a real problem as the event count will be
different to the count on the missing disk so it won't be included in
the array. However it could still cause confusion.
So make sure we clear all the relevant slots, not just the early ones.
Signed-off-by: NeilBrown <neilb@suse.de>
Now that we depend on md_update_sb to clear variable bits in
mddev->flags (rather than trying not to set them) it is important to
always call md_update_sb when appropriate.
md_check_recovery has this job but explicitly avoids it for ->external
metadata arrays. This is not longer appropraite, or needed.
However we do want to avoid taking the mddev lock if only
MD_CHANGE_PENDING is set as that is not cleared by md_update_sb for
external-metadata arrays.
Reported-by: "Kwolek, Adam" <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
drivers/firewire/nosy* is a stand-alone driver that does not depend on
CONFIG_FIREWIRE. Hence let make descend into drivers/firewire/ also
if that option is off.
The stand-alone driver drivers/ieee1394/init_ohci1394_dma* will soon be
moved into drivers/firewire/ too and will require the same makefile fix.
Side effect:
As mentioned in https://bugzilla.novell.com/show_bug.cgi?id=586172#c24
this influences the order in which either firewire-ohci or ohci1394 is
going to be bound to an OHCI-1394 controller in case of a modular build
of both drivers if no modprobe blacklist entries are configured.
However, a user of such a setup cannot expect deterministic behavior
anyway. The Kconfig help and the migration guide at
ieee1394.wiki.kernel.org recommend blacklist entries when a dual
IEEE 1394 stack build is being used. (The coexistence period of the two
stacks is planned to end soon.)
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The Thinkpad X100e seems to have some odd behaviour when the display is
powered off - the onboard r8169 starts generating rxfifo overflow errors.
The root cause of this has not yet been identified and may well be a
hardware design bug on the platform, but r8169 should be more resiliant to
this. This patch enables the rxfifo interrupt on 8168 devices and removes
the MAC version check in the interrupt handler, and the machine no longer
crashes when under network load while the screen turns off.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The VIAFB_GET_INFO device ioctl allows unprivileged users to read 246
bytes of uninitialized stack memory, because the "reserved" member of
the viafb_ioctl_info struct declared on the stack is not altered or
zeroed before being copied back to the user. This patch takes care of
it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
The NXP LPC32XX processor use the same watchdog as the Philips
PNX4008 processor.
Signed-off-by: Kevin Wells <wellsk40@gmail.com>
Tested-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Since it may be already enabled by bootloader or some other utility. This patch
makes sure that the watchdog is disabled before any userspace daemon opens the
device. It is also required by the watchdog API.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
irq and reboot notifier are acquired in module_init() but never released.
They should be released correctly, otherwise reloading the module or error
during module_init() will cause a problem.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Andrew Sharp <andy.sharp@lsi.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Some pcnet_cs compatible cards require an exact 16-lines match
of the ioport areas specified in CIS, but set the "iolines"
value in the CIS incorrectly. We can easily work around this
issue -- same as we do in serial_cs -- by first trying setting
iolines to the CIS-specified value, and then trying a 16-line
match.
Reported-and-tested-by: Wolfram Sang <w.sang@pengutronix.de>
Hardware-supplied-by: Jochen Frieling <j.frieling@pengutronix.de>
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
As the iomem / ioport setup differs per device, it is much better
to print out the device instead of the socket.
Tested-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
We shouldn't overwrite pre-set values, and we should also
set the port address to the beginning, and not the end of
the 8-port range.
CC: linux-serial@vger.kernel.org
Reported-by: Komuro <komurojun-mbn@nifty.com>
Hardware-supplied-by: Jochen Frieling <j.frieling@pengutronix.de>
Tested-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
The texture base address registers are in units of 256 bytes.
The original CS checker treated these offsets as bytes, so the
original check was wrong. I fixed the units in a patch during
the 2.6.36 cycle, but this ended up breaking some existing
userspace (probably due to a bug in either userspace texture allocation
or the drm texture mipmap checker). So for now, until we come
up with a better fix, just warn if the mipmap size it too large.
This will keep existing userspace working and it should be just
as safe as before when we were checking the wrong units. These
are GPU MC addresses, so if they fall outside of the VRAM or
GART apertures, they end up at the GPU default page, so this should
be safe from a security perspective.
v2: Just disable the warning. It just spams the log and there's
nothing the user can do about it.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <glisse@freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On resume, before starting the PAL state machine, check if the
adjust_link() method is well supplied. If not, this would lead to a
NULL pointer dereference in the phy_state_machine() function.
This scenario can happen if the Ethernet driver call manually the PHY
functions instead of using the PAL state machine. The mv643xx_eth driver
is a such example.
Signed-off-by: Simon Guinot <sguinot@lacie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It was recently brought to my attention that 802.3ad mode bonds would no
longer form when using some network hardware after a driver update.
After snooping around I realized that the particular hardware was using
page-based skbs and found that skb->data did not contain a valid LACPDU
as it was not stored there. That explained the inability to form an
802.3ad-based bond. For balance-alb mode bonds this was also an issue
as ARPs would not be properly processed.
This patch fixes the issue in my tests and should be applied to 2.6.36
and as far back as anyone cares to add it to stable.
Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: stable@kerne.org
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There has been periodic evidence that LVDS, on at least some
panels, prefers the dividers selected by the legacy pll algo.
This patch forces the use of the legacy pll algo on RV620
LVDS panels. The old behavior (new pll algo) can be selected
by setting the new_pll module parameter to 1.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30029
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not 100% sure this is due to BKL removal, its most likely a combination
of that + userspace timing changes in udev/plymouth. The drm adds the sysfs
device before the driver has completed internal loading, this causes udev
to make the node and plymouth to open it before we've completed loading.
The proper solution is to delay the sysfs manipulation until later in loading
however this causes knock on issues with sysfs connector nodes, so we can use
the global mutex to serialise loading and userspace opens.
Reported-by: Toni Spets (hifi on #radeon)
Signed-off-by: Dave Airlie <airlied@redhat.com>
v2: Julien Cristau pointed out that @nondestructive results in
double-negatives and confusion when trying to interpret the parameter,
so use @force instead. Much easier to type as well. ;-)
And fix the miscompilation of vmgfx reported by Sedat Dilek.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
My macbook infrared remote control was broken by commit
bd25f4dd69 ("HID: hiddev: use
usb_find_interface, get rid of BKL").
This device appears in dmesg as:
apple 0003:05AC:8242.0001: hiddev0,hidraw0: USB HID v1.11 Device
[Apple Computer, Inc. IR Receiver] on usb-0000:00:1d.2-1/input0
It stopped working as lircd was getting ENODEV when opening /dev/usb/hiddev0.
AFAICS hiddev_driver is a dummy driver so usb_find_interface(&hiddev_driver)
does not find anything.
The device is associated with the usbhid driver, so let's do
usb_find_interface(&hid_driver) instead.
$ ls -l /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver
lrwxrwxrwx 1 root root 0 2010-09-12 16:28 /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver -> ../../../../../../bus/usb/drivers/usbhid
Signed-off-by: Guillaume Chazarain <guichaz@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We must ensure that ide_proc_port_register_devices() occurs on an
interface before ide_proc_register_driver() executes for that
interfaces drives.
Therefore defer the registry of the driver device objects backed by
ide_bus_type until after ide_proc_port_register_devices() has run
and thus all of the drive->proc procfs directory pointers have been
setup.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Smatch complains because we check whether "pch->chan" is NULL and then
dereference it unconditionally on the next line. Partly the reason this
bug was introduced is because code was too complicated. I've simplified
it a little.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit fixes bogus CS rejection if it contains a sequence
of the following operations:
- Set the color buffer 0. track->cb[i].robj becomes non-NULL.
- Render.
- Set a larger zbuffer than the previously-set color buffer.
- Set a larger scissor area as well.
- Set the color channel mask to 0 to do depth-only rendering.
- Render. --> rejected, because track->cb[i].robj remained non-NULL,
therefore the conditional checking for the color channel mask and
friends is not performed, and the larger scissor area causes
the rejection.
This fixes bugs:
- https://bugs.freedesktop.org/show_bug.cgi?id=29762
- https://bugs.freedesktop.org/show_bug.cgi?id=28869
And maybe some others which seem to look the same.
If possible, this commit should go to stable as well.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cyril Chemparathy