tries to disable or configure it.
Signed-off-by: Timur Tabi
[port to crypto API]
Signed-off-by: Vinod Koul
Tested-by: Jeffrey Hugo
Thanks, Jeff. I appreciate it.
On 7/5/18 1:07 AM, Vinod wrote:
Yes we can add driver data in ACPI ID as well so code can be:
if (!has_acpi_companion(&pdev->dev)) {
rng->clk = devm_clk_get(&pdev->dev, "core");
if (IS_ERR(rng->clk))
return PTR_ERR(rng->clk);
On 7/5/18 1:07 AM, Vinod wrote:
Meanwhile any word from testing on ACPI systems?
Jeff Hugo is handling that for me. Since it's a whole new API, he's had
to start over.
On 7/4/18 6:44 AM, Vinod Koul wrote:
+ if (has_acpi_companion(&pdev->dev)) {
+ rng->skip_init = 1;
+ } else {
+ rng->clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(rng->clk))
+ return PTR_ERR(rng->clk);
+
+
On 7/4/18 1:10 AM, Vinod wrote:
Okay so I rechecked this, the hardware gives 32 bits of random data. I
am thinking of splitting the word and updating by each byte. That way
trailing zero can also be avoided which is the case now
The current driver only returns data in multiples of 4 bytes. Why
to disable or configure it.
Signed-off-by: Timur Tabi
[port to crypto API]
Signed-off-by: Vinod Koul
I've asked a colleague who still works at Qualcomm to test this code on
silicon. It looks okay, but I just want to be sure.
+ /*
+* ACPI systems have v2 hardware. The clock
On Thu, Jun 21, 2018 at 6:53 AM, Herbert Xu wrote:
> On Thu, Jun 21, 2018 at 02:27:10PM +0300, Stanimir Varbanov wrote:
> So does it generate one bit of output for each bit of hardware-
> generated entropy like /dev/random? Or does it use a hardware-
> generated seed to power a PRNG?
I have some
On 06/22/2018 01:03 PM, Timur Tabi wrote:
Perhaps it's because you implemented the 'wait' functionality in this
driver? Before the patch there wasn't any sort of wait check so we would
bail out if there wasn't any data even if the caller requested that we
wait for r
On 6/22/18 12:51 PM, Stephen Boyd wrote:
Perhaps it's because you implemented the 'wait' functionality in this
driver? Before the patch there wasn't any sort of wait check so we would
bail out if there wasn't any data even if the caller requested that we
wait for randomness to be available.
No,
On 6/22/18 10:38 AM, Stanimir Varbanov wrote:
Before entering into the read function we already hold a mutex which
serializes data reading so I cannot imagine how below sequence could
happen. Can you explain how to reproduce this race?
1. Core 1 reads status register, shows data is available.
2
On 6/22/18 12:36 AM, Stephen Boyd wrote:
Quoting Timur Tabi (2018-06-21 08:17:55)
@@ -96,11 +110,39 @@ static int msm_rng_read(struct hwrng *hwrng, void *data,
size_t max, bool wait)
/* read random data from hardware */
do {
- val = readl_relaxed(rng->b
On 6/21/18 11:44 PM, Vinod wrote:
So this make me think you should do 2 level support for ACPI, one ACPI
support and one V2 support where we dont touch CONFIG register. That way
both regions will work
The ACPI system is a v2 system. If you want, I can just remove the read
of the CONFIG regist
On 6/21/18 11:27 PM, Vinod wrote:
I have checked the series.
I am not sure I follow that this is v2 and you read CONFIG register.
Apart from that other changes look mostly okay with few nitpicks:)
It seems that there are two registers sets for v2 hardware, one with
CONFIG and one without. I
On 6/21/18 11:24 PM, Vinod wrote:
On 21-06-18, 23:18, Timur Tabi wrote:
On 6/21/18 11:17 PM, Vinod wrote:
this should be a separate patch
What exactly should be a separate patch? This part?
- rng->hwrng.name = KBUILD_MODNAME,
- rng->hwrng.init = msm_rng_init,
-
On 6/21/18 11:23 PM, Vinod wrote:
On 21-06-18, 10:17, Timur Tabi 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
On 6/21/18 11:17 PM, Vinod wrote:
this should be a separate patch
What exactly should be a separate patch? This part?
- rng->hwrng.name = KBUILD_MODNAME,
- rng->hwrng.init = msm_rng_init,
- rng->hwrng.cleanup = msm_rng_cleanup,
- rng->hwrng.read = msm_rng_read,
+
-by: Timur Tabi
---
drivers/char/hw_random/msm-rng.c | 40 ++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/msm-rng.c b/drivers/char/hw_random/msm-rng.c
index 44580588b938..f34713d23d77 100644
--- a/drivers/char/hw_random
e 1 reads status register, shows data is available.
2. Core 2 also reads status register, same result
3. Core 2 reads data register, depleting all entropy
4. Core 1 reads data register, which returns 0
Signed-off-by: Timur Tabi
---
drivers/char/hw_random/msm-rng.c | 57 +++
On Tue, Jun 19, 2018 at 4:54 AM, Vinod Koul wrote:
> This series adds support for newer version of hwrng as found in
> Qualcomm SoCs. To do that add new v2 compatible string and driver_data
> values for v2.
It's amazing you're sending this now, because I also have a PRNG
patchset that I'm sending
why we need to add another one back in.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
,
so that it is saved in the git history.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt; About your question, spin_lock_bh is used in the case of bottom/half as its
> name, there is no need to protect a running/pending list with
> spin_lock_irqsave.
Please respin the patch and include this information in the patch description.
--
Timur Tabi
Linux kernel developer at Freescale
Qiang Liu wrote:
> Use spin_lock_bh to instead of spin_lock_irqsave for improving performance.
Please provide some evidence that performance has improved, as well as an
explanation why it's okay to use spin_lock_bh, and why it's faster.
--
Timur Tabi
Linux kernel developer at Fre
else
> status = error;
>
> - dma_unmap_single(dev, request->dma_desc,
> + dma_unmap_single(priv->dev, request->dma_desc,
You have an indentation problem here.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from t
24 matches
Mail list logo
