cases when the code in question drastically
changed between versions of the series.
So, please add a tag (and feel free to add the same tag to the patch
1) and resend as v3.
Thanks!
--
With Best Regards,
Andy Shevchenko
ers 11-13 refer to the tags.
> On Fri, Mar 12, 2021 at 10:35 AM Andy Shevchenko
> wrote:
> >
> > On Fri, Mar 12, 2021 at 4:21 PM Tong Zhang wrote:
> > >
> > > ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()
> > > before calling
cvf]
Don't you miss the tag I gave?
--
With Best Regards,
Andy Shevchenko
verywhere else use a common sense, when put
backtraces, oopses, etc in the commit message, i.e. leave only ~2-3
(significant) lines instead of 20-30.
--
With Best Regards,
Andy Shevchenko
il, the vf2pf_lock is either not initialized or destroyed, a subsequent
> use of vf2pf_lock will cause issue.
> To fix this issue, only set this flag if adf_dev_init() returns 0.
Makes sense, but please leave only ~2-3 (significant) lines from the
below noisy dump
Reviewed-by: Andy Shevchen
ually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.
--
With Best Regards,
Andy Shevchenko
Use traditional error check pattern
ret = ...;
if (ret)
return ret;
...
instead of checking error code to be 0.
Signed-off-by: Andy Shevchenko
---
drivers/crypto/caam/ctrl.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a
. Patches 1 to 3 apply also to
> Alex's tree (next). Patches 4 and 5 are optional and can be applied at a later
> stage.
Thanks!
FWIW,
Reviewed-by: Andy Shevchenko
> Changes from v4:
> - Patch #2: added Reviewed-by tag from Cornelia Huck
> - Patch #5: added Suggested-
On Wed, Jul 4, 2018 at 2:45 PM, Horia Geanta wrote:
> On 7/4/2018 2:58 AM, Logan Gunthorpe wrote:
>>
>>
>> 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.
>>
>
On Wed, Jul 4, 2018 at 8:23 PM, Logan Gunthorpe wrote:
> On 7/4/2018 11:21 AM, Andy Shevchenko wrote:
>> I think it doesn't contradict with what you are saying rather supports it.
>>
>> I would expect to have lo-hi and hi-lo semantics done according to the
>&g
On Wed, Jul 4, 2018 at 8:16 PM, Andy Shevchenko
wrote:
> On Wed, Jul 4, 2018 at 8:13 PM, Logan Gunthorpe wrote:
>> On 7/4/2018 11:10 AM, Andy Shevchenko wrote:
>>> We have an iDMA 32-bit hardware (see drivers/dma/dw/) which has an
>>> extension 64-bit registers w
On Wed, Jul 4, 2018 at 8:13 PM, Logan Gunthorpe wrote:
> On 7/4/2018 11:10 AM, Andy Shevchenko wrote:
>> We have an iDMA 32-bit hardware (see drivers/dma/dw/) which has an
>> extension 64-bit registers where only one of them has a specific bit
>> to "commit" the
ot;commit" the changes written to all of them. And by some very
unknown reason that bit is in lo part which automatically means we
must to write it last.
--
With Best Regards,
Andy Shevchenko
n explicit call to BUG().
That's why we see wrong instruction trap.
--
With Best Regards,
Andy Shevchenko
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
>>> t
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
re any URL which contains dmesg out of kernel with
this commit reverted?
(It would be even better if we would have 'ignore_loglevel ' there
when CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG=y)
--
With Best Regards,
Andy Shevchenko
is the environment / make variable you supply (like ARCH,
CROSS_COMPILE, etc)?
--
With Best Regards,
Andy Shevchenko
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?
>>
>> Oop
urrently don't follow the spec, however this
>> is a good opportunity to fix the code.
>>
>> Signed-off-by: Logan Gunthorpe
>> Reviewed-by: Horia Geantă
>> Reviewed-by: Andy Shevchenko
>> Cc: Dan Douglass
>> Cc: Herbert Xu
>> Cc: &qu
27;s been around relatively unchanged for a few
> cycles now and I'm getting a bit tired of resubmitting it with little to
> no interest.
>
The first patches that I didn't reviewed before makes sense to me, the
rest (at the end) FWIW,
Reviewed-by: Andy Shevchenko
> Thanks,
&
Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them
to the generic header.
No functional change implied.
Signed-off-by: Andy Shevchenko
---
crypto/md4.c | 17 -
crypto/md5.c | 17 -
include/linux
On Tue, Mar 6, 2018 at 1:46 PM, Greg Kroah-Hartman
wrote:
> On Tue, Mar 06, 2018 at 12:48:29PM +0200, Andy Shevchenko wrote:
>> On Mon, Mar 5, 2018 at 9:08 PM, Logan Gunthorpe wrote:
>> > Clean up the ifdefs which conditionally defined the io{read|write}64
>> > fun
habetical ordering?
--
With Best Regards,
Andy Shevchenko
ything better. It's not an octet though, but 16 bytes
> ('q' is for quadword, meaning four 16-bit words in Intel terminology).
It's apparently follows Intel's terminology by implying "word", so, "octetword".
--
With Best Regards,
Andy Shevchenko
On Tue, Aug 22, 2017 at 8:55 PM, Logan Gunthorpe wrote:
> On 22/08/17 11:40 AM, Andy Shevchenko wrote:
>> Recomendation is kinda arguable. I doubt modern architectures make
>> difference between IO operations and MMIO.
>> Does, for example, PCI requires some special s
On Tue, Aug 22, 2017 at 8:56 PM, Logan Gunthorpe wrote:
>
>
> On 22/08/17 11:41 AM, Andy Shevchenko wrote:
>>>
>>> @@ -59,6 +59,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>
>>
>> I
On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe wrote:
> This is just a resend seeing I've gotten no feedback in a couple weeks.
Overall quite a good clean up! Thanks!
After addressing my comments you may take my
Reviewed-by: Andy Shevchenko
> Changes since v6:
> ** none **
>
> +#include
I would rather try to squeeze to most alpabetiacelly ordered part of this block.
Otherwise it's a pretty nice clean up!
--
With Best Regards,
Andy Shevchenko
oph Hellwig
> cc: Arnd Bergmann
> cc: Alan Cox
> cc: Greg Kroah-Hartman
cc -> Cc ?
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 31, 2017 at 9:04 PM, Logan Gunthorpe wrote:
>
>
> On 31/07/17 12:03 PM, Andy Shevchenko wrote:
>>
>> Per commit 3a044178cccf they are exactly created for this kind of cases.
>>
>
> Sure, ok, and my patchset provides the same set of functions to satisf
On Mon, Jul 31, 2017 at 9:00 PM, Logan Gunthorpe wrote:
> On 31/07/17 11:58 AM, Andy Shevchenko wrote:
>> On Mon, Jul 31, 2017 at 7:31 PM, Logan Gunthorpe wrote:
>>> On 31/07/17 10:10 AM, Andy Shevchenko wrote:
>>>> Some drivers (hardware) would like to have non-
On Mon, Jul 31, 2017 at 7:31 PM, Logan Gunthorpe wrote:
> On 31/07/17 10:10 AM, Andy Shevchenko wrote:
>> Some drivers (hardware) would like to have non-atomic MMIO accesses
>> when readq() defined
>
> Huh? But that's the whole point of the io64-nonatomic header. If a
On Mon, Jul 31, 2017 at 6:55 PM, Logan Gunthorpe wrote:
> On 30/07/17 10:03 AM, Andy Shevchenko wrote:
>> On Thu, Jul 27, 2017 at 2:19 AM, Logan Gunthorpe wrote:
>>> In order to provide non-atomic functions for io{read|write}64 that will
>>> use readq and writeq wh
e cases we want to substitute atomic in favour of non-atomic
when both are defined.
So, please don't do this "smartly".
> +u64 ioread64_lo_hi(void __iomem *addr)
> +{
> + IO_COND(addr, return pio_read64_lo_hi(port), return readq(addr));
> + return 0xff
ral shape of the code), and the
> > original
> > ccp-platform.c is no longer built.
> >
> > Shouldn't ccp-platform.c be deleted by this patch?
> >
>
> Good catch. Both ccp-platform.c and ccp-pci.c should have been
> deleted
> by this patch. I missed deleting it, will fix in next rev.
Don't forget to use -M -C when preparing / sending patches.
--
Andy Shevchenko
Intel Finland Oy
On Fri, Nov 20, 2015 at 2:30 PM, Peter Ujfalusi wrote:
> On 11/20/2015 02:24 PM, Andy Shevchenko wrote:
>> On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote:
>>> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote:
>>>> On 11/19/2015 01:25 PM, Arnd Bergm
m data
Why not unified device properties?
--
With Best Regards,
Andy Shevchenko
--
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
On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
>> >
>> > I assume that the sst-firmware.c case is a mistake, it should just use a
>> > plain DMA_SLAVE and not DMA_MEMCPY.
>>
>> Other
ful
(IIRC Russel's opinion).
On the other hand there are a lot of drivers that are used on the set
of platforms starting from legacy and abandoned ones (like AVR32) to
relatively new and newest.
And I'm not a fan of those thousands of API calls either.
--
With Best Regards,
Andy Shevchenk
these...
>
> I just had a look myself. carma has been removed fortunately in linux-next,
> so we don't have to worry about that any more.
>
> I assume that the sst-firmware.c case is a mistake, it should just use a
> plain DMA_SLAVE and not DMA_MEMCPY.
Other way around.
--
With Best Regards,
Andy Shevchenko
--
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
/arch/x86/include/asm/qspinlock.h:17:317: error: call to
> ‘__compiletime_assert_17’ declared with attribute error: Need native
> word sized stores/loads for atomicity.
> scripts/Makefile.build:264: recipe for target 'crypto/jitterentropy.o' failed
--
With Best Regards,
Andy She
On Wed, 2014-07-09 at 11:31 -0700, Tadeusz Struk wrote:
> On 07/09/2014 08:24 AM, Andy Shevchenko wrote:
>
> > In this case it slightly changes the output, namely the four tetrads will be
> > output on one line.
> >
> > Signed-off-by: Andy Shevchenko
>
> It&
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote:
> Instead of custom approach let's use recently introduced seq_hex_dump()
> helper.
>
> In this case it slightly changes the output, namely the four tetrads will be
> output on one line.
The above paragraph is
han
> the horrid one above.
I have considered to modify hex_dump_to_buffer() to return how many
bytes it actually proceed to the buffer. In that case we can directly
print to m->buf like other seq_ calls do.
But I still have doubts about it. Any opinion?
--
Andy Shevchenko
Intel Finland
In one case indeed it does, in another - no, though it seems it prints
same data (by meaning) in both cases. I would like driver maintainer
to say a word what they think about it.
On Wed, Jul 9, 2014 at 9:26 PM, Joe Perches wrote:
> On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wr
Instead of custom approach let's use recently added seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko
---
drivers/media/pci/saa7164/saa7164-core.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko
---
drivers/parisc/ccio-dma.c | 14 +++---
drivers/parisc/sba_iommu.c | 11 +++
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/parisc
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko
---
drivers/crypto/qat/qat_common/adf_transport_debug.c | 16 ++--
1
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko
---
drivers/s390/crypto/zcrypt_api.c | 10 +-
1 file changed, 1 inse
This introduces a new helper and switches current users to use it.
parisc and s390 weren't tested anyhow, the other are compile tested.
Andy Shevchenko (5):
seq_file: provide an analogue of print_hex_dump()
saa7164: convert to seq_hex_dump()
crypto: qat - use seq_hex_dump() to dump bu
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko
---
fs/seq_file.c| 35 +++
include/linux/seq_file.h | 4
2
It seems commit d764593a "crypto: aesni - AVX and AVX2 version of AESNI-GCM
encode and decode" breaks a build on x86_32 since it's designed only for
x86_64. This patch makes a compilation unit conditional to CONFIG_64BIT and
functions usage to CONFIG_X86_64.
Signed-off-by:
53 matches
Mail list logo
