Am Mittwoch, 4. Juli 2018, 08:10:35 CEST schrieb Vinod:
Hi Vinod,
> On 04-07-18, 09:40, Vinod wrote:
> > Hi Stephan,
> >
> > On 03-07-18, 15:28, Stephan Mueller wrote:
> > > Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
> > > > +static int qcom_rng_read(struct qcom_rng *rng, void
On 04-07-18, 09:40, Vinod wrote:
> Hi Stephan,
>
> On 03-07-18, 15:28, Stephan Mueller wrote:
> > Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
> > > +static int qcom_rng_read(struct qcom_rng *rng, void *data, size_t max)
> > > +{
> > > + size_t currsize = 0;
> > > + u32 *retdata =
On 03-07-18, 11:08, Jeffrey Hugo wrote:
> On 7/3/2018 12:04 AM, Vinod Koul wrote:
> > +#if IS_ENABLED(CONFIG_ACPI)
> > +static const struct acpi_device_id qcom_rng_acpi_match[] = {
> > + {
> > + .id = "QCOM8160",
> > + },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(acpi, msm_rng_acpi
On 03-07-18, 09:10, Timur Tabi wrote:
> On 7/3/18 1:04 AM, Vinod Koul wrote:
> > Add support for probing on ACPI systems, with ACPI HID QCOM8160.
> >
> > On ACPI systems, clocks are always enabled, the PRNG should
> > already be enabled, and the register region is read-only.
> > The driver only ve
Hi Stephan,
On 03-07-18, 15:28, Stephan Mueller wrote:
> Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
> > +static int qcom_rng_read(struct qcom_rng *rng, void *data, size_t max)
> > +{
> > + size_t currsize = 0;
> > + u32 *retdata = data;
>
> How can you be sure that this cast
On Tue, Jul 3, 2018 at 9:02 PM, Logan Gunthorpe wrote:
> Actually, scratch that: try this patch as I forgot the read side on the
> previous one.
Yes, this fixes the boot regression, thanks!
You can add:
Tested-by: Fabio Estevam
On 03/07/18 05:57 PM, Logan Gunthorpe wrote:
> To confirm, can you try the patch below?
Actually, scratch that: try this patch as I forgot the read side on the
previous one.
Logan
--
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 5826acd9194e..796ff764dcbf 100644
On 03/07/18 04:21 PM, Andy Shevchenko wrote:
> It is an explicit call to BUG().
> That's why we see wrong instruction trap.
Ok, I think I see the problem... the code is rather confusing:
Prior to the patch, IOs were BE depending on caam_little_end but if
caam_imx was set, then it wrote two LE
On Tue, Jul 3, 2018 at 6:16 PM, Logan Gunthorpe wrote:
> Is this a virtual machine? And if so, any chance we can get an image and
> qemu command line to run it ourselves?
This is a real imx6 development board. I have never tried it on qemu.
Let me see if I can reproduce it on quemu.
101000.jr0: job ring error: irqstate: 0103
[4.037036] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[4.043751] Modules linked in:
[4.046829] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.18.0-rc3-next-20180703-1-g62a05d4-dirty #498
[4.056317] Hardware name: Fre
On Tue, Jul 3, 2018 at 8:20 PM, Logan Gunthorpe wrote:
> Oh. So some IO in some other place must have changed to trigger the BUG...
Yes, there are two 64-bit write operations inside caam_jr_init().
If I use the old 64-bit write function then things works fine:
--- a/drivers/crypto/caam/jr.c
++
On 03/07/18 04:21 PM, Andy Shevchenko wrote:
> On Wed, Jul 4, 2018 at 12:20 AM, Logan Gunthorpe wrote:
>> On 7/3/2018 1:40 PM, Fabio Estevam wrote:
>
>> Also, it could be helpful if you can compile with CONFIG_DEBUG_INFO and
>> use gdb to find out what line "caam_jr_interrupt+0x120" points to
On Wed, Jul 4, 2018 at 12:20 AM, Logan Gunthorpe wrote:
> On 7/3/2018 1:40 PM, Fabio Estevam wrote:
> Also, it could be helpful if you can compile with CONFIG_DEBUG_INFO and
> use gdb to find out what line "caam_jr_interrupt+0x120" points to in
> your image.
It is an explicit call to BUG().
That
On 7/3/2018 1:40 PM, Fabio Estevam wrote:
>> So I have no idea what's going on here... Are we sure this is the patch
>> causing the problem? Did you bisect?
>
> Yes, I am sure that 46e4bf08f6388ba748 is the one causing the kernel boot
> issue.
Also, it could be helpful if you can compile with CO
On 7/3/2018 2:10 PM, Fabio Estevam wrote:
> On Tue, Jul 3, 2018 at 4:58 PM, Andy Shevchenko
> wrote:
>
>> By the way, is there any URL which contains dmesg out of kernel with
>> this commit reverted?
>
> Yes, here is the linux-next 20180626 dmesg (which is the last
> linux-next that does not con
On Tue, Jul 3, 2018 at 11:40 PM, Andy Shevchenko
wrote:
> On Tue, Jul 3, 2018 at 11:10 PM, Fabio Estevam wrote:
>> On Tue, Jul 3, 2018 at 4:58 PM, Andy Shevchenko
>> wrote:
>>
>>> By the way, is there any URL which contains dmesg out of kernel with
>>> this commit reverted?
>>
>> Yes, here is th
On Tue, Jul 3, 2018 at 11:10 PM, Fabio Estevam wrote:
> On Tue, Jul 3, 2018 at 4:58 PM, Andy Shevchenko
> wrote:
>
>> By the way, is there any URL which contains dmesg out of kernel with
>> this commit reverted?
>
> Yes, here is the linux-next 20180626 dmesg (which is the last
> linux-next that d
On Tue, Jul 3, 2018 at 4:58 PM, Andy Shevchenko
wrote:
> By the way, is there any URL which contains dmesg out of kernel with
> this commit reverted?
Yes, here is the linux-next 20180626 dmesg (which is the last
linux-next that does not contain 46e4bf08f63 and it boots fine) :
https://storage.ke
On Tue, Jul 3, 2018 at 10:40 PM, Fabio Estevam wrote:
> On Tue, Jul 3, 2018 at 3:47 PM, Logan Gunthorpe wrote:
>
>> Ok, I'm at a bit of a loss... When I look at the assembly before and
>> after the patch, it looks pretty much the same. Additionally, the
>> function where the undefined exception o
On Tue, Jul 3, 2018 at 3:47 PM, Logan Gunthorpe wrote:
> Ok, I'm at a bit of a loss... When I look at the assembly before and
> after the patch, it looks pretty much the same. Additionally, the
> function where the undefined exception occurs (caam_jr_interrupt())
> doesn't make any use of wr_reg6
On 03/07/18 12:11 PM, Fabio Estevam wrote:
> On Tue, Jul 3, 2018 at 3:09 PM, Andy Shevchenko
> wrote:
>
>> Btw, what is the environment did you use to build it?
>> and what is the environment / make variable you supply (like ARCH,
>> CROSS_COMPILE, etc)?
>
> I build it on a Dell laptop running
On Tue, Jul 3, 2018 at 3:09 PM, Andy Shevchenko
wrote:
> Btw, what is the environment did you use to build it?
> and what is the environment / make variable you supply (like ARCH,
> CROSS_COMPILE, etc)?
I build it on a Dell laptop running Ubuntu 16.04 with the following
variables exported:
expo
On Tue, Jul 3, 2018 at 9:06 PM, Fabio Estevam wrote:
> Hi Logan,
>
> On Tue, Jul 3, 2018 at 3:01 PM, Logan Gunthorpe wrote:
>
>> Besides that, it looks like we are hitting an undefined instruction. So
>> my best guess is that we are somehow now calling a proper 64bit read
>> when we should be cal
On Tue, Jul 3, 2018 at 9:01 PM, Logan Gunthorpe wrote:
> On 03/07/18 11:36 AM, Andy Shevchenko wrote:
>>> This is now in linux-next as commit 46e4bf08f6388 and it breaks
>>> booting imx6 (32-bit ARM):
>>> Any ideas on how to fix this issue?
>>
>> Oops, first of all the header should be hi-lo inst
Hi Logan,
On Tue, Jul 3, 2018 at 3:01 PM, Logan Gunthorpe wrote:
> Besides that, it looks like we are hitting an undefined instruction. So
> my best guess is that we are somehow now calling a proper 64bit read
> when we should be calling two 32-bit reads.
Yes, it seems that's the case.
> Fabio
On 03/07/18 11:36 AM, Andy Shevchenko wrote:
>> This is now in linux-next as commit 46e4bf08f6388 and it breaks
>> booting imx6 (32-bit ARM):
>
>
>> Any ideas on how to fix this issue?
>
> Oops, first of all the header should be hi-lo instead of lo-hi.
> Does it fix it?
>
> Otherwise I didn'
Hi Andy,
On Tue, Jul 3, 2018 at 2:36 PM, Andy Shevchenko
wrote:
> Oops, first of all the header should be hi-lo instead of lo-hi.
> Does it fix it?
I tried as you suggested:
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -10,7 +10,7 @@
#include
#include
-#include
+#
On Tue, Jul 3, 2018 at 6:31 PM, Fabio Estevam wrote:
> Hi Logan,
>
> On Fri, Jun 22, 2018 at 4:47 PM, Logan Gunthorpe wrote:
>> Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
>> functions in non-64bit cases in favour of the new common
>> io-64-nonatomic-lo-hi header.
>>
>> To b
Add a new CCP/PSP PCI device ID and new PSP register offsets.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/sp-pci.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 78c1e9d..
In preparation for adding a new PSP device ID that uses different register
offsets, add support to the PSP version data for register offset values.
And then update the code to use these new register offset values.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c | 24 --
Remove some unused #defines for register offsets that are not used. This
will lessen the changes required when register offsets change between
versions of the device.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c |2 +-
drivers/crypto/ccp/psp-dev.h | 10 +-
2 files c
The wait_event() function is used to detect command completion. The
interrupt handler will set the wait condition variable when the interrupt
is triggered. However, the variable used for wait_event() is initialized
after the command has been submitted, which can create a race condition
with the i
Add a dev_notice() message to the PSP initialization to report when the
PSP initialization has succeeded and the PSP is enabled.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp
The following patches for the PSP support within the CCP driver are
included in this driver update series:
- Fix a possible race condition when checking for command completion
- Add a message to indicate if the PSP function has been enabled
- In preparation for moving register offsets into the ver
On 7/3/2018 12:04 AM, Vinod Koul wrote:
From: Timur Tabi
Add support for probing on ACPI systems, with ACPI HID QCOM8160.
On ACPI systems, clocks are always enabled, the PRNG should
already be enabled, and the register region is read-only.
The driver only verifies that the hardware is already
ARM
[2.056591] Modules linked in:
[2.059671] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.18.0-rc3-next-20180703 #484
[2.067338] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[2.073892] PC is at caam_jr_interrupt+0x120/0x12c
[2.078702] LR is at vprintk_emit
On Tue, Jul 3, 2018 at 11:18 AM, Fabio Estevam wrote:
> Hi Horia,
>
> I am not able to boot linux-next 20180703 on imx6 due to a problem
> with the CAAM driver.
which is caused by the following commit:
commit 46e4bf08f6388ba748597275012d715d5e1861e6
Author: Logan Gunthorpe
Date:
Hi Horia,
I am not able to boot linux-next 20180703 on imx6 due to a problem
with the CAAM driver.
Any ideas?
[1.872473] caam 210.caam: Entropy delay = 3200
[1.938223] caam 210.caam: Instantiated RNG4 SH0
[1.998983] caam 210.caam: Instantiated RNG4 SH1
[2.004019
On 7/3/18 1:04 AM, Vinod Koul wrote:
Add support for probing on ACPI systems, with ACPI HID QCOM8160.
On ACPI systems, clocks are always enabled, the PRNG should
already be enabled, and the register region is read-only.
The driver only verifies that the hardware is already
enabled never tries to
Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
Hi Vinod,
> +static int qcom_rng_read(struct qcom_rng *rng, void *data, size_t max)
> +{
> + size_t currsize = 0;
> + u32 *retdata = data;
How can you be sure that this cast is appropriate? I.e. how is it guaranteed
that data
40 matches
Mail list logo
