[PATCH v3 2/2] staging: iio: isl29028: move out of staging

Move ISL29028 ALS / Proximity Sensor out of staging and into mainline. Signed-off-by: Brian Masney --- drivers/iio/light/Kconfig| 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/isl29028.c | 723

[PATCH v3 1/2] staging: iio: isl29028: correct proximity sleep times

The sysfs attribute in_proximity_sampling_frequency_available currently shows the values 1 3 5 10 13 20 83 100. These values are supposed to correspond to the sleep values 800 400 200 100 75 50 12.5 0 (all in ms). When passing in a sampling frequency of 3, it actually uses a sleep time of 200ms

[PATCH v3 0/2] staging: iio: isl29028: move out of staging

Minor cleanup to the proximity sampling to move this driver out of staging. Datasheet: http://www.intersil.com/content/dam/Intersil/documents/isl2/isl29028.pdf Changes since v2: - Reject any value that is not in the in_proximity_sampling_frequency_available sysfs attribute. - Changed the

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

On 04/20/2017 11:37 AM, Haiyang Zhang wrote: -Original Message- From: Bjorn Helgaas [mailto:bhelg...@google.com] Sent: Thursday, April 20, 2017 2:33 PM To: Haiyang Zhang Cc: linux-...@vger.kernel.org; KY Srinivasan ; Stephen Hemminger

Re: [PATCH 1/1] staging: comedi: addi_apci_3xxx: check return value

On 23/04/17 10:52, Pan Bian wrote: From: Pan Bian Function pci_ioremap_bar() will return a NULL pointer if there is no enough memory. However, in function apci3xxx_auto_attach(), the return value of function pci_ioremap_bar() is not validated. This may result in NULL

Re: [Bug] VCHIQ functional test broken

> Russell King - ARM Linux hat am 24. April 2017 um > 20:59 geschrieben: > > > On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote: > > > What I can't see is how changing flush_dcache_page() has possibly broken > > > this: it seems to imply that you're getting

Re: [Bug] VCHIQ functional test broken

On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote: > > What I can't see is how changing flush_dcache_page() has possibly broken > > this: it seems to imply that you're getting flush_dcache_page() somehow > > called inbetween mapping it for DMA, using it for DMA and CPU accesses > >

Re: [Bug] VCHIQ functional test broken

> Russell King - ARM Linux hat am 24. April 2017 um > 18:40 geschrieben: > > > On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote: > > Am 20.04.2017 um 21:58 schrieb Rabin Vincent: > > > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote: > > >> I'm

Re: [Bug] VCHIQ functional test broken

On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote: > Am 20.04.2017 um 21:58 schrieb Rabin Vincent: > > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote: > >> I'm confused by what you're saying here. The driver has already been > >> converted to not use dmac_map_area (commit

Re: [Bug] VCHIQ functional test broken

Am 20.04.2017 um 21:58 schrieb Rabin Vincent: > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote: >> I'm confused by what you're saying here. The driver has already been >> converted to not use dmac_map_area (commit >> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg

[PATCH] staging: most: aim-sound style fixess

Replace hardcoded function name with __func__ Signed-off-by: Dhananjay Balan --- drivers/staging/most/aim-sound/sound.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/most/aim-sound/sound.c b/drivers/staging/most/aim-sound/sound.c index

[PATCH] staging: olpc_dcon: style fixes

removes hardcoded function name and uses __func__ to print info. Signed-off-by: Dhananjay Balan --- drivers/staging/olpc_dcon/olpc_dcon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c

Re: [PATCH v1 1/8] lib/uuid: Introduce uuid_{be|le}_cmp_p{p}() helpers

> New helpers take pointers to uuid_{be|le} as parameters. > > When using them on a raw data we don't need to do an ugly dereference and, > in some cases, a type casting. > > Cc: Andrew Morton > Cc: Arnd Bergmann > Cc: Liam Girdwood

Re: [PATCH] staging: ks7010: Change capability field to __le16

On Thu, Apr 20, 2017 at 09:02:26PM +0200, Johan Svensson wrote: > > On 2017-04-18 20:38, Greg KH wrote: > > On Tue, Apr 18, 2017 at 08:24:01PM +0200, Johan Svensson wrote: > >> Change capability field to __le16 in struct ap_info_t, > >> struct link_ap_info_t, and struct local_ap_t. > >> This

Re: [PATCH v1 1/8] lib/uuid: Introduce uuid_{be|le}_cmp_p{p}() helpers

On Sun, 2017-04-23 at 20:20 +, Winkler, Tomas wrote: > On Sun, 2017-04-23 at 15:42 +0300, Andy Shevchenko wrote: > > On Sun, Apr 23, 2017 at 1:29 PM, Winkler, Tomas > . > > com> wrote: > > > > New helpers take pointers to uuid_{be|le} as parameters. > > > > > > > > When

Re: [PATCH v1 2/8] ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}()

On Mon, 2017-04-24 at 10:21 +0530, Vinod Koul wrote: > On Fri, Apr 21, 2017 at 05:46:39PM +0300, Andy Shevchenko wrote: > > Recently introduced helpers take pointers to uuid_{be|le} instead of > > reference. > > Are they in linus's tree, if not it introduces dependency, so we might > want > to

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 09:07:45 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > I guess we could change the function to indicate that a key is valid > for decryption but not encryption > and have the implementation limiting based on that if there is an > interest in SP800-131A compliance. I

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 09:04:13 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > Thanks you for the clarification. As I think is obvious by now I am > not a FIPS expert by any stretch. > > Isn't the requirements on DRBG or KDF invocations pertain to key > generation only? > What happens if you

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

On Mon, Apr 24, 2017 at 9:21 AM, Stephan Müller wrote: > Am Montag, 24. April 2017, 08:16:50 CEST schrieb Stephan Müller: > > Hi Gilad, > >> > >> > int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, >> > >> > unsigned int keylen) >> > >> >

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

On Mon, Apr 24, 2017 at 9:16 AM, Stephan Müller wrote: > Am Montag, 24. April 2017, 08:06:09 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, >> >> Well, it turns out there is and we do :-) >> >> This is from crypto/des_generic.c: >> >> /* >> * RFC2451: >> * >> * For

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 08:16:50 CEST schrieb Stephan Müller: Hi Gilad, > > > > int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, > > > > unsigned int keylen) > > > > However, this does not check that k1 == k3. In this case DES3 > > becomes 2DES (2-keys

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 08:06:09 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > Well, it turns out there is and we do :-) > > This is from crypto/des_generic.c: > > /* > * RFC2451: > * > * For DES-EDE3, there is no known need to reject weak or > * complementation keys. Any weakness

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

On Sun, Apr 23, 2017 at 12:48 PM, Gilad Ben-Yossef wrote: > Hi, > > Thank you for the review. > > On Thu, Apr 20, 2017 at 4:39 PM, Stephan Müller wrote: > >>> +/* The function verifies that tdes keys are not weak.*/ >>> +static int