Re: Linux 3.16: all my drivers on SPI bus report WARNING: at drivers/base/dd.c:286
On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe christophe.le...@c-s.fr wrote: I've been able to identify the origin of the issue. It happens since the below commit. Do you know what should be done to fix that ? Christophe Actually, more things are wrong with what the driver is doing. If inside spi_add_device() the call to device_add() fails, then that code bails out without any call to spi_cleanup() and the same memory will leak (Is this intended?). Basically, fsl_spi_setup allocates memory using devm_kzalloc, while device_add expects that any memory allocated via this way is only done in the device's probe function. The simple fix would be to do a normal allocation (revert the patch) and add a free to the cleanup() function. Unfortunately that doesn't fix the memleak I mentioned above. So, some outside-the-box thinking brings me to conclude that another way to fix this problem is to allocate the devm_kzalloc not on the device's resource list but on the controller's resources (it's controller state after all...). Regards, Stijn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux 3.16: all my drivers on SPI bus report WARNING: at drivers/base/dd.c:286
On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe christophe.le...@c-s.fr wrote: I've been able to identify the origin of the issue. It happens since the below commit. Do you know what should be done to fix that ? Christophe Actually, more things are wrong with what the driver is doing. If inside spi_add_device() the call to device_add() fails, then that code bails out without any call to spi_cleanup() and the same memory will leak (Is this intended?). Basically, fsl_spi_setup allocates memory using devm_kzalloc, while device_add expects that any memory allocated via this way is only done in the device's probe function. The simple fix would be to do a normal allocation (revert the patch) and add a free to the cleanup() function. Unfortunately that doesn't fix the memleak I mentioned above. So, some outside-the-box thinking brings me to conclude that another way to fix this problem is to allocate the devm_kzalloc not on the device's resource list but on the controller's resources (it's controller state after all...). Regards, Stijn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, Aug 15, 2011 at 6:11 PM, Scott Wood scottw...@freescale.com wrote:
On 08/15/2011 10:59 AM, Artem Bityutskiy wrote:
On Tue, 2011-07-12 at 12:48 +0800, b35...@freescale.com wrote:
+ /*
+ * Hack for supporting the flash chip whose writesize is
+ * larger than 2K bytes.
+ */
+ if (mtd-writesize 2048) {
+ elbc_fcm_ctrl-subpage_shift = ffs(mtd-writesize 11) - 1;
+ elbc_fcm_ctrl-subpage_mask =
+ (1 elbc_fcm_ctrl-subpage_shift) - 1;
+ /*
+ * Rewrite mtd-writesize, mtd-oobsize, chip-page_shift
+ * and chip-pagemask.
+ */
+ mtd-writesize = 2048;
+ mtd-oobsize = 64;
+ chip-page_shift = ffs(mtd-writesize) - 1;
+ chip-pagemask = (chip-chipsize chip-page_shift) - 1;
+ }
So basically if the flash has 4KiB NAND pages, you are considering it as
a flash with 2KiB NAND pages. But surely this will work only if the
underlying flash has NOP 2 at least. Or even, if you consider that JFFS2
and YAFFS want to write to OOB, you need NOP 4 (2 ECC writes and 2
writes from YAFFS/JFFS2) ? So this won't work for NOP1 flashes?
Right. The set of chips that work with this controller is still larger
with this than without this.
It looks like NOP1 tends to be MLC -- you probably wouldn't want to use
MLC with this controller anyway as it only does 1-bit ECC.
I currently have the fsl_elbc_nand driver working with BCH codes in software.
The patch is fairly small (although I'm just hardcoding the required ECC
configuration). I'll see if I can clean it up and push it upstream soon.
Regards,
Stijn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] edac/85xx: PCI/PCIE error interrupt edac support.
On Thu, Jul 21, 2011 at 12:33 PM, Shaohui Xie shaohui@freescale.com wrote: From: Kai.Jiang kai.ji...@freescale.com Add pcie error interrupt edac support for mpc85xx and p4080. mpc85xx uses the legacy interrupt report mechanism - the error interrupts are reported directly to mpic. While, p4080 attaches most of error interrupts to interrupt 0. And report error interrupt to mpic via interrupt 0. This patch can handle both of them. Due to the error management register offset and definition difference between pci and pcie, use ccsr_pci structure to merge pci and pcie edac code into one. This code has been posted a couple of months ago, if I'm not mistaken. I'm currently testing it on a P2020 based design. One of the failures I'm trying to cope with is a PCIe device that does not send back a completion with data. e.g. a userspace process reads memory through a memory map, but the PCIe device is not responding. In this case the P2020 will stall due to the core_fault_in being asserted. If configured, this interrupt will be called, but it does nothing to cure the root cause (e.g. kill the process). End result is that the processor still hangs. I've been hacking my way around the kernel for a while and ended up a lot closer to a working solution to recover from such a failure. The issue I'm facing now is that the PIC can be configured to send the interrupt as a critical interrupt to one of both cores, but that may not be the core that is running the process that initiated the read. I've done 2 test-runs and both killed the right process, but I'd like to make sure that it's not by accident. Bottom-line: what mechanisms are in place (or are required) to ensure that the the right process (on the same core or on another core) is killed regardless of how the PIC is configured? Regards, Stijn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] misc: at24: parse OF-data, too
Hi Wolfram, I seem to be mistaken. I retried compatible=linux,24c64 and it did all the right things. I was mistaken that request_module() only takes the driver name, at24 in this case, and not all device names in the table_ids. This pretty much makes my patch redundant. Thanks for helping me clear things out. Regards, Stijn On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang w.s...@pengutronix.de wrote: Hi, As far as I could tell, using compatible = 24c64; didn't load the right module (module name is at24) and using at24 caused a device id mismatch because at24 is not a known device ID. I could be wrong here and if so, I'd very much like a source code hint as to why... Have you tried vendor, 24c64? All I can say is that it works for me. Plain at24 worked for years with pcm030.dts and pcm032.dts, so I don't know which issue you are facing. This patch is just about extending the support. My patch worked by changing drivers/of/of_i2c.c to allow a generic kind = statement that was filled in as i2c_board_info.type, to allow the module name and the device id to be different. This makes the at24 driver no longer rely on probing (which it claims is buggy anyway) and also benefits other drivers that support multiple devices, but where probing is difficult (e.g. lm90 driver). I'm in the process of getting employer approval to get these patches upstream. I hope you will get it approved, it is a lot easier to talk about code :) Best regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1 =tyTb -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] misc: at24: parse OF-data, too
Hi Wolfram,
I'm surprised that this would work. I've patched the at24 driver as well
to use OF data, but took a different approach.
As far as I could tell, using compatible = 24c64; didn't load the right
module
(module name is at24) and using at24 caused a device id mismatch because
at24 is not a known device ID. I could be wrong here and if so, I'd very
much
like a source code hint as to why...
My patch worked by changing drivers/of/of_i2c.c to allow a generic
kind = statement that was filled in as i2c_board_info.type, to allow
the module name and the device id to be different.
This makes the at24 driver no longer rely on probing (which it claims
is buggy anyway) and also benefits other drivers that support multiple
devices, but where probing is difficult (e.g. lm90 driver).
I'm in the process of getting employer approval to get these patches
upstream.
Regards,
Stijn
-Oorspronkelijk bericht-
From: Wolfram Sang
Sent: Wednesday, November 17, 2010 1:00 PM
To: devicetree-disc...@ozlabs.org
Cc: linuxppc-...@ozlabs.org
Subject: [PATCH 1/3] misc: at24: parse OF-data, too
Information about the pagesize and read-only-status may also come from
the devicetree. Parse this data, too, and act accordingly. While we are
here, change the initialization printout a bit. write_max is useful to
know to detect performance bottlenecks, the rest is superfluous.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
Changes since last version:
- use __be32 instead of u32
Documentation/powerpc/dts-bindings/eeprom.txt | 28 +
drivers/misc/eeprom/at24.c| 33
2 files changed, 55 insertions(+), 6 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/eeprom.txt
diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt
b/Documentation/powerpc/dts-bindings/eeprom.txt
new file mode 100644
index 000..4342c10
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/eeprom.txt
@@ -0,0 +1,28 @@
+EEPROMs (I2C)
+
+Required properties:
+
+ - compatible : should be manufacturer,type
+ If there is no specific driver for manufacturer, a generic
+ driver based on type is selected. Possible types are:
+ 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
+ 24c128, 24c256, 24c512, 24c1024, spd
+
+ - reg : the I2C address of the EEPROM
+
+Optional properties:
+
+ - pagesize : the length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong
value
+may result in data loss! If not specified, a safety value of
+'1' is used which will be very slow.
+
+ - read-only: this parameterless property disables writes to the eeprom
+
+Example:
+
+eep...@52 {
+ compatible = atmel,24c32;
+ reg = 0x52;
+ pagesize = 32;
+};
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 559b0b3..3a53efc 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -20,6 +20,7 @@
#include linux/log2.h
#include linux/bitops.h
#include linux/jiffies.h
+#include linux/of.h
#include linux/i2c.h
#include linux/i2c/at24.h
@@ -457,6 +458,27 @@ static ssize_t at24_macc_write(struct memory_accessor
*macc, const char *buf,
/*-*/
+#ifdef CONFIG_OF
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{
+ const __be32 *val;
+ struct device_node *node = client-dev.of_node;
+
+ if (node) {
+ if (of_get_property(node, read-only, NULL))
+ chip-flags |= AT24_FLAG_READONLY;
+ val = of_get_property(node, pagesize, NULL);
+ if (val)
+ chip-page_size = be32_to_cpup(val);
+ }
+}
+#else
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{ }
+#endif /* CONFIG_OF */
+
static int at24_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct at24_platform_data chip;
@@ -485,6 +507,9 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
*/
chip.page_size = 1;
+ /* update chipdata if OF is present */
+ at24_get_ofdata(client, chip);
+
chip.setup = NULL;
chip.context = NULL;
}
@@ -597,19 +622,15 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
i2c_set_clientdata(client, at24);
- dev_info(client-dev, %zu byte %s EEPROM %s\n,
+ dev_info(client-dev, %zu byte %s EEPROM, %s, %u bytes/write\n,
at24-bin.size, client-name,
- writable ? (writable) : (read-only));
+ writable ? writable : read-only, at24-write_max);
if (use_smbus == I2C_SMBUS_WORD_DATA ||
use_smbus == I2C_SMBUS_BYTE_DATA) {
dev_notice(client-dev, Falling back to %s reads,
performance will suffer\n, use_smbus ==
I2C_SMBUS_WORD_DATA ? word : byte);
}
- dev_dbg(client-dev,
- page_size %d, num_addresses %d, write_max %d, use_smbus %d\n,
- chip.page_size, num_addresses,
- at24-write_max, use_smbus);
/* export data to kernel code */
if (chip.setup)
--
Re: [PATCH 1/3] misc: at24: parse OF-data, too
On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang w.s...@pengutronix.de wrote: Hi, As far as I could tell, using compatible = 24c64; didn't load the right module (module name is at24) and using at24 caused a device id mismatch because at24 is not a known device ID. I could be wrong here and if so, I'd very much like a source code hint as to why... Have you tried vendor, 24c64? All I can say is that it works for me. Plain at24 worked for years with pcm030.dts and pcm032.dts, so I don't know which issue you are facing. This patch is just about extending the support. According to of_modalias_node, the prefix is stripped anyway, so that wouldn't help. The code probably worked using the buggy probing... My patch worked by changing drivers/of/of_i2c.c to allow a generic kind = statement that was filled in as i2c_board_info.type, to allow the module name and the device id to be different. This makes the at24 driver no longer rely on probing (which it claims is buggy anyway) and also benefits other drivers that support multiple devices, but where probing is difficult (e.g. lm90 driver). I'm in the process of getting employer approval to get these patches upstream. It'll get approved ;) It's the first time I'm taking these steps, but the procedures are there, so at most it'll take some extra time. I hope you will get it approved, it is a lot easier to talk about code :) Best regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1 =tyTb -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
