On Thu, Jun 21, 2018 at 04:35:44PM +0300, Gilad Ben-Yossef wrote:
>
> What about OFB? unless I've missed something there is no generic
> implementation... ?
In general we shouldn't add hardware drivers for algorithms that
do not have a generic implementation. Sometimes they slip through
though.
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->base + PRNG_STATUS);
> - if (
On 21-06-18, 23:30, Timur Tabi wrote:
> > But there is a bigger concern raised by Herbert on this not being a true
> > RNG and thus should be moved to crypto/
>
> I've asked some of the crypto experts in Q to answer that question.
That will be very helpful, I have not got any info on this. Altho
On 21-06-18, 23:46, Timur Tabi wrote:
> 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 w
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 21-06-18, 23:26, Timur Tabi wrote:
> 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 regis
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,
- rng->hwrng.c
On 21-06-18, 10:17, Timur Tabi wrote:
> 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, be
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 hardwa
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,
> - rng->hwrng.cleanup = msm_rng_cleanup,
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 hardware is already
> enabled nev
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,
+
On 21-06-18, 10:17, Timur Tabi wrote:
> The hwrng.read callback includes a boolean parameter called 'wait'
> which indicates whether the function should block and wait for
> more data.
>
> When 'wait' is true, the driver spins on the DATA_AVAIL bit or until
> a reasonable timeout. The timeout can
Quoting Vinod (2018-06-20 06:37:25)
> On 19-06-18, 22:58, Stephen Boyd wrote:
> > Quoting Vinod Koul (2018-06-19 02:54:30)
> > > Qcom 8996 and later chips support prng v2 which requires to
> > > implement only .read callback for hwrng.
> > >
> > > This version of chip has multiple Execution Enviro
On Wed, Jun 20, 2018 at 7:30 PM, Herbert Xu wrote:
> On Wed, Jun 20, 2018 at 12:04:01PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> uses the newly defined max digest size macro. Also adds a sanity-check
>> at use-time.
>>
>> [1]
>> https://lkm
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 disable or configure it.
Signed-off-b
The hwrng.read callback includes a boolean parameter called 'wait'
which indicates whether the function should block and wait for
more data.
When 'wait' is true, the driver spins on the DATA_AVAIL bit or until
a reasonable timeout. The timeout can occur if there is a heavy load
on reading the PRN
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
On Tue, Jun 19, 2018 at 5:27 PM, Herbert Xu wrote:
> On Sun, Jun 17, 2018 at 01:06:42PM +0300, Gilad Ben-Yossef wrote:
>>
>> It was ctr(aes). I wrongly assumed that we are supposed to unconditionally
>> copy
>> the cipher-text block post operation and let the caller do with it what it
>> wants and
* Jarkko Sakkinen wrote:
> create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
> create mode 100644 drivers/platform/x86/intel_sgx/Makefile
> create mode 100644 drivers/platform/x86/intel_sgx/le/Makefile
> create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/Makefile
> create
On Thu, Jun 21, 2018 at 2:47 PM, Hadar Gat wrote:
> finup() operation was incorrect, padding was missing.
> Fix by setting the ccree HW to enable padding.
>
> Signed-off-by: Hadar Gat
> Cc: sta...@vger.kernel.org
Acked-by: Gilad Ben-Yossef
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
val
On Thu, Jun 21, 2018 at 02:27:10PM +0300, Stanimir Varbanov wrote:
>
> OK, I just wanted to say that it is _not_ PRNG and the register names
> gives us wrong impression.
So does it generate one bit of output for each bit of hardware-
generated entropy like /dev/random? Or does it use a hardware-
g
finup() operation was incorrect, padding was missing.
Fix by setting the ccree HW to enable padding.
Signed-off-by: Hadar Gat
Cc: sta...@vger.kernel.org
---
drivers/crypto/ccree/cc_hash.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccree/cc_h
Hi Herbert,
On 06/21/2018 01:15 PM, Herbert Xu wrote:
> On Thu, Jun 21, 2018 at 12:56:34PM +0300, Stanimir Varbanov wrote:
>>
>>> Is this really a pseudo-RNG? If so it needs to be moved over to
>>> the algif_rng interface.
>>
>> Despite the register name (PRNG_ registers prefix) the IP is using FI
On Thu, Jun 21, 2018 at 12:56:34PM +0300, Stanimir Varbanov wrote:
>
> > Is this really a pseudo-RNG? If so it needs to be moved over to
> > the algif_rng interface.
>
> Despite the register name (PRNG_ registers prefix) the IP is using FIPS
> approved algorithm and we can claim that this is true
Hi Herbert,
On 06/19/2018 05:28 PM, Herbert Xu wrote:
> On Mon, Jun 18, 2018 at 07:42:59PM +0530, Vinod Koul wrote:
>> Qcom 8996 and later chips support prng v2 where we need to only
>> implement .read callback for hwrng.
>>
>> Add a new table for v2 which supports this and get version required fo
27 matches
Mail list logo
