Hi,
I'm having a hard time debugging a custom SPI device with multiple
interrupt GPIO pins, connected to a Samsung Artik 710 SoC module.
The device is a microcontroller acting as an SPI-CAN bridge (emulating
the hi3110, so SPI slave device) for two separate can busses.
[The idea was to make it em
how this fix is related to commit
220669495bf8b68130a8218607147c7b74c28d2b
"powerpc: Add TBI PHY node to first MDIO bus"
which fixed the behavior in kernel 3.3, which was later broken by the
above commit on kernel 3.7.
Signed-off-by: Gerlando Falauto
Cc: Timur Tabi
Cc: David
error, print a message but continue anyway.
Signed-off-by: Gerlando Falauto
Cc: Timur Tabi
Cc: David S. Miller
Cc: Kumar Gala
---
Changes from v1:
- Added type cast & fixed range
- removed freescale recipients
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 10 ++
1 file changed, 10 i
how this fix is related to commit
220669495bf8b68130a8218607147c7b74c28d2b
"powerpc: Add TBI PHY node to first MDIO bus"
which fixed the behavior in kernel 3.3, which was later broken by the
above commit on kernel 3.7.
Change-Id: If78651268435aaed1f07ebdef374c46c0a528429
Signed-off
error, print a message but continue anyway.
Change-Id: If1e7d8931f440ea9259726c36d3df797dda016fb
Signed-off-by: Gerlando Falauto
Cc: Timur Tabi
Cc: David S. Miller
Cc: Andy Fleming
Cc: Kumar Gala
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 10 ++
1 file changed, 10 insertions(+)
Hi Thomas,
did anything ever come out of this?
I'm encountering a similar but different problem, where a nested
interrupt handler is called directly from the resend tasklet (and
therefore -- if I'm not mistaken -- in an atomic context, which is
unexpected). This issue however appears during s
Hi Matthew,
On 01/17/2014 11:57 PM, Matthew Garrett wrote:
Some hardware may be broken in interesting and board-specific ways, such
that various bits of functionality don't work. This patch provides a
mechanism for overriding mii registers during init based on the contents of
the device tree dat
Hi,
On 03/13/2014 01:57 PM, Austin Boyle wrote:
Hi Gerlando,
[...]
In my opinion, we're breaking something here (call it userspace API or
otherwise). My suggestion would then be to make it an optional feature to be
explicitly enabled on the device tree, like Heicho did for CFI flashes:
ht
Hi Austin,
On 03/08/2014 05:36 PM, Austin Boyle wrote:
Existing calculation of block protect bits only works for devices with 64
sectors or more. This patch generalises the calculation based on the number of
sectors. This logic is applicable to the STmicro devices:
m25p10, p20, p40, p80, p16, pe
Hi Austin, Brian,
thank you for taking care of this.
On 03/08/2014 04:03 PM, Austin Boyle wrote:
[...]
I don't think there is an issue with some bootloaders not supporting
this feature, it is already optional.
What do you mean exactly by "it is optional"?
I agree with you that an explicit io
eing things"?
Thank you,
Gerlando
P.S. FWIW, the original author of the patch seem to have disappeared.
On 11/20/2013 09:04 PM, Gerlando Falauto wrote:
Hi,
On 01/04/2013 01:02 AM, Austin Boyle wrote:
This patch adds generic support for flash protection on STmicro chips.
On chips with le
Hi Florian,
On 02/11/2014 06:43 PM, Florian Fainelli wrote:
Hi Gerlando,
2014-02-11 1:09 GMT-08:00 Gerlando Falauto :
Hi Florian,
first of all, thank you for your answer.
On 02/10/2014 06:09 PM, Florian Fainelli wrote:
Hi Gerlando,
Le lundi 10 février 2014, 17:14:59 Gerlando Falauto a
Hi Florian,
first of all, thank you for your answer.
On 02/10/2014 06:09 PM, Florian Fainelli wrote:
Hi Gerlando,
Le lundi 10 février 2014, 17:14:59 Gerlando Falauto a écrit :
Hi,
I'm currently trying to fix an issue for which this patch provides a
partial solution, so apologies in ad
Hi,
I'm currently trying to fix an issue for which this patch provides a
partial solution, so apologies in advance for jumping into the
discussion for my own purposes...
On 02/04/2014 09:39 PM, Florian Fainelli wrote:> 2014-01-17 Matthew
Garrett :
>> Some hardware may be broken in interesti
Hi,
On 01/04/2013 01:02 AM, Austin Boyle wrote:
This patch adds generic support for flash protection on STmicro chips.
On chips with less than 3 protection bits, the unused bits are don't cares
and so can be written anyway.
I have two remarks:
1) I believe this introduces incompatibilities wi
Hi Mark,
On 11/13/2013 02:33 PM, Mark Brown wrote:
On Wed, Nov 13, 2013 at 09:02:28AM +0100, Gerlando Falauto wrote:
The bindings assumed that the cs-gpios property is always there.
However, a single SPI device can also work fine without an explicit chip select.
Use the SPI_GPIO_NO_CHIPSELECT
The bindings assumed that the cs-gpios property is always there.
However, a single SPI device can also work fine without an explicit chip select.
Use the SPI_GPIO_NO_CHIPSELECT mode when the property is not present or invaild.
Signed-off-by: Gerlando Falauto
Cc: Maxime Ripard
Cc: Mark Brown
Hi Stephan,
On 11/11/2013 07:53 PM, Stephen Warren wrote:
On 11/11/2013 11:28 AM, Gerlando Falauto wrote:
Hi everyone,
[jumping in on an old discussion]
On 09/09/2013 06:19 PM, Mark Brown wrote:
On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
On 09/04/2013 03:05 AM, Lars
Hi everyone,
[jumping in on an old discussion]
On 09/09/2013 06:19 PM, Mark Brown wrote:
On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
On 09/04/2013 03:05 AM, Lars Poeschel wrote:
The driver that tries to use the GPIO requested by this patch before HAS to
fail. This is exa
enable handling of separate mask registers for Orion SoC GPIOs,
fixing indeed the regression introduced by e59347a
"arm: orion: Use generic irq chip".
Reported-by: Joey Oravec
Signed-off-by: Holger Brunck
Signed-off-by: Gerlando Falauto
Cc: linux-arm-ker...@lists.infradead.org
Cc: Si
Hi Thomas, Sebastian,
I see these changes made it to 3.11.
AFAICT though, 3.10.9 still has the original bug (the one that got me to
write the patch for handling separate mask registers) and I am bit
confused as to how to integrate that back into 3.10 (or any previous
affected kernels, as they
Hi Peter,
sorry for the slow response...
On 09/09/2013 12:08 PM, Peter Zijlstra wrote:
On Tue, Sep 03, 2013 at 10:26:19AM -0700, John Stultz wrote:
Enabling the SCHED_FEAT(HRTICK, true) bit tends to cause lots of issues
on the various hardware I have, tripping the lockdep warnings on various
o
critical section.
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Gerlando Falauto
Cc: Mathieu Desnoyers
Cc: stable #3.11, 3.10
Reported-by: Gerlando Falauto
Tested-by: Lin Ming
Signed-off-by: John Stultz
For what it's worth (I guess it's a bit late now):
Tested-by: Gerlando Falaut
Hi John,
On 09/03/2013 07:26 PM, John Stultz wrote:
On 09/03/2013 07:57 AM, Gerlando Falauto wrote:
Hi,
I tried again from scratch, so let me recap the whole situation, so we
can all view it from the same standpoint. This should make the problem
easier to see and reproduce.
I can confirm
Hi,
I tried again from scratch, so let me recap the whole situation, so we
can all view it from the same standpoint. This should make the problem
easier to see and reproduce.
I can confirm that running a stock 3.10 kernel with HRTICK enabled:
diff --git a/kernel/sched/features.h b/kernel/sch
Hi Stephen,
>
Just curious. Do you have this patch from 3.11 applied to your 3.10
kernel tree?
Nope, I didn't. But I applied it, and it doesn't seem to make a
difference, unfortunately. :-(
Thanks for your help anyway!
Gerlando
commit 971ee28cbd1ccd87b3164facd9359a534c1d2892
Author: Peter
Hi,
sorry, it took me a while to narrow it down...
On 08/30/2013 01:45 AM, John Stultz wrote:
On 08/29/2013 01:56 PM, Falauto, Gerlando wrote:
Hi everyone,
I ran into the deadlock situation reported at the bottom.
Actually, on my latest 3.10 kernel for some reason I don't get the
report (the
Hi David, Michael,
I'm in the unpleasant position of needing to apply the UAPI
disintegration to some "proprietary" stuff, and I would like the use the
same scripts used mainline.
Would it be possible get ahold of the necessary scripts?
I tried looking and I only found [1] where the reference
Commit-ID: af80b0fed67261dcba2ce2406db1d553d07cbe75
Gitweb: http://git.kernel.org/tip/af80b0fed67261dcba2ce2406db1d553d07cbe75
Author: Gerlando Falauto
AuthorDate: Mon, 6 May 2013 14:30:21 +
Committer: Thomas Gleixner
CommitDate: Wed, 29 May 2013 10:57:10 +0200
genirq: Generic
Commit-ID: 899f0e66fff36ebb6dd6a83af9aa631f6cb7e0dc
Gitweb: http://git.kernel.org/tip/899f0e66fff36ebb6dd6a83af9aa631f6cb7e0dc
Author: Gerlando Falauto
AuthorDate: Mon, 6 May 2013 14:30:19 +
Committer: Thomas Gleixner
CommitDate: Wed, 29 May 2013 10:57:10 +0200
genirq: Generic
Commit-ID: cfeaa93f8a13ae9117ae20933a38a406de80849e
Gitweb: http://git.kernel.org/tip/cfeaa93f8a13ae9117ae20933a38a406de80849e
Author: Gerlando Falauto
AuthorDate: Mon, 6 May 2013 14:30:17 +
Committer: Thomas Gleixner
CommitDate: Wed, 29 May 2013 10:57:09 +0200
genirq: Generic
Hi Thomas,
On 05/06/2013 04:30 PM, Thomas Gleixner wrote:
Changes vs. V1:
- Fixed the generic chip pointer thinko (Sebastian Hesselbarth)
- Proper support for mask cache
- Read mask hardware only for the first map of an generic chip
instance
- sun4i
Hi everyone,
any chance we could move this pachset to the next level (at least for
mainline)?
Thanks a lot!
Gerlando
On 03/21/2013 06:12 PM, Gerlando Falauto wrote:
This patchset addresses a regression found with the Orion GPIO controller
when both Edge- and Level- based interrupts are
Hi everyone,
On 04/10/2012 08:12 PM, Sergei Trofimovich wrote:
On Mon, 09 Apr 2012 22:28:28 +0100
Ian Campbell wrote:
On Sun, 2012-04-08 at 11:59 +0300, Sergei Trofimovich wrote:
In order to make the box boot I had to set:
CONFIG_EMBEDDED=y
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
Hi David,
On 07/25/2012 05:26 PM, David Woodhouse wrote:
On Wed, 2012-07-25 at 17:21 +0200, Gerlando Falauto wrote:
So could someone please spend a few words on what happened in the meantime?
To me it looks like the l2-mtd tree got rebased at some point, but I'm
quite at loss about this
Hi folks, Stepehen,
On 07/17/2012 03:00 AM, Stephen Rothwell wrote:
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
drivers/mtd/chips/cfi_cmdset_0002.c between commit 420962884379 ("mtd:
cfi_cmdset_0002: Micron M29EW bugfixes as per TN-13-07") from the mtd
tree and commi
36 matches
Mail list logo
