Hello Kshitiz,
On 09.04.24 12:54, Kshitiz Varshney wrote:
> Hi David,
>> + b->fmt_version = DCP_BLOB_VERSION;
>> + get_random_bytes(b->nonce, AES_KEYSIZE_128);
>> + get_random_bytes(b->blob_key, AES_KEYSIZE_128);
>
> We can use HWRNG instead of using kernel RNG. Please refer
>
Hello Tokunori-san,
On 20.02.22 13:22, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Could you please try the version 2 patch attached for the error case?
> This version is to check the DQ true data 0xFF by chip_good().
I had a similar patch locally as well at first. I just tested yours
and I can'
Hello Tokunori,
On 06.03.22 16:49, Tokunori Ikegami wrote:
> Hi,
>
> On 2022/03/04 20:11, Ahmad Fatoum wrote:
>> Hello Tokunori-san,
>>
>> On 20.02.22 13:22, Tokunori Ikegami wrote:
>>> Hi Ahmad-san,
>>>
>>> Could you please try the version
Hello Tokunori-san,
On 08.03.22 17:13, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> On 2022/03/08 18:44, Ahmad Fatoum wrote:
>> Hello Tokunori,
>>
>> On 06.03.22 16:49, Tokunori Ikegami wrote:
>>> Hi,
>>>
>>> On 2022/03/04 20:11, Ahmad Fatoum
igher than 512
- skip all odd ratios except for 1:1
- skip 1:1 ratio if and only if !support_1_1_ratio
And for all others, calculate the appropriate divider. Adjust the
code to facilitate this.
Fixes: a50b7926d015 ("ASoC: fsl_sai: implement 1:1 bclk:mclk ratio support")
Signed-off-by: Ahma
Hi,
I've been investigating a breakage on a PowerPC MPC8313: The SoC is connected
via the "Enhanced Local Bus Controller" to a 8-bit-parallel S29GL064N flash,
which is represented as a memory-mapped cfi-flash.
The regression began in v4.17-rc1 with
dfeae1073583 ("mtd: cfi_cmdset_0002: Change w
or miss something important.
>> I hope that's not the case here; if you think it is, don't hesitate to
>> tell me about it in a public reply. That's in everyone's interest, as
>> what I wrote above might be misleading to everyone reading this; any
>> sug
fly into most of them. Unfortunately
>>>> therefore I sometimes will get things wrong or miss something important.
>>>> I hope that's not the case here; if you think it is, don't hesitate to
>>>> tell me about it in a public reply. That's in everyone's
> I think this should work for S29GL964N since the chip_ready() is used and
> works as mentioned.
yes, this resolves my issue:
Tested-by: Ahmad Fatoum
>>>> Doesn't seem to be a buffered write issue here though as the writes
>>>> did work fine before dfeae1073583.
Hello George,
On 05.03.25 13:15, George Cherian wrote:
>> On 05.03.25 12:28, George Cherian wrote:
that can't be disabled and would protect against system lock up:
Consider a memory-corruption bug (perhaps externally via DMA), which
partially
overwrites both main and kdump ke
Hi George,
On 05.03.25 12:28, George Cherian wrote:
> Hi Ahmad,
>> Hi George,
>> On 05.03.25 11:10, George Cherian wrote:
>>> This series adds a new kernel command line option to watchdog core to
>>> stop the watchdog on panic. This is useul in certain systems which prevents
>>> successful loading
Hi George,
On 05.03.25 11:10, George Cherian wrote:
> This series adds a new kernel command line option to watchdog core to
> stop the watchdog on panic. This is useul in certain systems which prevents
> successful loading of kdump kernel due to watchdog reset.
>
> Some of the watchdog drivers st
Hi George,
Hi Guenter,
On 05.03.25 11:34, George Cherian wrote:
>> why is armada_37xx_wdt also here?
>> The stop function in that driver may not sleep.
> Marek,
>
> Thanks for reviewing.
> Since the stop function has a regmap_write(), I thought it might sleep.
> Now that you pointed it out, I ass
13 matches
Mail list logo
