On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe
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_de
On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe
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_ad
On Mon, Aug 15, 2011 at 6:11 PM, Scott Wood 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.
>>> + */
>>> +
On Thu, Jul 21, 2011 at 12:33 PM, Shaohui Xie wrote:
> From: Kai.Jiang
>
> 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
As far as I know, you're violating PCIe spec.
PCIe base spec (rev1.0a) states that a device must start link training
within 80ms
after a fundamental reset and that each device must be ready to accept config
requests within 100ms after fundamental reset.
Regards,
Stijn
On Sun, Jan 30, 2011 at 4:07
Hi Wolfram,
I seem to be mistaken. I retried "compatible=" 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
On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang 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
>> ver
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
