Since 43cc71eed1, the platform modalias is
prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable network
platform drivers, to re-enable auto loading.
NOTE: didn't change drivers/net/fs_enet/fs_enet-main.c "old binding" support.
That looks problematic in the first place (it even uses the ancient "struct
device_driver" binding scheme for platform_bus!) and I suspect it will vanish
soonish when arch/powerpc rules the world. Also, drivers/net/ne.c would have
needed more thought to sort out.
[akpm@linux-foundation.org: fix sgiseeq.c]
[dbrownell@users.sourceforge.net: more drivers, registration fixes]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Vitaly Bordug <vitb@kernel.crashing.org>
Cc: Dale Farnsworth <dale@farnsworth.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrew Victor <andrew@sanpeople.com>
Cc: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Let platform do some specific initialisation and cleanup
things during pxaficp_ir probing and removing. E.g. this
can be usefull to request/free gpios used by the platform
to control the transceiver.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
two reasons:
1. GPIO namings and their mode definitions are conceptually not part
of the PXA register definitions
2. this is actually a temporary move in the transition of PXA2xx to
use MFP-alike APIs (as what PXA3xx is now doing), so that legacy
code will still work and new code can be added in step by step
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
To clearly state the intent of copying to linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To clearly state the intent of copying from linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the common, open coded 'skb->mac.raw = skb->data' operation, so that we can
later turn skb->mac.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple case, next will handle the slightly more
"complex" cases.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch removes the unnecessary bit number from CKENnn_XXXX
definitions for PXA, so that
CKEN0_PWM0 --> CKEN_PWM0
CKEN1_PWM1 --> CKEN_PWM1
...
CKEN24_CAMERA --> CKEN_CAMERA
The reasons for the change of these defitions are:
1. they do not scale - they are currently valid for pxa2xx, but
definitely not valid for pxa3xx, e.g., pxa3xx has bit 3 for camera
instead of bit 24
2. they are unnecessary - the peripheral name within the definition
has already announced its usage, we don't need those bit numbers
to know which peripheral we are going to enable/disable clock for
3. they are inconvenient - think about this: a driver programmer
for pxa has to remember which bit in the CKEN register to turn
on/off
Another change in the patch is to make the definitions equal to its
clock bit index, so that
#define CKEN_CAMERA (24)
instead of
#define CKEN_CAMERA (1 << 24)
this change, however, will add a run-time bit shift operation in
pxa_set_cken(), but the benefit of this change is that it scales
when bit index exceeds 32, e.g., pxa3xx has two registers CKENA
and CKENB, totally 64 bit for this, suppose CAMERA clock enabling
bit is CKENB:10, one can simply define CKEN_CAMERA to be (32 + 10)
and so that pxa_set_cken() need minimum change to adapt to that.
Signed-off-by: eric miao <eric.y.miao@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch addresses the following issues with the pxa2xx FIr driver:
1. increment overrun error counter and not frame error counter on ICSR1_ROR bit set in ICSR1.
2. drop frames reported with the frame error from the IC.
3. when resetting the receiver and preparing it for the next DMA in pxa_irda_fir_irq() actually clear the Rx FIFO. See description in Table 11-2 in PXA270 Developer's Manual of the RXE bit.
Correction added in version 2: clearing the IC Rx FIFO also has to be done in pxa_irda_fir_dma_tx_irq()
Signed-off-by: G. Liakhovetski <gl@dsa-ac.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
pxaficp_ir.c was not converted to the device model framework.
Signed-off-by: Paul Sokolovsky <pmiscml@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
Patch from Richard Purdie
Update the PXA irda driver to match the recent platform device
suspend/resume level changes.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Convert everyone who uses platform_bus_type to include
linux/platform_device.h.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Patch from Nicolas Pitre
This is the PXA2xx common IRDA driver, plus platform support
for Lubbock and Mainstone.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Acked-by: Jean Tourrilhes <jt@hpl.hp.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
