Re: [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers
On Wed, Mar 21, 2018 at 6:37 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
>
> This is v13 of my cleanup series to push a number of instances of people
> defining their own io{read|write}64 functions into common headers seing
> they don't exist in non-64bit systems. This series adds inline functions to
> the
> io-64-nonatomic headers and then cleans up the drivers that defined their
> own copies.
>
> This cleanup was originally requested by Greg after he reviewed my
> Switchtec NTB code. And I hope someone can pick it up or at least give
> feedback on it soon as it'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 <andy.shevche...@gmail.com>
> Thanks,
>
> Logan
>
> --
>
> Changes since v12:
> - Rebased onto v4.16-rc6
> - Split patch 0001 into two and reworked the commit log as requested
> by Luc Van Oostenryck
>
> Changes since v11:
> - Rebased onto v4.16-rc5
> - Added a patch (0001) to fix some old and new sparse warnings
> that the kbuild robot warned about this cycle. The latest version
> of sparse was required to reproduce these.
> - Added a patch (0002) to add io{read|write}64 to parisc which the kbuild
> robot also found errors for this cycle
>
> Changes since v10:
> - Rebased onto v4.16-rc4, this droped the drm/tilcdc patch which was
> picked up by that tree and is already in 4.16.
>
> Changes since v9:
> - Rebased onto v4.15-rc6
> - Fixed a couple of issues in the new version of the CAAM patch as
> pointed out by Horia
>
> Changes since v8:
> - Rebased onto v4.15-rc2, as a result rewrote patch 7 seeing someone did
> some similar cleanup in that area.
> - Added a patch to clean up the Switchtec NTB driver which landed in
> v4.15-rc1
>
> Changes since v7:
> - Fix minor nits from Andy Shevchenko
> - Rebased onto v4.14-rc1
>
> Changes since v6:
> ** none **
>
> Changes since v5:
> - Added a fix to the tilcdc driver to ensure it doesn't use the
> non-atomic operation. (This includes adding
> io{read|write}64[be]_is_nonatomic
> defines).
>
> Changes since v4:
> - Add functions so the powerpc implementation of iomap.c compiles. (As
> noticed by Horia)
>
> Changes since v3:
>
> - I noticed powerpc didn't use the appropriate functions seeing
> readq/writeq were not defined when iomap.h was included. Thus I've
> included a patch to adjust this
> - Fixed some mistakes with a couple of the defines in io-64-nonatomic*
> headers
> - Fixed a typo noticed by Horia.
>
> (earlier versions were drastically different)
>
> --
>
> Logan Gunthorpe (10):
> iomap: Use correct endian conversion function in mmio_writeXXbe
> iomap: Fix sparse endian check warnings
> parisc: iomap: introduce io{read|write}64
> powerpc: io.h: move iomap.h include so that it can use readq/writeq
> defs
> powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}
> iomap: introduce io{read|write}64_{lo_hi|hi_lo}
> io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
> ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
> crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
> ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common
> header
>
> arch/parisc/include/asm/io.h | 9 +++
> arch/parisc/lib/iomap.c| 64 +++
> arch/powerpc/include/asm/io.h | 6 +-
> arch/powerpc/kernel/iomap.c| 40 ++
> drivers/crypto/caam/regs.h | 30 +--
> drivers/ntb/hw/intel/ntb_hw_intel.c| 30 +--
> drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 36 +
> include/asm-generic/iomap.h| 26 --
> include/linux/io-64-nonatomic-hi-lo.h | 64 +++
> include/linux/io-64-nonatomic-lo-hi.h | 64 +++
> lib/iomap.c| 140
> -
> 11 files changed, 409 insertions(+), 100 deletions(-)
>
> --
> 2.11.0
--
With Best Regards,
Andy Shevchenko
[PATCH v1] crypto: Deduplicate le32_to_cpu_array() and cpu_to_le32_array()
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 <andriy.shevche...@linux.intel.com>
---
crypto/md4.c | 17 -
crypto/md5.c | 17 -
include/linux/byteorder/generic.h | 17 +
3 files changed, 17 insertions(+), 34 deletions(-)
diff --git a/crypto/md4.c b/crypto/md4.c
index 3515af425cc9..810fefb0a007 100644
--- a/crypto/md4.c
+++ b/crypto/md4.c
@@ -64,23 +64,6 @@ static inline u32 H(u32 x, u32 y, u32 z)
#define ROUND2(a,b,c,d,k,s) (a = lshift(a + G(b,c,d) + k + (u32)0x5A827999,s))
#define ROUND3(a,b,c,d,k,s) (a = lshift(a + H(b,c,d) + k + (u32)0x6ED9EBA1,s))
-/* XXX: this stuff can be optimized */
-static inline void le32_to_cpu_array(u32 *buf, unsigned int words)
-{
- while (words--) {
- __le32_to_cpus(buf);
- buf++;
- }
-}
-
-static inline void cpu_to_le32_array(u32 *buf, unsigned int words)
-{
- while (words--) {
- __cpu_to_le32s(buf);
- buf++;
- }
-}
-
static void md4_transform(u32 *hash, u32 const *in)
{
u32 a, b, c, d;
diff --git a/crypto/md5.c b/crypto/md5.c
index f7ae1a48225b..f776ef43d621 100644
--- a/crypto/md5.c
+++ b/crypto/md5.c
@@ -32,23 +32,6 @@ const u8 md5_zero_message_hash[MD5_DIGEST_SIZE] = {
};
EXPORT_SYMBOL_GPL(md5_zero_message_hash);
-/* XXX: this stuff can be optimized */
-static inline void le32_to_cpu_array(u32 *buf, unsigned int words)
-{
- while (words--) {
- __le32_to_cpus(buf);
- buf++;
- }
-}
-
-static inline void cpu_to_le32_array(u32 *buf, unsigned int words)
-{
- while (words--) {
- __cpu_to_le32s(buf);
- buf++;
- }
-}
-
#define F1(x, y, z)(z ^ (x & (y ^ z)))
#define F2(x, y, z)F1(z, x, y)
#define F3(x, y, z)(x ^ y ^ z)
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index 451aaa0786ae..4b13e0a3e15b 100644
--- a/include/linux/byteorder/generic.h
+++ b/include/linux/byteorder/generic.h
@@ -156,6 +156,23 @@ static inline void le64_add_cpu(__le64 *var, u64 val)
*var = cpu_to_le64(le64_to_cpu(*var) + val);
}
+/* XXX: this stuff can be optimized */
+static inline void le32_to_cpu_array(u32 *buf, unsigned int words)
+{
+ while (words--) {
+ __le32_to_cpus(buf);
+ buf++;
+ }
+}
+
+static inline void cpu_to_le32_array(u32 *buf, unsigned int words)
+{
+ while (words--) {
+ __cpu_to_le32s(buf);
+ buf++;
+ }
+}
+
static inline void be16_add_cpu(__be16 *var, u16 val)
{
*var = cpu_to_be16(be16_to_cpu(*var) + val);
--
2.16.2
Re: [PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header
On Tue, Mar 6, 2018 at 1:46 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> 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 <log...@deltatee.com> wrote:
>> > Clean up the ifdefs which conditionally defined the io{read|write}64
>> > functions in favour of the new common io-64-nonatomic-lo-hi header.
>>
>> > #include
>> > #include
>> > #include
>> > +#include
>>
>> A nit, can we preserve alphabetical ordering?
>
> Ugh, why, it doesn't matter at all :)
I'm fine with either way, but ordering is a good thing to have in long
term prospective.
Easy to find what headers are in there, easy to understand if you need
another one or not, easy to maintain the list w/o duplications.
I saw already few examples where long list of headers contained
duplications b/c it was in messy order.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header
On Mon, Mar 5, 2018 at 9:08 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
> Clean up the ifdefs which conditionally defined the io{read|write}64
> functions in favour of the new common io-64-nonatomic-lo-hi header.
> #include
> #include
> #include
> +#include
A nit, can we preserve alphabetical ordering?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH RFC 0/3] API for 128-bit IO access
On Wed, Jan 24, 2018 at 12:28 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Wed, Jan 24, 2018 at 10:05 AM, Yury Norov <yno...@caviumnetworks.com>
> wrote:
>> * For 128-bit read/write functions I take suffix 'o', which means read/write
>> the octet of bytes. Is this name OK?
>
> Can't think of anything 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
Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
On Tue, Aug 22, 2017 at 8:55 PM, Logan Gunthorpe <log...@deltatee.com> 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 signal (message / wire) >> handling when pio_*() accessors used vs. mmio_*() ones? > Sort of. There is a difference between the two in x86. Yes, the difference is in signaling. The question is if it's still in use. Looks like yes... > But really if it's > not a valid recommendation someone should just go through and deprecate one > of them or document better when one should be used over the other. In any > case it's still really ugly to mix the two types in the same driver. Mixing is ugly, totally agree. -- With Best Regards, Andy Shevchenko
Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
On Tue, Aug 22, 2017 at 8:56 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 22/08/17 11:41 AM, Andy Shevchenko wrote: >>> >>> @@ -59,6 +59,7 @@ >>> #include >>> #include >>> #include >>> +#include >> >> >> I would rather try to squeeze to most alpabetiacelly ordered part of this >> block. >> Otherwise it's a pretty nice clean up! >> > > I don't understand. The includes were not alphabetically in any order > originally and I'd rather not reorder them in my patch. In excerpt I see if you put your include before random.h you will get 3 headers in order. There may be even better sequence, I didn't check. -- With Best Regards, Andy Shevchenko
Re: [PATCH v7 0/7] make io{read|write}64 globally usable
On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe <log...@deltatee.com> 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 <andy.shevche...@gmail.com>
> Changes since v6:
> ** none **
>
> Changes since v5:
> - Added a fix to the tilcdc driver to ensure it doesn't use the
> non-atomic operation. (This includes adding
> io{read|write}64[be]_is_nonatomic
> defines).
>
> Changes since v4:
> - Add functions so the powerpc implementation of iomap.c compiles. (As
> noticed by Horia)
>
> Changes since v3:
>
> - I noticed powerpc didn't use the appropriate functions seeing
> readq/writeq were not defined when iomap.h was included. Thus I've
> included a patch to adjust this
> - Fixed some mistakes with a couple of the defines in io-64-nonatomic*
> headers
> - Fixed a typo noticed by Horia.
>
> (earlier versions were drastically different)
>
> Horia Geantă (1):
> crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
>
> Logan Gunthorpe (6):
> drm/tilcdc: ensure nonatomic iowrite64 is not used
> powerpc: io.h: move iomap.h include so that it can use readq/writeq
> defs
> powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}
> iomap: introduce io{read|write}64_{lo_hi|hi_lo}
> io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
> ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
>
> arch/powerpc/include/asm/io.h | 6 +-
> arch/powerpc/kernel/iomap.c | 40 +++
> drivers/crypto/caam/regs.h| 35 ++---
> drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +-
> drivers/ntb/hw/intel/ntb_hw_intel.c | 30 +---
> include/asm-generic/iomap.h | 26 +--
> include/linux/io-64-nonatomic-hi-lo.h | 64 +
> include/linux/io-64-nonatomic-lo-hi.h | 64 +
> lib/iomap.c | 132
> ++
> 9 files changed, 331 insertions(+), 68 deletions(-)
>
> --
> 2.11.0
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > Now that ioread64 and iowrite64 are available in io-64-nonatomic, > we can remove the hack at the top of ntb_hw_intel.c and replace it > with an include. > @@ -59,6 +59,7 @@ > #include > #include > #include > +#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
Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
> This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
> they are not already defined by the architecture. (As they are provided
> by the generic iomap library).
>
> The patch also points io{read|write}64[be] to the variant specified by the
> header name.
>
> This is because new drivers are encouraged to use ioreadXX, et al instead
> of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly.
>
> [1] ldd3: section 9.4.2
ldd -> LDD
It's a pretty outdated book, though quite many chapters are actual for
these days.
Recomendation is kinda arguable. I doubt modern architectures make
difference between IO operations and MMIO.
Does, for example, PCI requires some special signal (message / wire)
handling when pio_*() accessors used vs. mmio_*() ones?
> cc: Christoph Hellwig <h...@lst.de>
> cc: Arnd Bergmann <a...@arndb.de>
> cc: Alan Cox <gno...@lxorguk.ukuu.org.uk>
> cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
cc -> Cc ?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
On Mon, Jul 31, 2017 at 9:04 PM, Logan Gunthorpe <log...@deltatee.com> 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 satisfy > such a use. Okay, please, Cc me for next version, I think I need fresh view on it. Thanks! -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
On Mon, Jul 31, 2017 at 9:00 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > On 31/07/17 11:58 AM, Andy Shevchenko wrote: >> On Mon, Jul 31, 2017 at 7:31 PM, Logan Gunthorpe <log...@deltatee.com> 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 >>> driver wants a specific non-atomic access they should just code two 32 >>> bit accesses. > >> You mean to call them directly as lo_hi_XXX() or hi_lo_XXX() ? >> Yes it would work. > > I suppose you could do that too but I really meant just using two io32 > calls. That's the most explicit way to indicate you want a non-atomic > access. Per commit 3a044178cccf they are exactly created for this kind of cases. -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
On Mon, Jul 31, 2017 at 7:31 PM, Logan Gunthorpe <log...@deltatee.com> 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 > driver wants a specific non-atomic access they should just code two 32 > bit accesses. You mean to call them directly as lo_hi_XXX() or hi_lo_XXX() ? Yes it would work. >> In case of readq() / writeq() it's defined by the order of inclusion: >> >> 1) >> include <...non-atomic...> >> include >> >> Always non-atomic will be used. > > I'm afraid you're wrong about this. The io-64-nonatomic-xx header > includes linux/io.h. Thus the order of the includes doesn't matter and > it will always auto switch. In any case, making an interface do > different things depending on the order of include files is *completely* > insane. Yes, you are right. I was thinking about something unrelated. -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
On Mon, Jul 31, 2017 at 6:55 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
> On 30/07/17 10:03 AM, Andy Shevchenko wrote:
>> On Thu, Jul 27, 2017 at 2:19 AM, Logan Gunthorpe <log...@deltatee.com> wrote:
>>> In order to provide non-atomic functions for io{read|write}64 that will
>>> use readq and writeq when appropriate. We define a number of variants
>>> of these functions in the generic iomap that will do non-atomic
>>> operations on pio but atomic operations on mmio.
>>>
>>> These functions are only defined if readq and writeq are defined. If
>>> they are not, then the wrappers that always use non-atomic operations
>>> from include/linux/io-64-nonatomic*.h will be used.
>>
>> Don't you see here a slight problem?
>>
>> In some cases we want to substitute atomic in favour of non-atomic
>> when both are defined.
>> So, please don't do this "smartly".
>
> I'm not sure what you mean here. The driver should use ioread64 and
> include an io-64-nonatomic header. Then there are three cases:
>
> 1) The arch has no atomic 64 bit io operations defined. In this case it
> uses the non-atomic inline function in the io-64-nonatomic header.
Okay
> 2) The arch uses CONFIG_GENERIC_IOMAP and has readq defined, but not
> ioread64 defined (likely because pio can't do atomic 64 bit operations
> but mmio can). In this case we need to use the ioread64_xx functions
> defined in iomap.c which do atomic mmio and non-atomic pio.
Not okay.
Some drivers (hardware) would like to have non-atomic MMIO accesses
when readq() defined
> 3) The arch has ioread64 defined so the atomic operation is used.
Not okay. Same reason as above.
In case of readq() / writeq() it's defined by the order of inclusion:
1)
include <...non-atomic...>
include
Always non-atomic will be used.
2)
include
include <...non-atomic...>
Auto switch like you described.
I don't like above solution, since it's fragile, but few drivers depend on that.
If you wish to do it always like 2) perhaps we need to split accessors
to ones for fixed bus width and ones for atomic/non-atomic cases.
OTOH, it would be done by introducing
memcpyXX_fromio()
memcpyXX_toio()
memsetXX_io()
Where XX = 64, 32, 16, 8.
Note, that ioreadXX_rep() is not the same as above.
P.S. I have done a table of comparison between IO accessors in Linux
kernel and it looks hell out of being consistent.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
On Thu, Jul 27, 2017 at 2:19 AM, Logan Gunthorpe <log...@deltatee.com> wrote:
> In order to provide non-atomic functions for io{read|write}64 that will
> use readq and writeq when appropriate. We define a number of variants
> of these functions in the generic iomap that will do non-atomic
> operations on pio but atomic operations on mmio.
>
> These functions are only defined if readq and writeq are defined. If
> they are not, then the wrappers that always use non-atomic operations
> from include/linux/io-64-nonatomic*.h will be used.
Don't you see here a slight problem?
In some 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 0xffffLL;
> +}
U missed u.
--
With Best Regards,
Andy Shevchenko
Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device
On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote: > Hi Mark, > > On 03/02/2017 11:39 AM, Mark Rutland wrote: > > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > > > > > > +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \ > > > ccp-ops.o \ > > > ccp-dev-v3.o \ > > > ccp-dev-v5.o \ > > > - ccp-platform.o \ > > > ccp-dmaengine.o > > > > It looks like ccp-platform.c has morphed into sp-platform.c (judging > > by > > the compatible string and general 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 <andriy.shevche...@linux.intel.com> Intel Finland Oy
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Fri, Nov 20, 2015 at 2:30 PM, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: > On 11/20/2015 02:24 PM, Andy Shevchenko wrote: >> On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann <a...@arndb.de> wrote: >>> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: >> >>> Another idea would be to remove the filter function from struct dma_chan_map >>> and pass the map through platform data >> >> Why not unified device properties? > > Is this some Windows/ACPI feature? Nope. Check drivers/base/property.c > Quick search gives mostly MSDN and > Windows10 related links. > > We only need dma_chan_map for platforms which has not been converted to DT and > still using legacy boot. Or platforms which can still boot in legacy mode. In > DT/ACPI mode we do not need this map at all. -- 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
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > Another idea would be to remove the filter function from struct dma_chan_map > and pass the map through platform 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
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: > Hi Vinod, > > bringing this old thread back to life as I just started to work on this. What I remember we need to convert drivers to use new API meanwhile it is good to keep old one to avoid patch storm which does nothing useful (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 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
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann <a...@arndb.de> 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 way around. >> > > Ok, I see. In that case I guess it also shouldn't call > dmaengine_slave_config(), right? I don't think that's valid > on a MEMCPY channel. Hmm… That's right, though I suspect still one thing why it's done this way. Let's ask Vinod and Liam about that. -- 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
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Wed, Nov 18, 2015 at 5:07 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >> >> 2. non slave channel requests, where only the functionality matters, like >> >> memcpy, interleaved, memset, etc. >> >> We could have a simple: >> >> dma_request_channel(mask); >> >> >> >> But looking at the drivers using dmaengine legacy dma_request_channel() >> >> API: >> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE: >> >> drivers/misc/carma/carma-fpga.c >> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG >> >> drivers/misc/carma/carma-fpga-program.c >> >> DMA_MEMCPY|DMA_SLAVE|DMA_SG >> >> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE >> >> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY >> >> >> >> as examples. >> >> Not sure how valid are 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
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On Fri, May 29, 2015 at 10:14 PM, Jim Davis jim.ep...@gmail.com wrote: Building with the attached random configuration file, Hit the very same error against next-20150605. The issue with that file we have no compiler optimization enabled. So, guys, how you would recommend to fix it? By the way, I'm building the x86_64_defconfig with following changes diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 315b861..363824f 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -172,9 +172,11 @@ CONFIG_TIGON3=y CONFIG_NET_TULIP=y CONFIG_E100=y CONFIG_E1000=y +CONFIG_E1000E=y CONFIG_SKY2=y CONFIG_FORCEDETH=y CONFIG_8139TOO=y +CONFIG_R8169=y CONFIG_FDDI=y CONFIG_INPUT_POLLDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set @@ -198,7 +200,7 @@ CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_INTEL is not set # CONFIG_HW_RANDOM_AMD is not set CONFIG_NVRAM=y -CONFIG_HPET=y +# CONFIG_HPET is not set # CONFIG_HPET_MMAP is not set CONFIG_I2C_I801=y CONFIG_WATCHDOG=y @@ -206,8 +208,8 @@ CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_DRM=y -CONFIG_DRM_I915=y -CONFIG_DRM_I915_KMS=y +# CONFIG_DRM_I915 is not set +CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_EFI=y @@ -224,8 +226,8 @@ CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=y -CONFIG_SND_HDA_INTEL=y -CONFIG_SND_HDA_HWDEP=y +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDA_HWDEP is not set CONFIG_HIDRAW=y CONFIG_HID_GYRATION=y CONFIG_LOGITECH_FF=y @@ -307,3 +309,56 @@ CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DISABLE=y # CONFIG_CRYPTO_ANSI_CPRNG is not set +CONFIG_FUNCTION_TRACER=y +CONFIG_I2C_DESIGNWARE_PCI=y +CONFIG_I2C_DESIGNWARE_PLATFORM=m +CONFIG_GPIOLIB=y +CONFIG_GPIO_INTEL_MID=y +CONFIG_INTEL_MID_WATCHDOG=y +CONFIG_NOP_USB_XCEIV=y +CONFIG_USB_CHIPIDEA=y +CONFIG_USB_CHIPIDEA_UDC=y +CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_X86_EXTENDED_PLATFORM=y +CONFIG_X86_INTEL_MID=y +CONFIG_EFI_STUB=y +CONFIG_EFI_MIXED=y +CONFIG_EARLY_PRINTK_EFI=y +CONFIG_FB=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_DYNAMIC_DEBUG=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_SERIAL=y +CONFIG_USB_SERIAL_PL2303=y +CONFIG_USB_USBNET=y +CONFIG_USB_NET_AX88179_178A=y +CONFIG_USB_NET_MCS7830=y +CONFIG_USB_NET_AX8817X=y +CONFIG_X86_INTEL_LPSS=y +CONFIG_PM_RUNTIME=y +CONFIG_DW_DMAC_CORE=m +CONFIG_DW_DMAC=m +CONFIG_DW_DMAC_PCI=m +CONFIG_DMATEST=m +CONFIG_SERIAL_8250_DMA=y +CONFIG_SERIAL_8250_PCI=y +CONFIG_SERIAL_8250_DW=m +CONFIG_MMC=m +CONFIG_MMC_SDHCI=m +CONFIG_MMC_SDHCI_ACPI=m +CONFIG_ACPI_DEBUG=y +CONFIG_ACPI_PROCFS_POWER=y +CONFIG_DMA_API_DEBUG=y +CONFIG_DEBUG_LOCKDEP=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_BAYTRAIL=y +CONFIG_PWM=y +CONFIG_PWM_LPSS=m +CONFIG_PWM_LPSS_PCI=m +CONFIG_PWM_LPSS_PLATFORM=m +CONFIG_SPI=y +CONFIG_SPI_PXA2XX_PCI=m +CONFIG_SPI_PXA2XX=m In file included from ./arch/x86/include/asm/spinlock.h:46:0, from include/linux/spinlock.h:87, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from crypto/jitterentropy.c:52: In function ‘native_queued_spin_unlock’, inlined from ‘queued_spin_unlock’ at ./arch/x86/include/asm/qspinlock.h:38:2 , inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2, inlined from ‘__raw_spin_unlock’ at include/linux/spinlock_api_smp.h:153:2, inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2, inlined from ‘jent_kcapi_cleanup’ at crypto/jitterentropy.c:844:2: ./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. In function ‘native_queued_spin_unlock’, inlined from ‘queued_spin_unlock’ at ./arch/x86/include/asm/qspinlock.h:38:2 , inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2, inlined from ‘__raw_spin_unlock’ at include/linux/spinlock_api_smp.h:153:2, inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2, inlined from ‘jent_kcapi_random’ at crypto/jitterentropy.c:856:2: ./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 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
Re: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Thu, 2014-07-10 at 09:58 +0200, Marek Vasut wrote:
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's calling seq_printf() instead
of printk(). Can you not instead generalize print_hex_dump() and based
on it's invocation, make it call either seq_printf() or printk() ?
How do you propose doing that given any seq_foo call
requires a struct seq_file * and print_hex_dump needs
a KERN_LEVEL.
I can imagine a rather nasty way, I can't say I would like it myself tho. The
general idea would be to pull out the entire switch {} statement into a
separate
functions , one for printk() and one for seq_printf() cases. Then, have a
generic do_hex_dump() call which would take as an argument a pointer to
either
of those functions and a void * to either the seq_file or level . Finally,
there
would have to be a wrapper to call the do_hex_dump() with the correct
function
pointer and it's associated arg.
Nasty? Yes ... Ineffective? Most likely.
It looks not good idea, yeah.
Is there an actual value to it?
Reducing the code duplication, but I wonder if there is a smarter solution
than
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_foo calls do.
But I still have doubts about it. Any opinion?
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
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
Re: [PATCH v1 3/5] crypto: qat - use seq_hex_dump() to dump buffers
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 andriy.shevche...@linux.intel.com It's ok, I can still read it. It seems I miscalculated the tetrads. It should be 8 per line, correct? In that case we could easily use 32 bytes per line and thus remove that paragraph from commit message. Acked-by: Tadeusz Struk tadeusz.st...@intel.com Thanks! -- Andy Shevchenko andriy.shevche...@intel.com Intel Finland Oy -- 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
[PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
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 andriy.shevche...@linux.intel.com
---
fs/seq_file.c| 35 +++
include/linux/seq_file.h | 4
2 files changed, 39 insertions(+)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 3857b72..fec4a6b 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/cred.h
#include linux/mm.h
+#include linux/printk.h
#include asm/uaccess.h
#include asm/page.h
@@ -794,6 +795,40 @@ void seq_pad(struct seq_file *m, char c)
}
EXPORT_SYMBOL(seq_pad);
+/* Analogue of print_hex_dump() */
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int prefix_type,
+ int rowsize, int groupsize, const void *buf, size_t len,
+ bool ascii)
+{
+ const u8 *ptr = buf;
+ int i, linelen, remaining = len;
+ unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+
+ if (rowsize != 16 rowsize != 32)
+ rowsize = 16;
+
+ for (i = 0; i len; i += rowsize) {
+ linelen = min(remaining, rowsize);
+ remaining -= rowsize;
+
+ hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
+ linebuf, sizeof(linebuf), ascii);
+
+ switch (prefix_type) {
+ case DUMP_PREFIX_ADDRESS:
+ seq_printf(m, %s%p: %s\n, prefix_str, ptr + i,
linebuf);
+ break;
+ case DUMP_PREFIX_OFFSET:
+ seq_printf(m, %s%.8x: %s\n, prefix_str, i, linebuf);
+ break;
+ default:
+ seq_printf(m, %s%s\n, prefix_str, linebuf);
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(seq_hex_dump);
+
struct list_head *seq_list_start(struct list_head *head, loff_t pos)
{
struct list_head *lh;
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index 52e0097..6a8be4c 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -107,6 +107,10 @@ int seq_write(struct seq_file *seq, const void *data,
size_t len);
__printf(2, 3) int seq_printf(struct seq_file *, const char *, ...);
__printf(2, 0) int seq_vprintf(struct seq_file *, const char *, va_list args);
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int prefix_type,
+ int rowsize, int groupsize, const void *buf, size_t len,
+ bool ascii);
+
int seq_path(struct seq_file *, const struct path *, const char *);
int seq_dentry(struct seq_file *, struct dentry *, const char *);
int seq_path_root(struct seq_file *m, const struct path *path,
--
2.0.1
--
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
[PATCH v1 0/5] fs/seq_file: introduce seq_hex_dump() helper
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 buffers parisc: use seq_hex_dump() to dump buffers [S390] zcrypt: use seq_hex_dump() to dump buffers .../crypto/qat/qat_common/adf_transport_debug.c| 16 ++ drivers/media/pci/saa7164/saa7164-core.c | 31 +++ drivers/parisc/ccio-dma.c | 14 ++--- drivers/parisc/sba_iommu.c | 11 ++- drivers/s390/crypto/zcrypt_api.c | 10 +-- fs/seq_file.c | 35 ++ include/linux/seq_file.h | 4 +++ 7 files changed, 52 insertions(+), 69 deletions(-) -- 2.0.1 -- 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
[PATCH v1 5/5] [S390] zcrypt: use seq_hex_dump() to dump buffers
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 andriy.shevche...@linux.intel.com
---
drivers/s390/crypto/zcrypt_api.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index 0e18c5d..d1f9983 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -1203,16 +1203,8 @@ static void sprinthx(unsigned char *title, struct
seq_file *m,
static void sprinthx4(unsigned char *title, struct seq_file *m,
unsigned int *array, unsigned int len)
{
- int r;
-
seq_printf(m, \n%s\n, title);
- for (r = 0; r len; r++) {
- if ((r % 8) == 0)
- seq_printf(m, );
- seq_printf(m, %08X , array[r]);
- if ((r % 8) == 7)
- seq_putc(m, '\n');
- }
+ seq_hex_dump(m, , DUMP_PREFIX_NONE, 32, 4, array, len, false);
seq_putc(m, '\n');
}
--
2.0.1
--
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
[PATCH v1 3/5] crypto: qat - use seq_hex_dump() to dump buffers
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 andriy.shevche...@linux.intel.com
---
drivers/crypto/qat/qat_common/adf_transport_debug.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_transport_debug.c
b/drivers/crypto/qat/qat_common/adf_transport_debug.c
index 6b69745..8b103cf 100644
--- a/drivers/crypto/qat/qat_common/adf_transport_debug.c
+++ b/drivers/crypto/qat/qat_common/adf_transport_debug.c
@@ -86,9 +86,7 @@ static int adf_ring_show(struct seq_file *sfile, void *v)
{
struct adf_etr_ring_data *ring = sfile-private;
struct adf_etr_bank_data *bank = ring-bank;
- uint32_t *msg = v;
void __iomem *csr = ring-bank-csr_addr;
- int i, x;
if (v == SEQ_START_TOKEN) {
int head, tail, empty;
@@ -111,18 +109,8 @@ static int adf_ring_show(struct seq_file *sfile, void *v)
seq_puts(sfile, --- Ring data \n);
return 0;
}
- seq_printf(sfile, %p:, msg);
- x = 0;
- i = 0;
- for (; i (ADF_MSG_SIZE_TO_BYTES(ring-msg_size) 2); i++) {
- seq_printf(sfile, %08X, *(msg + i));
- if ((ADF_MSG_SIZE_TO_BYTES(ring-msg_size) 2) != i + 1
- (++x == 8)) {
- seq_printf(sfile, \n%p:, msg + i + 1);
- x = 0;
- }
- }
- seq_puts(sfile, \n);
+ seq_hex_dump(sfile, , DUMP_PREFIX_ADDRESS, 16, 4,
+v, ADF_MSG_SIZE_TO_BYTES(ring-msg_size), false);
return 0;
}
--
2.0.1
--
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
[PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/parisc/ccio-dma.c | 14 +++---
drivers/parisc/sba_iommu.c | 11 +++
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 8b490d7..9d353d2 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -1101,20 +1101,12 @@ static const struct file_operations ccio_proc_info_fops
= {
static int ccio_proc_bitmap_info(struct seq_file *m, void *p)
{
- int len = 0;
struct ioc *ioc = ioc_list;
while (ioc != NULL) {
- u32 *res_ptr = (u32 *)ioc-res_map;
- int j;
-
- for (j = 0; j (ioc-res_size / sizeof(u32)); j++) {
- if ((j 7) == 0)
- len += seq_puts(m, \n );
- len += seq_printf(m, %08x, *res_ptr);
- res_ptr++;
- }
- len += seq_puts(m, \n\n);
+ seq_hex_dump(m,, DUMP_PREFIX_NONE, 32, 4, ioc-res_map,
+ioc-res_size, false);
+ seq_putc(m, '\n');
ioc = ioc-next;
break; /* XXX - remove me */
}
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index 1ff1b67..fbc4db9 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -1857,15 +1857,10 @@ sba_proc_bitmap_info(struct seq_file *m, void *p)
{
struct sba_device *sba_dev = sba_list;
struct ioc *ioc = sba_dev-ioc[0]; /* FIXME: Multi-IOC support! */
- unsigned int *res_ptr = (unsigned int *)ioc-res_map;
- int i, len = 0;
- for (i = 0; i (ioc-res_size/sizeof(unsigned int)); ++i, ++res_ptr) {
- if ((i 7) == 0)
- len += seq_printf(m, \n );
- len += seq_printf(m, %08x, *res_ptr);
- }
- len += seq_printf(m, \n);
+ seq_hex_dump(m,, DUMP_PREFIX_NONE, 32, 4, ioc-res_map,
+ioc-res_size, false);
+ seq_printf(m, \n);
return 0;
}
--
2.0.1
--
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
[PATCH v1 2/5] saa7164: convert to seq_hex_dump()
Instead of custom approach let's use recently added seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/pci/saa7164/saa7164-core.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index 1bf0697..6f81584 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -1065,7 +1065,6 @@ static int saa7164_proc_show(struct seq_file *m, void *v)
struct saa7164_dev *dev;
struct tmComResBusInfo *b;
struct list_head *list;
- int i, c;
if (saa7164_devcount == 0)
return 0;
@@ -1089,35 +1088,13 @@ static int saa7164_proc_show(struct seq_file *m, void
*v)
seq_printf(m, .m_pdwGetReadPos = 0x%x (0x%08x)\n,
b-m_dwGetWritePos, saa7164_readl(b-m_dwGetWritePos));
- c = 0;
seq_printf(m, \n Set Ring:\n);
- seq_printf(m, \n addr 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f\n);
- for (i = 0; i b-m_dwSizeSetRing; i++) {
- if (c == 0)
- seq_printf(m, %04x:, i);
+ seq_hex_dump(m, , DUMP_PREFIX_OFFSET, 16, 1,
+b-m_pdwSetRing, b-m_dwSizeSetRing, false);
- seq_printf(m, %02x, *(b-m_pdwSetRing + i));
-
- if (++c == 16) {
- seq_printf(m, \n);
- c = 0;
- }
- }
-
- c = 0;
seq_printf(m, \n Get Ring:\n);
- seq_printf(m, \n addr 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f\n);
- for (i = 0; i b-m_dwSizeGetRing; i++) {
- if (c == 0)
- seq_printf(m, %04x:, i);
-
- seq_printf(m, %02x, *(b-m_pdwGetRing + i));
-
- if (++c == 16) {
- seq_printf(m, \n);
- c = 0;
- }
- }
+ seq_hex_dump(m, , DUMP_PREFIX_OFFSET, 16, 1,
+b-m_pdwGetRing, b-m_dwSizeGetRing, false);
mutex_unlock(b-lock);
--
2.0.1
--
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
Re: [PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
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 j...@perches.com wrote:
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.
Doesn't this also change the output from
to
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
[PATCH v1] crypto: aesni - fix build on x86 (32bit)
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: Andy Shevchenko andriy.shevche...@linux.intel.com
---
arch/x86/crypto/Makefile | 3 ++-
arch/x86/crypto/aesni-intel_glue.c | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 84ee1e1..188b993 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -75,7 +75,8 @@ ifeq ($(avx2_supported),yes)
serpent-avx2-y := serpent-avx2-asm_64.o serpent_avx2_glue.o
endif
-aesni-intel-y := aesni-intel_asm.o aesni-intel_avx.o aesni-intel_glue.o fpu.o
+aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o
+aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx.o
ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o
sha1-ssse3-y := sha1_ssse3_asm.o sha1_ssse3_glue.o
crc32c-intel-y := crc32c-intel_glue.o
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 3ae311d..948ad0e 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1473,6 +1473,7 @@ static int __init aesni_init(void)
if (!x86_match_cpu(aesni_cpu_id))
return -ENODEV;
+#ifdef CONFIG_X86_64
#ifdef CONFIG_AS_AVX2
if (boot_cpu_has(X86_FEATURE_AVX2)) {
pr_info(AVX2 version of gcm_enc/dec engaged.\n);
@@ -1492,6 +1493,7 @@ static int __init aesni_init(void)
aesni_gcm_enc_tfm = aesni_gcm_enc;
aesni_gcm_dec_tfm = aesni_gcm_dec;
}
+#endif
err = crypto_fpu_init();
if (err)
--
1.8.5.2
--
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
