[PATCH] Bluetooth: Delete error messages for failed memory allocations in two functions
From: Markus Elfring
Date: Mon, 22 May 2017 08:42:28 +0200
Omit two extra messages for memory allocation failures in these functions.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
net/bluetooth/ecdh_helper.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
index 24d4e60f8c48..c7b1a9aee579 100644
--- a/net/bluetooth/ecdh_helper.c
+++ b/net/bluetooth/ecdh_helper.c
@@ -92,8 +92,6 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8
private_key[32],
- if (!buf) {
- pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
- buf_len);
+ if (!buf)
goto free_req;
- }
+
crypto_ecdh_encode_key(buf, buf_len, &p);
/* Set A private Key */
@@ -173,8 +171,5 @@ bool generate_ecdh_keys(u8 public_key[64], u8
private_key[32])
- if (!buf) {
- pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
- buf_len);
+ if (!buf)
goto free_req;
- }
do {
if (tries++ >= max_tries)
--
2.13.0
Re: [PATCH] kconfig: always use user input symbols
Hi Tycho,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170522]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tycho-Andersen/kconfig-always-use-user-input-symbols/20170522-143552
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/bitops.h:16:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/asm-generic/bug.h:15,
from arch/x86/include/asm/bug.h:81,
from include/linux/bug.h:4,
from include/linux/page-flags.h:9,
from kernel/bounds.c:9:
arch/x86/include/asm/arch_hweight.h: In function '__arch_hweight64':
>> arch/x86/include/asm/arch_hweight.h:54:42: error: expected ':' or ')' before
>> 'POPCNT64'
asm (ALTERNATIVE("call __sw_hweight64", POPCNT64, X86_FEATURE_POPCNT)
^
arch/x86/include/asm/alternative.h:132:28: note: in definition of macro
'ALTINSTR_REPLACEMENT'
b_replacement(num)":\n\t" newinstr "\n" e_replacement(num) ":\n\t"
^~~~
>> arch/x86/include/asm/arch_hweight.h:54:7: note: in expansion of macro
>> 'ALTERNATIVE'
asm (ALTERNATIVE("call __sw_hweight64", POPCNT64, X86_FEATURE_POPCNT)
^~~
make[2]: *** [kernel/bounds.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [sub-make] Error 2
vim +54 arch/x86/include/asm/arch_hweight.h
d61931d8 Borislav Petkov 2010-03-05 38 static inline unsigned int
__arch_hweight8(unsigned int w)
d61931d8 Borislav Petkov 2010-03-05 39 {
d61931d8 Borislav Petkov 2010-03-05 40 return __arch_hweight32(w &
0xff);
d61931d8 Borislav Petkov 2010-03-05 41 }
d61931d8 Borislav Petkov 2010-03-05 42
d14edb16 Denys Vlasenko 2015-08-04 43 #ifdef CONFIG_X86_32
d61931d8 Borislav Petkov 2010-03-05 44 static inline unsigned long
__arch_hweight64(__u64 w)
d61931d8 Borislav Petkov 2010-03-05 45 {
d61931d8 Borislav Petkov 2010-03-05 46 return
__arch_hweight32((u32)w) +
d61931d8 Borislav Petkov 2010-03-05 47
__arch_hweight32((u32)(w >> 32));
d14edb16 Denys Vlasenko 2015-08-04 48 }
d61931d8 Borislav Petkov 2010-03-05 49 #else
d14edb16 Denys Vlasenko 2015-08-04 50 static __always_inline unsigned long
__arch_hweight64(__u64 w)
d14edb16 Denys Vlasenko 2015-08-04 51 {
f5967101 Borislav Petkov 2016-05-30 52 unsigned long res;
d14edb16 Denys Vlasenko 2015-08-04 53
c59bd568 H. Peter Anvin 2010-05-17 @54 asm (ALTERNATIVE("call
__sw_hweight64", POPCNT64, X86_FEATURE_POPCNT)
d61931d8 Borislav Petkov 2010-03-05 55 : "="REG_OUT
(res)
d61931d8 Borislav Petkov 2010-03-05 56 : REG_IN (w));
d61931d8 Borislav Petkov 2010-03-05 57
d61931d8 Borislav Petkov 2010-03-05 58 return res;
d61931d8 Borislav Petkov 2010-03-05 59 }
d14edb16 Denys Vlasenko 2015-08-04 60 #endif /* CONFIG_X86_32 */
d61931d8 Borislav Petkov 2010-03-05 61
d61931d8 Borislav Petkov 2010-03-05 62 #endif
:: The code at line 54 was first introduced by commit
:: c59bd5688299cddb71183e156e7a3c1409b90df2 x86, hweight: Use a 32-bit
popcnt for __arch_hweight32()
:: TO: H. Peter Anvin
:: CC: H. Peter Anvin
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
RE: [PATCH] efi-pstore: Fix write/erase id tracking
Thanks Kees,
I confirm that with below patch on top of 4.12.0-rc2 pstore efi vars is now
working as expected again.
BR,
Marta
> -Original Message-
> From: Kees Cook [mailto:keesc...@chromium.org]
> Sent: Friday, May 19, 2017 9:27 PM
> To: Lofstedt, Marta
> Cc: Anton Vorontsov ; Colin Cross
> ; Luck, Tony ; Matt Fleming
> ; Ard Biesheuvel ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] efi-pstore: Fix write/erase id tracking
>
> Prior to the pstore interface refactoring, the "id" generated during a backend
> pstore_write() was only retained by the internal pstore inode tracking list.
> Additionally the "part" was ignored, so EFI would encode this in the id. This
> corrects the misunderstandings and correctly sets "id" during pstore_write(),
> and uses "part"
> directly during pstore_erase().
>
> Reported-by: Marta Lofstedt
> Fixes: 76cc9580e3fb ("pstore: Replace arguments for write() API")
> Fixes: a61072aae693 ("pstore: Replace arguments for erase() API")
> Signed-off-by: Kees Cook
> ---
> Since the pstore refactor broke this, I intend to push this via the pstore
> tree.
> ---
> drivers/firmware/efi/efi-pstore.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-
> pstore.c
> index 44148fd4c9f2..dda2e96328c0 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -53,6 +53,7 @@ static int efi_pstore_read_func(struct efivar_entry
> *entry,
> if (sscanf(name, "dump-type%u-%u-%d-%lu-%c",
> &record->type, &part, &cnt, &time,
> &data_type) == 5) {
> record->id = generic_id(time, part, cnt);
> + record->part = part;
> record->count = cnt;
> record->time.tv_sec = time;
> record->time.tv_nsec = 0;
> @@ -64,6 +65,7 @@ static int efi_pstore_read_func(struct efivar_entry
> *entry,
> } else if (sscanf(name, "dump-type%u-%u-%d-%lu",
> &record->type, &part, &cnt, &time) == 4) {
> record->id = generic_id(time, part, cnt);
> + record->part = part;
> record->count = cnt;
> record->time.tv_sec = time;
> record->time.tv_nsec = 0;
> @@ -77,6 +79,7 @@ static int efi_pstore_read_func(struct efivar_entry
> *entry,
>* multiple logs, remains.
>*/
> record->id = generic_id(time, part, 0);
> + record->part = part;
> record->count = 0;
> record->time.tv_sec = time;
> record->time.tv_nsec = 0;
> @@ -241,9 +244,15 @@ static int efi_pstore_write(struct pstore_record
> *record)
> efi_guid_t vendor = LINUX_EFI_CRASH_GUID;
> int i, ret = 0;
>
> + record->time.tv_sec = get_seconds();
> + record->time.tv_nsec = 0;
> +
> + record->id = generic_id(record->time.tv_sec, record->part,
> + record->count);
> +
> snprintf(name, sizeof(name), "dump-type%u-%u-%d-%lu-
> %c",
>record->type, record->part, record->count,
> - get_seconds(), record->compressed ? 'C' : 'D');
> + record->time.tv_sec, record->compressed ? 'C'
> : 'D');
>
> for (i = 0; i < DUMP_NAME_LEN; i++)
> efi_name[i] = name[i];
> @@ -255,7 +264,6 @@ static int efi_pstore_write(struct pstore_record
> *record)
> if (record->reason == KMSG_DUMP_OOPS)
> efivar_run_worker();
>
> - record->id = record->part;
> return ret;
> };
>
> @@ -287,7 +295,7 @@ static int efi_pstore_erase_func(struct efivar_entry
> *entry, void *data)
>* holding multiple logs, remains.
>*/
> snprintf(name_old, sizeof(name_old), "dump-
> type%u-%u-%lu",
> - ed->record->type, (unsigned
> int)ed->record->id,
> + ed->record->type, ed->record-
> >part,
> ed->record->time.tv_sec);
>
> for (i = 0; i < DUMP_NAME_LEN; i++)
> @@ -320,10 +328,7 @@ static int efi_pstore_erase(struct pstore_record
> *record)
> char name[DUMP_NAME_LEN];
> efi_char16_t efi_name[DUMP_NAME_LEN];
> int found, i;
> - unsigned int part;
>
> - do_div(record->id, 1000);
> - part = do_div(record->id, 100);
> snprintf(name, sizeof(name), "dump-type%u-%u-%d-%lu",
>record->type, record->part, record->count,
>record->time.tv_sec);
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
RE: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image
> -Original Message- > From: Pratyush Anand [mailto:pan...@redhat.com] > Sent: Monday, May 22, 2017 12:09 PM > To: AKASHI Takahiro ; Dave Young > ; Bharat Bhushan ; > b...@redhat.com; vgo...@redhat.com; cor...@lwn.net; > ke...@lists.infradead.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] kexec/kdump: Minor Documentation updates for > arm64 and Image > > > > On Friday 19 May 2017 09:15 AM, AKASHI Takahiro wrote: > >>> +to load dump-capture kernel. > >>> + > >>> + kexec -p \ > >>> + --initrd= \ > >>> + --append="root= " > >> For uncompressed Image, dtb is not necessary? > > Just for clarification, dtb is optional for both vmlinux and Image on > > arm64. (This means you can specify it if you want.) But this is also > > true for initrd and append(command line) to some extent. > > Yes, I agree. Should I mention "-dtb" also for "Image"? Also do we need to mention that it is optional somewhere in this document? I do not see "optional" is mentioned for other parameters and architecture. Does this looks ok: " -dtb= \" Thanks -Bharat > > > > More precisely, whether these parameters are optional or not will > > depend on architectures, not formats, I believe. > > May be not architecture, rather a distro environment. > > For example, we should be able to work without --initrd for any arch if kernel > has been compiled by configuring CONFG_INITRAMFS_SOURCE. > > ~Pratyush
Re: [PATCH] i2c: designware: Fix bogus sda_hold_time due to uninitialized vars
On 05/22/2017 08:46 AM, Jan Kiszka wrote:
We need to initializes those variables to 0 for platforms that do not
provide ACPI parameters. Otherwise, we set sda_hold_time to random
values, breaking e.g. Galileo and IOT2000 boards.
Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from
clock rate")
Signed-off-by: Jan Kiszka
---
Affects 4.12-rc2.
Acked-by: Jarkko Nikula
Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image
On Friday 19 May 2017 09:15 AM, AKASHI Takahiro wrote: +to load dump-capture kernel. + + kexec -p \ + --initrd= \ + --append="root= " For uncompressed Image, dtb is not necessary? Just for clarification, dtb is optional for both vmlinux and Image on arm64. (This means you can specify it if you want.) But this is also true for initrd and append(command line) to some extent. Yes, I agree. More precisely, whether these parameters are optional or not will depend on architectures, not formats, I believe. May be not architecture, rather a distro environment. For example, we should be able to work without --initrd for any arch if kernel has been compiled by configuring CONFG_INITRAMFS_SOURCE. ~Pratyush
Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c
Hi Guenter, > > Note that some files don't seem to have upstream > > users in board code, so they maybe could even be removed? I didn't check for > > While I understand where you are coming from, I am not typically that > aggressive. > Such removals force vendors who are not really forthcoming with upstreaming to > deviate even further from upstream. It makes them even less likely to submit > their > code upstream, and it may result in enforcing their belief that upstream > doesn't > really care about vendors struggling to release boards and systems to their > customers. I clearly see your point. I meant more the case where platform_data became cruft because platforms moved to DT. I agree this is not so much the case for HWMON but it was true for the I2C master driver where I could remove the platform data and could save the include file and some code. That was just a nice cleanup. > >I prefer the series to go upstream via the subsystem tree; if you prefer > >that I > >take it via I2C, just let me know. > > > Series applied to hwmon-next. Super, thanks! Regards, Wolfram signature.asc Description: PGP signature
Re: [PATCH] ALSA: sound/isa: constify snd_kcontrol_new structures
On Mon, May 22, 2017 at 11:59 AM, Takashi Iwai wrote:
> On Mon, 22 May 2017 08:20:45 +0200,
> Julia Lawall wrote:
>>
>>
>>
>> On Mon, 22 May 2017, Bhumika Goyal wrote:
>>
>> > On Sun, May 21, 2017 at 12:39 PM, Takashi Iwai wrote:
>> > > On Wed, 17 May 2017 14:33:45 +0200,
>> > > Bhumika Goyal wrote:
>> > >>
>> > >> On Wed, May 17, 2017 at 5:50 PM, Takashi Iwai wrote:
>> > >> > On Wed, 17 May 2017 13:38:56 +0200,
>> > >> > Bhumika Goyal wrote:
>> > >> >>
>> > >> >> Declare snd_kcontrol_new structures as const as they are only passed
>> > >> >> an
>> > >> >> argument to the function snd_ctl_new1. This argument is of type
>> > >> >> const,
>> > >> >> so snd_kcontrol_new structures having this property can be made
>> > >> >> const.
>> > >> >> Done using Coccinelle:
>> > >> >>
>> > >> >> @r disable optional_qualifier@
>> > >> >> identifier x;
>> > >> >> position p;
>> > >> >> @@
>> > >> >> static struct snd_kcontrol_new x@p={...};
>> > >> >>
>> > >> >> @ok@
>> > >> >> identifier r.x;
>> > >> >> position p;
>> > >> >> @@
>> > >> >> snd_ctl_new1(&x@p,...)
>> > >> >>
>> > >> >> @bad@
>> > >> >> position p != {r.p,ok.p};
>> > >> >> identifier r.x;
>> > >> >> @@
>> > >> >> x@p
>> > >> >>
>> > >> >> @depends on !bad disable optional_qualifier@
>> > >> >> identifier r.x;
>> > >> >> @@
>> > >> >> +const
>> > >> >> struct snd_kcontrol_new x;
>> > >> >>
>> > >> >> Signed-off-by: Bhumika Goyal
>> > >> >
>> > >> > As I already asked, could you send as a patchset if you have multiple
>> > >> > similar patches?
>> > >> >
>> > >>
>> > >> Sure. Will combine the already sent ones and some new ones into a
>> > >> patchset and send again.
>> > >
>> > > Well, since there haven't been new submissions and the patches are
>> > > trivial, I applied the existing four patches. If you have newer ones,
>> > > please submit as a patchset.
>> > >
>> > >
>> >
>> > Hey,
>> >
>> > Thanks for applying the patches.
>> > I have a doubt that since some of my coming patches are for the sound
>> > subsystem containing similar changes and you will be applying those,
>> > so can I combine and put all the changes in a single patch or sending
>> > a patchset would be a correct way.
>>
>> I think he means that when you have more sound patches, just do them all
>> at once.
>
> Yes, that's my point.
>
> You've sent each patch individually, and this made me difficult to
> pick up, as I had to wonder "is this really all?" (then 10 minutes
> later another patch arrived :)
>
> At best, submit all the relevant patches via git-send-email with the
> proper cover letter in a single thread.
>
Thanks Julia and Takashi for clearing my doubt. I will keep this point
in mind for my future patches :)
Thanks,
Bhumika
>
> thanks,
>
> Takashi
[PATCH 4750/4750] net: ipv4: tcp: fixed comment coding style issue
Fixed a coding style issue
Signed-off-by: Rohit Chavan
---
net/ipv4/tcp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1e4c76d..87b0296 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2183,7 +2183,7 @@ void tcp_close(struct sock *sk, long timeout)
/* Now socket is owned by kernel and we acquire BH lock
- to finish close. No need to check for user refs.
+* to finish close. No need to check for user refs.
*/
local_bh_disable();
bh_lock_sock(sk);
@@ -2471,7 +2471,8 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
case TCP_MAXSEG:
/* Values greater than interface MTU won't take effect. However
* at the point when this call is done we typically don't yet
-* know which interface is going to be used */
+* know which interface is going to be used
+*/
if (val && (val < TCP_MIN_MSS || val > MAX_TCP_WINDOW)) {
err = -EINVAL;
break;
--
2.7.4
Re: [PATCH] ALSA: sound/isa: constify snd_kcontrol_new structures
On Mon, 22 May 2017 08:20:45 +0200,
Julia Lawall wrote:
>
>
>
> On Mon, 22 May 2017, Bhumika Goyal wrote:
>
> > On Sun, May 21, 2017 at 12:39 PM, Takashi Iwai wrote:
> > > On Wed, 17 May 2017 14:33:45 +0200,
> > > Bhumika Goyal wrote:
> > >>
> > >> On Wed, May 17, 2017 at 5:50 PM, Takashi Iwai wrote:
> > >> > On Wed, 17 May 2017 13:38:56 +0200,
> > >> > Bhumika Goyal wrote:
> > >> >>
> > >> >> Declare snd_kcontrol_new structures as const as they are only passed
> > >> >> an
> > >> >> argument to the function snd_ctl_new1. This argument is of type const,
> > >> >> so snd_kcontrol_new structures having this property can be made const.
> > >> >> Done using Coccinelle:
> > >> >>
> > >> >> @r disable optional_qualifier@
> > >> >> identifier x;
> > >> >> position p;
> > >> >> @@
> > >> >> static struct snd_kcontrol_new x@p={...};
> > >> >>
> > >> >> @ok@
> > >> >> identifier r.x;
> > >> >> position p;
> > >> >> @@
> > >> >> snd_ctl_new1(&x@p,...)
> > >> >>
> > >> >> @bad@
> > >> >> position p != {r.p,ok.p};
> > >> >> identifier r.x;
> > >> >> @@
> > >> >> x@p
> > >> >>
> > >> >> @depends on !bad disable optional_qualifier@
> > >> >> identifier r.x;
> > >> >> @@
> > >> >> +const
> > >> >> struct snd_kcontrol_new x;
> > >> >>
> > >> >> Signed-off-by: Bhumika Goyal
> > >> >
> > >> > As I already asked, could you send as a patchset if you have multiple
> > >> > similar patches?
> > >> >
> > >>
> > >> Sure. Will combine the already sent ones and some new ones into a
> > >> patchset and send again.
> > >
> > > Well, since there haven't been new submissions and the patches are
> > > trivial, I applied the existing four patches. If you have newer ones,
> > > please submit as a patchset.
> > >
> > >
> >
> > Hey,
> >
> > Thanks for applying the patches.
> > I have a doubt that since some of my coming patches are for the sound
> > subsystem containing similar changes and you will be applying those,
> > so can I combine and put all the changes in a single patch or sending
> > a patchset would be a correct way.
>
> I think he means that when you have more sound patches, just do them all
> at once.
Yes, that's my point.
You've sent each patch individually, and this made me difficult to
pick up, as I had to wonder "is this really all?" (then 10 minutes
later another patch arrived :)
At best, submit all the relevant patches via git-send-email with the
proper cover letter in a single thread.
thanks,
Takashi
Re: [PATCH] ALSA: sound/isa: constify snd_kcontrol_new structures
On Mon, 22 May 2017, Bhumika Goyal wrote:
> On Sun, May 21, 2017 at 12:39 PM, Takashi Iwai wrote:
> > On Wed, 17 May 2017 14:33:45 +0200,
> > Bhumika Goyal wrote:
> >>
> >> On Wed, May 17, 2017 at 5:50 PM, Takashi Iwai wrote:
> >> > On Wed, 17 May 2017 13:38:56 +0200,
> >> > Bhumika Goyal wrote:
> >> >>
> >> >> Declare snd_kcontrol_new structures as const as they are only passed an
> >> >> argument to the function snd_ctl_new1. This argument is of type const,
> >> >> so snd_kcontrol_new structures having this property can be made const.
> >> >> Done using Coccinelle:
> >> >>
> >> >> @r disable optional_qualifier@
> >> >> identifier x;
> >> >> position p;
> >> >> @@
> >> >> static struct snd_kcontrol_new x@p={...};
> >> >>
> >> >> @ok@
> >> >> identifier r.x;
> >> >> position p;
> >> >> @@
> >> >> snd_ctl_new1(&x@p,...)
> >> >>
> >> >> @bad@
> >> >> position p != {r.p,ok.p};
> >> >> identifier r.x;
> >> >> @@
> >> >> x@p
> >> >>
> >> >> @depends on !bad disable optional_qualifier@
> >> >> identifier r.x;
> >> >> @@
> >> >> +const
> >> >> struct snd_kcontrol_new x;
> >> >>
> >> >> Signed-off-by: Bhumika Goyal
> >> >
> >> > As I already asked, could you send as a patchset if you have multiple
> >> > similar patches?
> >> >
> >>
> >> Sure. Will combine the already sent ones and some new ones into a
> >> patchset and send again.
> >
> > Well, since there haven't been new submissions and the patches are
> > trivial, I applied the existing four patches. If you have newer ones,
> > please submit as a patchset.
> >
> >
>
> Hey,
>
> Thanks for applying the patches.
> I have a doubt that since some of my coming patches are for the sound
> subsystem containing similar changes and you will be applying those,
> so can I combine and put all the changes in a single patch or sending
> a patchset would be a correct way.
I think he means that when you have more sound patches, just do them all
at once.
julia
Re: [v4 1/1] mm: Adaptive hash table scaling
Pavel Tatashin writes:
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8afa63e81e73..15bba5c325a5 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7169,6 +7169,17 @@ static unsigned long __init
> arch_reserved_kernel_pages(void)
> #endif
>
> /*
> + * Adaptive scale is meant to reduce sizes of hash tables on large memory
> + * machines. As memory size is increased the scale is also increased but at
> + * slower pace. Starting from ADAPT_SCALE_BASE (64G), every time memory
> + * quadruples the scale is increased by one, which means the size of hash
> table
> + * only doubles, instead of quadrupling as well.
> + */
> +#define ADAPT_SCALE_BASE (64ull << 30)
> +#define ADAPT_SCALE_SHIFT2
> +#define ADAPT_SCALE_NPAGES (ADAPT_SCALE_BASE >> PAGE_SHIFT)
> +
> +/*
> * allocate a large system hash table from bootmem
> * - it is assumed that the hash table must contain an exact power-of-2
> * quantity of entries
> @@ -7199,6 +7210,14 @@ void *__init alloc_large_system_hash(const char
> *tablename,
> if (PAGE_SHIFT < 20)
> numentries = round_up(numentries, (1<<20)/PAGE_SIZE);
>
> + if (!high_limit) {
> + unsigned long long adapt;
> +
> + for (adapt = ADAPT_SCALE_NPAGES; adapt < numentries;
> + adapt <<= ADAPT_SCALE_SHIFT)
> + scale++;
> + }
This still doesn't work for me. The scale++ is overflowing according to
UBSAN (line 7221).
It looks like numentries is 194560.
0950 68 0a 50 49 44 20 68 61 73 68 20 74 61 62 6c 65 |h.PID hash table|
0960 20 65 6e 74 72 69 65 73 3a 20 34 30 39 36 20 28 | entries: 4096 (|
0970 6f 72 64 65 72 3a 20 32 2c 20 31 36 33 38 34 20 |order: 2, 16384 |
0980 62 79 74 65 73 29 0a 61 6c 6c 6f 63 5f 6c 61 72 |bytes).alloc_lar|
0990 67 65 5f 73 79 73 74 65 6d 5f 68 61 73 68 3a 20 |ge_system_hash: |
09a0 6e 75 6d 65 6e 74 72 69 65 73 20 31 39 34 35 36 |numentries 19456|
09b0 30 0a 61 6c 6c 6f 63 5f 6c 61 72 67 65 5f 73 79 |0.alloc_large_sy|
09c0 73 74 65 6d 5f 68 61 73 68 3a 20 61 64 61 70 74 |stem_hash: adapt|
09d0 20 30 0a 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d | 0.=|
09e0 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d ||
*
0a20 3d 3d 3d 0a 55 42 53 41 4e 3a 20 55 6e 64 65 66 |===.UBSAN: Undef|
0a30 69 6e 65 64 20 62 65 68 61 76 69 6f 75 72 20 69 |ined behaviour i|
0a40 6e 20 2e 2e 2f 6d 6d 2f 70 61 67 65 5f 61 6c 6c |n ../mm/page_all|
0a50 6f 63 2e 63 3a 37 32 32 31 3a 31 30 0a 73 69 67 |oc.c:7221:10.sig|
0a60 6e 65 64 20 69 6e 74 65 67 65 72 20 6f 76 65 72 |ned integer over|
0a70 66 6c 6f 77 3a 0a 32 31 34 37 34 38 33 36 34 37 |flow:.2147483647|
0a80 20 2b 20 31 20 63 61 6e 6e 6f 74 20 62 65 20 72 | + 1 cannot be r|
0a90 65 70 72 65 73 65 6e 74 65 64 20 69 6e 20 74 79 |epresented in ty|
0aa0 70 65 20 27 69 6e 74 20 5b 34 5d 27 0a 43 50 55 |pe 'int [4]'.CPU|
0ab0 3a 20 30 20 50 49 44 3a 20 30 20 43 6f 6d 6d 3a |: 0 PID: 0 Comm:|
0ac0 20 73 77 61 70 70 65 72 20 4e 6f 74 20 74 61 69 | swapper Not tai|
0ad0 6e 74 65 64 20 34 2e 31 32 2e 30 2d 72 63 31 2d |nted 4.12.0-rc1-|
0ae0 67 63 63 2d 36 2e 33 2e 31 2d 30 30 31 38 32 2d |gcc-6.3.1-00182-|
0af0 67 36 37 64 30 36 38 37 32 32 34 61 39 2d 64 69 |g67d0687224a9-di|
0b00 72 74 79 20 23 38 0a 43 61 6c 6c 20 54 72 61 63 |rty #8.Call Trac|
0b10 65 3a 0a 5b 63 30 65 30 35 65 61 30 5d 20 5b 63 |e:.[c0e05ea0] [c|
0b20 30 34 37 38 38 63 34 5d 20 75 62 73 61 6e 5f 65 |04788c4] ubsan_e|
0b30 70 69 6c 6f 67 75 65 2b 30 78 31 38 2f 30 78 34 |pilogue+0x18/0x4|
0b40 63 20 28 75 6e 72 65 6c 69 61 62 6c 65 29 0a 5b |c (unreliable).[|
0b50 63 30 65 30 35 65 62 30 5d 20 5b 63 30 34 37 39 |c0e05eb0] [c0479|
0b60 32 36 30 5d 20 68 61 6e 64 6c 65 5f 6f 76 65 72 |260] handle_over|
0b70 66 6c 6f 77 2b 30 78 62 63 2f 30 78 64 63 0a 5b |flow+0xbc/0xdc.[|
0b80 63 30 65 30 35 66 33 30 5d 20 5b 63 30 61 62 39 |c0e05f30] [c0ab9|
0b90 38 66 38 5d 20 61 6c 6c 6f 63 5f 6c 61 72 67 65 |8f8] alloc_large|
0ba0 5f 73 79 73 74 65 6d 5f 68 61 73 68 2b 30 78 65 |_system_hash+0xe|
0bb0 34 2f 30 78 35 65 63 0a 5b 63 30 65 30 35 66 39 |4/0x5ec.[c0e05f9|
0bc0 30 5d 20 5b 63 30 61 62 65 30 30 30 5d 20 76 66 |0] [c0abe000] vf|
0bd0 73 5f 63 61 63 68 65 73 5f 69 6e 69 74 5f 65 61 |s_caches_init_ea|
0be0 72 6c 79 2b 30 78 34 63 2f 30 78 36 34 0a 5b 63 |rly+0x4c/0x64.[c|
0bf0 30 65 30 35 66 62 30 5d 20 5b 63 30 61 61 35 32 |0e05fb0] [c0aa52|
0c00 31 38 5d 20 73 74 61 72 74 5f 6b 65 72 6e 65 6c |18] start_kernel|
0c10 2b 30 78 32 33 63 2f 30 78 33 63 34 0a 5b 63 30 |+0x23c/0x3c4.[c0|
0c20 65 30 35 66 66 30 5d 20 5b 30 30 30 30 33 34 34 |e05ff0] [344|
0c30 63 5d 20
Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent
Hi Laurent and Kieran, On Fri, May 19, 2017 at 05:42:07PM +0300, Laurent Pinchart wrote: > Hi Kieran, > > On Friday 19 May 2017 14:34:33 Kieran Bingham wrote: > > On 18/05/17 14:36, Laurent Pinchart wrote: > > > On Wednesday 17 May 2017 16:03:38 Kieran Bingham wrote: > > >> From: Kieran Bingham > > >> > > >> V4L2 async notifiers can pass the endpoint fwnode rather than the device > > >> fwnode. > > > > > > I'm not sure I would mention V4L2 in the commit message, as this is > > > generic. > > > > Good point > > > > >> Provide a helper to obtain the parent device fwnode without first > > >> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent. > > >> > > >> Signed-off-by: Kieran Bingham > > >> --- > > >> > > >> drivers/base/property.c | 25 + > > >> include/linux/property.h | 2 ++ > > >> 2 files changed, 27 insertions(+) > > >> > > >> diff --git a/drivers/base/property.c b/drivers/base/property.c > > >> index 627ebc9b570d..caf4316fe565 100644 > > >> --- a/drivers/base/property.c > > >> +++ b/drivers/base/property.c > > >> @@ -1245,6 +1245,31 @@ fwnode_graph_get_next_endpoint(struct > > >> fwnode_handle > > >> *fwnode, EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint); > > >> > > >> /** > > >> > > >> + * fwnode_graph_get_port_parent - Return device node of a port endpoint > > >> + * @fwnode: Endpoint firmware node pointing of the port > > >> + * > > >> + * Extracts firmware node of the device the @fwnode belongs to. > > > > > > I'm not too familiar with the fwnode API, but I know it's written in C, > > > where functions don't extract something but return a value :-) How about > > > > > > Return: the firmware node of the device the @endpoint belongs to. > > > > I'm not averse to the reword - but it is different to the other functions in > > the same context: > > > > fwnode_graph_get_remote_endpoint(struct fwnode_handle *fwnode) > > * Extracts firmware node of a remote endpoint the @fwnode points to. > > > > struct fwnode_handle *fwnode_graph_get_remote_port(struct fwnode_handle > > *fwnode) > > * Extracts firmware node of a remote port the @fwnode points to. > > > > fwnode_graph_get_remote_port_parent(struct fwnode_handle *fwnode) > > * Extracts firmware node of a remote device the @fwnode points to. > > > > Then with this function becoming: > > > > fwnode_graph_get_port_parent(struct fwnode_handle *endpoint) > > * Returns firmware node of the device the @endpoint belongs to. > > > > > > I guess those could be changed too ... > > My point is that the kerneldoc format documents return values with a > "Return:" > tag. The documentation for the function can still provide extra information. Yeah, let's do this right and then fix the rest. I've already submitted the pull request on this one --- the origin of that text is actually the V4L2 OF framework. Feel free to submit a patch that fixes it, I can do it as well. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[PATCH 2/2] ieee802154: ca8210: Delete an error message for a failed memory allocation in ca8210_skb_rx()
From: Markus Elfring
Date: Mon, 22 May 2017 08:03:17 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
drivers/net/ieee802154/ca8210.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 25ed11bb5ed3..f6df75e80a60 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -1808,10 +1808,9 @@ static int ca8210_skb_rx(
/* Allocate mtu size buffer for every rx packet */
skb = dev_alloc_skb(IEEE802154_MTU + sizeof(hdr));
- if (!skb) {
- dev_crit(&priv->spi->dev, "dev_alloc_skb failed\n");
+ if (!skb)
return -ENOMEM;
- }
+
skb_reserve(skb, sizeof(hdr));
msdulen = data_ind[22]; /* msdu_length */
--
2.13.0
[PATCH 1/2] ieee802154: ca8210: Delete an error message for a failed memory allocation in ca8210_probe()
From: Markus Elfring
Date: Mon, 22 May 2017 07:32:46 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
drivers/net/ieee802154/ca8210.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 25fd3b04b3c0..25ed11bb5ed3 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -3143,10 +3143,6 @@ static int ca8210_probe(struct spi_device *spi_device)
pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
- dev_crit(
- &spi_device->dev,
- "Could not allocate platform data\n"
- );
ret = -ENOMEM;
goto error;
}
--
2.13.0
[PATCH] mm: introduce MADV_CLR_HUGEPAGE
Currently applications can explicitly enable or disable THP for a memory
region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of
these advises is used, the region will always have
VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags.
The MADV_CLR_HUGEPAGE resets both these flags and allows managing THP in
the region according to system-wide settings.
Signed-off-by: Mike Rapoport
---
include/uapi/asm-generic/mman-common.h | 3 +++
mm/khugepaged.c| 7 +++
mm/madvise.c | 5 +
3 files changed, 15 insertions(+)
diff --git a/include/uapi/asm-generic/mman-common.h
b/include/uapi/asm-generic/mman-common.h
index 8c27db0..3201712 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -58,6 +58,9 @@
overrides the coredump filter bits */
#define MADV_DODUMP17 /* Clear the MADV_DONTDUMP flag */
+#define MADV_CLR_HUGEPAGE 18 /* Clear flags controlling backing with
+ hugepages */
+
/* compatibility flags */
#define MAP_FILE 0
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 945fd1c..b9ee9bb 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -336,6 +336,13 @@ int hugepage_madvise(struct vm_area_struct *vma,
* it got registered before VM_NOHUGEPAGE was set.
*/
break;
+ case MADV_CLR_HUGEPAGE:
+ *vm_flags &= ~(VM_HUGEPAGE | VM_NOHUGEPAGE);
+ /*
+* The vma will be treated according to the
+* system-wide settings in transparent_hugepage_flags
+*/
+ break;
}
return 0;
diff --git a/mm/madvise.c b/mm/madvise.c
index 25b78ee..ae650a3 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -105,6 +105,7 @@ static long madvise_behavior(struct vm_area_struct *vma,
break;
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
+ case MADV_CLR_HUGEPAGE:
error = hugepage_madvise(vma, &new_flags, behavior);
if (error) {
/*
@@ -684,6 +685,7 @@ madvise_behavior_valid(int behavior)
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
+ case MADV_CLR_HUGEPAGE:
#endif
case MADV_DONTDUMP:
case MADV_DODUMP:
@@ -739,6 +741,9 @@ madvise_behavior_valid(int behavior)
* MADV_NOHUGEPAGE - mark the given range as not worth being backed by
* transparent huge pages so the existing pages will not be
* coalesced into THP and new pages will not be allocated as THP.
+ * MADV_CLR_HUGEPAGE - clear MADV_HUGEPAGE/MADV_NOHUGEPAGE marking;
+ * the range will be treated by khugepaged according to the
+ * system wide settings
* MADV_DONTDUMP - the application wants to prevent pages in the given range
* from being included in its core dump.
* MADV_DODUMP - cancel MADV_DONTDUMP: no longer exclude from core dump.
--
2.7.4
[PATCH 0/2] ieee802154: ca8210: Adjustments for two function implementations
From: Markus Elfring Date: Mon, 22 May 2017 08:08:04 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in ca8210_probe() Delete an error message for a failed memory allocation in ca8210_skb_rx() drivers/net/ieee802154/ca8210.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) -- 2.13.0
Re: [PATCH] drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake
Hi, Nickey:
Sorry for the late reply. I've applied this patch to my branch
mediatek-drm-fixes-4.12-rc1.
Regards,
CK
On Tue, 2017-03-21 at 16:27 +0800, Nickey Yang wrote:
> mtk_hdmi_setup_vendor_specific_infoframe will return before handle
> mtk_hdmi_hw_send_info_frame.Because hdmi_vendor_infoframe_pack
> returns the number of bytes packed into the binary buffer or
> a negative error code on failure.
> So correct it.
>
> Signed-off-by: Nickey Yang
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index c262512..b43aa29 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1062,7 +1062,7 @@ static int
> mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
> }
>
> err = hdmi_vendor_infoframe_pack(&frame, buffer, sizeof(buffer));
> - if (err) {
> + if (err < 0) {
> dev_err(hdmi->dev, "Failed to pack vendor infoframe: %zd\n",
> err);
> return err;
linux-next: Tree for May 22
Hi all, Changes since 20170519: The netfilter tree lost its build failure. The net-next tree gained a build failure so I used the version from next-20170519. The selinux tree gained a conflict against Linus' tree and a build failure for which I applied a fix patch. The tip tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 2000 2292 files changed, 77464 insertions(+), 46252 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 260 trees (counting Linus' and 40 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (f3926e4c2a4b Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging fixes/master (97da3854c526 Linux 4.11-rc3) Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of headers right under uapi directories) Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1) Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1) Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card definitions) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (e41e53cd4fe3 powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash) Merging sparc/master (8b4822de59d5 Merge tag 'md/4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (6d18c732b95c bridge: start hello_timer when enabling KERNEL_STP in br_stp_start) Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay sequence numbers) Merging netfilter/master (6d18c732b95c bridge: start hello_timer when enabling KERNEL_STP in br_stp_start) Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed connections) Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype avoiding use-after-free of virtual interface) Merging mac80211/master (5667c86acf02 mac80211: strictly check mesh address extension mode) Merging sound-current/for-linus (fa16b69f1299 ALSA: hda - No loopback on ALC299 codec) Merging pci-current/for-linus (2ea659a9ef48 Linux 4.12-rc1) Merging driver-core.current/driver-core-linus (56f410cf45a1 Merge tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging tty.current/tty-linus (da4c279942b0 serial: enable serdev support) Merging usb.current/usb-linus (b51e0ceed1f9 Merge tag 'usb-serial-4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11) Merging usb-serial-fixes/usb-linus (8d7a10dd3239 USB: serial: qcserial: add more Lenovo EM74xx device IDs) Merging usb-chipidea-fixes/ci-for-usb-stable (aa1f058d7d92 usb: chipidea: udc: fix NULL pointer dereference if udc_start failed) Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of sizeof to pointer) Merging staging.current/staging-linus (56f410cf45a1 Merge tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging char-misc.current/char-misc-linus (56f410cf45a1 Merge tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging input-current/for-linus (3af9256150b3 Input: cros_ec_keyb - remove extraneous 'co
Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption
On Fri, May 19, 2017 at 3:53 AM, Joonsoo Kim wrote: > On Wed, May 17, 2017 at 03:17:13PM +0300, Andrey Ryabinin wrote: >> On 05/16/2017 04:16 AM, js1...@gmail.com wrote: >> > From: Joonsoo Kim >> > >> > Hello, all. >> > >> > This is an attempt to recude memory consumption of KASAN. Please see >> > following description to get the more information. >> > >> > 1. What is per-page shadow memory >> > >> > This patch introduces infrastructure to support per-page shadow memory. >> > Per-page shadow memory is the same with original shadow memory except >> > the granualarity. It's one byte shows the shadow value for the page. >> > The purpose of introducing this new shadow memory is to save memory >> > consumption. >> > >> > 2. Problem of current approach >> > >> > Until now, KASAN needs shadow memory for all the range of the memory >> > so the amount of statically allocated memory is so large. It causes >> > the problem that KASAN cannot run on the system with hard memory >> > constraint. Even if KASAN can run, large memory consumption due to >> > KASAN changes behaviour of the workload so we cannot validate >> > the moment that we want to check. >> > >> > 3. How does this patch fix the problem >> > >> > This patch tries to fix the problem by reducing memory consumption for >> > the shadow memory. There are two observations. >> > >> >> >> I think that the best way to deal with your problem is to increase shadow >> scale size. >> >> You'll need to add tunable to gcc to control shadow size. I expect that gcc >> has some >> places where 8-shadow scale size is hardcoded, but it should be fixable. >> >> The kernel also have some small amount of code written with >> KASAN_SHADOW_SCALE_SIZE == 8 in mind, >> which should be easy to fix. >> >> Note that bigger shadow scale size requires bigger alignment of allocated >> memory and variables. >> However, according to comments in gcc/asan.c gcc already aligns stack and >> global variables and at >> 32-bytes boundary. >> So we could bump shadow scale up to 32 without increasing current stack >> consumption. >> >> On a small machine (1Gb) 1/32 of shadow is just 32Mb which is comparable to >> yours 30Mb, but I expect it to be >> much faster. More importantly, this will require only small amount of simple >> changes in code, which will be >> a *lot* more easier to maintain. Interesting option. We never considered increasing scale in user space due to performance implications. But the algorithm always supported up to 128x scale. Definitely worth considering as an option. > I agree that it is also a good option to reduce memory consumption. > Nevertheless, there are two reasons that justifies this patchset. > > 1) With this patchset, memory consumption isn't increased in > proportional to total memory size. Please consider my 4Gb system > example on the below. With increasing shadow scale size to 32, memory > would be consumed by 128M. However, this patchset consumed 50MB. This > difference can be larger if we run KASAN with bigger machine. > > 2) These two optimization can be applied simulatenously. It is just an > orthogonal feature. If shadow scale size is increased to 32, memory > consumption will be decreased in case of my patchset, too. > > Therefore, I think that this patchset is useful in any case. It is definitely useful all else being equal. But it does considerably increase code size and complexity, which is an important aspect. Also note that there is also fixed size quarantine (1/32 of RAM) and redzones. Reducing shadow overhead beyond some threshold has diminishing returns, because overall overhead will be just dominated by quarantine/redzones. What's your target devices and constraints? We run KASAN on phones today without any issues. > Note that increasing shadow scale has it's own trade-off. It requires > that the size of slab object is aligned to shadow scale. It will > increase memory consumption due to slab. I've tried to retest your latest change on top of http://git.cmpxchg.org/cgit.cgi/linux-mmots.git d9cd9c95cc3b2fed0f04d233ebf2f7056741858c, but now this version https://codereview.appspot.com/325780043 always crashes during boot for me. Report points to zero shadow. [0.123434] == [0.125153] BUG: KASAN: double-free or invalid-free in cleanup_uevent_env+0x2c/0x40 [0.126900] [0.127318] CPU: 1 PID: 226 Comm: kworker/u8:0 Not tainted 4.12.0-rc1-mm1+ #376 [0.128995] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [0.130896] Call Trace: [0.131202] kworker/u8:0 (277) used greatest stack depth: 22976 bytes left [0.133129] dump_stack+0xb0/0x13d [0.133958] ? _atomic_dec_and_lock+0x1e3/0x1e3 [0.135020] ? load_image_and_restore+0xf6/0xf6 [0.136083] ? kmemdup+0x31/0x40 [0.136143] kworker/u8:0 (320) used greatest stack depth: 22112 bytes left [0.138294] ? cleanup_uevent_env+0x2c/0x40 [0.139255] prin
Re: [PATCH] i2c: designware: Fix bogus sda_hold_time due to uninitialized vars
> On 22 May 2017, at 07:46, Jan Kiszka wrote:
>
> We need to initializes those variables to 0 for platforms that do not
> provide ACPI parameters. Otherwise, we set sda_hold_time to random
> values, breaking e.g. Galileo and IOT2000 boards.
>
> Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI
> from clock rate")
> Signed-off-by: Jan Kiszka
Reviewed-by: Ard Biesheuvel
> ---
>
> Affects 4.12-rc2.
>
> drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 6283b99d2b17..d1263b82d646 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -94,9 +94,9 @@ static void dw_i2c_acpi_params(struct platform_device
> *pdev, char method[],
> static int dw_i2c_acpi_configure(struct platform_device *pdev)
> {
>struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
> +u32 ss_ht = 0, fp_ht = 0, hs_ht = 0, fs_ht = 0;
>acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>const struct acpi_device_id *id;
> -u32 ss_ht, fp_ht, hs_ht, fs_ht;
>struct acpi_device *adev;
>const char *uid;
>
Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers
On la, 2017-05-20 at 10:56 +0900, J. R. Okajima wrote: > "J. R. Okajima": > > > > I don't know whether the fix is good to me or not yet. I will test your > > fix, but I am busy now and my test will be a few weeks later. Other > > people may want the fix soon. So I'd suggest you to reproduce the > > problem on your side. I guess "mem=1G" or "mem=512M" will make it easier > > to reproduce the problem. > > Of course, if you are sure the fix is correct, then you don't have to > > wait for my test. Release it soon for other people. > > Now I am going to able to run my local test. > But V3 patch failed to apply onto v4.11.0. > > Would you provide us two versions of the patch, one for v4.11 series and > the other of v4.12-rcN? For v4.12-rc2 the backport is here: https://patchwork.freedesktop.org/patch/156990/ For quick testing on older kernels, just remove all lines with "_rcu" in drivers/gpu/drm/i915/i915_gem_shrinker.c . Regards, Joonas PS: It'll help to subscribe to and track our mailing list at intel-...@lists.freedesktop.org for future convenience. -- Joonas Lahtinen Open Source Technology Center Intel Corporation
Re: [PATCH 1/2] libsas: Don't process sas events in static works
Hi Dan, thanks for your review and comments! 在 2017/5/21 11:44, Dan Williams 写道: > On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote: >> Now libsas hotplug work is static, LLDD driver queue >> the hotplug work into shost->work_q. If LLDD driver >> burst post lots hotplug events to libsas, the hotplug >> events may pending in the workqueue like >> >> shost->work_q >> new work[PORTE_BYTES_DMAED] --> |[PHYE_LOSS_OF_SIGNAL][PORTE_BYTES_DMAED] -> >> processing >> |<---wait worker to process>| >> In this case, a new PORTE_BYTES_DMAED event coming, libsas try to queue it >> to shost->work_q, but this work is already pending, so it would be lost. >> Finally, libsas delete the related sas port and sas devices, but LLDD driver >> expect libsas add the sas port and devices(last sas event). >> >> This patch remove the static defined hotplug work, and use dynamic work to >> avoid missing hotplug events. > > If we go this route we don't even need: > > sas_port_event_fns > sas_phy_event_fns > sas_ha_event_fns Yes, these three fns are not necessary, just for avoid lots kfree in phy/port/ha event fns. > > ...just specify the target routine directly to INIT_WORK() and remove > the indirection. > > I also think for safety this should use a mempool that guarantees that > events can continue to be processed under system memory pressure. What I am worried about is it's would still fail if the mempool is used empty during memory pressure. > Also, have you considered the case when a broken phy starts throwing a > constant stream of events? Is there a point at which libsas should > stop queuing events and disable the phy? Not yet, I didn't find this issue in real case, but I agree, it's really a problem in some broken hardware, I think it's not a easy problem, we could improve it step by step. Thanks! Yijing. > > . >
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 2017-05-21 16:13, Jonathan Cameron wrote: > On 21/05/17 15:06, Jonathan Cameron wrote: >> On 21/05/17 13:44, Jan Kiszka wrote: >>> On 2017-05-21 14:18, Jonathan Cameron wrote: On 21/05/17 13:17, Jonathan Cameron wrote: > On 21/05/17 12:59, Jan Kiszka wrote: >> On 2017-05-21 12:47, Jonathan Cameron wrote: >>> On 17/05/17 16:28, Jan Kiszka wrote: This is an upstream port of an IIO driver for the TI ADC108S102 and ADC128S102. The former can be found on the Intel Galileo Gen2 and the Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is included. Due to the lack of regulators under ACPI, we hard-code the voltage provided to the VA pin of the ADC to 5 V, the value used on Galileo and IOT2000. For DT usage, the regulator "vref-supply" provides this information. Note that DT usage has not been tested. Original author: Bogdan Pricop Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: Todor Minchev . Signed-off-by: Jan Kiszka >>> Still an issue wrt to it being obviously correct in the ordering in >>> probe >>> and remove. >>> >>> As a reviewer I want to be able to run through each step in probe >>> and >>> compare with remove to ensure they occur in the opposite order and >>> reverse all the steps in probe. Where ever it deviates from that I >>> have >>> to think about it and we all know the last thing a reviewer with >>> a big >>> backlog of patches wants to do is to think hard ;) >>> >>> Anyhow, I've fixed up and applied to the togreg branch of iio.git >>> and >>> pushed out as testing for the autobuilders to play with it. >>> >>> Please check I haven't made a mess of it. >> >> Forgot to push? Not finding it in togreg, which is 5 days old. >> > As it says, pushed out as testing... Togreg is non rebasing so only > gets pushed out publicly once all the trivial stuff the autobuilders > find has been sorted. > > Depending on how busy I am it can be a few days before I get a chance > to push out togreg, whereas testing goes every few patches when I'm > merging stuff. Mind you I hadn't pushed that for half an hour or so hence that might have been out of date too ;) >>> >>> OK, now I see what went wrong: Please have a second look at commit >>> 52d4de2441af... ;) >>> >>> Jan >>> >> Gah! Thanks. I knew I did that initially but thought I'd unwound the >> mess. >> Seems not - here goes again for trying not to be an idiot. >> >> Thanks for pointing this mess out. > Should now all be fixed up. I pulled the messed up patch to the tip and > split it up into the original two patches. 'looks' right now I think but > if you wouldn't mind having a quick look that would be great. > Looks and works fine! Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH v2 0/4] ARM: dts: keystone: Add support for new K2G evm
On 5/10/17 9:08 AM, Santosh Shilimkar wrote: On 4/24/2017 1:22 PM, Franklin S Cooper Jr wrote: This patchset adds support for new K2G Industrial Communication Engine evm. For now only a bare minimal dts which will allow ram boot. Additional peripherals will be added when base K2G SoC patches are upstreamed allowing peripherals to be enabled. Version 2 changes: Make various tweaks to allow unit address to be added to memory node. Franklin S Cooper Jr (4): ARM: dts: keystone-k2g: Remove skeleton.dtsi ARM: dts: k2g-evm: Add unit address to memory node ARM: keystone: Create new binding for K2G ICE evm ARM: dts: keystone: Add minimum support for K2G ICE evm Will pick this up for next merge window. Thanks !! Applied to 'for_4.13/keystone_dts'. Should show up in next soon. Regards, Santosh
Re: [PATCH] ALSA: sound/isa: constify snd_kcontrol_new structures
On Sun, May 21, 2017 at 12:39 PM, Takashi Iwai wrote:
> On Wed, 17 May 2017 14:33:45 +0200,
> Bhumika Goyal wrote:
>>
>> On Wed, May 17, 2017 at 5:50 PM, Takashi Iwai wrote:
>> > On Wed, 17 May 2017 13:38:56 +0200,
>> > Bhumika Goyal wrote:
>> >>
>> >> Declare snd_kcontrol_new structures as const as they are only passed an
>> >> argument to the function snd_ctl_new1. This argument is of type const,
>> >> so snd_kcontrol_new structures having this property can be made const.
>> >> Done using Coccinelle:
>> >>
>> >> @r disable optional_qualifier@
>> >> identifier x;
>> >> position p;
>> >> @@
>> >> static struct snd_kcontrol_new x@p={...};
>> >>
>> >> @ok@
>> >> identifier r.x;
>> >> position p;
>> >> @@
>> >> snd_ctl_new1(&x@p,...)
>> >>
>> >> @bad@
>> >> position p != {r.p,ok.p};
>> >> identifier r.x;
>> >> @@
>> >> x@p
>> >>
>> >> @depends on !bad disable optional_qualifier@
>> >> identifier r.x;
>> >> @@
>> >> +const
>> >> struct snd_kcontrol_new x;
>> >>
>> >> Signed-off-by: Bhumika Goyal
>> >
>> > As I already asked, could you send as a patchset if you have multiple
>> > similar patches?
>> >
>>
>> Sure. Will combine the already sent ones and some new ones into a
>> patchset and send again.
>
> Well, since there haven't been new submissions and the patches are
> trivial, I applied the existing four patches. If you have newer ones,
> please submit as a patchset.
>
>
Hey,
Thanks for applying the patches.
I have a doubt that since some of my coming patches are for the sound
subsystem containing similar changes and you will be applying those,
so can I combine and put all the changes in a single patch or sending
a patchset would be a correct way.
Thanks,
Bhumika
> thanks,
>
> Takashi
Re: gpio-exar: Why filtering out Commtech devices?
On 2017-05-22 07:48, Jan Kiszka wrote: > On 2017-05-21 22:08, Sudip Mukherjee wrote: >> Hi Jan, >> >> On 21/05/17 12:46, Jan Kiszka wrote: >>> Hi Sudip, >>> >>> why do we carry >>> >>> if (pcidev->vendor != PCI_VENDOR_ID_EXAR) >>> return -ENODEV; >>> >>> in gpio_exar_probe? This effectively prevents that >>> >>> EXAR_DEVICE(COMMTECH, COMMTECH_4222PCIE, pbn_exar_XR17V35x), >>> EXAR_DEVICE(COMMTECH, COMMTECH_4224PCIE, pbn_exar_XR17V35x), >>> EXAR_DEVICE(COMMTECH, COMMTECH_4228PCIE, pbn_exar_XR17V35x), >>> >>> gain GPIO support. Do those devices lack access to the pins? Or can we >>> drop the filter. I don't have access to those devices, just wondering >>> because the code is not explaining the reason. >> >> Same here. I do not have these devices and have no idea if they support >> the gpio pins or not. >> >> Adding Matt Schulte in the Cc list, maybe he can comment. >> >> > > If we need to keep the condition, it should be moved over to 8250_exar: > there is no point in creating the platform device at all then. But let's > wait for Matt's comment. Unfortunately, his account is no longer existing. Is there anyone else we can ask? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Re: is alpha jensen support dead?
Christoph Hellwig writes: > Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit 6aca0503847f6329460b15b3ab2b0e30bb752793 > Author: Christian Borntraeger > Date: Tue Feb 2 21:46:33 2016 -0800 > > alpha/dma: use common noop dma ops > > which switches pci-noop.c to use generic code, but fat fingered a symbol > and didn't wire up the Kconfig. > > Is there any value in keeping it alive? Especially as there probably > isn't any build coverage.. We still build the defconfig FWIW: http://kisskb.ellerman.id.au/kisskb/target/2499/ http://kisskb.ellerman.id.au/kisskb/target/2494/ cheers
Re: gpio-exar: Why filtering out Commtech devices?
On 2017-05-21 22:08, Sudip Mukherjee wrote: > Hi Jan, > > On 21/05/17 12:46, Jan Kiszka wrote: >> Hi Sudip, >> >> why do we carry >> >> if (pcidev->vendor != PCI_VENDOR_ID_EXAR) >> return -ENODEV; >> >> in gpio_exar_probe? This effectively prevents that >> >> EXAR_DEVICE(COMMTECH, COMMTECH_4222PCIE, pbn_exar_XR17V35x), >> EXAR_DEVICE(COMMTECH, COMMTECH_4224PCIE, pbn_exar_XR17V35x), >> EXAR_DEVICE(COMMTECH, COMMTECH_4228PCIE, pbn_exar_XR17V35x), >> >> gain GPIO support. Do those devices lack access to the pins? Or can we >> drop the filter. I don't have access to those devices, just wondering >> because the code is not explaining the reason. > > Same here. I do not have these devices and have no idea if they support > the gpio pins or not. > > Adding Matt Schulte in the Cc list, maybe he can comment. > > If we need to keep the condition, it should be moved over to 8250_exar: there is no point in creating the platform device at all then. But let's wait for Matt's comment. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
[PATCH] i2c: designware: Fix bogus sda_hold_time due to uninitialized vars
We need to initializes those variables to 0 for platforms that do not
provide ACPI parameters. Otherwise, we set sda_hold_time to random
values, breaking e.g. Galileo and IOT2000 boards.
Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI
from clock rate")
Signed-off-by: Jan Kiszka
---
Affects 4.12-rc2.
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 6283b99d2b17..d1263b82d646 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -94,9 +94,9 @@ static void dw_i2c_acpi_params(struct platform_device *pdev,
char method[],
static int dw_i2c_acpi_configure(struct platform_device *pdev)
{
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
+ u32 ss_ht = 0, fp_ht = 0, hs_ht = 0, fs_ht = 0;
acpi_handle handle = ACPI_HANDLE(&pdev->dev);
const struct acpi_device_id *id;
- u32 ss_ht, fp_ht, hs_ht, fs_ht;
struct acpi_device *adev;
const char *uid;
Re: [PATCH v2] drm: mediatek: change the variable type of rdma threshold
Hi, Bibby:
One comment inline.
On Fri, 2017-05-19 at 17:57 +0800, Bibby Hsieh wrote:
> For some greater resolution, the rdma threshold
> variable will overflow.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 0df05f9..9afdcd7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -37,7 +37,7 @@
> #define DISP_REG_RDMA_FIFO_CON 0x0040
> #define RDMA_FIFO_UNDERFLOW_EN BIT(31)
> #define RDMA_FIFO_PSEUDO_SIZE(bytes) (((bytes) / 16) << 16)
> -#define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes) ((bytes) / 16)
> +#define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes) (((bytes) / 16) & 0x3ff)
I think it's not necessary to do this mask operation. Before calling
RDMA_OUTPUT_VALID_FIFO_THRESHOLD(), you should make sure that width,
height, and vrefresh matches the HW spec, so the result of threshold
likely does not exceed 0x3ff. If width, height, and vrefresh matches the
HW spec but threshold exceed 0x3ff, maybe you should limited it to 0x3ff
rather than truncating it.
Regards,
CK
>
> /**
> * struct mtk_disp_rdma - DISP_RDMA driver structure
> @@ -109,7 +109,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> unsigned int height, unsigned int vrefresh,
> unsigned int bpc)
> {
> - unsigned int threshold;
> + unsigned long long threshold;
> unsigned int reg;
>
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
> @@ -121,7 +121,8 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
>* output threshold to 6 microseconds with 7/6 overhead to
>* account for blanking, and with a pixel depth of 4 bytes:
>*/
> - threshold = width * height * vrefresh * 4 * 7 / 100;
> + threshold = (unsigned long long)width * height * vrefresh *
> + 4 * 7 / 100;
> reg = RDMA_FIFO_UNDERFLOW_EN |
> RDMA_FIFO_PSEUDO_SIZE(SZ_8K) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
Re: is alpha jensen support dead?
On Sun, May 21, 2017 at 1:58 AM, Christoph Hellwig wrote: > Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit 6aca0503847f6329460b15b3ab2b0e30bb752793 > Author: Christian Borntraeger > Date: Tue Feb 2 21:46:33 2016 -0800 > > alpha/dma: use common noop dma ops > > which switches pci-noop.c to use generic code, but fat fingered a symbol > and didn't wire up the Kconfig. > > Is there any value in keeping it alive? Especially as there probably > isn't any build coverage.. > > Btw, how well is alpha working these days? It looks like there hasn't > been any maintainer activity for about two years. I haven't had time for alpha stuff in quite a while. I've never even had a Jensen, so it's never been important to me personally.
[PATCH v2] nvme/pci: remap BAR0 to cover admin CQ doorbell for large stride
The existing driver initially maps 8192 bytes of BAR0 which is
intended to cover doorbells of admin SQ and CQ. However, if a
large stride, e.g. 10, is used, the doorbell of admin CQ will
be out of 8192 bytes. Consequently, a page fault will be raised
when the admin CQ doorbell is accessed in nvme_configure_admin_queue().
This patch fixes this issue by remapping BAR0 before accessing
admin CQ doorbell if the initial mapping is not enough.
Signed-off-by: Xu Yu
---
Changes since v1:
* Move the bar (re)mapping logic in nvme_dev_map(), nvme_configure_admin_queue()
and nvme_setup_io_queues() to a new helper nvme_remap_bar().
* Replace several magic numbers by PAGE_SIZE and the new NVME_REG_DBS.
---
drivers/nvme/host/pci.c | 63 -
include/linux/nvme.h| 1 +
2 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 9d4640a..84a254a 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -91,6 +91,7 @@ struct nvme_dev {
int q_depth;
u32 db_stride;
void __iomem *bar;
+ unsigned long bar_mapped_size;
struct work_struct reset_work;
struct work_struct remove_work;
struct timer_list watchdog_timer;
@@ -1316,6 +1317,30 @@ static int nvme_alloc_admin_tags(struct nvme_dev *dev)
return 0;
}
+static unsigned long db_bar_size(struct nvme_dev *dev, unsigned nr_io_queues)
+{
+ return NVME_REG_DBS + ((nr_io_queues + 1) * 8 * dev->db_stride);
+}
+
+static int nvme_remap_bar(struct nvme_dev *dev, unsigned long size)
+{
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+ if (size <= dev->bar_mapped_size)
+ return 0;
+ if (dev->bar)
+ iounmap(dev->bar);
+ dev->bar = ioremap(pci_resource_start(pdev, 0), size);
+ if (!dev->bar) {
+ dev->bar_mapped_size = 0;
+ return -ENOMEM;
+ }
+ dev->bar_mapped_size = size;
+ dev->dbs = dev->bar + NVME_REG_DBS;
+
+ return 0;
+}
+
static int nvme_configure_admin_queue(struct nvme_dev *dev)
{
int result;
@@ -1323,6 +1348,10 @@ static int nvme_configure_admin_queue(struct nvme_dev
*dev)
u64 cap = lo_hi_readq(dev->bar + NVME_REG_CAP);
struct nvme_queue *nvmeq;
+ result = nvme_remap_bar(dev, db_bar_size(dev, 0));
+ if (result < 0)
+ return result;
+
dev->subsystem = readl(dev->bar + NVME_REG_VS) >= NVME_VS(1, 1, 0) ?
NVME_CAP_NSSRC(cap) : 0;
@@ -1514,16 +1543,12 @@ static inline void nvme_release_cmb(struct nvme_dev
*dev)
}
}
-static size_t db_bar_size(struct nvme_dev *dev, unsigned nr_io_queues)
-{
- return 4096 + ((nr_io_queues + 1) * 8 * dev->db_stride);
-}
-
static int nvme_setup_io_queues(struct nvme_dev *dev)
{
struct nvme_queue *adminq = dev->queues[0];
struct pci_dev *pdev = to_pci_dev(dev->dev);
- int result, nr_io_queues, size;
+ int result, nr_io_queues;
+ unsigned long size;
nr_io_queues = num_online_cpus();
result = nvme_set_queue_count(&dev->ctrl, &nr_io_queues);
@@ -1542,20 +1567,15 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
nvme_release_cmb(dev);
}
- size = db_bar_size(dev, nr_io_queues);
- if (size > 8192) {
- iounmap(dev->bar);
- do {
- dev->bar = ioremap(pci_resource_start(pdev, 0), size);
- if (dev->bar)
- break;
- if (!--nr_io_queues)
- return -ENOMEM;
- size = db_bar_size(dev, nr_io_queues);
- } while (1);
- dev->dbs = dev->bar + 4096;
- adminq->q_db = dev->dbs;
- }
+ do {
+ size = db_bar_size(dev, nr_io_queues);
+ result = nvme_remap_bar(dev, size);
+ if (!result)
+ break;
+ if (!--nr_io_queues)
+ return -ENOMEM;
+ } while (1);
+ adminq->q_db = dev->dbs;
/* Deregister the admin queue's interrupt */
free_irq(pci_irq_vector(pdev, 0), adminq);
@@ -2061,8 +2081,7 @@ static int nvme_dev_map(struct nvme_dev *dev)
if (pci_request_mem_regions(pdev, "nvme"))
return -ENODEV;
- dev->bar = ioremap(pci_resource_start(pdev, 0), 8192);
- if (!dev->bar)
+ if (nvme_remap_bar(dev, NVME_REG_DBS + PAGE_SIZE))
goto release;
return 0;
diff --git a/include/linux/nvme.h b/include/linux/nvme.h
index b625bac..7715be4 100644
--- a/include/linux/nvme.h
+++ b/include/linux/nvme.h
@@ -101,6 +101,7 @@ enum {
NVME_REG_ACQ= 0x0030, /* Admin CQ Base Address */
NVME_REG_CMBLOC = 0x0038, /* Controller Memory Buffer
[PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()
From: Markus Elfring Date: Mon, 22 May 2017 06:42:33 +0200 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/net/usb/usbnet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 802ba68d37d1..b73c2a40501c 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -2129,6 +2129,6 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype, } - req = kmalloc(sizeof(struct usb_ctrlrequest), GFP_ATOMIC); + req = kmalloc(sizeof(*req), GFP_ATOMIC); if (!req) goto fail_free_buf; -- 2.13.0
[PATCH] cpufreq: dt: Set default policy->transition_delay_ns
The rate_limit_us for the schedutil governor is getting set to 500 ms by default for the ARM64 hikey board. And its way too much, even for the default value. Lets set the default transition_delay_ns to something more realistic (10 ms), while the userspace always have a chance to set something it wants. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq-dt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index c943787d761e..70eac3fd89ac 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -275,6 +275,9 @@ static int cpufreq_init(struct cpufreq_policy *policy) policy->cpuinfo.transition_latency = transition_latency; + /* Set the default transition delay to 10ms */ + policy->transition_delay_us = 10 * USEC_PER_MSEC; + return 0; out_free_cpufreq_table: -- 2.7.4
[PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()
From: Markus Elfring
Date: Mon, 22 May 2017 06:33:48 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
drivers/net/usb/usbnet.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 79048e72c1bd..802ba68d37d1 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -2124,10 +2124,7 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd,
u8 reqtype,
if (data) {
buf = kmemdup(data, size, GFP_ATOMIC);
- if (!buf) {
- netdev_err(dev->net, "Error allocating buffer"
- " in %s!\n", __func__);
+ if (!buf)
goto fail_free;
- }
}
--
2.13.0
[PATCH 0/2] usbnet: Adjustments for usbnet_write_cmd_async()
From: Markus Elfring Date: Mon, 22 May 2017 07:04:03 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/net/usb/usbnet.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) -- 2.13.0
[PATCH v2 1/4] mtd: mchp23k256: Add OF device ID table
This allows registering of this device via a Device Tree.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
---
Changes in v2
- collect review/test from Andrew
.../devicetree/bindings/mtd/microchip,mchp23k256.txt | 18 ++
drivers/mtd/devices/mchp23k256.c | 8
2 files changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
new file mode 100644
index ..25e5ad38b0f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -0,0 +1,18 @@
+* MTD SPI driver for Microchip 23K256 (and similar) serial SRAM
+
+Required properties:
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+- compatible : Must be "microchip,mchp23k256"
+- reg : Chip-Select number
+- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
+
+Example:
+
+ spi-sram@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "microchip,mchp23k256";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ };
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index e237db9f1bdb..9d8306a15833 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
struct mchp23k256_flash {
struct spi_device *spi;
@@ -166,9 +167,16 @@ static int mchp23k256_remove(struct spi_device *spi)
return mtd_device_unregister(&flash->mtd);
}
+static const struct of_device_id mchp23k256_of_table[] = {
+ { .compatible = "microchip,mchp23k256" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
+
static struct spi_driver mchp23k256_driver = {
.driver = {
.name = "mchp23k256",
+ .of_match_table = of_match_ptr(mchp23k256_of_table),
},
.probe = mchp23k256_probe,
.remove = mchp23k256_remove,
--
2.11.0.24.ge6920cf
[PATCH v2 0/4] mtd: mchp23k256: device tree and mchp23lcv1024
This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Chris Packham (4): mtd: mchp23k256: Add OF device ID table mtd: mchp23k256: switch to mtd_device_register() mtd: mchp23k256: add partitioning support mtd: mchp23k256: Add support for mchp23lcv1024 .../bindings/mtd/microchip,mchp23k256.txt | 18 ++ drivers/mtd/devices/mchp23k256.c | 69 ++ 2 files changed, 75 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt -- 2.11.0.24.ge6920cf
[PATCH v2 3/4] mtd: mchp23k256: add partitioning support
Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Additionally we must specify a non-zero erasesize for the partitions to be writeable. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect revew/test from Andrew drivers/mtd/devices/mchp23k256.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c index 2542f5b8b63f..02c6b9dcbd3e 100644 --- a/drivers/mtd/devices/mchp23k256.c +++ b/drivers/mtd/devices/mchp23k256.c @@ -143,6 +143,7 @@ static int mchp23k256_probe(struct spi_device *spi) data = dev_get_platdata(&spi->dev); + mtd_set_of_node(&flash->mtd, spi->dev.of_node); flash->mtd.dev.parent = &spi->dev; flash->mtd.type = MTD_RAM; flash->mtd.flags= MTD_CAP_RAM; @@ -151,6 +152,10 @@ static int mchp23k256_probe(struct spi_device *spi) flash->mtd._read= mchp23k256_read; flash->mtd._write = mchp23k256_write; + flash->mtd.erasesize = PAGE_SIZE; + while (flash->mtd.size & (flash->mtd.erasesize - 1)) + flash->mtd.erasesize >>= 1; + err = mtd_device_register(&flash->mtd, data ? data->parts : NULL, data ? data->nr_parts : 0); if (err) -- 2.11.0.24.ge6920cf
[PATCH v2 4/4] mtd: mchp23k256: Add support for mchp23lcv1024
The mchp23lcv1024 is software compatible with the mchp23k256, the
only difference (from a software point of view) is the size. There
is no way to detect the size so we must be told via a Device Tree.
Signed-off-by: Chris Packham
---
Changes in v2:
- fix formatting in switch statement
- add support for 24-bit addressing
.../bindings/mtd/microchip,mchp23k256.txt | 2 +-
drivers/mtd/devices/mchp23k256.c | 53 ++
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
index 25e5ad38b0f0..7328eb92a03c 100644
--- a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -3,7 +3,7 @@
Required properties:
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
-- compatible : Must be "microchip,mchp23k256"
+- compatible : Must be one of "microchip,mchp23k256" or
"microchip,mchp23lcv1024"
- reg : Chip-Select number
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 02c6b9dcbd3e..878f23955e29 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -21,10 +21,14 @@
#include
#include
+#define MAX_CMD_SIZE 4
+enum chips { mchp23k256, mchp23lcv1024 };
+
struct mchp23k256_flash {
struct spi_device *spi;
struct mutexlock;
struct mtd_info mtd;
+ u8 addr_width;
};
#define MCHP23K256_CMD_WRITE_STATUS0x01
@@ -34,22 +38,35 @@ struct mchp23k256_flash {
#define to_mchp23k256_flash(x) container_of(x, struct mchp23k256_flash, mtd)
+static void mchp23k256_addr2cmd(struct mchp23k256_flash *flash,
+ unsigned int addr, u8 *cmd)
+{
+ /* cmd[0] has opcode */
+ cmd[1] = addr >> (flash->addr_width * 8 - 8);
+ cmd[2] = addr >> (flash->addr_width * 8 - 16);
+ cmd[3] = addr >> (flash->addr_width * 8 - 24);
+}
+
+static int mchp23k256_cmdsz(struct mchp23k256_flash *flash)
+{
+ return 1 + flash->addr_width;
+}
+
static int mchp23k256_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const unsigned char *buf)
{
struct mchp23k256_flash *flash = to_mchp23k256_flash(mtd);
struct spi_transfer transfer[2] = {};
struct spi_message message;
- unsigned char command[3];
+ unsigned char command[MAX_CMD_SIZE];
spi_message_init(&message);
command[0] = MCHP23K256_CMD_WRITE;
- command[1] = to >> 8;
- command[2] = to;
+ mchp23k256_addr2cmd(flash, to, command);
transfer[0].tx_buf = command;
- transfer[0].len = sizeof(command);
+ transfer[0].len = mchp23k256_cmdsz(flash);
spi_message_add_tail(&transfer[0], &message);
transfer[1].tx_buf = buf;
@@ -73,17 +90,16 @@ static int mchp23k256_read(struct mtd_info *mtd, loff_t
from, size_t len,
struct mchp23k256_flash *flash = to_mchp23k256_flash(mtd);
struct spi_transfer transfer[2] = {};
struct spi_message message;
- unsigned char command[3];
+ unsigned char command[MAX_CMD_SIZE];
spi_message_init(&message);
memset(&transfer, 0, sizeof(transfer));
command[0] = MCHP23K256_CMD_READ;
- command[1] = from >> 8;
- command[2] = from;
+ mchp23k256_addr2cmd(flash, from, command);
transfer[0].tx_buf = command;
- transfer[0].len = sizeof(command);
+ transfer[0].len = mchp23k256_cmdsz(flash);
spi_message_add_tail(&transfer[0], &message);
transfer[1].rx_buf = buf;
@@ -128,6 +144,7 @@ static int mchp23k256_probe(struct spi_device *spi)
struct mchp23k256_flash *flash;
struct flash_platform_data *data;
int err;
+ enum chips chip;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
if (!flash)
@@ -143,15 +160,30 @@ static int mchp23k256_probe(struct spi_device *spi)
data = dev_get_platdata(&spi->dev);
+ if (spi->dev.of_node)
+ chip = (enum chips)of_device_get_match_data(&spi->dev);
+ else
+ chip = mchp23k256;
+
mtd_set_of_node(&flash->mtd, spi->dev.of_node);
flash->mtd.dev.parent = &spi->dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
flash->mtd.writesize= 1;
- flash->mtd.size = SZ_32K;
flash->mtd._read= mchp23k256_read;
flash->mtd._write = mchp23k256_write;
+ switch (chip) {
+ case mchp23lcv1024:
+ flash->mtd.size = SZ_128K;
+ flash->addr_width = 3;
[PATCH v2 2/4] mtd: mchp23k256: switch to mtd_device_register()
Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from Andrew drivers/mtd/devices/mchp23k256.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c index 9d8306a15833..2542f5b8b63f 100644 --- a/drivers/mtd/devices/mchp23k256.c +++ b/drivers/mtd/devices/mchp23k256.c @@ -151,9 +151,8 @@ static int mchp23k256_probe(struct spi_device *spi) flash->mtd._read= mchp23k256_read; flash->mtd._write = mchp23k256_write; - err = mtd_device_parse_register(&flash->mtd, NULL, NULL, - data ? data->parts : NULL, - data ? data->nr_parts : 0); + err = mtd_device_register(&flash->mtd, data ? data->parts : NULL, + data ? data->nr_parts : 0); if (err) return err; -- 2.11.0.24.ge6920cf
[PATCH v3 2/2] arm64: dts: add sp804 timer node for Hi3660
The Hi3660 SoC comes with the sp804 timer in addition to the
architecture timers. These ones are shutdown when reaching a deep idle
states and a backup timer is needed. The sp804 belongs to another power
domain and can fulfill the purpose of replacing temporarily an
architecture timer when the CPU is idle.
Describe it in the device tree, so it can be enabled at boot time.
Suggested-by: Daniel Lezcano
Acked-by: Daniel Lezcano
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 138fcba..f75c792 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -173,6 +173,17 @@
#clock-cells = <1>;
};
+ dual_timer0: timer@fff14000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x0 0xfff14000 0x0 0x1000>;
+ interrupts = ,
+;
+ clocks = <&crg_ctrl HI3660_OSC32K>,
+<&crg_ctrl HI3660_OSC32K>,
+<&crg_ctrl HI3660_OSC32K>;
+ clock-names = "timer1", "timer2", "apb_pclk";
+ };
+
ufs: ufs@ff3b {
compatible = "jedec,ufs-1.1", "hisilicon,hi3660-ufs";
reg = <0x0 0xff3b 0x0 0x1000>, /* 0: HCI standard */
--
1.9.1
[PATCH v3 1/2] clk: Hi3660: register fixed_rate_clks with CLK_OF_DECLARE_DRIVER
The timer will register into system at very early phase at kernel boot;
if timer needs to use clock, the clock should be get ready in function
of_clk_init() so later the timer driver probe can retrieve clock
successfully. This is finished in below flow on arm64:
start_kernel()
`-> time_init()
`-> of_clk_init(NULL)=> register timer's clock
`-> clocksource_probe() => register timer
On Hi3660 the sp804 timer uses clock "osc32k", this clock is registered
as platform driver rather than CLK_OF_DECLARE_DRIVER method. As result,
sp804 timer probe returns failure due if cannot bind clock properly.
To fix the failure, this patch is to split crgctrl clocks into two
subsets. One part is for fixed_rate_clks which includes pre-defined
fixed rate clocks, and "osc32k" clock is in this category; So we change
their registration to CLK_OF_DECLARE_DRIVER method, as result the clocks
can be registered ahead with function of_clk_init() and timer driver can
bind timer clock successfully; the rest of the crgctrl clocks are still
registered by the probe of the platform driver.
This patch also adds checking for all crgctrl clocks registration and
print out log if any clock has failure.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/clk-hi3660.c | 48 ++
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/hisilicon/clk-hi3660.c
b/drivers/clk/hisilicon/clk-hi3660.c
index fd5ce7f..271008b 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -452,6 +452,8 @@
CLK_SET_RATE_PARENT, 0x90, 0, 0, },
};
+static struct hisi_clock_data *clk_crgctrl_data;
+
static void hi3660_clk_iomcu_init(struct device_node *np)
{
struct hisi_clock_data *clk_data;
@@ -514,38 +516,64 @@ static void hi3660_clk_sctrl_init(struct device_node *np)
clk_data);
}
-static void hi3660_clk_crgctrl_init(struct device_node *np)
+static void hi3660_clk_crgctrl_early_init(struct device_node *np)
{
- struct hisi_clock_data *clk_data;
int nr = ARRAY_SIZE(hi3660_fixed_rate_clks) +
ARRAY_SIZE(hi3660_crgctrl_gate_sep_clks) +
ARRAY_SIZE(hi3660_crgctrl_gate_clks) +
ARRAY_SIZE(hi3660_crgctrl_mux_clks) +
ARRAY_SIZE(hi3660_crg_fixed_factor_clks) +
ARRAY_SIZE(hi3660_crgctrl_divider_clks);
+ int i;
- clk_data = hisi_clk_init(np, nr);
- if (!clk_data)
+ clk_crgctrl_data = hisi_clk_init(np, nr);
+ if (!clk_crgctrl_data)
return;
+ for (i = 0; i < nr; i++)
+ clk_crgctrl_data->clk_data.clks[i] = ERR_PTR(-EPROBE_DEFER);
+
hisi_clk_register_fixed_rate(hi3660_fixed_rate_clks,
ARRAY_SIZE(hi3660_fixed_rate_clks),
-clk_data);
+clk_crgctrl_data);
+}
+CLK_OF_DECLARE_DRIVER(hi3660_clk_crgctrl, "hisilicon,hi3660-crgctrl",
+ hi3660_clk_crgctrl_early_init);
+
+static void hi3660_clk_crgctrl_init(struct device_node *np)
+{
+ struct clk **clks;
+ int i;
+
+ if (!clk_crgctrl_data)
+ hi3660_clk_crgctrl_early_init(np);
+
+ /* clk_crgctrl_data initialization failed */
+ if (!clk_crgctrl_data)
+ return;
+
hisi_clk_register_gate_sep(hi3660_crgctrl_gate_sep_clks,
ARRAY_SIZE(hi3660_crgctrl_gate_sep_clks),
- clk_data);
+ clk_crgctrl_data);
hisi_clk_register_gate(hi3660_crgctrl_gate_clks,
ARRAY_SIZE(hi3660_crgctrl_gate_clks),
- clk_data);
+ clk_crgctrl_data);
hisi_clk_register_mux(hi3660_crgctrl_mux_clks,
ARRAY_SIZE(hi3660_crgctrl_mux_clks),
- clk_data);
+ clk_crgctrl_data);
hisi_clk_register_fixed_factor(hi3660_crg_fixed_factor_clks,
ARRAY_SIZE(hi3660_crg_fixed_factor_clks),
- clk_data);
+ clk_crgctrl_data);
hisi_clk_register_divider(hi3660_crgctrl_divider_clks,
ARRAY_SIZE(hi3660_crgctrl_divider_clks),
- clk_data);
+ clk_crgctrl_data);
+
+ clks = clk_crgctrl_data->clk_data.clks;
+ for (i = 0; i < clk_crgctrl_data->clk_data.clk_num; i++) {
+ if (IS_ERR(clks[i]) && PTR_ERR(clks[i]) != -EPROBE_DEFER)
+ pr_err("Failed to register crgctrl clock[%d] err=%ld\n",
+ i, PTR_ERR(clks[i]));
+ }
}
static const struct of_device_id hi3660_clk_match_table[] = {
--
1.9.1
[PATCH v3 0/2] Hi3660: enable sp804 timer
This patch set is to enable sp804 timer on Hi3660 for Hikey960 platform. On Hi3660, the sp804 timer co-exists with CPUs' architecture timer; but sp804 timer is located in SoC level but CPU's architecture timer is in CPU power domain. sp804 timer is used as broadcast timer when CPU enters idle states and the CPU (includes architecture timer) power domain is powered off. So sp804 timer enabling is prerequisite before we enable CPUIdle on Hi3660. This patch set is to enable sp804 timer, the first patch is to adjust subset of crgctrl clock regiseration to CLK_OF_DECLARE_DRIVER method so ensure timer clock is avaiable when timer probing. The second patch is to add description for timer in dts. Have rebased this patch set on Guodong's dts patch set [1] and verified this patch set on Hikey960. [1] http://archive.armlinux.org.uk/lurker/message/20170517.083733.8207a50e.en.html Changes from v2: * According to Stephen's suggestion, only changed necessary clocks of fixed_rate_clks to CLK_OF_DECLARE_DRIVER method. Changes from v1: * Follow Steven's suggestion on IRC, Change to only use CLK_OF_DECLARE_DRIVER for crgctrl clock. Leo Yan (2): clk: Hi3660: register fixed_rate_clks with CLK_OF_DECLARE_DRIVER arm64: dts: add sp804 timer node for Hi3660 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 11 +++ drivers/clk/hisilicon/clk-hi3660.c| 48 --- 2 files changed, 49 insertions(+), 10 deletions(-) -- 1.9.1
Re: CHIPPro NAND issue with 4.12 rc1
On 2017-05-20 23:45, Boris Brezillon wrote:
Le Sat, 20 May 2017 15:24:06 -0600,
Angus Ainslie a écrit :
On 2017-05-20 09:14, Boris Brezillon wrote:
> Le Sat, 20 May 2017 08:49:04 -0600,
> Angus Ainslie a écrit :
>
>> Hi All,
>>
>> I'm trying to boot a CHIPPro with the stock 4.12 rc1 kernel. If I make
>> no modifications to the sun5i-gr8-chip-pro.dtb the kernel boots but
>> can't find the root partition.
>>
>> So I added the partitions to the dts file
>>
>> diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
>> b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
>> index c55b11a..0e61e6b 100644
>> --- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
>> +++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
>> @@ -146,6 +146,32 @@
>> reg = <0>;
>> allwinner,rb = <0>;
>> nand-ecc-mode = "hw";
>> +nand-on-flash-bbt;
>> +
>> +spl@0 {
>> + label = "SPL";
>> + reg = /bits/ 64 <0x0 0x40>;
>> +};
>> +
>> +spl-backup@40 {
>> + label = "SPL.backup";
>> + reg = /bits/ 64 <0x40 0x40>;
>> +};
>> +
>> +u-boot@80 {
>> + label = "U-Boot";
>> + reg = /bits/ 64 <0x80 0x40>;
>> +};
>> +
>> +env@c0 {
>> + label = "env";
>> + reg = /bits/ 64 <0xc0 0x40>;
>> +};
>> +
>> +rootfs@100 {
>> + label = "rootfs";
>> + reg = /bits/ 64 <0x100 0x1f00>;
>> +};
>> };
>> };
>>
>> and now the kernel finds the partition but it times out trying to
>> mount
>> it. It seems to be something in the dts files because if I use the
>> ntc-gr8-crumb.dts from the ntc 4.4.30 kernel then the system boots all
>> the way to userland.
>
> Hm, that's weird. Just changing the dtb makes it work? Did you try to
> dump both dtbs and figure out what else changes?
>
Yeah I thought it was weird too. I was thinking that maybe the pin
muxes
were getting changed and the rb net or the interrupt net was getting
changed to a different function.
I did decompile to 2 dtb's and I couldn't find many differences. They
were mostly around some pull ups and drive strength for some of the
NAND
and i2c pins. I tried adding those changes and it still didn't work so
I
went back to the minimal set of changes to reproduce the bug.
> Also, I wonder how the NAND is correctly detected without this patch
> [1].
>
That patch seems to be in my 4.12-rc1 kernel, I have a definition for
the TC58NVG2S0H.
>>
>> [7.13] ubi0: scanning is finished
>> [7.15] ubi0: attached mtd4 (name "rootfs", size 496 MiB)
>> [7.16] ubi0: PEB size: 262144 bytes (256 KiB), LEB size:
>> 258048
>> bytes
>> [7.17] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page
>> size
>> 1024
>> [7.18] ubi0: VID header offset: 1024 (aligned 1024), data
>> offset: 4096
>> [7.19] ubi0: good PEBs: 1977, bad PEBs: 7, corrupted PEBs: 0
>> [7.20] ubi0: user volume: 1, internal volumes: 1, max. volumes
>> count: 128
>> [7.21] ubi0: max/mean erase counter: 3/1, WL threshold: 4096,
>> image sequence number: 177407
>> [7.22] ubi0: available PEBs: 1, total reserved PEBs: 1976,
>> PEBs
>> reserved for bad PEB handling: 33
>
> UBI attach works...
>
>> [7.24] hctosys: unable to open rtc device (rtc0)
>> [7.25] vcc3v0: disabling
Interestingly, it starts failing after the core disables all unused
regulators. Not sure this is related but that's worth having a look.
I looked at the schematics and it seems VCC-3V3 (which is powering the
NAND chip) is enabled with the EXTEN pin of the AXP209 [1]. I don't
know
if this pin is controlled by Linux, but maybe you can dump register
0x12 and check if EXTEN is set to 1.
I didn't manage to dump the register but I did go in and turn vcc3v0 and
vcc3v3 to regulator-always-on and added another change from the
ntc-gr8-crumb dts file to couple the two 3v3 regulators.
diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
index c55b11a..6744e78 100644
--- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
@@ -83,6 +83,18 @@
pinctrl-0 = <&wifi_reg_on_pin_chip_pro>;
reset-gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; /* PB10 */
};
+
+ /*
+ * Both LDO3 and LDO4 are used in parallel to power up the
+ * WiFi/BT Chip.
+ */
+ vcc_wifi: wifi_reg {
+compatible = "coupled-voltage-regulator";
+regulator-name = "vcc-wifi";
+vin0-supply = <®_ldo3>;
+vin1-supply = <®_ldo4>;
+ };
+
};
&codec {
@@ -128,7 +140,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
- vmmc-supply = <®_vcc3v3>;
+ vmmc-supply = <&vcc_wifi>;
mmc-pwrseq = <&mmc0_pwrseq>;
bus-width = <4>;
non-removable;
@@ -146,6 +158,32 @@
reg = <0>;
allwinner,rb = <0>;
nand-ecc-mode = "hw";
+nand-on-flash-bbt;
+
+
[PATCH linux-next 1/1] spi: imx: only allow dynamic burst in PIO mode
Currently only PIO mode supports dynamic burst length adjust, in DMA mode, bpw (bytes per word) value still has to be used as burst length, other wise transfer issue will be caused. This patch avoid using dynamic burst in DMA mode by set reset dynamic_burst when DMA mode is used. Signed-off-by: Jiada Wang Reported-and-tested-by: Fabio Estevam --- drivers/spi/spi-imx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 19b30cf..2768e64 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -242,6 +242,7 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi, return false; spi_imx->wml = i; + spi_imx->dynamic_burst = 0; return true; } -- 2.9.3
Re: [PATCH 3/4] mtd: mchp23k256: add partitioning support
On 18/05/17 03:29, Boris Brezillon wrote:
> Hi Chris,
>
> On Wed, 17 May 2017 17:39:07 +1200
> Chris Packham wrote:
>
>> Setting the of_node for the mtd device allows the generic mtd code to
>> setup the partitions. Additionally we must specify a non-zero erasesize
>> for the partitions to be writeable.
>>
>> Signed-off-by: Chris Packham
>> ---
>> drivers/mtd/devices/mchp23k256.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/mchp23k256.c
>> b/drivers/mtd/devices/mchp23k256.c
>> index 2542f5b8b63f..02c6b9dcbd3e 100644
>> --- a/drivers/mtd/devices/mchp23k256.c
>> +++ b/drivers/mtd/devices/mchp23k256.c
>> @@ -143,6 +143,7 @@ static int mchp23k256_probe(struct spi_device *spi)
>>
>> data = dev_get_platdata(&spi->dev);
>>
>> +mtd_set_of_node(&flash->mtd, spi->dev.of_node);
>> flash->mtd.dev.parent = &spi->dev;
>> flash->mtd.type = MTD_RAM;
>> flash->mtd.flags= MTD_CAP_RAM;
>> @@ -151,6 +152,10 @@ static int mchp23k256_probe(struct spi_device *spi)
>> flash->mtd._read= mchp23k256_read;
>> flash->mtd._write = mchp23k256_write;
>>
>> +flash->mtd.erasesize = PAGE_SIZE;
>> +while (flash->mtd.size & (flash->mtd.erasesize - 1))
>> +flash->mtd.erasesize >>= 1;
>> +
>
> Can we fix allocate_partition() to properly handle the
> master->erasesize == 0 case instead of doing that?
>
Do you mean something like this?
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index ea5e5307f667..0cd20ed6b374 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -577,6 +577,7 @@ static struct mtd_part *allocate_partition(struct
mtd_info *master,
part->name);
}
if ((slave->mtd.flags & MTD_WRITEABLE) &&
+ master->erasesize != 0 &&
mtd_mod_by_eb(slave->mtd.size, &slave->mtd)) {
slave->mtd.flags &= ~MTD_WRITEABLE;
I'm happy to submit this as a formal patch but it could potentially
affect a number of devices. Whereas the snippet I initially added is
consistent with drivers/mtd/chips/map_ram.c.
For now I'll leave v2 as-is but I can send a v3 if needed.
[PATCH] ocfs2: fix a static checker warning
This patch will fix a static checker warning, this warning was
caused by commit d56a8f32e4c662509ce50a37e78fa66c777977d3. after
apply this patch, the error return value will not be NULL(zero).
Signed-off-by: Gang He
---
fs/ocfs2/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index 382401d..1a1e007 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -136,7 +136,7 @@ struct inode *ocfs2_ilookup(struct super_block *sb, u64
blkno)
struct inode *ocfs2_iget(struct ocfs2_super *osb, u64 blkno, unsigned flags,
int sysfile_type)
{
- int rc = 0;
+ int rc = -ESTALE;
struct inode *inode = NULL;
struct super_block *sb = osb->sb;
struct ocfs2_find_inode_args args;
--
1.8.5.6
Re: [PATCH 4/6] ubifs: Maintain a parent pointer
Hi Richard,
On Sun, May 21, 2017 at 10:20:49PM +0200, Richard Weinberger wrote:
> The new feature UBIFS_FLG_PARENTPOINTER allows looking
> up the parent. Usually the Linux VFS walks down the filesystem
> and no parent pointers are needed. But when a filesystem
> is exportable via NFS such a lookup is needed.
> We can use a padding field in struct ubifs_ino_node to
> maintain a pointer to the parent inode.
>
> Signed-off-by: Richard Weinberger
> ---
> fs/ubifs/dir.c | 21 +++--
> fs/ubifs/journal.c | 5 -
> fs/ubifs/sb.c | 2 ++
> fs/ubifs/super.c | 1 +
> fs/ubifs/ubifs-media.h | 12 +---
> fs/ubifs/ubifs.h | 4
> 6 files changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
> index e79b529df9c3..a6eadb52a1a8 100644
> --- a/fs/ubifs/dir.c
> +++ b/fs/ubifs/dir.c
> @@ -171,6 +171,7 @@ struct inode *ubifs_new_inode(struct ubifs_info *c,
> struct inode *dir,
> }
>
> inode->i_ino = ++c->highest_inum;
> + ui->parent_inum = dir->i_ino;
> /*
>* The creation sequence number remains with this inode for its
>* lifetime. All nodes for this inode have a greater sequence number,
> @@ -1374,7 +1375,7 @@ static int do_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> if (unlink)
> ubifs_assert(inode_is_locked(new_inode));
>
> - if (old_dir != new_dir) {
> + if (move) {
> if (ubifs_crypt_is_encrypted(new_dir) &&
> !fscrypt_has_permitted_context(new_dir, old_inode))
> return -EPERM;
> @@ -1528,8 +1529,12 @@ static int do_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> mark_inode_dirty(whiteout);
> whiteout->i_state &= ~I_LINKABLE;
> iput(whiteout);
> + whiteout_ui->parent_inum = new_dir->i_ino;
> }
>
> + if (move)
> + old_inode_ui->parent_inum = new_dir->i_ino;
> +
> err = ubifs_jnl_rename(c, old_dir, old_inode, &old_nm, new_dir,
> new_inode, &new_nm, whiteout, sync);
I think that old_inode_ui->parent_inum could point old_dir, even though
old_inode
is a child of new_dir. this could happen that there is power-cut before
old_inode is synced. so I guess that old_inode is needed to be written with
rename's node group in ubifs_jnl_rename. is it right?
> if (err)
> @@ -1571,6 +1576,8 @@ static int do_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> inc_nlink(old_dir);
> }
> }
> + if (move)
> + old_inode_ui->parent_inum = old_dir->i_ino;
> if (whiteout) {
> drop_nlink(whiteout);
> iput(whiteout);
> @@ -1592,6 +1599,8 @@ static int ubifs_xrename(struct inode *old_dir, struct
> dentry *old_dentry,
> int sync = IS_DIRSYNC(old_dir) || IS_DIRSYNC(new_dir);
> struct inode *fst_inode = d_inode(old_dentry);
> struct inode *snd_inode = d_inode(new_dentry);
> + struct ubifs_inode *fst_inode_ui = ubifs_inode(fst_inode);
> + struct ubifs_inode *snd_inode_ui = ubifs_inode(snd_inode);
> struct timespec time;
> int err;
> struct fscrypt_name fst_nm, snd_nm;
> @@ -1623,7 +1632,10 @@ static int ubifs_xrename(struct inode *old_dir, struct
> dentry *old_dentry,
> old_dir->i_mtime = old_dir->i_ctime = time;
> new_dir->i_mtime = new_dir->i_ctime = time;
>
> - if (old_dir != new_dir) {
> + if (new_dir != old_dir) {
> + fst_inode_ui->parent_inum = new_dir->i_ino;
> + snd_inode_ui->parent_inum = old_dir->i_ino;
> +
> if (S_ISDIR(fst_inode->i_mode) && !S_ISDIR(snd_inode->i_mode)) {
> inc_nlink(new_dir);
> drop_nlink(old_dir);
> @@ -1637,6 +1649,11 @@ static int ubifs_xrename(struct inode *old_dir, struct
> dentry *old_dentry,
> err = ubifs_jnl_xrename(c, old_dir, fst_inode, &fst_nm, new_dir,
> snd_inode, &snd_nm, sync);
>
> + if (err && new_dir != old_dir) {
> + fst_inode_ui->parent_inum = old_dir->i_ino;
> + snd_inode_ui->parent_inum = new_dir->i_ino;
> + }
> +
> unlock_4_inodes(old_dir, new_dir, NULL, NULL);
> ubifs_release_budget(c, &req);
>
> diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
> index 294519b98874..8eaf8f2f1fe1 100644
> --- a/fs/ubifs/journal.c
> +++ b/fs/ubifs/journal.c
> @@ -66,7 +66,6 @@
> */
> static inline void zero_ino_node_unused(struct ubifs_ino_node *ino)
> {
> - memset(ino->padding1, 0, 4);
> memset(ino->padding2, 0, 26);
> }
>
> @@ -470,6 +469,10 @@ static void pack_inode(struct ubifs_info *c, struct
> ubifs_ino_node *ino,
> ino->xattr_cnt = cpu_to_le32(ui->xattr_cnt);
> ino->xattr_size = cpu_to_le32(ui->xattr_size);
> ino->xattr_names = cpu_to_le32(ui->xattr_names)
Re: [PATCH 2/3] regulator: lp87565: Add support for lp87565 PMIC regulators
On Friday 19 May 2017 09:23 PM, Andrew F. Davis wrote:
> On 05/19/2017 07:42 AM, Keerthy wrote:
>> The regulators set consists of 4 BUCKs. The output
>> voltages are configurable and are meant to supply power to the
>> main processor and other components. The ramp delay is configurable
>> for all BUCKs. The BUCKs can be configured in single phase or
>> multiphase modes.
>>
>> Signed-off-by: Keerthy
>> ---
>> drivers/regulator/Kconfig | 8 ++
>> drivers/regulator/Makefile| 1 +
>> drivers/regulator/lp87565-regulator.c | 244
>> ++
>> 3 files changed, 253 insertions(+)
>> create mode 100644 drivers/regulator/lp87565-regulator.c
>>
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 48db87d..7c34ff8 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -365,6 +365,14 @@ config REGULATOR_LP8755
>>chip contains six step-down DC/DC converters which can support
>>9 mode multiphase configuration.
>>
>> +config REGULATOR_LP87565
>> +tristate "TI LP87565 Power regulators"
>> +depends on MFD_TI_LP87565 && OF
>> +help
>> + This driver supports LP87565 voltage regulator chips. LP87565
>> + provides four step-down converters. It supports software based
>> + voltage control for different voltage domains
>> +
>> config REGULATOR_LP8788
>> tristate "TI LP8788 Power Regulators"
>> depends on MFD_LP8788
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index dc3503f..fee6b8c 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -46,6 +46,7 @@ obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
>> obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
>> obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
>> obj-$(CONFIG_REGULATOR_LP873X) += lp873x-regulator.o
>> +obj-$(CONFIG_REGULATOR_LP87565) += lp87565-regulator.o
>> obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
>> obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
>> obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
>> diff --git a/drivers/regulator/lp87565-regulator.c
>> b/drivers/regulator/lp87565-regulator.c
>> new file mode 100644
>> index 000..5849cf3
>> --- /dev/null
>> +++ b/drivers/regulator/lp87565-regulator.c
>> @@ -0,0 +1,244 @@
>> +/*
>> + * Regulator driver for LP87565 PMIC
>> + *
>> + * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether expressed or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License version 2 for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#define LP87565_REGULATOR(_name, _id, _of, _ops, _n, _vr, _vm, _er, _em, \
>> + _delay, _lr, _cr) \
>> +[_id] = { \
>> +.desc = { \
>> +.name = _name,\
>> +.supply_name= _of "-in",\
>> +.id = _id, \
>> +.of_match = of_match_ptr(_of),\
>> +.regulators_node= of_match_ptr("regulators"),\
>> +.ops= &_ops,\
>> +.n_voltages = _n, \
>> +.type = REGULATOR_VOLTAGE,\
>> +.owner = THIS_MODULE, \
>> +.vsel_reg = _vr, \
>> +.vsel_mask = _vm, \
>> +.enable_reg = _er, \
>> +.enable_mask= _em, \
>> +.ramp_delay = _delay, \
>> +.linear_ranges = _lr, \
>> +.n_linear_ranges= ARRAY_SIZE(_lr), \
>> +}, \
>> +.ctrl2_reg = _cr, \
>> +}
>> +
>> +#define LP87565_Q1_MIN_IDX LP87565_BUCK_10
>
> Unused?
Yes! Thanks for catching it.
>
>> +
>> +struct lp87565_regulator {
>> +struct regulator_desc desc;
>> +unsigned int ctrl2_reg;
>> +};
>> +
>> +static const struct lp87565_regulator regulators[];
>> +
>> +static const struct regulator_linear_range bu
Re: [PATCH 1/3] mfd: lp87565: Add lp87565 PMIC support
On Friday 19 May 2017 09:12 PM, Andrew F. Davis wrote:
> On 05/19/2017 07:42 AM, Keerthy wrote:
>> The LP87565 chip is a power management IC for Portable Navigation Systems
>> and Tablet Computing devices. It contains the following components:
>>
>> - Configurable Bucks(Single and multi-phase).
>> - Configurable General Purpose Output Signals (GPO).
>>
>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>> output.
>>
>> Signed-off-by: Keerthy
>> ---
>> Documentation/devicetree/bindings/mfd/lp87565.txt | 44
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/lp87565.c | 103
>> include/linux/mfd/lp87565.h | 275
>> ++
>> 5 files changed, 437 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>> create mode 100644 drivers/mfd/lp87565.c
>> create mode 100644 include/linux/mfd/lp87565.h
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt
>> b/Documentation/devicetree/bindings/mfd/lp87565.txt
>> new file mode 100644
>> index 000..38a00a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
>> @@ -0,0 +1,44 @@
>> +TI LP873565 PMIC MFD driver
>> +
>> +Required properties:
>> + - compatible: "ti,lp87565", "ti,lp87565-q1"
>
> The of_device_id table in the driver only seems to match for
> "ti,lp87565-q1", not "ti,lp87565".
I will add both. ti,lp87565 is the generic one and the ti,lp87565-q1 is
a specific one with dual phase regulators.
>
>> + - reg:I2C slave address.
>> + - gpio-controller:Marks the device node as a GPIO Controller.
>> + - #gpio-cells:Should be two. The first cell is the pin number and
>> +the second cell is used to specify flags.
>> +See ../gpio/gpio.txt for more information.
>> + - xxx-in-supply: Phandle to parent supply node of each regulator
>> +populated under regulators node. xxx should match
>> +the supply_name populated in driver.
>> + - regulators: List of child nodes that specify the regulator
>> +initialization data.
>> +Example:
>> +
>> +lp87565: lp87565@60 {
>
> pmic: lp87565@60 {
>
> Is more standard.
Sure. I will change that.
Thanks for reviewing.
>
>> +compatible = "ti,lp87565-q1";
>> +reg = <0x60>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +
>> +buck10-in-supply =<&vsys_3v3>;
>> +buck23-in-supply =<&vsys_3v3>;
>> +regulators: regulators {
>> +buck10_reg: buck10 {
>> +/*VDD_MPU*/
>> +regulator-name = "buck10";
>> +regulator-min-microvolt = <85>;
>> +regulator-max-microvolt = <125>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +};
>> +
>> +buck23_reg: buck23 {
>> +/* VDD_GPU*/
>> +regulator-name = "buck23";
>> +regulator-min-microvolt = <85>;
>> +regulator-max-microvolt = <125>;
>> +regulator-boot-on;
>> +regulator-always-on;
>> +};
>> +};
>> +};
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 3eb5c93..5e884f3 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1325,6 +1325,20 @@ config MFD_TI_LP873X
>>This driver can also be built as a module. If so, the module
>>will be called lp873x.
>>
>> +config MFD_TI_LP87565
>> +tristate "TI LP87565 Power Management IC"
>> +depends on I2C
>> +select MFD_CORE
>> +select REGMAP_I2C
>> +help
>> + If you say yes here then you get support for the LP87565 series of
>> + Power Management Integrated Circuits (PMIC).
>> + These include voltage regulators, thermal protection, configurable
>> + General Purpose Outputs (GPO) that are used in portable devices.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called lp87565.
>> +
>> config MFD_TPS65218
>> tristate "TI TPS65218 Power Management chips"
>> depends on I2C
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index c16bf1e..7edbe1b 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -25,6 +25,7 @@ obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o
>> obj-$(CONFIG_HTC_I2CPLD)+= htc-i2cpld.o
>>
>> obj-$(CONFIG_MFD_TI_LP873X) += lp873x.o
>> +obj-$(CONFIG_MFD_TI_LP87565)+= lp87565.o
>>
>> obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)+= davinci_voicecodec.o
>> obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
>> diff --git a/drivers/mfd/lp87565.c b/drivers/m
Re: linux-next: build failure after merge of the net-next tree
On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use
> in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
>
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped
> packets")
>
> This probably broke every architecture that has its own
> arch//include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
Indeed. I added the architecture specific versions in patch
http://patchwork.ozlabs.org/patch/765238/
That fixes the powerpc build for me. The new option is now
defined in every file that also defines the last added such
option SCM_TIMESTAMPING_OPT_STATS. Apologies for
missing this earlier.
Re: linux-next: build failure after merge of the net-next tree
Hi Dave,
On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller
wrote:
>
> From: Stephen Rothwell
> Date: Mon, 22 May 2017 11:16:05 +1000
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > net/socket.c: In function 'put_ts_pktinfo':
> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first
> > use in this function)
> > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> > ^
> > Caused by commit
> >
> > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped
> > packets")
> >
> > This probably broke every architecture that has its own
> > arch//include/uapi/asm/socket.h that does not include
> > include/uapi/asm-generic/socket.h :-(
> >
> > I have used the net-next tree from next-20170519 for today.
>
> I've just pushed the following, thanks for the report:
Looks good except:
> diff --git a/arch/parisc/include/uapi/asm/socket.h
> b/arch/parisc/include/uapi/asm/socket.h
> index 5147018..784b871 100644
> --- a/arch/parisc/include/uapi/asm/socket.h
> +++ b/arch/parisc/include/uapi/asm/socket.h
> @@ -97,4 +97,6 @@
>
> #define SO_COOKIE0x4032
>
> +#define SCM_TIMESTAMPING_PKTINFO 58
Does this need to be 0x4033 (or something)?
--
Cheers,
Stephen Rothwell
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm64/include/asm/cpufeature.h
between commit:
63a1e1c95e60 ("arm64/cpufeature: don't use mutex in bringup path")
from Linus' tree and commit:
d54bb72551b9 ("arm64/cpufeature: Use static_branch_enable_cpuslocked()")
from the tip tree.
I have no idea what the correct resolution is here, so I have just gone
with the former for now (i.e. removed the
static_branch_enable_cpuslocked() call). This will probably need a
better (or even correct :-)) fix.
I fixed it up (see above) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
Re: [PATCH v3 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
On Sat, 2017-05-20 at 15:46 -0400, Paul Gortmaker wrote:
> On Tue, May 9, 2017 at 10:06 PM, Ryder Lee wrote:
> > Add support for the Mediatek PCIe Gen2 controller which can
> > be found on MT7623 series SoCs.
> >
> > Signed-off-by: Ryder Lee
> > ---
> > drivers/pci/host/Kconfig | 11 +
> > drivers/pci/host/Makefile| 1 +
> > drivers/pci/host/pcie-mediatek.c | 563
> > +++
> > 3 files changed, 575 insertions(+)
> > create mode 100644 drivers/pci/host/pcie-mediatek.c
> >
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index f7c1d4d..aef0de9 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -174,6 +174,17 @@ config PCIE_ROCKCHIP
> > There is 1 internal PCIe port available to support GEN2 with
> > 4 slots.
> >
> > +config PCIE_MEDIATEK
> > + bool "Mediatek PCIe controller"
>
> You've got bool here and correctly use the builtin register
> function, but you still have a couple stray references to
> the module.h header and MODULE macros. Can you
> please also clean them up and resend with those gone?
>
> Thanks,
> Paul.
> --
> > +#include
> > +#include
>
> []
>
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_pcie_ids);
> > +
> > +static struct platform_driver mtk_pcie_driver = {
> > + .probe = mtk_pcie_probe,
> > + .driver = {
> > + .name = "mtk-pcie",
> > + .of_match_table = mtk_pcie_ids,
> > + .suppress_bind_attrs = true,
> > + },
> > +};
> > +
> > +builtin_platform_driver(mtk_pcie_driver);
> > +
> > +MODULE_DESCRIPTION("Mediatek PCIe host controller driver.");
> > +MODULE_LICENSE("GPL v2");
I've already removed them at patch v5. Thanks a lot, Paul!
Re: [for-next][PATCH 09/33] selftests: ftrace: Add test to test reading of set_ftrace_file
Hi Steve,
On Fri, 21 Apr 2017 17:30:29 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> The set_ftrace_file lists both functions that are filtered, as well as
> function probes (triggers) that are attached to a function, like traceon or
> stacktrace, etc. The reading of this file is not as trivial as most pseudo
> files are, and there's been various bugs that have appeared in the past
> when there's a mix of probes and functions listed. There's also a difference
> when reading the file using dd with a block size of 1.
Would you know which commit fixed this dd/cat differences on
set_ftrace_filter? When I've run this test on 4.9-stable kernel,
it failed because the result of "dd -bs=1" and "cat" on
set_ftrace_filter were different.
Thank you,
>
> This test performs the following:
>
> o Resets set_ftrace_filter
>
> o Makes sure only " all functions enabled " is listed
>
> (All checks uses cat, and dd with bs=1 and bs=100)
>
> o Adds a traceon trigger to schedule
>
> o Checks if only " all function enabled " and the trigger is there.
>
> o Adds tracing of schedule
>
> o Checks if only schedule and the trigger is there
>
> o Adds tracing of do_IRQ as well
>
> o Checks if only schedule, do_IRQ and the trigger is there
>
> o Adds a traceon trigger to do_IRQ
>
> o Checks if only schedule, do_IRQ and both triggers are there
>
> o Removes tracing of do_IRQ
>
> o Checks if only schedule and both triggers are there
>
> o Removes tracing of schedule
>
> o Checks if only " all functions enabled " and both triggers are
> there
>
> o Removes the triggers
>
> o Checks if only " all functions enabled " is there
>
> o Adds tracing of schedule
>
> o Checks if only schedule is there
>
> o Adds tracing of do_IRQ
>
> o Checks if only schedule and do_IRQ are there
>
> Signed-off-by: Steven Rostedt (VMware)
> ---
> .../ftrace/test.d/ftrace/func_set_ftrace_file.tc | 132
> +
> 1 file changed, 132 insertions(+)
> create mode 100644
> tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc
>
> diff --git
> a/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc
> b/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc
> new file mode 100644
> index ..113b4d9bc733
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc
> @@ -0,0 +1,132 @@
> +#!/bin/sh
> +# description: ftrace - test reading of set_ftrace_filter
> +#
> +# The set_ftrace_filter file of ftrace is used to list functions as well as
> +# triggers (probes) attached to functions. The code to read this file is not
> +# straight forward and has had various bugs in the past. This test is
> designed
> +# to add functions and triggers to that file in various ways and read that
> +# file in various ways (cat vs dd).
> +#
> +
> +# The triggers are set within the set_ftrace_filter file
> +if [ ! -f set_ftrace_filter ]; then
> +echo "set_ftrace_filter not found? Is dynamic ftrace not set?"
> +exit_unsupported
> +fi
> +
> +do_reset() {
> +reset_tracer
> +reset_ftrace_filter
> +disable_events
> +clear_trace
> +enable_tracing
> +}
> +
> +fail() { # mesg
> +do_reset
> +echo $1
> +exit $FAIL
> +}
> +
> +do_reset
> +
> +FILTER=set_ftrace_filter
> +FUNC1="schedule"
> +FUNC2="do_IRQ"
> +
> +ALL_FUNCS=" all functions enabled "
> +
> +test_func() {
> +if ! echo "$1" | grep -q "^$2\$"; then
> + return 0
> +fi
> +echo "$1" | grep -v "^$2\$"
> +return 1
> +}
> +
> +check_set_ftrace_filter() {
> +cat=`cat $FILTER`
> +dd1=`dd if=$FILTER bs=1 | grep -v -e 'records in' -e 'records out' -e
> 'bytes copied'`
> +dd100=`dd if=$FILTER bs=100 | grep -v -e 'records in' -e 'records out'
> -e 'bytes copied'`
> +
> +echo "Testing '$@'"
> +
> +while [ $# -gt 0 ]; do
> + echo "test $1"
> + if cat=`test_func "$cat" "$1"`; then
> + return 0
> + fi
> + if dd1=`test_func "$dd1" "$1"`; then
> + return 0
> + fi
> + if dd100=`test_func "$dd100" "$1"`; then
> + return 0
> + fi
> + shift
> +done
> +
> +if [ -n "$cat" ]; then
> + return 0
> +fi
> +if [ -n "$dd1" ]; then
> + return 0
> +fi
> +if [ -n "$dd100" ]; then
> + return 0
> +fi
> +return 1;
> +}
> +
> +if check_set_ftrace_filter "$ALL_FUNCS"; then
> +fail "Expected only $ALL_FUNCS"
> +fi
> +
> +echo "$FUNC1:traceoff" > set_ftrace_filter
> +if check_set_ftrace_filter "$ALL_FUNCS" "$FUNC1:traceoff:unlimited"; then
> +fail "Expected $ALL_FUNCS and $FUNC1:traceoff:unlimited"
> +fi
> +
> +echo "$FUNC1" > set_ftrace_filter
> +if check_set_ftrace_filter "$FUNC1" "$FUNC1:traceoff:unlimited"; then
> +fail "Expected $FUNC1 and $FUNC1:traceoff:unlimited"
> +fi
> +
> +echo "$FUNC2" >> set_ftrace_filter
> +if check_set_ftrace_filter "$FUNC1" "$FUNC2" "$FUN
Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell
Date: Mon, 22 May 2017 11:16:05 +1000
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use
> in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped
> packets")
>
> This probably broke every architecture that has its own
> arch//include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
>
> I have used the net-next tree from next-20170519 for today.
I've just pushed the following, thanks for the report:
net: Define SCM_TIMESTAMPING_PKTINFO on all architectures.
A definition was only provided for asm-generic/socket.h
using platforms, define it for the others as well
Reported-by: Stephen Rothwell
Signed-off-by: David S. Miller
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h| 2 ++
arch/m32r/include/uapi/asm/socket.h| 2 ++
arch/mips/include/uapi/asm/socket.h| 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h| 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
11 files changed, 22 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h
b/arch/alpha/include/uapi/asm/socket.h
index 148d7a3..0926de6 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h
b/arch/frv/include/uapi/asm/socket.h
index 1ccf456..e491ff0 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h
b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b4..8693724 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h
b/arch/m32r/include/uapi/asm/socket.h
index ae6548d..5d97890 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h
b/arch/mips/include/uapi/asm/socket.h
index 3418ec9..365ff51 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h
b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92..d013c0d 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h
b/arch/parisc/include/uapi/asm/socket.h
index 5147018..784b871 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_COOKIE 0x4032
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h
b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0..bc4ca72 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h
b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf..fb9769d 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h
b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19..5d67330 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
#define SO_COOKIE 0x003b
+#define SCM_TIMESTAMPING_PKTINFO 0x003c
+
/* Secur
Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c
On 05/21/2017 01:34 PM, Wolfram Sang wrote:
It doesn't make sense to use include/linux/i2c for client drivers which may in
fact rather be hwmon or input or whatever devices. As a result, I want to
deprecate include/linux/i2c for good. This series moves the include files to a
better location, largely include/platform_data because that is what most of th
> moved include files contain. Note that some files don't seem to have upstream
users in board code, so they maybe could even be removed? I didn't check for
While I understand where you are coming from, I am not typically that
aggressive.
Such removals force vendors who are not really forthcoming with upstreaming to
deviate even further from upstream. It makes them even less likely to submit
their
code upstream, and it may result in enforcing their belief that upstream doesn't
really care about vendors struggling to release boards and systems to their
customers.
that now, but I did it for one i2c master driver recently. So, it may be
possible. pmbus.h got moved just one layer upwards, see the patch description
there.
I prefer the series to go upstream via the subsystem tree; if you prefer that I
take it via I2C, just let me know.
Series applied to hwmon-next.
Thanks,
Guenter
No runtime testing because of no HW, but buildbot is happy with this series at
least. A branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data
Thanks and kind regards,
Wolfram
Wolfram Sang (5):
hwmon: ads1015: move header file out of I2C realm
hwmon: ds620: move header file out of I2C realm
hwmon: ltc4245: move header file out of I2C realm
hwmon: max6639: move header file out of I2C realm
hwmon: pmbus: move header file out of I2C realm
Documentation/hwmon/ads1015| 2 +-
Documentation/hwmon/ltc4245| 2 +-
Documentation/hwmon/pmbus-core | 2 +-
MAINTAINERS| 4 ++--
drivers/hwmon/ads1015.c| 2 +-
drivers/hwmon/ds620.c | 2 +-
drivers/hwmon/ltc4245.c| 2 +-
drivers/hwmon/max6639.c| 2 +-
drivers/hwmon/pmbus/pmbus.c| 2 +-
drivers/hwmon/pmbus/pmbus_core.c | 2 +-
drivers/hwmon/pmbus/ucd9000.c | 2 +-
drivers/hwmon/pmbus/ucd9200.c | 2 +-
drivers/iio/adc/ti-ads1015.c | 2 +-
include/linux/{i2c => platform_data}/ads1015.h | 0
include/linux/{i2c => platform_data}/ds620.h | 0
include/linux/{i2c => platform_data}/ltc4245.h | 0
include/linux/{i2c => platform_data}/max6639.h | 0
include/linux/{i2c => }/pmbus.h| 0
18 files changed, 14 insertions(+), 14 deletions(-)
rename include/linux/{i2c => platform_data}/ads1015.h (100%)
rename include/linux/{i2c => platform_data}/ds620.h (100%)
rename include/linux/{i2c => platform_data}/ltc4245.h (100%)
rename include/linux/{i2c => platform_data}/max6639.h (100%)
rename include/linux/{i2c => }/pmbus.h (100%)
Linux 4.12-rc2
I'm back on the usual Sunday schedule, and everything else looks fairly normal too. This rc2 is maybe a bit bigger than usual, but the whole merge window was bigger than most, so maybe it's just that. And it's not like it's huge - usually the rc2 week is fairly quiet as people find issues. The fixes in rc2 are pretty much all around - drivers (md, networking, usb, staging, gpu, watchdog..), architectures (x86, arm[64], powerpc and s390, kvm updates), core networking, bpf, filesystems.. The appended shortlog gives an overview of the details, and it's not so big you can't scan through it for a flavor. Nothing particularly odd stands out, aside from just the size in general. And it's not like even that is exceptional - 4.9 remains the most massive release, and 4.12 won't challenge that even if it's at the big end. I'm just hoping that the rest of the rc's won't continue this "larger than usual" trend. Go out and test. So far, despite the larger size, I've not been seeing anything unusual. Linus --- Adam Ford (1): ARM: dts: LogicPD Torpedo: Fix camera pin mux Al Viro (2): fix unsafe_put_user() osf_wait4(): fix infoleak Alan Stern (2): USB: ene_usb6250: fix DMA to the stack USB: xhci: fix lock-inversion problem Alexandre Belloni (2): watchdog: sama5d4: fix WDDIS handling watchdog: sama5d4: fix race condition Ander Conselvan de Oliveira (1): drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages Andreas Kemnade (1): ARM: dts: gta04: fix polarity of clocks for mcbsp4 Andrey Korolyov (1): USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs Andy Gospodarek (1): samples/bpf: run cleanup routines when receiving SIGTERM Anthony Mallet (1): USB: serial: ftdi_sio: fix setting latency for unprivileged users Anton Bondarenko (1): usb: core: fix potential memory leak in error path during hcd creation Ard Biesheuvel (1): i2c: designware: don't infer timings described by ACPI from clock rate Arkadi Sharshevsky (2): mlxsw: spectrum_dpipe: Fix incorrect entry index mlxsw: spectrum_router: Fix rif counter freeing routine Arnd Bergmann (11): ARM: omap2+: make omap4_get_cpu1_ns_pa_addr declaration usable tee: add ARM_SMCCC dependency soc: imx: add PM dependency for IMX7_PM_DOMAINS staging: fsl-dpaa2/eth: add ETHERNET dependency mlx5e: add CONFIG_INET dependency iommu/mediatek: Include linux/dma-mapping.h gpu: host1x: select IOMMU_IOVA watchdog: orion: fix compile-test dependencies ARM: remove duplicate 'const' annotations' firmware: ti_sci: fix strncat length check arm64: dts: rockchip: fix include reference Artur Paszkiewicz (1): md: don't return -EAGAIN in md_allow_write for external metadata arrays Bart Van Assche (1): scsi: scsi_lib: Add #include Baruch Siach (4): ARM: dts: bcm2835: fix uart0 pinctrl node names ARM: dts: bcm2835: fix i2c0 pins ARM: dts: bcm2835: fix uart0/uart1 pins ARM: dts: bcm2835: add index to the ethernet alias Bert Kenward (1): sfc: revert changes to NIC revision numbers Bjørn Mork (2): USB: serial: qcserial: add more Lenovo EM74xx device IDs qmi_wwan: add another Lenovo EM74xx device ID Bogdan Mirea (1): usb: gadget: gserial: check if console kthread exists Boris Brezillon (1): drm/atmel-hlcdc: Fix output initialization Chopra, Manish (2): qlcnic: Fix link configuration with autoneg disabled qlcnic: Update version to 5.3.66 Chris Brandt (2): usb: r8a66597-hcd: decrease timeout usb: r8a66597-hcd: select a different endpoint on timeout Christoffer Dall (2): KVM: arm/arm64: Fix bug when registering redist iodevs KVM: arm/arm64: Hold slots_lock when unregistering kvm io bus devices Christoph Hellwig (5): scsi: MAINTAINERS: update OSD entries dm rq: add a missing break to map_request dm mpath: don't return -EIO from dm_report_EIO dm mpath: multipath_clone_and_map must not return -EIO net/smc: Add warning about remote memory exposure Christophe JAILLET (3): SMB2: Fix share type handling drm/nouveau/secboot: plug memory leak in ls_ucode_img_load_gr() error path firmware: Google VPD: Fix memory allocation error handling Chuanxiao Dong (1): drm/i915/gvt: not to restore in-context mmio Colin Ian King (6): drm/i915/gvt: fix typo: "supporte" -> "support" scsi: lpfc: ensure els_wq is being checked before destroying it scsi: pmcraid: remove redundant check to see if request_size is less than zero netxen_nic: set rcode to the return status from the call to netxen_issue_cmd ethernet: aquantia: remove redundant checks on error status dm cache: handle kmalloc failure allocating background_tracker struct Craig Gallek (1): ipv6: Prevent overrun when parsing v6 header options Dan Carpenter (5): scsi
linux-next: build failure after merge of the selinux tree
Hi Paul,
After merging the selinux tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/infiniband/core/uverbs_cmd.c: In function 'create_qp':
drivers/infiniband/core/uverbs_cmd.c:1513:4: error: label 'err_destroy' used
but not defined
goto err_destroy;
^
Caused by commit
89b54b4d09bd ("IB/core: Enforce PKey security on QPs")
interacting with commit
fd3c7904db6e ("IB/core: Change idr objects to use the new schema")
from Linus' tree.
I have applied the following merge fix patch for today:
From: Stephen Rothwell
Date: Mon, 22 May 2017 12:45:57 +1000
Subject: [PATCH] IB/core: fix up for create_qp label changes
Signed-off-by: Stephen Rothwell
---
drivers/infiniband/core/uverbs_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index 558fd5204b32..0ad3b05405d8 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -1510,7 +1510,7 @@ static int create_qp(struct ib_uverbs_file *file,
if (cmd->qp_type != IB_QPT_XRC_TGT) {
ret = ib_create_qp_security(qp, device);
if (ret)
- goto err_destroy;
+ goto err_cb;
qp->real_qp = qp;
qp->device= device;
--
2.11.0
--
Cheers,
Stephen Rothwell
Re: [PATCH 1/1] printk: add __printf attributes to internal functions
On (05/20/17 11:18), Nicolas Iooss wrote: > When compiling with -Wsuggest-attribute=format, gcc complains that some > functions in kernel/printk/printk_safe.c transmit their argument to > printf-like functions without having a printf attribute. Silence these > warnings by adding relevant __printf attributes. > > Signed-off-by: Nicolas Iooss no objections from my side. Reviewed-by: Sergey Senozhatsky -ss
Re: [PATCH] initramfs: Fix disabling of initramfs (and its compression)
On Sat, 20 May 2017 20:33:35 -0700
Florian Fainelli wrote:
> Commit db2aa7fd15e8 ("initramfs: allow again choice of the embedded
> initram compression algorithm") introduced the possibility to select the
> initramfs compression algorithm from Kconfig and while this is a nice
> feature it broke the use case described below.
>
> Here is what my build system does:
>
> - kernel is initially configured not to have an initramfs included
> - build the user space root file system
> - re-configure the kernel to have an initramfs included
> (CONFIG_INITRAMFS_SOURCE="/path/to/romfs") and set relevant
> CONFIG_INITRAMFS options, in my case, no compression option
> (CONFIG_INITRAMFS_COMPRESSION_NONE)
> - kernel is re-built with these options -> kernel+initramfs image is
> copied
> - kernel is re-built again without these options -> kernel image is
> copied
>
> Building a kernel without an initramfs means setting this option:
>
> CONFIG_INITRAMFS_SOURCE="" (and this one only)
>
> whereas building a kernel with an initramfs means setting these options:
>
> CONFIG_INITRAMFS_SOURCE="/home/fainelli/work/uclinux-rootfs/romfs
> /home/fainelli/work/uclinux-rootfs/misc/initramfs.dev"
> CONFIG_INITRAMFS_ROOT_UID=1000
> CONFIG_INITRAMFS_ROOT_GID=1000
> CONFIG_INITRAMFS_COMPRESSION_NONE=y
> CONFIG_INITRAMFS_COMPRESSION=""
>
> Commit db2aa7fd15e857891cefbada8348c8d938c7a2bc ("initramfs: allow again
> choice of the embedded initram compression algorithm") is problematic
> because CONFIG_INITRAMFS_COMPRESSION which is used to determine the
> initramfs_data.cpio extension/compression is a string, and due to how
> Kconfig works it will evaluate in order, how to assign it.
>
> Setting CONFIG_INITRAMFS_COMPRESSION_NONE with
> CONFIG_INITRAMFS_SOURCE="" cannot possibly work (because of the depends
> on INITRAMFS_SOURCE!="" imposed on CONFIG_INITRAMFS_COMPRESSION ) yet we
> still get CONFIG_INITRAMFS_COMPRESSION assigned to ".gz" because
> CONFIG_RD_GZIP=y is set in my kernel, even when there is no initramfs
> being built.
>
> So we basically end-up generating two initramfs_data.cpio* files, one
> without extension, and one with .gz. This causes usr/Makefile to track
> usr/initramfs_data.cpio.gz, and not usr/initramfs_data.cpio anymore,
> that is also largely problematic after
> 9e3596b0c6539e28546ff7c72a06576627068353 ("kbuild: initramfs cleanup,
> set target from Kconfig") because we used to track all possible
> initramfs_data files in the $(targets) variable before that commit.
>
> The end result is that the kernel with an initramfs clearly does not
> contain what we expect it to, it has a stale initramfs_data.cpio file
> built into it, and we keep re-generating an initramfs_data.cpio.gz file
> which is not the one that we want to include in the kernel image proper.
>
> The fix consists in hiding CONFIG_INITRAMFS_COMPRESSION when
> CONFIG_INITRAMFS_SOURCE="". This puts us back in a state to the pre-4.10
> behavior where we can properly disable and re-enable initramfs within
> the same kernel .config file, and be in control of what
> CONFIG_INITRAMFS_COMPRESSION is set to.
>
> Fixes: db2aa7fd15e8 ("initramfs: allow again choice of the embedded initram
> compression algorithm")
> Fixes: 9e3596b0c653 ("kbuild: initramfs cleanup, set target from Kconfig")
> Signed-off-by: Florian Fainelli
This is very thorough, thank you for tracking it down and fixing it.
I can't say I've worked through the problem in the code, but your
changelog and the proposed fix seem reasonable to me. So for what
it's worth:
Acked-by: Nicholas Piggin
> ---
> usr/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/usr/Kconfig b/usr/Kconfig
> index c0c48507e44e..ad0543e21760 100644
> --- a/usr/Kconfig
> +++ b/usr/Kconfig
> @@ -220,6 +220,7 @@ config INITRAMFS_COMPRESSION_LZ4
> endchoice
>
> config INITRAMFS_COMPRESSION
> + depends on INITRAMFS_SOURCE!=""
> string
> default "" if INITRAMFS_COMPRESSION_NONE
> default ".gz" if INITRAMFS_COMPRESSION_GZIP
linux-next: manual merge of the selinux tree with Linus' tree
Hi Paul,
Today's linux-next merge of the selinux tree got a conflict in:
include/rdma/ib_verbs.h
between commit:
2fc775726491 ("IB/opa-vnic: RDMA NETDEV interface")
from Linus' tree and commit:
89b54b4d09bd ("IB/core: Enforce PKey security on QPs")
from the selinux tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/rdma/ib_verbs.h
index ba8314ec5768,c9e903fc824b..
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@@ -1890,7 -1878,10 +1930,8 @@@ enum ib_mad_result
IB_MAD_RESULT_CONSUMED = 1 << 2 /* Packet consumed: stop processing */
};
-#define IB_DEVICE_NAME_MAX 64
-
struct ib_port_cache {
+ u64 subnet_prefix;
struct ib_pkey_cache *pkey;
struct ib_gid_table *gid;
u8 lmc;
@@@ -1912,34 -1903,12 +1953,40 @@@ struct ib_port_immutable
u32 max_mad_size;
};
+/* rdma netdev type - specifies protocol type */
+enum rdma_netdev_t {
+ RDMA_NETDEV_OPA_VNIC,
+ RDMA_NETDEV_IPOIB,
+};
+
+/**
+ * struct rdma_netdev - rdma netdev
+ * For cases where netstack interfacing is required.
+ */
+struct rdma_netdev {
+ void *clnt_priv;
+ struct ib_device *hca;
+ u8 port_num;
+
+ /* control functions */
+ void (*set_id)(struct net_device *netdev, int id);
+ /* send packet */
+ int (*send)(struct net_device *dev, struct sk_buff *skb,
+ struct ib_ah *address, u32 dqpn);
+ /* multicast */
+ int (*attach_mcast)(struct net_device *dev, struct ib_device *hca,
+ union ib_gid *gid, u16 mlid,
+ int set_qkey, u32 qkey);
+ int (*detach_mcast)(struct net_device *dev, struct ib_device *hca,
+ union ib_gid *gid, u16 mlid);
+};
+
+ struct ib_port_pkey_list {
+ /* Lock to hold while modifying the list. */
+ spinlock_tlist_lock;
+ struct list_head pkey_list;
+ };
+
struct ib_device {
/* Do not access @dma_device directly from ULP nor from HW drivers. */
struct device*dma_device;
Re: [PATCH v2 3/4] arm: dts: rk3229: add a new cpu opp table
Hi Heiko,
On 2017/5/20 5:46, Heiko Stuebner wrote:
Hi Frank,
Am Mittwoch, 17. Mai 2017, 18:16:16 CEST schrieb Frank Wang:
From: Finley Xiao
This patch adds some new frequencies for rk3229 board.
Signed-off-by: Finley Xiao
Signed-off-by: Frank Wang
Acked-by: Viresh Kumar
---
arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 +++
I'm not yet sure if I like that approach. The other option I'm considering
and also tend to prefer at the moment would be to have this in a
rk3229.dtsi, creating a chain of
rk322x.dtsi
\- rk3228-evb.dts
\- rk3229.dtsi
\- rk3229-evb.dts
similar to what we do with the rk3xxx.dtsi -> rk3188.dtsi.
If I remember correctly, there are some other tiny differences between the
rk3228 and rk3229, so having the rk3229.dtsi already would make it
easier to place needed stuff into it later on.
That makes sense, I will amend that based on your comments.
BR.
Frank
Heiko
1 file changed, 85 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi
diff --git a/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
b/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
new file mode 100644
index 000..89e8413
--- /dev/null
+++ b/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+ /delete-node/ opp-table0;
+
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-40800 {
+ opp-hz = /bits/ 64 <40800>;
+ opp-microvolt = <95>;
+ clock-latency-ns = <4>;
+ opp-suspend;
+ };
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <975000>;
+ };
+ opp-81600 {
+ opp-hz = /bits/ 64 <81600>;
+ opp-microvolt = <100>;
+ };
+ opp-100800 {
+ opp-hz = /bits/ 64 <100800>;
+ opp-microvolt = <1175000>;
+ };
+ opp-12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <1275000>;
+ };
+ opp-129600 {
+ opp-hz = /bits/ 64 <129600>;
+ opp-microvolt = <1325000>;
+ };
+ opp-139200 {
+ opp-hz = /bits/ 64 <139200>;
+ opp-microvolt = <1375000>;
+ };
+ opp-146400 {
+ opp-hz = /bits/ 64 <146400>;
+ opp-microvolt = <140>;
+ };
+ };
+};
RE: [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g
> -Original Message-
> From: Chen, Xiaoguang
> Sent: Thursday, May 18, 2017 7:20 PM
> To: He, Min ; alex.william...@redhat.com;
> kra...@redhat.com; intel-...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
> ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> ; Tian, Kevin
> Cc: Niu, Bing
> Subject: RE: [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g
>
> Hi min,
>
> >-Original Message-
> >From: He, Min
> >Sent: Thursday, May 18, 2017 11:44 PM
> >To: Chen, Xiaoguang ;
> >alex.william...@redhat.com; kra...@redhat.com; intel-
> >g...@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> >zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
> >d...@lists.freedesktop.org; Wang, Zhi A ; Tian, Kevin
> >
> >Cc: Niu, Bing ; Chen, Xiaoguang
> >
> >Subject: RE: [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g
> >
> >Xiaoguang,
> >I have some comments inline. Thanks.
> >
> >> -Original Message-
> >> From: intel-gvt-dev
> >> [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On Behalf Of
> >> Xiaoguang Chen
> >> Sent: Thursday, May 18, 2017 2:50 AM
> >> To: alex.william...@redhat.com; kra...@redhat.com; intel-
> >> g...@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> >> zhen...@linux.intel.com; Lv, Zhiyuan ;
> >> intel-gvt- d...@lists.freedesktop.org; Wang, Zhi A
> >> ; Tian, Kevin
> >> Cc: Niu, Bing ; Chen, Xiaoguang
> >>
> >> Subject: [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g
> >>
> >> OpRegion is needed to support display related operation for intel
> >> vgpu.
> >>
> >> A vfio device region is added to intel vgpu to deliver the host
> >> OpRegion information to user space so user space can construct the
> >> OpRegion for vgpu.
> >>
> >> Signed-off-by: Bing Niu
> >> Signed-off-by: Xiaoguang Chen
> >> ---
> >> drivers/gpu/drm/i915/gvt/kvmgt.c| 97
> >> +
> >> drivers/gpu/drm/i915/gvt/opregion.c | 12 -
> >> 2 files changed, 107 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> index 3c6a02b..389f072 100644
> >> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> @@ -53,6 +53,8 @@
> >> #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) <<
> >> VFIO_PCI_OFFSET_SHIFT)
> >> #define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
> >>
> >> +#define OPREGION_SIGNATURE "IntelGraphicsMem"
> >> +
> >> struct vfio_region;
> >> struct intel_vgpu_regops {
> >>size_t (*rw)(struct intel_vgpu *vgpu, char *buf, @@ -436,6 +438,92
> >> @@ static void kvmgt_protect_table_del(struct kvmgt_guest_info *info,
> >>}
> >> }
> >>
> >> +static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char
> >> *buf,
> >> + size_t count, loff_t *ppos, bool iswrite) {
> >> + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
> >> + VFIO_PCI_NUM_REGIONS;
> >> + void *base = vgpu->vdev.region[i].data;
> >> + loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
> >> +
> >> + if (pos >= vgpu->vdev.region[i].size || iswrite) {
> >> + gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
> >> + return -EINVAL;
> >> + }
> >> + count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
> >> + memcpy(buf, base + pos, count);
> >> +
> >> + return count;
> >> +}
> >> +
> >> +static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
> >> + struct vfio_region *region)
> >> +{
> >> + memunmap(region->data);
> >> +}
> >> +
> >> +static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
> >> + .rw = intel_vgpu_reg_rw_opregion,
> >> + .release = intel_vgpu_reg_release_opregion, };
> >> +
> >> +static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
> >> + unsigned int type, unsigned int subtype,
> >> + const struct intel_vgpu_regops *ops,
> >> + size_t size, u32 flags, void *data) {
> >> + struct vfio_region *region;
> >> +
> >> + region = krealloc(vgpu->vdev.region,
> >> + (vgpu->vdev.num_regions + 1) * sizeof(*region),
> >> + GFP_KERNEL);
> >> + if (!region)
> >> + return -ENOMEM;
> >> +
> >> + vgpu->vdev.region = region;
> >> + vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
> >> + vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
> >> + vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
> >> + vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
> >> + vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
> >> + vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
> >> + vgpu->vdev.num_regions++;
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int intel_vgpu_reg_init_opregion(struct intel_vgpu *vgpu) {
> >> + unsigned int addr;
> >> + void *base;
> >> + int ret;
> >> +
> >> + addr = vgpu->gvt->opregion.opregion_pa;
> >> + if (!addr || !(~addr
[PATCH] mm, THP, swap: Check whether CONFIG_THP_SWAP enabled earlier
From: Huang Ying
This patch is only a code clean up patch without functionality
changes. It moves CONFIG_THP_SWAP checking from inside swap slot
allocation to before we start swapping the THP. This makes the code
path a little easier to be followed and understood.
Signed-off-by: "Huang, Ying"
Cc: Johannes Weiner
Cc: Minchan Kim
---
mm/swap_slots.c | 3 +--
mm/vmscan.c | 3 ++-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index 90c1032a8ac3..14c2a91289e5 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -310,8 +310,7 @@ swp_entry_t get_swap_page(struct page *page)
entry.val = 0;
if (PageTransHuge(page)) {
- if (IS_ENABLED(CONFIG_THP_SWAP))
- get_swap_pages(1, true, &entry);
+ get_swap_pages(1, true, &entry);
return entry;
}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f7e949ac9756..90722afd4916 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1134,7 +1134,8 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
* away. Chances are some or all of the
* tail pages can be freed without IO.
*/
- if (!compound_mapcount(page) &&
+ if ((!IS_ENABLED(CONFIG_THP_SWAP) ||
+!compound_mapcount(page)) &&
split_huge_page_to_list(page, page_list))
goto activate_locked;
}
--
2.11.0
[PATCH v2] ocfs2: give an obvious tip for dismatch cluster names
This patch is used to add an obvious error message, due to
dismatch cluster names between on-disk and in the current cluster.
We can meet this case during OCFS2 cluster migration, if we can
give the user an obvious tip for why they can not mount the file
system after migration, they can quickly fix this dismatch problem.
Second, also move printing ocfs2_fill_super() errno to the front
of ocfs2_dismount_volume() function, since ocfs2_dismount_volume()
will also print it's own message.
Compare with initial version, we only print this error tip when
the user uses pcmk stack. since in o2cb stack, the user will not
meet this error.
Signed-off-by: Gang He
---
fs/ocfs2/super.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index ca1646f..fc25d4a 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -1208,14 +1208,15 @@ static int ocfs2_fill_super(struct super_block *sb,
void *data, int silent)
read_super_error:
brelse(bh);
+ if (status)
+ mlog_errno(status);
+
if (osb) {
atomic_set(&osb->vol_state, VOLUME_DISABLED);
wake_up(&osb->osb_mount_event);
ocfs2_dismount_volume(sb, 1);
}
- if (status)
- mlog_errno(status);
return status;
}
@@ -1843,6 +1844,9 @@ static int ocfs2_mount_volume(struct super_block *sb)
status = ocfs2_dlm_init(osb);
if (status < 0) {
mlog_errno(status);
+ if (status == -EBADR && ocfs2_userspace_stack(osb))
+ mlog(ML_ERROR, "couldn't mount because cluster name on"
+ " disk does not match the running cluster name.\n");
goto leave;
}
--
1.8.5.6
Re: [PATCH] perf/x86/intel: Drop kernel samples even though :u is specified
On 5/19/2017 9:33 PM, Jin, Yao wrote: On 5/19/2017 8:36 PM, Peter Zijlstra wrote: On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote: Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or something that would skip the test and preserve current behaviour. OK, I understand now. For example, for PEBS event, its capabilities should be set with PERF_PMU_CAP_NO_SKID. Except you cannot in fact do that, since PEBS is the same struct pmu as the normal counters (they share counter space after all). Also, weren't there PEBS errata that would allow this to happen? But no, more for other architectures to opt out for some reason. But I'm thinking we want to start out by unconditionally doing this. It would be good to try and Cc most arch pmu maintainers on this though, so they can object. I'm thinking v2 of patch will only do simple tasks: 1. Define PERF_PMU_CAP_NO_SKID but don't bind it to any event. 2. Move the skid checking from x86 specific code to generic code. Before performing skid checking, test the PERF_PMU_CAP_NO_SKID bit first. For binding PERF_PMU_CAP_NO_SKID to event, that may be other arch related patches. Thanks Jin Yao Hi Peter, Maybe it's not very easy to move the skid checking to generic code because we don't have a common kernel_ip() available to determine if ip is a kernel address. I was trying to move kernel_ip() from arch/x86/events/perf_event.h to generic code, but some difficulties I have: For example, in new kernel_ip(), we may use many conditional-compilation for all arch, for example: #ifdef CONFIG_X86_32 return ip > PAGE_OFFSET; #endif #ifdef CONFIG_X86_64 return (long)ip < 0; #endif #ifdef CONFIG_ARM .. #ifdef CONFIG_MIPS .. But the code is being ugly and hard to maintain. And frankly I don't know kernel address space for all arch. Any idea? Could we just do at x86 side this time? Thanks Jin Yao
[GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12
Hi Arnd, Olof, Last week, I thought I found a problem in my pull request, but it turned out my misunderstanding. So, my pull request I sent is OK. I am re-sending this request mail for clarification. Here are some ARM UniPhier SoC fixes for v4.12. Due to the eMMC driver update, PHY parameters must be specified via DT to make the eMMC controller work again. The rest is DTC warning fixes reported when building DT with W=1. Please pull! The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git tags/uniphier-fixes-v4.12 for you to fetch changes up to 96abf9ded7954d9e6f3a7775353d9550b1283db9: arm64: dts: uniphier: fix simple-bus unit address format error (2017-05-14 11:43:46 +0900) UniPhier ARM SoC fixes for v4.12 - add necessary DT properties to get eMMC work again - fix DTC warnings when compiled with W=1 Masahiro Yamada (4): arm64: dts: uniphier: add input-delay properties to Cadence eMMC node arm64: dts: uniphier: add cdns, phy-dll-delay-sdclk(-hsmmc) for eMMC ARM: dts: uniphier: fix simple-bus unit address format error arm64: dts: uniphier: fix simple-bus unit address format error Viresh Kumar (2): ARM: uniphier: Use - instead of @ for DT OPP entries arm64: uniphier: Use - instead of @ for DT OPP entries arch/arm/boot/dts/uniphier-ld4.dtsi | 2 +- arch/arm/boot/dts/uniphier-pro4.dtsi | 2 +- arch/arm/boot/dts/uniphier-pro5.dtsi | 34 ++--- arch/arm/boot/dts/uniphier-pxs2.dtsi | 18 +-- arch/arm/boot/dts/uniphier-sld3.dtsi | 2 +- arch/arm/boot/dts/uniphier-sld8.dtsi | 2 +- arch/arm/boot/dts/uniphier-support-card.dtsi | 4 +-- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 21 - arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 39 +--- 9 files changed, 67 insertions(+), 57 deletions(-) -- Best Regards Masahiro Yamada
RE: [PATCH v2 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf
Hi Alex,
>-Original Message-
>From: Alex Williamson [mailto:alex.william...@redhat.com]
>Sent: Saturday, May 20, 2017 12:34 AM
>To: Chen, Xiaoguang
>Cc: kra...@redhat.com; intel-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>; Tian, Kevin
>Subject: Re: [PATCH v2 5/5] drm/i915/gvt: Adding interface so user space can
>get
>the dma-buf
>
>On Thu, 18 May 2017 17:50:05 +0800
>Xiaoguang Chen wrote:
>
>> User space will try to create a management fd for the dma-buf operation.
>> Using this management fd user can query the plane information and
>> create a dma-buf fd if necessary.
>> GVT-g will handle the life cycle of the management fd and will align
>> the life cycle of the fd with the vfio device.
>> User space should handle the life cycle of the created dma-buf fd
>> close the dma-buf fd timely when finishing use.
>>
>> Signed-off-by: Xiaoguang Chen
>> ---
>> drivers/gpu/drm/i915/gvt/gvt.c | 2 +
>> drivers/gpu/drm/i915/gvt/gvt.h | 3 ++
>> drivers/gpu/drm/i915/gvt/kvmgt.c | 89
>
>> include/uapi/drm/i915_drm.h | 2 +
>> include/uapi/linux/vfio.h| 12 ++
>> 5 files changed, 108 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c
>> b/drivers/gpu/drm/i915/gvt/gvt.c index 2032917..48e04e6 100644
>> --- a/drivers/gpu/drm/i915/gvt/gvt.c
>> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
>> @@ -54,6 +54,8 @@
>> .vgpu_reset = intel_gvt_reset_vgpu,
>> .vgpu_activate = intel_gvt_activate_vgpu,
>> .vgpu_deactivate = intel_gvt_deactivate_vgpu,
>> +.vgpu_query_dmabuf = intel_vgpu_query_dmabuf,
>> +.vgpu_create_dmabuf = intel_vgpu_create_dmabuf,
>> };
>>
>> /**
>> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h
>> b/drivers/gpu/drm/i915/gvt/gvt.h index a553120..b7fdfd5 100644
>> --- a/drivers/gpu/drm/i915/gvt/gvt.h
>> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
>> @@ -185,6 +185,7 @@ struct intel_vgpu {
>> struct kvm *kvm;
>> struct work_struct release_work;
>> atomic_t released;
>> +struct vfio_device *vfio_device;
>> } vdev;
>> #endif
>> struct intel_vgpu_plane_info *plane_info; @@ -469,6 +470,8 @@ struct
>> intel_gvt_ops {
>> void (*vgpu_reset)(struct intel_vgpu *);
>> void (*vgpu_activate)(struct intel_vgpu *);
>> void (*vgpu_deactivate)(struct intel_vgpu *);
>> +int (*vgpu_query_dmabuf)(struct intel_vgpu *, void *);
>> +int (*vgpu_create_dmabuf)(struct intel_vgpu *, void *);
>> };
>>
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> index 389f072..9a663df 100644
>> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> @@ -41,6 +41,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "i915_drv.h"
>> #include "gvt.h"
>> @@ -524,6 +525,66 @@ static int intel_vgpu_reg_init_opregion(struct
>intel_vgpu *vgpu)
>> return ret;
>> }
>>
>> +static int intel_vgpu_dmabuf_mgr_fd_mmap(struct file *file,
>> +struct vm_area_struct *vma)
>> +{
>> +return -EPERM;
>> +}
>> +
>> +static int intel_vgpu_dmabuf_mgr_fd_release(struct inode *inode,
>> +struct file *filp)
>> +{
>> +struct intel_vgpu *vgpu = filp->private_data;
>> +
>> +if (vgpu->vdev.vfio_device != NULL)
>> +vfio_device_put(vgpu->vdev.vfio_device);
>> +else
>> +gvt_vgpu_err("intel vgpu dmabuf mgr fd is in a wrong state\n");
>
>You could do:
>
>if (WARN_ON(!vgpu->vdev.vfio_device))
> return -EINVAL;
OK.
>
>> +
>> +return 0;
>> +}
>> +
>> +static long intel_vgpu_dmabuf_mgr_fd_ioctl(struct file *filp,
>> +unsigned int ioctl, unsigned long arg) {
>> +struct intel_vgpu *vgpu = filp->private_data;
>> +int minsz;
>> +struct intel_vgpu_dmabuf dmabuf;
>> +int ret;
>> +struct fd f;
>> +
>> +minsz = offsetofend(struct intel_vgpu_dmabuf, tiled);
>> +if (copy_from_user(&dmabuf, (void __user *)arg, minsz))
>> +return -EFAULT;
>> +
>> +f = fdget(dmabuf.fd);
>> +
>> +if (ioctl == INTEL_VGPU_QUERY_DMABUF)
>> +ret = intel_gvt_ops->vgpu_query_dmabuf(vgpu, &dmabuf);
>> +else if (ioctl == INTEL_VGPU_GENERATE_DMABUF)
>> +ret = intel_gvt_ops->vgpu_create_dmabuf(vgpu, &dmabuf);
>
>Why are these still Intel specific?
Ah, the v2 patch series were sent before our discussion in other thread. Will
change it in v3.
>
>> +else {
>> +fdput(f);
>> +gvt_vgpu_err("unsupported dmabuf operation\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (ret != 0) {
>> +fdput(f);
>> +gvt_vgpu_err("gvt-g get dmabuf failed:%d\n", ret);
>> +return -EINVAL;
>> +}
>> +fdput(f);
>> +
>> +return copy_to_user((void __user *)arg, &dmabuf, minsz) ? -EFAULT :
>> +0; }
>> +
>> +static const struct file_ope
Re: [PATCH v2] kconfig: Check for libncurses before menuconfig
2017-05-21 18:44 GMT+09:00 Borislav Petkov : > On Sun, May 21, 2017 at 06:15:53PM +0900, Masahiro Yamada wrote: >> Could you change line 199 >> >> $(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog >> >> to >> >> $(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog >> >> and send v2, please? > > Here it is: > > --- > From: Borislav Petkov > Date: Sun, 9 Apr 2017 15:07:08 +0200 > Subject: [PATCH v2] kconfig: Check for libncurses before menuconfig > > There is a check and a nice user-friendly message when the curses > library is not present on the system and the user wants to do "make > menuconfig". It doesn't get issued, though. Instead, we fail the build > when mconf.c doesn't find the curses.h header: > > HOSTCC scripts/kconfig/mconf.o > In file included from scripts/kconfig/mconf.c:23:0: > scripts/kconfig/lxdialog/dialog.h:38:20: fatal error: curses.h: No such > file or directory >#include CURSES_LOC > ^ > compilation terminated. > > Make sure dochecklxdialog gets run before mconf is compiled so that the > user sees the error message instead: > > $ make menuconfig >*** Unable to find the ncurses libraries or the >*** required header files. >*** 'make menuconfig' requires the ncurses libraries. >*** >*** Install ncurses (ncurses-devel) and try again. >*** > scripts/kconfig/Makefile:203: recipe for target > 'scripts/kconfig/dochecklxdialog' failed > make[1]: *** [scripts/kconfig/dochecklxdialog] Error 1 > Makefile:548: recipe for target 'menuconfig' failed > make: *** [menuconfig] Error 2 > > Signed-off-by: Borislav Petkov > Cc: linux-kbu...@vger.kernel.org > Link: http://lkml.kernel.org/r/20170409130708.4753-1...@alien8.de > --- > scripts/kconfig/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 90a091b6ae4d..eb8144643b78 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -196,7 +196,7 @@ clean-files += config.pot linux.pot > > # Check that we have the required ncurses stuff installed for lxdialog > (menuconfig) > PHONY += $(obj)/dochecklxdialog > -$(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog > +$(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog > $(obj)/dochecklxdialog: > $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) > $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf) > Acked-by: Masahiro Yamada I will pick it up for v4.13 if it is not applied via kconfig. I still will somebody can maintain the kconfig subsystem, though. -- Best Regards Masahiro Yamada
Re: [lkp-robot] [waitid()] 75f64d68f9: Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode=
On Sun, May 21, 2017 at 3:19 PM, Linus Torvalds
wrote:
>
> Did an "allyesconfig" build on 32-bit x86, and looked at who uses the
> 8-byte get_user/put_user cases:
I've done more testing.
It turns out that quite independently of all these patches, our 32-bit
x86 code is entirely broken.
In particular, __get_user_asm_u64() has two independent bugs, one
fairly harmless, and one that can be entirely deadly.
The harmless one is that we have the ASM_STAC/ASM_CLAC markers around
the user access in there, even though they should have gotten removed.
That cone can be considered a "merge error" between commit
b2f680380ddf ("x86/mm/32: Add support for 64-bit __get_user() on
32-bit kernels")
that added the 64-bit case, and commit
11f1a4b9755f x86: reorganize SMAP handling in user space accesses
that moved the CLAC/STAC into the caller.
So it turns out that a 64-bit __get_user() case will have a double
pair of STAC/CLAC instructions, making it even slower than it should
otherwise be. But it all still *works* fine.
The much worse issue is that the asm is just buggered, and when it does
"1: movl %2,%%eax\n" \
"2: movl %3,%%edx\n" \
it can be that %eax is actually used for the address, so the second
move can do crazy bad things. It can (and does) generate code like
this:
18c: 8b 00 mov(%eax),%eax
18e: 8b 50 04mov0x4(%eax),%edx
(I'm not sure that actually happens anywhere in the kernel, but it did
happen in my test-case).
So the 64-bit output needs to be marked as being an early-clobber,
meaning that it can be written to early in the asm. So we need to use
"=&A", not "=A" for it.
Adding Ben LaHaise to the cc, since that "=A" bug goes back to the
original implementation of __get_user_asm_u64() (which is only a year
ago, but still).
I've committed a fix, and now the generated asm looks ok, but I don't
actually have any 32-bit x86 machines left. Hopefully somebody still
does and can test this..
Linus
[DT Question] "simple-mfd" DT binding
Hi DT experts,
I have a question about "simple-mfd".
Documentation/devicetree/bindings/mfd/mfd.txt says as allows:
--8<-
Optional properties:
- compatible : "simple-mfd" - this signifies that the operating system should
consider all subnodes of the MFD device as separate devices akin to how
"simple-bus" indicates when to see subnodes as children for a simple
memory-mapped bus.
--8<-
I'd like to be sure about the statement above.
Does this mean, "simple-bus" and "simple-mfd" are technically interchangeable?
If so, I thought the example some lines below is questionable.
-8<---
Example:
foo@1000 {
compatible = "syscon", "simple-mfd";
reg = <0x01000 0x1000>;
led@08.0 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x01>;
label = "myled";
default-state = "on";
};
};
-8<---
Because "simple-bus" indicates that child nodes are
simply memory mapped, but the node "register-bit-led"
can not be memory-mapped.
So, "simple-mfd" can not be replaced "simple-bus" here.
arch/arm/boot/dts/arm-realview-pb1176.dts is a real example.
If I replace "simple-mfd" with "simple-bus",
DTC warns "empty reg/ranges property".
$ sed -i -e 's/simple-mfd/simple-bus/'
arch/arm/boot/dts/arm-realview-pb1176.dts
$ make -s ARCH=arm defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- W=1 arm-realview-pb1176.dtb
...
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.0 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.1 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.2 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.3 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.4 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.5 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.6 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/led@08.7 missing or empty reg/ranges
property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/osc0@0c missing or empty reg/ranges property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/osc1@10 missing or empty reg/ranges property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/osc2@14 missing or empty reg/ranges property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/osc3@18 missing or empty reg/ranges property
arch/arm/boot/dts/arm-realview-pb1176.dtb: Warning (simple_bus_reg):
Node /soc/syscon@1000/osc4@1c missing or empty reg/ranges property
--
Best Regards
Masahiro Yamada
Re: [PATCH] slub/memcg: Cure the brainless abuse of sysfs attributes
On Sat, 20 May 2017, Thomas Gleixner wrote: > memcg_propagate_slab_attrs() abuses the sysfs attribute file functions to > propagate settings from the root kmem_cache to a newly created > kmem_cache. It does that with: > > attr->show(root, buf); > attr->store(new, buf, strlen(bug); > > Aside of being a lazy and absurd hackery this is broken because it does not > check the return value of the show() function. > > Some of the show() functions return 0 w/o touching the buffer. That means in > such a case the store function is called with the stale content of the > previous show(). That causes nonsense like invoking kmem_cache_shrink() on > a newly created kmem_cache. In the worst case it would cause handing in an > uninitialized buffer. > > This should be rewritten proper by adding a propagate() callback to those > slub_attributes which must be propagated and avoid that insane conversion > to and from ASCII, but that's too large for a hot fix. > > Check at least the return value of the show() function, so calling store() > with stale content is prevented. > > Reported-by: Steven Rostedt > Signed-off-by: Thomas Gleixner > Cc: sta...@vger.kernel.org Acked-by: David Rientjes
Re: [PATCH] usb: mtu3: cleanup with list_first_entry_or_null()
Hi,
On Sat, 2017-05-20 at 21:19 +0200, Greg Kroah-Hartman wrote:
> On Sun, May 21, 2017 at 02:05:31AM +0900, Masahiro Yamada wrote:
> > The combo of list_empty() and list_first_entry() can be replaced with
> > list_first_entry_or_null().
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > drivers/usb/mtu3/mtu3.h | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
> > index aa6fd6a..7b6dc23 100644
> > --- a/drivers/usb/mtu3/mtu3.h
> > +++ b/drivers/usb/mtu3/mtu3.h
> > @@ -356,12 +356,8 @@ static inline struct mtu3_ep *to_mtu3_ep(struct usb_ep
> > *ep)
> >
> > static inline struct mtu3_request *next_request(struct mtu3_ep *mep)
> > {
> > - struct list_head *queue = &mep->req_list;
> > -
> > - if (list_empty(queue))
> > - return NULL;
> > -
> > - return list_first_entry(queue, struct mtu3_request, list);
> > + return list_first_entry_or_null(&mep->req_list, struct mtu3_request,
> > + list);
>
> Even better, why is this an inlined function at all? Why not just have
> it "open coded" everywhere it is used?
>
This can avoid repeated function definition, currently it is used in
three files.
> thanks,
>
> greg k-h
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
net/socket.c: In function 'put_ts_pktinfo':
net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in
this function)
put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
^
Caused by commit
aad9c8c470f2 ("net: add new control message for incoming HW-timestamped
packets")
This probably broke every architecture that has its own
arch//include/uapi/asm/socket.h that does not include
include/uapi/asm-generic/socket.h :-(
I have used the net-next tree from next-20170519 for today.
--
Cheers,
Stephen Rothwell
Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD
John Stultz writes: > CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago > to allow a transition from the old vsyscall implementations to > the new method (which simplified internal accounting and made > timekeeping more precise). I'm sure it's completely obvious to everyone except me what needs to be done, but can you spell it out for me? Keeping in mind that I don't know anything about the time keeping code. > However, PPC and IA64 have yet to make the transition, despite > in some cases me sending test patches to try to help it along. > > http://patches.linaro.org/patch/30501/ > http://patches.linaro.org/patch/35412/ I've never seen a PPC patch, did you send one? > If its helpful, my last pass at the patches can be found here: > https://git.linaro.org/people/john.stultz/linux.git dev/oldvsyscall-cleanup Looks like it's just a draft for PPC. Do you think that should work and it just needs testing? The comment about the vdso being "slightly behind" is a little concerning. cheers
Re: [PATCH RFC 0/3] Improve stability of system clock
John Stultz writes: > On Wed, May 17, 2017 at 9:54 PM, Richard Cochran > wrote: >> On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote: >>> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >>> wrote: >>> > Is there a better way to run the timekeeping code in an userspace >>> > application? I suspect it would need something like the Linux Kernel >>> > Library project. >>> >>> I dunno. There's probably a cleaner way to go about it, but I also >>> feel like the benefit of just having the test in the kernel tree is >>> that it can be managed as a unified whole, rather then the test being >>> a separate thing and always playing catchup to kernel changes. >> >> I vaguely recall a rant on the list years ago from a Linux bigwhig >> saying how we don't support that kind of thing. But maybe it is my >> imagination. In any case, IMHO running user space tests for chunks of >> kernel code can be quite useful. > > So a few years ago I mentioned this at a testing session at I think > Linux Plubmers' and Rusty (CC'ed) commented that he had some netfilter > (or iptables?) simulator code that never made it upstream. However, > now that kselftests are integrated with the kernel this could change. > At least that's my memory of the discussion. Yep, we did it with nfsim, but forward porting was a PITA. Good luck! Rusty.
Re: [PATCH v4 2/2] tpm: vtpm_proxy: Implement request_locality function.
On 05/20/2017 08:47 AM, Jarkko Sakkinen wrote:
On Mon, May 15, 2017 at 11:56:51AM -0400, Stefan Berger wrote:
On 05/15/2017 08:41 AM, Jarkko Sakkinen wrote:
On Wed, May 10, 2017 at 07:54:22PM -0400, Stefan Berger wrote:
Implement the request_locality function. To set the locality on the
backend we define vendor-specific TPM 1.2 and TPM 2 ordinals and send
a command to the backend to set the locality for the next commands.
Signed-off-by: Stefan Berger
---
drivers/char/tpm/tpm.h| 1 +
drivers/char/tpm/tpm_vtpm_proxy.c | 34 ++
include/uapi/linux/vtpm_proxy.h | 5 +
3 files changed, 40 insertions(+)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 4b4c8de..10f0467 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -527,6 +527,7 @@ enum tpm_transmit_flags {
TPM_TRANSMIT_UNLOCKED = BIT(0),
};
+ssize_t tpm_transfer(struct tpm_chip *chip, u8 *buf, u32 count, size_t bufsiz);
ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
u8 *buf, size_t bufsiz, unsigned int flags);
ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
b/drivers/char/tpm/tpm_vtpm_proxy.c
index 751059d..374c4ff 100644
--- a/drivers/char/tpm/tpm_vtpm_proxy.c
+++ b/drivers/char/tpm/tpm_vtpm_proxy.c
@@ -371,6 +371,39 @@ static bool vtpm_proxy_tpm_req_canceled(struct tpm_chip
*chip, u8 status)
return ret;
}
+static int vtpm_proxy_request_locality(struct tpm_chip *chip, int locality)
+{
+ struct tpm_buf buf;
+ int rc;
+ const struct tpm_output_header *header;
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ rc = tpm_buf_init(&buf, TPM2_ST_SESSIONS,
+ TPM2_CC_SET_LOCALITY);
+ else
+ rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND,
+ TPM_ORD_SET_LOCALITY);
+ if (rc)
+ return rc;
+ tpm_buf_append_u8(&buf, locality);
+
+ rc = tpm_transfer(chip, buf.data, tpm_buf_length(&buf), PAGE_SIZE);
+ if (rc < 0) {
+ locality = rc;
+ goto out;
+ }
+
+ header = (const struct tpm_output_header *)buf.data;
+ rc = be32_to_cpu(header->return_code);
+ if (rc)
+ locality = -1;
+
+out:
+ tpm_buf_destroy(&buf);
+
+ return locality;
+}
+
static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
.flags = TPM_OPS_AUTO_STARTUP,
.recv = vtpm_proxy_tpm_op_recv,
@@ -380,6 +413,7 @@ static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
.req_complete_mask = VTPM_PROXY_REQ_COMPLETE_FLAG,
.req_complete_val = VTPM_PROXY_REQ_COMPLETE_FLAG,
.req_canceled = vtpm_proxy_tpm_req_canceled,
+ .request_locality = vtpm_proxy_request_locality,
};
/*
diff --git a/include/uapi/linux/vtpm_proxy.h b/include/uapi/linux/vtpm_proxy.h
index a69e991..6b91c2c 100644
--- a/include/uapi/linux/vtpm_proxy.h
+++ b/include/uapi/linux/vtpm_proxy.h
@@ -46,4 +46,9 @@ struct vtpm_proxy_new_dev {
#define VTPM_PROXY_IOC_NEW_DEV _IOWR(0xa1, 0x00, struct
vtpm_proxy_new_dev)
+/* vendor specific commands to set locality */
+#define TPM2_CC_SET_LOCALITY 0x20001000
+#define TPM_ORD_SET_LOCALITY 0x20001000
+
+
#endif /* _UAPI_LINUX_VTPM_PROXY_H */
--
2.4.3
This is a question.
Did you have some kind of big idea with 0x20? I was just thinking
that one way to do this would to allocate starting from 0x.
Not quite. Per TPM 1.2 and TPM 2 specs we should operate here with Vendor
specific commands and they are identified by bit 29.
Check section 17 'Ordinals':
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
Check section 8.9 TPMA_CC:
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf
If anything was the 'big idea' then it was the offset '0x1000' :-)
Stefan
Maybe we should use have concept of driver specific commands? You could
in theory use vtpm to proxy a real chip and this would cause a potential
regression as vendor specific code might collide.
As long as the recipient knows where the command is coming from, it can
interpret it and convert it to whatever the target understands. In this
case it would only need to know that these commands are coming from the
Linux vTPM proxy device driver with the meaning of setting the locality.
I think the danger of collision is low and anything like driver specific
commands seems like it would have to become a standard within TCG where
they would allocate a range for those types of commands. I'd rather not
go down that road.
Stefan
Re: [PATCH v2 0/8] fujitsu-laptop: use device-specific data instead of module-wide globals
Hi Michael On Fri, May 19, 2017 at 09:44:40AM +0200, Micha?? K??pie?? wrote: > fujitsu-laptop registers two ACPI drivers that access each other's > module-wide structures. To improve data encapsulation and lay the > groundwork for separating the two aforementioned ACPI drivers into > separate modules, move away from module-wide global data structures by > using device-specific data instead. > : I have had a quick look through this series. To my eye it addresses the outcome of our discussion over the last couple of weeks, and looks good. I had one query regarding patch 5/8, but that might just be a case of me not knowing about a subtlety of WARN_ONCE(). In any case this isn't a major issue and would be easily resolved if needed. Once I get feedback on patch 5/8 (and after seeing any additional comments from Darren et al) I can send through a reviewed-by. Regards jonathan
Re: [rcu:rcu/next 91/91] ftrace.c:undefined reference to `synchronize_rcu_tasks'
On Mon, May 22, 2017 at 03:16:42AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > rcu/next > head: f1b89dcf23ef0999fae8bbc34cc9eb3fe00bc677 > commit: f1b89dcf23ef0999fae8bbc34cc9eb3fe00bc677 [91/91] rcu: Remove Tasks RCU > config: x86_64-acpi-redef (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > git checkout f1b89dcf23ef0999fae8bbc34cc9eb3fe00bc677 > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >kernel/built-in.o: In function `ftrace_shutdown': > >> ftrace.c:(.text+0x9142d): undefined reference to `synchronize_rcu_tasks' Expected behavior, so I should have used "experimental". I will be providing a new implementation of synchronize_rcu_tasks() "real soon now". Thanx, Paul
Re: [PATCH v2 5/8] platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device
On Fri, May 19, 2017 at 09:44:45AM +0200, Micha?? K??pie?? wrote: > It is easier to simply store a module-wide > pointer to the last (most likely only) FUJ02E3 ACPI device found, make > the aforementioned API use it and cover our bases by warning the user if > firmware exposes multiple FUJ02E3 ACPI devices. > : > @@ -788,6 +789,9 @@ static int acpi_fujitsu_laptop_add(struct acpi_device > *device) > if (!priv) > return -ENOMEM; > > + WARN_ONCE(fext, "More than one FUJ02E3 ACPI device was found. Driver > may not work as intended."); > + fext = device; > + > fujitsu_laptop = priv; > fujitsu_laptop->acpi_handle = device->handle; > sprintf(acpi_device_name(device), "%s", I thought WARN_ONCE() printed the warning when it was encountered for the first time and then suppressed it on all other occasions. If this is true then we'll get the warning even when there is only one FUJ02E3 in the system. Am I missing something? Regards jonathan
Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
Sorry, forget 'To' Mike, Russ and Frank On 05/22/17 at 07:14am, Baoquan He wrote: > On 05/21/17 at 01:38pm, Thomas Garnier wrote: > > On Sat, May 20, 2017 at 5:02 AM, Baoquan He wrote: > > > arch/x86/mm/kaslr.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c > > > index aed2064..20b0456 100644 > > > --- a/arch/x86/mm/kaslr.c > > > +++ b/arch/x86/mm/kaslr.c > > > @@ -27,6 +27,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "mm_internal.h" > > > > > > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void) > > > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING; > > > > > > /* Adapt phyiscal memory region size based on available memory */ > > > - if (memory_tb < kaslr_regions[0].size_tb) > > > + if (memory_tb < kaslr_regions[0].size_tb && !is_early_uv_system()) > > > > Given your example, any way we could just restrict memory_tb to be > > 32TB? Or different configurations will result in different mappings? > > Thanks for looking into this, Thomas! > > For that machine where I used to reproduce the bug and test, 32TB memory > need be mapped to the direct mapping region. I am not sure if SGI UV > system has larger MMIOH region now or in the future in different machine. > If they have machine owning MMIOH region bigger than 64TB, then it's a > problem SGI UV need fix because that will break system whether kaslr > enabled or not. > > Hi Mike, Russ and Frank, > > About Thomas's question, could you help answer it? Could other SGI UV > system has MMIOH region bigger than 32TB? > > Thanks > Baoquan > > > > > > kaslr_regions[0].size_tb = memory_tb; > > > > > > /* Calculate entropy available between regions */
Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
On 05/21/17 at 01:38pm, Thomas Garnier wrote: > On Sat, May 20, 2017 at 5:02 AM, Baoquan He wrote: > > arch/x86/mm/kaslr.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c > > index aed2064..20b0456 100644 > > --- a/arch/x86/mm/kaslr.c > > +++ b/arch/x86/mm/kaslr.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include > > > > #include "mm_internal.h" > > > > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void) > > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING; > > > > /* Adapt phyiscal memory region size based on available memory */ > > - if (memory_tb < kaslr_regions[0].size_tb) > > + if (memory_tb < kaslr_regions[0].size_tb && !is_early_uv_system()) > > Given your example, any way we could just restrict memory_tb to be > 32TB? Or different configurations will result in different mappings? Thanks for looking into this, Thomas! For that machine where I used to reproduce the bug and test, 32TB memory need be mapped to the direct mapping region. I am not sure if SGI UV system has larger MMIOH region now or in the future in different machine. If they have machine owning MMIOH region bigger than 64TB, then it's a problem SGI UV need fix because that will break system whether kaslr enabled or not. Hi Mike, Russ and Frank, About Thomas's question, could you help answer it? Could other SGI UV system has MMIOH region bigger than 32TB? Thanks Baoquan > > > kaslr_regions[0].size_tb = memory_tb; > > > > /* Calculate entropy available between regions */
[PATCH] blackfin: merge the two TWI header files
There seems to be no need for separate ones since all users include both
files anyhow. Merge them because include/linux/i2c is to be deprecated.
Signed-off-by: Wolfram Sang
---
Only build tested (by buildbot) due to no HW.
arch/blackfin/include/asm/bfin_twi.h | 134 +++-
arch/blackfin/kernel/debug-mmrs.c| 1 -
drivers/i2c/busses/i2c-bfin-twi.c| 1 -
include/linux/i2c/bfin_twi.h | 145 ---
4 files changed, 133 insertions(+), 148 deletions(-)
delete mode 100644 include/linux/i2c/bfin_twi.h
diff --git a/arch/blackfin/include/asm/bfin_twi.h
b/arch/blackfin/include/asm/bfin_twi.h
index aaa0834d34aa7e..211e9c78f6fb89 100644
--- a/arch/blackfin/include/asm/bfin_twi.h
+++ b/arch/blackfin/include/asm/bfin_twi.h
@@ -1,7 +1,7 @@
/*
* bfin_twi.h - interface to Blackfin TWIs
*
- * Copyright 2005-2010 Analog Devices Inc.
+ * Copyright 2005-2014 Analog Devices Inc.
*
* Licensed under the GPL-2 or later.
*/
@@ -10,6 +10,138 @@
#define __ASM_BFIN_TWI_H__
#include
+#include
+#include
+
+/*
+ * ADI twi registers layout
+ */
+struct bfin_twi_regs {
+ u16 clkdiv;
+ u16 dummy1;
+ u16 control;
+ u16 dummy2;
+ u16 slave_ctl;
+ u16 dummy3;
+ u16 slave_stat;
+ u16 dummy4;
+ u16 slave_addr;
+ u16 dummy5;
+ u16 master_ctl;
+ u16 dummy6;
+ u16 master_stat;
+ u16 dummy7;
+ u16 master_addr;
+ u16 dummy8;
+ u16 int_stat;
+ u16 dummy9;
+ u16 int_mask;
+ u16 dummy10;
+ u16 fifo_ctl;
+ u16 dummy11;
+ u16 fifo_stat;
+ u16 dummy12;
+ u32 __pad[20];
+ u16 xmt_data8;
+ u16 dummy13;
+ u16 xmt_data16;
+ u16 dummy14;
+ u16 rcv_data8;
+ u16 dummy15;
+ u16 rcv_data16;
+ u16 dummy16;
+};
+
+struct bfin_twi_iface {
+ int irq;
+ spinlock_t lock;
+ charread_write;
+ u8 command;
+ u8 *transPtr;
+ int readNum;
+ int writeNum;
+ int cur_mode;
+ int manual_stop;
+ int result;
+ struct i2c_adapter adap;
+ struct completion complete;
+ struct i2c_msg *pmsg;
+ int msg_num;
+ int cur_msg;
+ u16 saved_clkdiv;
+ u16 saved_control;
+ struct bfin_twi_regs __iomem *regs_base;
+};
+
+/* TWO-WIRE INTERFACE (TWI) MASKS /
+/* TWI_CLKDIV Macros (Use: *pTWI_CLKDIV = CLKLOW(x)|CLKHI(y); ) */
+#defineCLKLOW(x) ((x) & 0xFF)/* Periods Clock Is Held Low */
+#define CLKHI(y) (((y)&0xFF)<<0x8) /* Periods Before New Clock Low */
+
+/* TWI_PRESCALE Masks */
+#definePRESCALE0x007F /* SCLKs Per Internal Time Reference
(10MHz) */
+#defineTWI_ENA 0x0080 /* TWI Enable */
+#defineSCCB0x0200 /* SCCB Compatibility Enable */
+
+/* TWI_SLAVE_CTL Masks */
+#defineSEN 0x0001 /* Slave Enable */
+#defineSADD_LEN0x0002 /* Slave Address Length */
+#defineSTDVAL 0x0004 /* Slave Transmit Data Valid */
+#defineNAK 0x0008 /* NAK Generated At Conclusion Of
Transfer */
+#defineGEN 0x0010 /* General Call Address Matching
Enabled */
+
+/* TWI_SLAVE_STAT Masks*/
+#defineSDIR0x0001 /* Slave Transfer Direction (RX/TX*) */
+#define GCALL 0x0002 /* General Call Indicator */
+
+/* TWI_MASTER_CTL Masks*/
+#defineMEN 0x0001 /* Master Mode Enable */
+#defineMADD_LEN0x0002 /* Master Address Length */
+#defineMDIR0x0004 /* Master Transmit Direction (RX/TX*) */
+#defineFAST0x0008 /* Use Fast Mode Timing Specs */
+#defineSTOP0x0010 /* Issue Stop Condition*/
+#defineRSTART 0x0020 /* Repeat Start or Stop* At End Of
Transfer */
+#defineDCNT0x3FC0 /* Data Bytes To Transfer */
+#defineSDAOVR 0x4000 /* Serial Data Override*/
+#defineSCLOVR 0x8000 /* Serial Clock Override */
+
+/* TWI_MASTER_STAT Masks */
+#defineMPROG 0x0001 /* Master Transfer In Progress */
+#defineLOSTARB 0x0002 /* Lost Arbitration Indicator (Xfer
Aborted) */
+#defineANAK0x0004 /* Address Not Acknowledged*/
+#defineDNAK0x0008 /* Data Not Acknowledged */
+#defineBUFRDERR0x0010 /* Buffer Read Error */
+#defineBUFWRERR0x0020 /* Buffer Write Error
Re: [lkp-robot] [waitid()] 75f64d68f9: Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode=
On Sun, May 21, 2017 at 2:37 PM, Linus Torvalds wrote: > > I'm pretty sure there's a reason we added support for it on x86-32, > because there are structures that use __u64 and fill things one entry > at a time. Did an "allyesconfig" build on 32-bit x86, and looked at who uses the 8-byte get_user/put_user cases: __get_user_8: i915_perf_open_ioctl __put_user_8: snapshot_ioctl sys_sendfile64 timerfd_read eventfd_read userfaultfd_ioctl kpagecgroup_read kpagecount_read kpageflags_read __ncp_ioctl blkdev_ioctl drm_mode_object_get_properties drm_mode_getproperty_ioctl efi_test_ioctl params_to_user __rds_rdma_map so it's not common, but both do get used. Would any of those be changed to the unsafe versions? Maybe not. But I think we're better off being consistent. We basically allow all kernel integer types to be used for put/get_user(), and the fact that some architectures don't support them is just a quirk of that architecture, not a sign that it shouldn't be done. Linus
[PATCH 0/1] gpu: move include files out of include/linux/i2c
It doesn't make sense to use include/linux/i2c for client drivers which may in
fact rather be hwmon or input or whatever devices. As a result, I want to
deprecate include/linux/i2c for good. This series moves the include files to a
better location, largely include/linux/platform_data because that is what most
of the moved include files contain. Please let me know if you think another
location is more suitable.
I prefer the series to go upstream via the subsystem tree; if you prefer that I
take it via I2C, just let me know.
No runtime testing because of no HW, but buildbot is happy with this series at
least. A branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data
Thanks and kind regards,
Wolfram
Wolfram Sang (1):
gpu: drm: tc35876x: move header file out of I2C realm
arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c | 2 +-
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 2 +-
include/linux/{i2c => platform_data}/tc35876x.h | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename include/linux/{i2c => platform_data}/tc35876x.h (100%)
--
2.11.0
[PATCH 1/1] gpu: drm: tc35876x: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c | 2 +-
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 2 +-
include/linux/{i2c => platform_data}/tc35876x.h | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename include/linux/{i2c => platform_data}/tc35876x.h (100%)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
b/arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
index b1526b95fd43ac..2905376559f160 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
@@ -11,7 +11,7 @@
*/
#include
-#include
+#include
#include
/*tc35876x DSI_LVDS bridge chip and panel platform data*/
diff --git a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
index 771ff66711af78..37c997e24b9ebb 100644
--- a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
+++ b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
@@ -26,7 +26,7 @@
#include "mdfld_output.h"
#include "mdfld_dsi_pkg_sender.h"
#include "tc35876x-dsi-lvds.h"
-#include
+#include
#include
#include
#include
diff --git a/include/linux/i2c/tc35876x.h
b/include/linux/platform_data/tc35876x.h
similarity index 100%
rename from include/linux/i2c/tc35876x.h
rename to include/linux/platform_data/tc35876x.h
--
2.11.0
[PATCH 1/2] video: adp8860: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/blackfin/mach-bf537/boards/stamp.c| 2 +-
drivers/video/backlight/adp8860_bl.c | 2 +-
include/linux/{i2c => platform_data}/adp8860.h | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename include/linux/{i2c => platform_data}/adp8860.h (100%)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index 24985e658c19cd..7db90c72bd8ddc 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -2047,7 +2047,7 @@ static struct adp8870_backlight_platform_data
adp8870_pdata = {
#endif
#if IS_ENABLED(CONFIG_BACKLIGHT_ADP8860)
-#include
+#include
static struct led_info adp8860_leds[] = {
{
.name = "adp8860-led7",
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index 510e559c060e59..e7315bf14d6015 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -18,7 +18,7 @@
#include
#include
-#include
+#include
#define ADP8860_EXT_FEATURES
#define ADP8860_USE_LEDS
diff --git a/include/linux/i2c/adp8860.h b/include/linux/platform_data/adp8860.h
similarity index 100%
rename from include/linux/i2c/adp8860.h
rename to include/linux/platform_data/adp8860.h
--
2.11.0
[PATCH 2/2] video: adp8870: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/blackfin/mach-bf537/boards/stamp.c| 2 +-
drivers/video/backlight/adp8870_bl.c | 2 +-
include/linux/{i2c => platform_data}/adp8870.h | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename include/linux/{i2c => platform_data}/adp8870.h (100%)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index 7db90c72bd8ddc..7528148dc4925b 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -1995,7 +1995,7 @@ static struct adp5588_gpio_platform_data
adp5588_gpio_data = {
#endif
#if IS_ENABLED(CONFIG_BACKLIGHT_ADP8870)
-#include
+#include
static struct led_info adp8870_leds[] = {
{
.name = "adp8870-led7",
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 21acac90fd773f..058d1def2d1f4b 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -18,7 +18,7 @@
#include
#include
-#include
+#include
#define ADP8870_EXT_FEATURES
#define ADP8870_USE_LEDS
diff --git a/include/linux/i2c/adp8870.h b/include/linux/platform_data/adp8870.h
similarity index 100%
rename from include/linux/i2c/adp8870.h
rename to include/linux/platform_data/adp8870.h
--
2.11.0
[PATCH 0/2] video: move include files out of include/linux/i2c
It doesn't make sense to use include/linux/i2c for client drivers which may in
fact rather be hwmon or input or whatever devices. As a result, I want to
deprecate include/linux/i2c for good. This series moves the include files to a
better location, largely include/linux/platform_data because that is what most
of the moved include files contain. Note that some files don't seem to have
upstream users in board code, so they maybe could even be removed? I didn't
check for that now, but I did it for one i2c master driver recently. So, it may
be possible.
I prefer the series to go upstream via the subsystem tree; if you prefer that I
take it via I2C, just let me know.
No runtime testing because of no HW, but buildbot is happy with this series at
least. A branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data
Thanks and kind regards,
Wolfram
Wolfram Sang (2):
video: adp8860: move header file out of I2C realm
video: adp8870: move header file out of I2C realm
arch/blackfin/mach-bf537/boards/stamp.c| 4 ++--
drivers/video/backlight/adp8860_bl.c | 2 +-
drivers/video/backlight/adp8870_bl.c | 2 +-
include/linux/{i2c => platform_data}/adp8860.h | 0
include/linux/{i2c => platform_data}/adp8870.h | 0
5 files changed, 4 insertions(+), 4 deletions(-)
rename include/linux/{i2c => platform_data}/adp8860.h (100%)
rename include/linux/{i2c => platform_data}/adp8870.h (100%)
--
2.11.0
[PATCH 2/3] mfd: tps65010: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/arm/mach-omap1/board-h2-mmc.c | 2 +-
arch/arm/mach-omap1/board-h2.c | 2 +-
arch/arm/mach-omap1/board-h3-mmc.c | 2 +-
arch/arm/mach-omap1/board-h3.c | 2 +-
arch/arm/mach-omap1/board-osk.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
drivers/mfd/tps65010.c | 2 +-
drivers/usb/host/ohci-omap.c| 2 +-
drivers/usb/phy/phy-isp1301-omap.c | 2 +-
drivers/video/fbdev/omap/lcd_h3.c | 2 +-
include/linux/{i2c => mfd}/tps65010.h | 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
rename include/linux/{i2c => mfd}/tps65010.h (99%)
diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
b/arch/arm/mach-omap1/board-h2-mmc.c
index 357be2debc9da8..91bda9c802ff38 100644
--- a/arch/arm/mach-omap1/board-h2-mmc.c
+++ b/arch/arm/mach-omap1/board-h2-mmc.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include "board-h2.h"
#include "mmc.h"
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 675254ee4b1e93..dece47d76282ac 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-h3-mmc.c
b/arch/arm/mach-omap1/board-h3-mmc.c
index 4f58bfa5e7549e..692c267a9a9052 100644
--- a/arch/arm/mach-omap1/board-h3-mmc.c
+++ b/arch/arm/mach-omap1/board-h3-mmc.c
@@ -14,7 +14,7 @@
#include
#include
-#include
+#include
#include "common.h"
#include "board-h3.h"
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index e62f9d454f1005..6d32beeb2d8857 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 4dfb995048103b..f20361b8ffb6e0 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -38,7 +38,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
index 262ab07447483a..6cac7da15e2b0d 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
@@ -17,7 +17,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c
b/arch/arm/mach-s3c24xx/mach-osiris.c
index 70b0eb7d31347f..64b1a0b7b803a1 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -24,7 +24,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
index d829a6131f09e5..2ab67386b4ef1e 100644
--- a/drivers/mfd/tps65010.c
+++ b/drivers/mfd/tps65010.c
@@ -32,7 +32,7 @@
#include
#include
-#include
+#include
#include
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index a4d814b7f38066..91393ec7d8503c 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -53,7 +53,7 @@
#define DRIVER_DESC "OHCI OMAP driver"
#ifdef CONFIG_TPS65010
-#include
+#include
#else
#define LOW0
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 042c5a8fd423d8..c6052c814bcc24 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -96,7 +96,7 @@ struct isp1301 {
#if IS_REACHABLE(CONFIG_TPS65010)
-#include
+#include
#else
diff --git a/drivers/video/fbdev/omap/lcd_h3.c
b/drivers/video/fbdev/omap/lcd_h3.c
index 9d2da146813ef0..796f4634c4c6f1 100644
--- a/drivers/video/fbdev/omap/lcd_h3.c
+++ b/drivers/video/fbdev/omap/lcd_h3.c
@@ -21,7 +21,7 @@
#include
#include
-#include
+#include
#include
#include "omapfb.h"
diff --git a/include/linux/i2c/tps65010.h b/include/linux/mfd/tps65010.h
similarity index 99%
rename from include/linux/i2c/tps65010.h
rename to include/linux/mfd/tps65010.h
index 08aa92278d71cd..a1fb9bc5311de4 100644
--- a/include/linux/i2c/tps65010.h
+++ b/include/linux/mfd/tps65010.h
@@ -1,4 +1,4 @@
-/* linux/i2c/tps65010.h
+/* linux/mfd/tps65010.h
*
* Functions to access TPS65010 power management device.
*
--
2.11.0
[PATCH 3/3] mfd: twl: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/arm/mach-omap2/common.h| 2 +-
arch/arm/mach-omap2/omap_twl.c | 2 +-
drivers/gpio/gpio-twl4030.c | 2 +-
drivers/iio/adc/twl4030-madc.c | 2 +-
drivers/iio/adc/twl6030-gpadc.c | 2 +-
drivers/input/keyboard/twl4030_keypad.c | 2 +-
drivers/input/misc/twl4030-pwrbutton.c | 2 +-
drivers/input/misc/twl4030-vibra.c | 2 +-
drivers/mfd/twl-core.c | 6 +++---
drivers/mfd/twl4030-audio.c | 2 +-
drivers/mfd/twl4030-irq.c | 2 +-
drivers/mfd/twl4030-power.c | 2 +-
drivers/mfd/twl6030-irq.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 2 +-
drivers/power/supply/twl4030_charger.c | 2 +-
drivers/pwm/pwm-twl-led.c | 2 +-
drivers/pwm/pwm-twl.c | 2 +-
drivers/regulator/twl-regulator.c | 2 +-
drivers/regulator/twl6030-regulator.c | 2 +-
drivers/rtc/rtc-twl.c | 2 +-
drivers/usb/phy/phy-twl6030-usb.c | 2 +-
drivers/video/backlight/pandora_bl.c| 2 +-
drivers/watchdog/twl4030_wdt.c | 2 +-
include/linux/{i2c => mfd}/twl.h| 0
sound/soc/codecs/twl4030.c | 2 +-
25 files changed, 26 insertions(+), 26 deletions(-)
rename include/linux/{i2c => mfd}/twl.h (100%)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 8cc6338fcb1288..b5ad7fcb80ed24 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -29,7 +29,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 1346b3ab34a5e3..295124b248ae3f 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -16,7 +16,7 @@
#include
#include
#include
-#include
+#include
#include "soc.h"
#include "voltage.h"
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 24f388ed46d4c4..9b511df5450eb6 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -35,7 +35,7 @@
#include
#include
-#include
+#include
/*
* The GPIO "subchip" supports 18 GPIOs which can be configured as
diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
index 0c74869a540ad3..5a64eda1652061 100644
--- a/drivers/iio/adc/twl4030-madc.c
+++ b/drivers/iio/adc/twl4030-madc.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
index becbb0aef232b9..bc0e60b9da452e 100644
--- a/drivers/iio/adc/twl6030-gpadc.c
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -33,7 +33,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 39e72b3219d8a4..f9f98ef1d98e3f 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index 1c13005b228fa7..b307cca1702226 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -27,7 +27,7 @@
#include
#include
#include
-#include
+#include
#define PWR_PWRON_IRQ (1 << 0)
diff --git a/drivers/input/misc/twl4030-vibra.c
b/drivers/input/misc/twl4030-vibra.c
index caa5a62c42fbe0..6c51d404874bbd 100644
--- a/drivers/input/misc/twl4030-vibra.c
+++ b/drivers/input/misc/twl4030-vibra.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index c64615dca2bd33..2a09dde4ca6efc 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -44,7 +44,7 @@
#include
#include
-#include
+#include
/* Register descriptions for audio */
#include
@@ -173,7 +173,7 @@ static struct twl_private *twl_priv;
static struct twl_mapping twl4030_map[] = {
/*
* NOTE: don't change this table without updating the
-* defines for TWL4030_MODULE_*
+* defines for TWL4030_MODULE_*
* so they continue to match the order in this table.
*/
@@ -344,7 +344,7 @@ static const struct regmap_config twl4030_regmap_config[4]
= {
static struct twl_mapping twl6030_map[] = {
/*
* NOTE: don't change this table without updating the
-* defines for TWL4030_MODULE_*
+* defines for TWL4030_MODULE_*
* so they continue to match the order in this table.
*/
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index 0a160648
[PATCH 1/3] mfd: dm355evm_msp: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
drivers/input/misc/dm355evm_keys.c| 2 +-
drivers/mfd/dm355evm_msp.c| 2 +-
drivers/rtc/rtc-dm355evm.c| 2 +-
include/linux/{i2c => mfd}/dm355evm_msp.h | 0
4 files changed, 3 insertions(+), 3 deletions(-)
rename include/linux/{i2c => mfd}/dm355evm_msp.h (100%)
diff --git a/drivers/input/misc/dm355evm_keys.c
b/drivers/input/misc/dm355evm_keys.c
index bab256ef32b9b3..c803db64a3760d 100644
--- a/drivers/input/misc/dm355evm_keys.c
+++ b/drivers/input/misc/dm355evm_keys.c
@@ -15,7 +15,7 @@
#include
#include
-#include
+#include
#include
diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
index 86eca614507bd8..2a2756709f22f0 100644
--- a/drivers/mfd/dm355evm_msp.c
+++ b/drivers/mfd/dm355evm_msp.c
@@ -18,7 +18,7 @@
#include
#include
#include
-#include
+#include
/*
diff --git a/drivers/rtc/rtc-dm355evm.c b/drivers/rtc/rtc-dm355evm.c
index f225cd873ff6c2..97d8259b94940f 100644
--- a/drivers/rtc/rtc-dm355evm.c
+++ b/drivers/rtc/rtc-dm355evm.c
@@ -13,7 +13,7 @@
#include
#include
-#include
+#include
#include
diff --git a/include/linux/i2c/dm355evm_msp.h b/include/linux/mfd/dm355evm_msp.h
similarity index 100%
rename from include/linux/i2c/dm355evm_msp.h
rename to include/linux/mfd/dm355evm_msp.h
--
2.11.0
[PATCH] gpu: ipu-v3: vdic: include AUTO field order bit in ipu_vdi_set_field_order
The field order selection in VDIC_C register uses different bits
depending on whether the VDIC is receiving from a CSI ("AUTO") or
from memory ("MAN"). Since the VDIC cannot receive from both CSI
and memory at the same time, set or clear both field order bits to
cover both cases.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-vdi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-vdi.c b/drivers/gpu/ipu-v3/ipu-vdi.c
index f27bf5a..a663893 100644
--- a/drivers/gpu/ipu-v3/ipu-vdi.c
+++ b/drivers/gpu/ipu-v3/ipu-vdi.c
@@ -88,9 +88,9 @@ void ipu_vdi_set_field_order(struct ipu_vdi *vdi, v4l2_std_id
std, u32 field)
reg = ipu_vdi_read(vdi, VDI_C);
if (top_field_0)
- reg &= ~VDI_C_TOP_FIELD_MAN_1;
+ reg &= ~(VDI_C_TOP_FIELD_MAN_1 | VDI_C_TOP_FIELD_AUTO_1);
else
- reg |= VDI_C_TOP_FIELD_MAN_1;
+ reg |= VDI_C_TOP_FIELD_MAN_1 | VDI_C_TOP_FIELD_AUTO_1;
ipu_vdi_write(vdi, reg, VDI_C);
spin_unlock_irqrestore(&vdi->lock, flags);
--
2.7.4
[PATCH 0/3] mfd: move include files out of include/linux/i2c
It doesn't make sense to use include/linux/i2c for client drivers which may in
fact rather be hwmon or input or whatever devices. As a result, I want to
deprecate include/linux/i2c for good. This series moves the include files to a
better location, for the mfd subsystem to include/linux/mfd. Because of twl.h,
this touches quite some subsystems, but I still think it is worth it.
I prefer the series to go upstream via the subsystem tree; if you prefer that I
take it via I2C, just let me know.
No runtime testing because of no HW, but buildbot is happy with this series at
least. A branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data
Thanks and kind regards,
Wolfram
Wolfram Sang (3):
mfd: dm355evm_msp: move header file out of I2C realm
mfd: tps65010: move header file out of I2C realm
mfd: twl: move header file out of I2C realm
arch/arm/mach-omap1/board-h2-mmc.c| 2 +-
arch/arm/mach-omap1/board-h2.c| 2 +-
arch/arm/mach-omap1/board-h3-mmc.c| 2 +-
arch/arm/mach-omap1/board-h3.c| 2 +-
arch/arm/mach-omap1/board-osk.c | 2 +-
arch/arm/mach-omap2/common.h | 2 +-
arch/arm/mach-omap2/omap_twl.c| 2 +-
arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
drivers/gpio/gpio-twl4030.c | 2 +-
drivers/iio/adc/twl4030-madc.c| 2 +-
drivers/iio/adc/twl6030-gpadc.c | 2 +-
drivers/input/keyboard/twl4030_keypad.c | 2 +-
drivers/input/misc/dm355evm_keys.c| 2 +-
drivers/input/misc/twl4030-pwrbutton.c| 2 +-
drivers/input/misc/twl4030-vibra.c| 2 +-
drivers/mfd/dm355evm_msp.c| 2 +-
drivers/mfd/tps65010.c| 2 +-
drivers/mfd/twl-core.c| 6 +++---
drivers/mfd/twl4030-audio.c | 2 +-
drivers/mfd/twl4030-irq.c | 2 +-
drivers/mfd/twl4030-power.c | 2 +-
drivers/mfd/twl6030-irq.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 2 +-
drivers/power/supply/twl4030_charger.c| 2 +-
drivers/pwm/pwm-twl-led.c | 2 +-
drivers/pwm/pwm-twl.c | 2 +-
drivers/regulator/twl-regulator.c | 2 +-
drivers/regulator/twl6030-regulator.c | 2 +-
drivers/rtc/rtc-dm355evm.c| 2 +-
drivers/rtc/rtc-twl.c | 2 +-
drivers/usb/host/ohci-omap.c | 2 +-
drivers/usb/phy/phy-isp1301-omap.c| 2 +-
drivers/usb/phy/phy-twl6030-usb.c | 2 +-
drivers/video/backlight/pandora_bl.c | 2 +-
drivers/video/fbdev/omap/lcd_h3.c | 2 +-
drivers/watchdog/twl4030_wdt.c| 2 +-
include/linux/{i2c => mfd}/dm355evm_msp.h | 0
include/linux/{i2c => mfd}/tps65010.h | 2 +-
include/linux/{i2c => mfd}/twl.h | 0
sound/soc/codecs/twl4030.c| 2 +-
41 files changed, 41 insertions(+), 41 deletions(-)
rename include/linux/{i2c => mfd}/dm355evm_msp.h (100%)
rename include/linux/{i2c => mfd}/tps65010.h (99%)
rename include/linux/{i2c => mfd}/twl.h (100%)
--
2.11.0
[PATCH 1/3] gpio: max732x: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/arm/mach-pxa/littleton.c | 2 +-
drivers/gpio/gpio-max732x.c| 2 +-
include/linux/{i2c => platform_data}/max732x.h | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename include/linux/{i2c => platform_data}/max732x.h (100%)
diff --git a/arch/arm/mach-pxa/littleton.c b/arch/arm/mach-pxa/littleton.c
index 051c554776a6e7..fae38fdc8d8e56 100644
--- a/arch/arm/mach-pxa/littleton.c
+++ b/arch/arm/mach-pxa/littleton.c
@@ -27,7 +27,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/gpio/gpio-max732x.c b/drivers/gpio/gpio-max732x.c
index 4ea4c6a1313b13..7f4d26ce5f231a 100644
--- a/drivers/gpio/gpio-max732x.c
+++ b/drivers/gpio/gpio-max732x.c
@@ -20,7 +20,7 @@
#include
#include
#include
-#include
+#include
#include
diff --git a/include/linux/i2c/max732x.h b/include/linux/platform_data/max732x.h
similarity index 100%
rename from include/linux/i2c/max732x.h
rename to include/linux/platform_data/max732x.h
--
2.11.0
[PATCH 2/3] gpio: pcf857x: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/arm/mach-davinci/board-da830-evm.c| 2 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-pxa/balloon3.c | 2 +-
arch/arm/mach-pxa/stargate2.c | 2 +-
arch/mips/ath79/mach-pb44.c| 2 +-
drivers/gpio/gpio-pcf857x.c| 2 +-
include/linux/{i2c => platform_data}/pcf857x.h | 0
8 files changed, 7 insertions(+), 7 deletions(-)
rename include/linux/{i2c => platform_data}/pcf857x.h (100%)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 58075627c6df3e..f673cd7a676658 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 20f1874a5657e2..70e00dbeec9694 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index cb176826d1cbe4..ca69d0b96a4f07 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index d452a49c039647..1467c1d1e54194 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -27,7 +27,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-pxa/stargate2.c b/arch/arm/mach-pxa/stargate2.c
index 7b6610e9dae46c..2d45d18b1a5e0a 100644
--- a/arch/arm/mach-pxa/stargate2.c
+++ b/arch/arm/mach-pxa/stargate2.c
@@ -26,7 +26,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/mips/ath79/mach-pb44.c b/arch/mips/ath79/mach-pb44.c
index 67b980d94fb7aa..be78298dffb4f3 100644
--- a/arch/mips/ath79/mach-pb44.c
+++ b/arch/mips/ath79/mach-pb44.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include "machtypes.h"
#include "dev-gpio-buttons.h"
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 8ddf9302ce3b07..a4fd78b9c0e4e3 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -20,7 +20,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/include/linux/i2c/pcf857x.h b/include/linux/platform_data/pcf857x.h
similarity index 100%
rename from include/linux/i2c/pcf857x.h
rename to include/linux/platform_data/pcf857x.h
--
2.11.0
[PATCH 3/3] gpio: adp5588: move header file out of I2C realm
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
This driver could also go via the input-tree or my tree. I don't really care
and just picked some subsystem :) Let me know if you are okay with that.
arch/blackfin/mach-bf537/boards/stamp.c| 2 +-
drivers/gpio/gpio-adp5588.c| 2 +-
drivers/input/keyboard/adp5588-keys.c | 2 +-
include/linux/{i2c => platform_data}/adp5588.h | 0
4 files changed, 3 insertions(+), 3 deletions(-)
rename include/linux/{i2c => platform_data}/adp5588.h (100%)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index eaec7b4832a29a..24985e658c19cd 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -22,7 +22,7 @@
#include
#endif
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpio/gpio-adp5588.c b/drivers/gpio/gpio-adp5588.c
index c0f718b1231727..e717f8dc39667c 100644
--- a/drivers/gpio/gpio-adp5588.c
+++ b/drivers/gpio/gpio-adp5588.c
@@ -16,7 +16,7 @@
#include
#include
-#include
+#include
#define DRV_NAME "adp5588-gpio"
diff --git a/drivers/input/keyboard/adp5588-keys.c
b/drivers/input/keyboard/adp5588-keys.c
index 53fe9a3fb6204d..f9d273c8b30695 100644
--- a/drivers/input/keyboard/adp5588-keys.c
+++ b/drivers/input/keyboard/adp5588-keys.c
@@ -20,7 +20,7 @@
#include
#include
-#include
+#include
/* Key Event Register xy */
#define KEY_EV_PRESSED (1 << 7)
diff --git a/include/linux/i2c/adp5588.h b/include/linux/platform_data/adp5588.h
similarity index 100%
rename from include/linux/i2c/adp5588.h
rename to include/linux/platform_data/adp5588.h
--
2.11.0
