Commit 4c1fba44296 (Add support for QE DMA mode and CPM1/CPM2 chips)
added unconditional calls to _cpm_init() / _cpm_free() from
probe()/remove(), but only checked if we're actually using CPM mode
in _init(), causing the WARN_ON in mpc8xxx_spi_free_dummy_rx() for !CPM.
Fix it by adding the same
This patch series adds support for the MPC512x from Freescale to the
mpc5xxx_can MSCAN driver. It has been tested on a MPC5121 and MPC5200B
board.
Changes since v2:
- Debugging for development code remove.
- Bus-off recovery tested and fixed for MPC5121.
Changes since v1:
- Various coding
From: Wolfgang Grandegger w...@denx.de
This patch adds documentation for the MSCAN OF device bindings for
the MPC512x and moves the one for the MPC5200 to the new common file
Documentation/powerpc/dts-bindings/fsl/can.txt.
Signed-off-by: Wolfgang Grandegger w...@denx.de
Reviewed-by: Wolfram Sang
From: Wolfgang Grandegger w...@denx.de
The start_xmit function of the MSCAN Driver did return improperly if
the CAN dlc check failed (skb not freed and invalid return code). This
patch adds a proper check of the frame lenght and data size and returns
now correctly. Furthermore, a typo has been
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
Changes since v1:
- Document OF binding for IRQ as requested by Kumar.
Changes since v2:
- Fix xlate prototype mismatch warning (intspec should be const)
.../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 22 +++-
Dario Presti wrote:
Hello,
I'm working on MPC8323_rdb board whit 1 new flash device S29GL512P instead
of original flash devices.
the bootloader is u-boot 1.1.6 (I know is too old and I'm going to upgrade
it) and the kernel is 2.6.20.
2.6.20 is also too old. :-)
I did this modification to the
Wolfgang Grandegger wrote:
The start_xmit function of the MSCAN Driver did return improperly if
the CAN dlc check failed (skb not freed and invalid return code). This
patch adds a proper check of the frame lenght and data size and returns
now correctly.
@@ -177,8 +177,13 @@ static
This patch series adds support for the MPC512x from Freescale to the
mpc5xxx_can MSCAN driver. It has been tested on a MPC5121 and MPC5200B
board.
Changes since v3:
- drop invalid skb packets in mscan_start_xmit() silently as suggested
by David Miller in the thread [RFC] ndo_validate_skb: Let
From: Wolfgang Grandegger w...@denx.de
This patch adds documentation for the MSCAN OF device bindings for
the MPC512x and moves the one for the MPC5200 to the new common file
Documentation/powerpc/dts-bindings/fsl/can.txt.
Signed-off-by: Wolfgang Grandegger w...@denx.de
Reviewed-by: Wolfram Sang
From: Wolfgang Grandegger w...@denx.de
The start_xmit function of the MSCAN Driver did return improperly if
the CAN dlc check failed (skb not freed and invalid return code). This
patch adds a proper check of the frame lenght and data size and returns
now correctly. The invalid skb packets are
From: Wolfgang Grandegger w...@denx.de
The main differences compared to the MSCAN on the MPC5200 are:
- More flexibility in choosing the CAN source clock and frequency:
Three different clock sources can be selected: ip, ref or sys.
For the latter two, a clock divider can be defined as well.
On Sat, Jan 2, 2010 at 17:39, Finn Thain fth...@telegraphics.com.au wrote:
On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
On Tue, Nov 17, 2009 at 10:04, Finn Thain fth...@telegraphics.com.au
wrote:
Add platform driver to the pmac-zilog driver for mac 68k, putting the
powermac-specific bits
On Tue, Nov 17, 2009 at 10:04, Finn Thain fth...@telegraphics.com.au wrote:
Add platform driver to the pmac-zilog driver for mac 68k, putting the
powermac-specific bits inside #ifdef CONFIG_PPC_PMAC.
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.c 2009-11-17
17:07:28.0 +1100
Right now, a number of drivers honor the status property on device
nodes (via of_device_is_available() checks), but it's open-coded in each
driver. I'm thinking of hiding arbitrary devices from the kernel, and
setting this property seems like the best approach, but at the moment
that would require
I think that is definitely a solution. It does centralize the testing
for this particular issue. The only thing question I have is if its
really better to have the upper level do the check. Shouldn't the
driver itself handle the hardware and device node status?
On Thu, 2010-01-07 at 15:07
Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm) and
I'll
leave it to you guys to figure out what this _means_:
I've failed to reproduce so far on both a Wallstreet powerbook (similar
generation and chipset as your beige G3) and a G5 with an added serial
port using
16 matches
Mail list logo