This fixes warnings when CONFIG_DMA_API_DEBUG=y:
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000004781a020] [size=64 bytes]
net eth0: DMA-API: device driver frees DMA memory with different size [device address=0x000000004781a020] [map size=2048 bytes] [unmap size=64 bytes]
Moreover pass the platform device to dma_{,un}map_single which makes
more sense because the logical network device doesn't know anything
about dma.
Passing the platform device was a suggestion by Lothar Waßmann.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This undoes the effects of phy_start in fec_enet_open.
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Moreover stop listing all i.MX platforms featuring a FEC, and use
the platform's config symbol that selects registration of a fec device
instead. This might make it easier to add new platforms.
Set default = y for ARMs having a fec to reduce defconfig sizes.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Saving it first into struct net_device->base_addr (which is an unsigned
long) is pointless and only needs to use more casts than necessary.
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
alloc_etherdev internally uses kzalloc, so the private data is already
zerod out.
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
dev_set_drvdata is called unconditionally in the probe function and so
it cannot be NULL.
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
memcpy takes a const void * as 2nd argument. So the argument is
converted automatically to void * anyhow.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This reintroduces commit 47970b1b which was subsequently reverted
as f00eaeea. The original change was broken and caused X startup
failures and generally made privileged processes incapable of reading
device dependent config space. The normal capable() interface returns
true on success, but the LSM interface returns 0 on success. This thinko
is now fixed in this patch, and has been confirmed to work properly.
So, once again...Eric Paris noted that commit de139a3 ("pci: check caps
from sysfs file open to read device dependent config space") caused the
capability check to bypass security modules and potentially auditing.
Rectify this by calling security_capable() when checking the open file's
capabilities for config space reads.
Reported-by: Eric Paris <eparis@redhat.com>
Tested-by: Dave Young <hidave.darkstar@gmail.com>
Acked-by: James Morris <jmorris@namei.org>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Riesen <raa.lkml@gmail.com>
Cc: Sedat Dilek <sedat.dilek@googlemail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: James Morris <jmorris@namei.org>
The "Type 2" SMBIOS record that contains Board Name is not
strictly required and may be absent in the SMBIOS on some
platforms.
( Please note that Type 2 is not listed in Table 3 in Sec 6.2
("Required Structures and Data") of the SMBIOS v2.7
Specification. )
Use the Manufacturer Name (aka System Vendor) name.
Print Board Name only when it is present.
Before the fix:
(i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011
(ii) oops output: Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6
After the fix:
(i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011
(ii) oops output: Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: <stable@kernel.org> # .3x - good for debugging, please apply as far back as it applies cleanly
LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Platform code can now set the MICREL_PHY_50MHZ_CLK bit of dev_flags in a fixup
routine (registered with phy_register_fixup_for_uid()), to make the KZS8051RNL
PHY work with 50MHz RMII reference clock.
Cc: David J. Choi <david.choi@micrel.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
VF Driver should use mailbox command timeout specified in t4fw_interface.h
rather than hard-coded value of 500ms.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a Virtual Machine is rebooted, KVM currently fails to issue a Function
Level Reset against any "Attached PCI Devices" (AKA "PCI Passthrough"). In
addition to leaving the attached device in a random state in the next booted
kernel (which sort of violates the entire idea of a reboot reseting hardware
state), this leaves our peer thinking that the link is still up. (Note that
a bug has been filed with the KVM folks, #25332, but there's been no
response on that as of yet.) So, we add a "->shutdown()" method for the
Virtual Function PCI Device to handle administrative shutdowns like a
reboot.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When CONFIG_DEBUG_FS we get "ERR_PTR()"s back from the debugfs routines
instead of NULL. Use the right predicates to check for this.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Check module parameter validity in the module initialization routine instead
of the PCI Device Probe routine.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The problematic boards have a recommended reference divider
to be used when spread spectrum is enabled on the laptop panel.
Enable the use of the recommended reference divider along with
the new pll algo.
v2: testing options
v3: When using the fixed reference divider with LVDS, prefer
min m to max p and use fractional feedback dividers.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=28852https://bugzilla.kernel.org/show_bug.cgi?id=24462https://bugzilla.kernel.org/show_bug.cgi?id=26552
MacbookPro issues reported by Justin Mattock <justinmattock@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
With the specification of hardware,
the processing at the time of driver starting was modified.
This device write automatically the MAC address read from serial ROM
into a MAC Adress1A/1B register at the time of power on reset.
However, when stable clock is not supplied,
the writing of MAC Adress1A/1B register may not be completed.
In this case, it is necessary to load MAC address to MAC Address1A/1B register
by the MAC Address1 load register.
This patch always does the above processing,
in order not to be dependent on system environment.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes this build warning:
drivers/net/wireless/iwlwifi/iwl-3945.c:411:13: warning: 'iwl3945_good_plcp_health' defined but not used
As per Johannes Berg.
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit: "p54: enhance rssi->dBm database import"
changed the way how the driver deals with the
rssical data. A new data format was necessary
and hence this patch.
NOTE: (for users with a custom eeprom binary)
I spent some time updating p54tools to support
the new format too: => (git available from)
http://git.kernel.org/?p=linux/kernel/git/chr/p54tools.git
It now comes with a simplistic script "n800_rssi2v2.sh"
which can be used to automate the conversion.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes several shortcomings of the
previous implementation. Features of the
rewrite include:
* handles undocumented "0x0000" word at the
start of the frequency table.
(Affected some early? DELL 1450 USB devices
and my Symbol 5GHz miniPCI card.)
* supports more than just one reference point
per band. (Also needed for the Symbol card.)
* ships with default values in case the eeprom
data is damaged, absent or unsupported.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some channel indices of the low 5GHz band clash with
those of the 2.4GHz band. Therefore we should go
with the channel's center frequency.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Case assert is violated should be quite unlikely.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Writing beacon to device happen through multiple write command calls.
zd_usb_iowrite16v uses synchronous urb call and with multiple write
commands in row causes high CPU usage.
Make asynchronous zd_usb_iowrite16v_async available outside zd_usb.c
and use where possible.
This lower CPU usage from ~10% to ~2% on Intel Atom when running
AP-mode with 100 TU beacon interval.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Writing beacon to device happen through multiple write command calls.
zd_usb_iowrite16v uses synchronous urb call and with multiple write
commands in row causes high CPU usage.
This patch makes zd_usb_iowrite16v use asynchronous urb submit within
zd_usb.c. zd_usb_iowrite16v_async_start is used to initiate writing
multiple commands to device using zd_usb_iowrite16v_async. Each URB
is delayed and submitted to device by next zd_usb_iowrite16v_async
call or by call to zd_usb_iowrite16v_async_end. URBs submitted by
zd_usb_iowrite16v_async have URB_NO_INTERRUPT set and last URB
send by zd_usb_iowrite16v_async_end does not. This lower CPU
usage when doing writes that require multiple URBs.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
zd1211rw is using usb_bulk_msg() with usb_sndbulkpipe() on interrupt endpoint.
However usb_bulk_msg() internally corrects this and makes interrupt URB.
It's better to change usb_bulk_msgs in zd1211rw to usb_interrupt_msg for less
confusion.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Beaconing should be disabled before stopping beacon queue.
Not doing so could queue up beacons in hw that causes
failure to stop Tx DMA, due to pending frames in hw
and also unnecessary beacon tasklet schedule.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 739fd94 ("rt2x00: Pad beacon to multiple of 32 bits")
added calls to skb_pad() without checking the return value,
which could cause problems if any of those calls does happen
to fail. Add checks to prevent this from happening.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The statement 'select CAN_SOFTING' may ignore the dependancies
for CAN_SOFTING while selecting CAN_SOFTING_CS, as is therefore a bad choice.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'rtc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
RTC: Fix minor compile warning
RTC: Convert rtc drivers to use the alarm_irq_enable method
RTC: Fix rtc driver ioctl specific shortcutting
Currently when two or more buffers are queued by the camera driver
and so the double buffering is enabled in the idmac, we lose one
frame comming from CSI since the reporting of arrival of the first
frame is deferred by the DMAIC_7_EOF interrupt handler and reporting
of the arrival of the last frame is not done at all. So when requesting
N frames from the image sensor we actually receive N - 1 frames in
user space.
The reason for this behaviour is that the DMAIC_7_EOF interrupt
handler misleadingly assumes that the CUR_BUF flag is pointing to the
buffer used by the IDMAC. Actually it is not the case since the
CUR_BUF flag will be flipped by the FSU when the FSU is sending the
<TASK>_NEW_FRM_RDY signal when new frame data is delivered by the CSI.
When sending this singal, FSU updates the DMA_CUR_BUF and the
DMA_BUFx_RDY flags: the DMA_CUR_BUF is flipped, the DMA_BUFx_RDY
is cleared, indicating that the frame data is beeing written by
the IDMAC to the pointed buffer. DMA_BUFx_RDY is supposed to be
set to the ready state again by the MCU, when it has handled the
received data. DMAIC_7_CUR_BUF flag won't be flipped here by the
IPU, so waiting for this event in the EOF interrupt handler is wrong.
Actually there is no spurious interrupt as described in the comments,
this is the valid DMAIC_7_EOF interrupt indicating reception of the
frame from CSI.
The patch removes code that waits for flipping of the DMAIC_7_CUR_BUF
flag in the DMAIC_7_EOF interrupt handler. As the comment in the
current code denotes, this waiting doesn't help anyway. As a result
of this removal the reporting of the first arrived frame is not
deferred to the time of arrival of the next frame and the drivers
software flag 'ichan->active_buffer' is in sync with DMAIC_7_CUR_BUF
flag, so the reception of all requested frames works.
This has been verified on the hardware which is triggering the
image sensor by the programmable state machine, allowing to
obtain exact number of frames. On this hardware we do not tolerate
losing frames.
This patch also removes resetting the DMA_BUFx_RDY flags of
all channels in ipu_disable_channel() since transfers on other
DMA channels might be triggered by other running tasks and the
buffers should always be ready for data sending or reception.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Bosch C_CAN controller is a full-CAN implementation which is compliant
to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can be
obtained from:
http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/c_can/users_manual_c_can.pdf
This patch adds the support for this controller.
The following are the design choices made while writing the controller
driver:
1. Interface Register set IF1 has be used only in the current design.
2. Out of the 32 Message objects available, 16 are kept aside for RX
purposes and the rest for TX purposes.
3. NAPI implementation is such that both the TX and RX paths function
in polling mode.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This PCH_GBE driver had an issue that the receiving data is not normal.
This driver had not removed correctly the padding data
which the DMA include in receiving data.
This patch fixed this issue.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some JMicron Chip treat 0 as error checksum for UDP packets.
Which should be "No checksum needed".
Reported-by: Adam Swift <Adam.Swift@omnitude.net>
Confirmed-by: "Aries Lee" <arieslee@jmicron.com>
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The value of the register which holds receive Unicast MAC Address
sometimes get messed-up after resume.
This patch refill it before enabling the hardware filter.
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Adding control to clk_rx, and makes the control of clk_{rx|tx|tcp}
with safer sequence.
This sequence is provided by JMicron.
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clear Transmit Timer/Retry setting while full-duplex.
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
