CM-X300 can be assembled with different NAND flashes from different
manufacturers. Adding their configuration to the kernel is impractical,
therefore we will use the default NAND controller settings set up by the
bootloader.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Setup gpio-keys for EzX phones
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Acked-by: Daniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add a call to pxa_set_ac97_info() to enable the audio support.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
csb726 used obsolete and not working out-of-tree driver smc911x.
Switch it to use new smsc911x driver.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
I'm not going to maintain separate defconfigs for magician and hx4700.
This should probably be renamed to htcpxa_defconfig.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add voltage regulation capability to pxa2xx cpufreq
driver. The cpufreq will ask for a "vcc_core" regulator to
the regulator framework.
If a regulator is found at probe time, it will be used with
values specified in PXA270 Electrical, Mechanical, and
Thermal Specifications.
If not, it will be assumed for now that frequency change
will work without voltage control. This assumes that the
IPL/SPL installs sane values to an existing voltage
regulator (ie. voltage high enough to support the full
range).
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
PXA processors have several low-power modes. Currently kernel supports
only one of these modes for PM_SUSPEND_MEM.
This patch adds ability to set desired suspend mode for PXA27x based
machines.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Reviewed-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
As reported by Aric Blumer, the pxa27x_udc driver does work
with pxa3xx devices. Add support into device files.
Reported-by: Aric Blumer <aric@sdgsystems.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Matt Reimer <mattjreimer@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
The default value is 16 IRQs. Zylonite needs 32, ASIC3 based boards need 70.
My problem is still that due to the way IRQ_GPIO is hardcoded, ASIC3 based boards
need 70 IRQs starting at IRQ_BOARD_START. If I define ASIC3 IRQs similar to LoCoMo
or SA1111, things break as soon as something selects PXA_HAVE_BOARD_IRQS.
Increasing the default number of board IRQs to 70 instead doesn't seem very nice.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
The PXA_PWM config option is really redundant since the introduction
of HAVE_PWM, replace that with HAVE_PWM to avoid confusion.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
PWMs on PXA168/910 start at number 1 instead of 0, (i.e. PWM1/2/3/4 instead
of PWM0/1/2/3 on PXA25x/PXA27x/PXA3xx). Allow this number to be specified
in pwm_id_table.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Ideally we should have a directory of drivers and a link to the 'active'
driver. For now just show the first device which is effectively the existing
semantics without a warning.
This is an update on the original buggy patch that I then forgot to
resubmit. Confusingly it was proposed by Red Hat, written by Etched Pixels
fixed and submitted by Intel ...
Resolves-Bug: http://bugzilla.kernel.org/show_bug.cgi?id=9749
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This matches Bartlomiej's patch for ide_pci_generic:
c339dfdd65
In the libata case netcell has its own mini driver. I suspect this fix is
actually only needed for some firmware revs but it does no harm either way.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: prevent deadlock in xfs_qm_shake()
xfs: fix overflow in xfs_growfs_data_private
xfs: fix double unlock in xfs_swap_extents()
This patch fixes a bug which unconfigured struct tcf_proto keeps
chaining in tc_ctl_tfilter(), and avoids kernel panic in
cls_cgroup_classify() when we use cls_cgroup.
When we execute 'tc filter add', tcf_proto is allocated, initialized
by classifier's init(), and chained. After it's chained,
tc_ctl_tfilter() calls classifier's change(). When classifier's
change() fails, tc_ctl_tfilter() does not free and keeps tcf_proto.
In addition, cls_cgroup is initialized in change() not in init(). It
accesses unconfigured struct tcf_proto which is chained before
change(), then hits Oops.
Signed-off-by: Minoru Usui <usui@mxm.nes.nec.co.jp>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Tested-by: Minoru Usui <usui@mxm.nes.nec.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Patch to fix bad length checking in e1000. E1000 by default does two
things:
1) Spans rx descriptors for packets that don't fit into 1 skb on recieve
2) Strips the crc from a frame by subtracting 4 bytes from the length prior to
doing an skb_put
Since the e1000 driver isn't written to support receiving packets that span
multiple rx buffers, it checks the End of Packet bit of every frame, and
discards it if its not set. This places us in a situation where, if we have a
spanning packet, the first part is discarded, but the second part is not (since
it is the end of packet, and it passes the EOP bit test). If the second part of
the frame is small (4 bytes or less), we subtract 4 from it to remove its crc,
underflow the length, and wind up in skb_over_panic, when we try to skb_put a
huge number of bytes into the skb. This amounts to a remote DOS attack through
careful selection of frame size in relation to interface MTU. The fix for this
is already in the e1000e driver, as well as the e1000 sourceforge driver, but no
one ever pushed it to e1000. This is lifted straight from e1000e, and prevents
small frames from causing the underflow described above
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mike Rapoport