On 17/04/13 15:06, Matt Fleming wrote:
(Cc'ing some more folks)
On 16/04/13 16:58, Bryan O'Donoghue wrote:
This warning is caused by efi_enter_virtual_mode mapping memory marked
as !EFI_RUNTIME_MEMORY. The reason this memory is being mapped is to
work around buggy code that stor
memory EFI_RUNTIME_MEMORY is is consistent with the code in
arch/ia64/kernel/efi.c:efi_enter_virtual_mode();
Signed-off-by: Bryan O'Donoghue
---
Documentation/kernel-parameters.txt |4
arch/x86/platform/efi/efi.c | 14 +++---
2 files changed, 15 insertions(
UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
is an ancient African word meaning "Why do something right when you can
do it so wrong that children will weep and brave adults will cower before
you", and "UEI" is Celtic for "We missed DOS so we burne
On 19/04/13 06:58, Greg KH wrote:
This patch gives the option to switch off that behavior - if your BIOS
has neither BGRT - nor bugs that require mapping of EFI boot code/data
No, never add new boot options, no users, or distros, know to set them.
Isn't there some way we can dynamically determi
Architectural MSRs associated with microcode are for P6 or higher.
Add a check to early microcode to detect < P6.
Without a check for < P6 - we end up reading from unimplemented MSRs
on Pentium.
Signed-off-by: Bryan O'Donoghue
---
arch/x86/kernel/microcode_intel_ear
On 19/04/13 20:11, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 06:23:03PM +0100, Bryan O'Donoghue wrote:
Architectural MSRs associated with microcode are for P6 or higher.
Add a check to early microcode to detect< P6.
Without a check for< P6 - we end up reading from unimplemen
On 19/04/13 22:25, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
Just filter out P5 and earlier. The code already does that for CPUs
which don't have CPUID.
Actually, an alternative - more practical albeit not very accurate
More practical ? Hmm - the
On 20/04/13 00:13, H. Peter Anvin wrote:
On 04/19/2013 02:44 PM, Bryan O'Donoghue wrote:
On 19/04/13 22:25, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
Just filter out P5 and earlier. The code already does that for CPUs
which don't
es and less code to accomplish the fix.
Signed-off-by: Bryan O'Donoghue
---
arch/x86/kernel/microcode_core_early.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/microcode_core_early.c
b/arch/x86/kernel/microcode_core_early.c
index 577db
only memory with attribute EFI_RUNTIME_MEMORY will be mapped.
Mapping only memory EFI_RUNTIME_MEMORY is is consistent with the code in
arch/ia64/kernel/efi.c:efi_enter_virtual_mode();
Signed-off-by: Bryan O'Donoghue
---
arch/x86/platform/efi/efi-bgrt.c | 20 +++-
arch/x8
te 0 and to throw an
error if that bit is not present, based on the PS/2 specification.
Signed-off-by: Bryan O'Donoghue <[EMAIL PROTECTED]>
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/inp
Vojtech Pavlik wrote:
>>Not all mice folow the protocol unfortunately. PLease try instead the
>>patch below
Yes Dmitry, that does as advertised.
Bryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Greetings list.
arch/arm/config.in has an error which breaks make.
I've googled this a bit just by searching for drivers/ssi/Config.in and the
first reference I find to this breakage is in 2002 !
For completeness shouldn't this really be removed once and for all?
I'm not clear on what the procedu
Greetings list.
I'm curious about something which looks like an error in the mpc8xx
build of the latest 2.6.11-rc1 kernel.
Firstly, I have a 2.4.28-rc1 which builds just fine for this arch,
however from an almost totally similar kernel config as was used in the
2.4, and with the same compiler,
[2] https://bitbucket.org/andy-shev/linux/branch/topic%2Fdw%2Fqrk
>
> Bryan, since this series doesn't include any DMA management quirks I
> didn't
> address it. It is a matter of the following series which I would send
> later.
OK I'm not 100% happy with that but I
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/timesync_platform.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/timesync_platform.c
b/drivers/staging/greybus/timesync_platform.c
index 50e8883..113f3d6 100644
--- a/drivers/st
On Wed, 2016-09-07 at 15:39 +0300, Andy Shevchenko wrote:
> +#define IPCMSG_COLD_OFF0x80/* Only for Tangier
> */
Andy, I'm wondering are these magic numbers documented somewhere ?
---
bod
On Wed, 2016-09-14 at 20:29 +0200, Greg KH wrote:
> On Wed, Sep 14, 2016 at 08:07:54PM +0200, Greg KH wrote:
> >
> > On Wed, Sep 14, 2016 at 06:36:26PM +0100, Mark Rutland wrote:
> > >
> > > Hi Greg,
> > >
> > > On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote:
> > > >
> > > > Given that
On Thu, 2016-09-15 at 11:13 +0100, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 10:35:33AM +0100, Bryan O'Donoghue wrote:
> >
> I don't think the history matters,
Your comment seemed to indicate you thought we were reading a
architectural timer directly - which we aren&#
On Thu, 2016-09-15 at 11:35 +0100, Bryan O'Donoghue wrote:
>
Here's a slightly better diagram.
PMIC -> refclk provided to each (timer) element below.
MSM8994(timer) -- > USB
WD8a
APBridgeA (timer) -> UniPro b
On Thu, 2016-09-15 at 12:17 +0200, Greg KH wrote:
> This
> > is the first I've heard of timesync having a binding. I can't
> imagine
> > why it needs one.
>
> Ah, I'll let Bryan answer that one :)
It's possible we could drop the binding. It was needed to describe the
register location of the MMIO
x27;re all likely to
> end
> up exasperated.
>
> Please do Cc me on those.
>
> Regardless, until those appear and a reasonable time has been given
> for
> replies, my comments regarding the lack of review stand, as does my
> NAK
> for the series.
>
> On Thu, Se
On Thu, 2016-09-15 at 13:46 +0100, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote:
> >
> > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote:
> > >
> > > For example, you have absolutely no guarantee as to what
On Thu, 2016-09-15 at 16:47 +0100, Mark Rutland wrote:
> On
> I can't say this any more explicitly:
>
>
> * The DT *cannot* know anything about get_cycles() *
>
>
> It's no more complex than
On 24/10/17 09:25, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Greg Kroah-Hartman
Cc: "Bryan O'Donoghue"
Cc: J
On 24/10/17 10:35, Bryan O'Donoghue wrote:
On 24/10/17 09:25, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list
pointer to
all timer callbacks, switch to using the new timer_setup() and
from_timer()
to pass the timer pointer explicitly.
Cc: Greg Kroah-Ha
On 24/10/17 13:47, Kees Cook wrote:
On Tue, Oct 24, 2017 at 2:40 AM, Bryan O'Donoghue
wrote:
On 24/10/17 10:35, Bryan O'Donoghue wrote:
On 24/10/17 09:25, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer
to
all timer callbacks, switch to
On 24/10/17 14:14, Kees Cook wrote:
On Tue, Oct 24, 2017 at 5:52 AM, Bryan O'Donoghue
wrote:
On 24/10/17 13:47, Kees Cook wrote:
On Tue, Oct 24, 2017 at 2:40 AM, Bryan O'Donoghue
wrote:
On 24/10/17 10:35, Bryan O'Donoghue wrote:
On 24/10/17 09:25, Kees Cook wrote:
In
On 24/10/17 15:49, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Greg Kroah-Hartman
Cc: "Bryan O'Donoghue"
Cc: J
;gb->kfifo_lat);
out_conn:
device_unregister(dev);
@@ -1302,7 +1282,6 @@ static void gb_loopback_disconnect(struct gb_bundle
*bundle)
kthread_stop(gb->task);
kfifo_free(&gb->kfifo_lat);
- kfifo_free(&gb->kfifo_ts);
gb_connection_latency_tag_disable(gb->connection);
debugfs_remove(gb->file);
This looks right to me
Reviewed-by: Bryan O'Donoghue
On 02/11/17 14:32, Arnd Bergmann wrote:
This driver is the only one using the deprecated timeval_to_ns()
helper. Changing it from do_gettimeofday() to ktime_get() makes
the code more efficient, more robust against concurrent
settimeofday(), more accurate and lets us get rid of that helper
in the
On 03/11/17 20:21, Kees Cook wrote:
On Mon, Oct 30, 2017 at 5:05 PM, Kees Cook wrote:
On Mon, Oct 30, 2017 at 5:01 PM, wrote:
There's a separate change to loopback.c an old patch ARAIR that will subtract
use of the timer from loopback.c so you can skip that bit.
Okay, cool. Since the op
if (gb->ts.tv_usec == 0 && gb->ts.tv_sec == 0)
- do_gettimeofday(&gb->ts);
+ if (ktime_to_ns(gb->ts) == 0)
+ gb->ts = ktime_get();
mutex_unlock(&gb->mutex);
/* Else operations to perform */
Fine with this change too.
Acked-by: Bryan O'Donoghue
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to operation.h and get/set
methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
Cc: Jo
two birds with err, two stones (no aggression to
birds intended) namely:
- Converting over to the core asynchronous API
- Getting rid of the timer code in loopback which will unblock what Kees is
doing.
Bryan O'Donoghue (2):
staging: greybus: operation: add private data with get/set acce
the cringe-worthy 'pending' flag. The completion callback
triggered by operation.c will provide an authoritative result code -
including -ETIMEDOUT for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Kees Co
On 05/11/17 12:24, Johan Hovold wrote:
+ if (error) {
gb->error++;
+ gb->iteration_count++;
+ }
And this looks like an unrelated bug fix that should go in it's own
patch, right?
I pinged t
the core asynchronous API
- Getting rid of the timer code in loopback which will unblock what Kees is
doing.
Bryan O'Donoghue (4):
staging: greybus: loopback: Hold per-connection mutex across
operations
staging: greybus: loopback: Fix iteration count on async path
staging: greybus: op
the cringe-worthy 'pending' flag. The completion callback
triggered by operation.c will provide an authoritative result code -
including -ETIMEDOUT for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Kees
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to struct gb_operation and
get/set methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support")
Signed-off-by: Bryan O'Donoghue
Reported-by: Mitch Tasman
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Mitch Tasman
Cc: gre
ult several members of the per connection struct gb_loopback are racy.
The solution is restoring the old location of mutex_unlock(&gb->mutex) as
it was in commit d9fb3754ecf8 ("greybus: loopback: Relax locking during
loopback operations").
Fixes: 8e1d6c336d74 ("greybus: loopback: dr
the cringe-worthy 'pending' flag. The completion callback
triggered by operation.c will provide an authoritative result code -
including -ETIMEDOUT for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Kees
rds with err, two stones (no aggression to
birds intended) namely:
- Converting over to the core asynchronous API
- Getting rid of the timer code in loopback which will unblock what Kees is
doing.
Bryan O'Donoghue (4):
staging: greybus: loopback: Hold per-connection mutex across
operat
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to struct gb_operation and
get/set methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
ult several members of the per connection struct gb_loopback are racy.
The solution is restoring the old location of mutex_unlock(&gb->mutex) as
it was in commit d9fb3754ecf8 ("greybus: loopback: Relax locking during
loopback operations").
Fixes: 8e1d6c336d74 ("greybus: loopback: dr
asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support")
Signed-off-by: Bryan O'Donoghue
Reported-by: Mitch Tasman
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Mitch Tasman
Cc: gre
On 30/10/17 11:32, Johan Hovold wrote:
The right thing to do here is to respin your patch from last year which
converts the loopback driver to use the timeout handling in greybus
core.
Actually I wasn't clear if you wanted to to that yourself aswell as the
rest if it.
But sure I can do that
On 30/10/17 11:38, Johan Hovold wrote:
On Mon, Oct 30, 2017 at 11:35:50AM +, Bryan O'Donoghue wrote:
On 30/10/17 11:32, Johan Hovold wrote:
The right thing to do here is to respin your patch from last year which
converts the loopback driver to use the timeout handling in greybus
On 05/10/15 16:19, Kweh, Hock Leong wrote:
-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, October 05, 2015 9:14 PM
So this one is still a separate patch.
If you're going to ignore review comments, maybe I should stop wasting my
time reviewing your stuff..
On 06/10/15 11:53, Kweh, Hock Leong wrote:
-Original Message-
From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie]
Sent: Tuesday, October 06, 2015 5:27 AM
Wilson - trying to test this out on a Galileo Gen2 - which branch are you doing
this against ?
I can apply the first
On 07/10/15 03:01, Kweh, Hock Leong wrote:
-Original Message-
From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie]
Sent: Tuesday, October 06, 2015 10:54 PM
Aside from that, I'm curious which types of capsules you've used here
too - does it include the MFH header
On 07/10/15 20:13, Kweh, Hock Leong wrote:
From: "Kweh, Hock Leong"
Dear maintainers & communities,
This patchset is created on top of Matt's patchset:
1.)https://lkml.org/lkml/2014/10/7/390
"[PATCH 1/2] efi: Move efi_status_to_err() to efi.h"
2.)https://lkml.org/lkml/2014/10/7/391
"[PATCH 2/2
rs.
Finally then if #1 and #2 are true, the fixes here allow the CAAM to come
up and for the RNG to be useable again.
Bryan O'Donoghue (3):
crypto: caam: Fix endless loop when RNG is already initialized
crypto: caam: add logic to detect when running under TrustZone
crypto: caam: detec
crap - looks like just the cover note got sent.
sorry folks
rs.
Finally then if #1 and #2 are true, the fixes here allow the CAAM to come
up and for the RNG to be useable again.
Bryan O'Donoghue (3):
crypto: caam: Fix endless loop when RNG is already initialized
crypto: caam: add logic to detect when running under TrustZone
crypto: caam: detec
eported-by: Ryan Harkin
Signed-off-by: Bryan O'Donoghue
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
fix between u-boot and
Linux is available in these two threads
Link: https://github.com/OP-TEE/optee_os/issues/1408
Link: https://tinyurl.com/yam5gv9a
Link: https://patchwork.ozlabs.org/cover/865042
Signed-off-by: Bryan O'Donoghue
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Es
handle the case of determining if the block is usable
when ctrlpriv->trustzone is true.
Signed-off-by: Bryan O'Donoghue
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
---
drive
uot;
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/clk/imx/clk-imx7d.c | 3 +++
include/dt-bindings/clock/imx7d-clock.h | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc
ag]
Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend
support")
Tested-by: Ryan Harkin
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signe
From: Rui Miguel Silva
Add CAAM device node to the i.MX7s device tree.
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghu
On 24/01/18 18:12, Auer, Lukas wrote:
On Wed, 2018-01-24 at 14:50 +, Bryan O'Donoghue wrote:
From: Rui Miguel Silva
Add CAAM device node to the i.MX7s device tree.
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc:
On 24/01/18 22:48, Bryan O'Donoghue wrote:
The clock configuration has changed to just one CAAM-specific clock in
addition to the ahb clock. This also means that additional
modifications to the CAAM driver are necessary or it will complain that
it doesn't find all clocks.
Sure -
On 25/01/18 13:20, Auer, Lukas wrote:
On Wed, 2018-01-24 at 14:50 +, Bryan O'Donoghue wrote:
When TrustZone is enabled on sec4 compatible silicon the first page
of the
CAAM is reserved for TrustZone only, this means that access to the
deco
registers is restricted and will return zero
On 25/01/18 17:50, Horia Geantă wrote:
If the first ("global") caam register page is not accessible, RNG init is not
the only problem. For e.g. device endianness detection won't work.
Hi Horia,
Yes I had that thought that there were other gotchas lurking once the
CAAM was in a more restricted
: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/imx7s.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 82ad26e..e38c159 100644
--- a/arch/arm/boot/dts/imx7s.dts
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/caa
io Estevam
Cc: Peng Fan
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/clk/imx/clk-imx7d.c | 1 +
include/dt-bindings/clock/imx7d-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7
t #1 is not then it's a NOP as Linux has full permission to rewrite the
deco registers in the first page of CAAM registers.
Finally then if #1 and #2 are true, the fixes here allow the CAAM to come
up and for the RNG to be useable again.
Bryan O'Donoghue (1):
crypto: caam: Fix endless lo
Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: "David S. Miller"
Cc: Lukas Auer
Cc: # 4.12+
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 98986d3..0a
ag]
Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend
support")
Tested-by: Ryan Harkin
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: "David S. Miller"
Cc: Lukas Auer
Cc: # 4.12+
Reviewe
atch
for the NULL pointer dereference fixes a cash on this path). If #2 is true
but #1 is not then it's a NOP as Linux has full permission to rewrite the
deco registers in the first page of CAAM registers.
Finally then if #1 and #2 are true, the fixes here allow the CAAM to come
up and for
uot;
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/clk/imx/clk-imx7d.c | 1 +
include/dt-bindings/clock/imx7d-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..52ab096
From: Rui Miguel Silva
Add CAAM device node to the i.MX7s device tree.
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghu
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/d
2+
Reviewed-by: Horia Geantă
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 027e121..98986d3 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/cryp
Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Cc: # 4.12+
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.
Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Cc: # 4.12+
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.
, the fixes here allow the CAAM to come
up and for the RNG to be useable again.
Bryan O'Donoghue (1):
crypto: caam: Fix endless loop when RNG is already initialized
Rui Miguel Silva (4):
crypto: caam: Fix null dereference at error path
crypto: caam: do not use mem and emi_slow clock f
From: Rui Miguel Silva
Add CAAM device node to the i.MX7s device tree.
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghu
2+
Reviewed-by: Horia Geantă
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 027e121..98986d3 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/cryp
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/crypto/caam/ctrl.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/d
uot;
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
drivers/clk/imx/clk-imx7d.c | 1 +
include/dt-bindings/clock/imx7d-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..52ab096
t get into this loop mess later
on.
Fixes: 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver")
Signed-off-by: Bryan O'Donoghue
Cc: a.zu...@towertech.it
Cc: alexandre.bell...@free-electrons.com
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: # v3.16+
---
On 04/12/2018 20:58, Cristian Sicilia wrote:
Some concatenated strings are now spaced.
Signed-off-by: Cristian Sicilia
---
drivers/staging/greybus/loopback.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybu
On 05/12/2018 21:00, Sicilia Cristian wrote:
It doesn't change the result string
So why do it then ?
On 06/12/2018 15:05, Greg Kroah-Hartman wrote:
On Thu, Dec 06, 2018 at 09:43:46AM +, Bryan O'Donoghue wrote:
On 05/12/2018 21:00, Sicilia Cristian wrote:
It doesn't change the result string
So why do it then ?
Because it is easier to read this way and odds are checkpatch
On 06/12/2018 16:23, Greg Kroah-Hartman wrote:
On Thu, Dec 06, 2018 at 04:14:53PM +, Bryan O'Donoghue wrote:
On 06/12/2018 15:05, Greg Kroah-Hartman wrote:
On Thu, Dec 06, 2018 at 09:43:46AM +0000, Bryan O'Donoghue wrote:
On 05/12/2018 21:00, Sicilia Cristian wrote:
It doesn&#x
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Since lbid isn't mentioned anywhere else in greybus/, it's hard to
figure out how it was meant to be used. It does seem like entirely
dead (write-only) code.
yep, dead code
Reviewed-by: Bryan O'Donoghue
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the followup cleanup.
What's the problem you're fixing here ?
Is it tested ?
On 23/10/2018 17:20, Rasmus Villemoes wrote:
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the follow
On 28/12/2023 11:41, Ulf Hansson wrote:
Let's avoid some of the boilerplate code to manage the vcodec PM domains,
by converting into using dev_pm_domain_attach|detach_list().
Cc: Mauro Carvalho Chehab
Cc: Stanimir Varbanov
Cc: Vikash Garodia
Cc: "Bryan O'Donoghue"
Cc:
- qcom,pmi632-vbus-reg
- const: qcom,pm8150b-vbus-reg
Reviewed-by: Bryan O'Donoghue
ot;;
+ reg = <0x1100>;
+ };
+
pm7250b_temp: temp-alarm@2400 {
compatible = "qcom,spmi-temp-alarm";
reg = <0x2400>;
Reviewed-by: Bryan O'Donoghue
swap";
+ vdd-vbus-supply = <&pm7250b_vbus>;
+ };
+
pm7250b_temp: temp-alarm@2400 {
compatible = "qcom,spmi-temp-alarm";
reg = <0x2400>;
Reviewed-by: Bryan O'Donoghue
remote-endpoint = <&pm7250b_role_switch_in>;
};
&usb_1_hsphy {
@@ -740,10 +790,15 @@ &usb_1_hsphy {
&usb_1_qmpphy {
vdda-phy-supply = <&vreg_l22a>;
vdda-pll-supply = <&vreg_l16a>;
+ orientation-switch;
status = "okay";
};
+&usb_1_qmpphy_out {
+ remote-endpoint = <&pm7250b_typec_mux_in>;
+};
+
&wifi {
vdd-0.8-cx-mx-supply = <&vreg_l4a>;
vdd-1.8-xo-supply = <&vreg_l7a>;
This looks consistent with 8250
Reviewed-by: Bryan O'Donoghue
On 01/04/2024 18:21, Adam Skladowski wrote:
Add node describing wireless connectivity subsystem.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 104 ++
1 file changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b
On 13/04/2024 18:03, Adam Skladowski wrote:
This patch series provide support for display subsystem, gpu
and also adds wireless connectivity subsystem support.
Changes since v2
1. Disabled mdss_dsi nodes by default
2. Changed reg size of mdss_dsi0 to be equal on both
3. Added op
,
+ .cp_nonpixel_size = 0x2480,
.fwname = "qcom/vpu-2.0/venus.mbn",
};
Reviewed-by: Bryan O'Donoghue
1 - 100 of 547 matches
Mail list logo
