Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers

[Sascha Hauer]

On Thu, Jun 18, 2015 at 02:33:48PM +0200, Ludovic Desroches wrote:
> On Wed, Jun 17, 2015 at 09:55:56AM -0600, Stephen Warren wrote:
> > On 06/17/2015 06:38 AM, Ludovic Desroches wrote:
> > >Hi Stephen,
> > >
> > >On Mon, Jun 15, 2015 at 09:58:05AM -0600, Stephen Warren wrote:
> > >>On 06/10/2015 09:04 AM, Ludovic Desroches wrote:
> > >>>When having a controller which allows per pin muxing, declaring with
> > >>>which groups a function can be used is a useless constraint since groups
> > >>>are something virtual.
> > >>
> > >>This isn't true.
> > >>
> > >>Irrespective of whether a particular piece of pinmux HW can control the 
> > >>mux
> > >>function for each pin individually, or only in groups, it's quite likely
> > >>that each function can only be selected onto a subset of those pins or
> > >>groups. Requiring the pinctrl driver to inform the core which set of
> > >>pins/groups particular functions can be selected onto seems quite
> > >>reasonable.
> > >>
> > >>In my opinion at least, for HW that can select the mux function at the
> > >>per-pin level, the only sensible set of groups is one group per pin with
> > >>each group containing a single pin. Any other use of groups is a
> > >>SW/user-level construct, and is something unrelated to why the pinctrl
> > >>subsystem supports groups. If we want to represent those groups in 
> > >>pinctrl,
> > >>there should be two separate sets of groups; one to represent the actual 
> > >>HW
> > >>capabilities, and one to represent the SW/user-level convenience
> > >>abstractions.
> > >
> > >Groups that I would like to use are not something related to the user or
> > >software. It's an hardware reality but they would be more flexibles.
> > >
> > >Usually the muxing is done by selecting a function (which seems to be
> > >device related: usart, spi, etc.), then you select on which pins you
> > >want this function.
> > >
> > >In my case, I can't select a function only by choosing a mux. It is a
> > >combination of the mux and the pin on which it is applied. So my
> > >functions will be GPIO, A, B, C, etc. If I use function A on pin 12, I
> > >will have my i2c clock signal but I can have this signal on pin 58 if I
> > >use function C. Do you understand what I mean? It's not very easy to
> > >explain... So here is a real example:
> > >
> > >  --
> > >|  | pio peripheral|
> > >  --
> > >| signal | dir | func | signal   | dir | ioset |
> > >  --
> > >| PA8| I/O | A| SDMMC0_DAT6  | I/O | 1 |
> > >|| | B| QSPI1_IO1| I/O | 1 |
> > >|| | D| TCLK5| I   | 1 |
> > >|| | E| FLEXCOM2_IO2 | I/O | 1 |
> > >|| | F| NWE/NANDWE   | O   | 2 |
> > >  --
> > >| PD28   | I/O | A| SPI1_NPCS0   | I/O | 3 |
> > >|| | B| TDI  | I/O | 3 |
> > >|| | C| FLEXCOM2_IO2 | I   | 2 |
> > >  --
> > >
> > >
> > >You are right that having a group per pin is a solution.
> > >
> > >If I follow your proposal (tell me if I'm wrong):
> > >- I will have 128 groups since I have 128 pins.
> > 
> > Yes.
> > 
> > >- I will have functions GPIO, A, B, C, D, E, F.
> > 
> > You could have functions A..F, and require the user to determine what option
> > they want for each pin, find the pin-specific mux function value for each
> > pin, and put that into the DT (or other pinmux data source). For example,
> > the bcm2835 pinctrl driver works this way.
> > 
> > In that case, each of the functions A..F could be selected on each pin, so
> > you'd have a very simple "get pins for function" implementation.
> > 
> > Alternatively, you could define a logic function per IO controller or signal
> > that gets pinmuxed. In the example above, FLEXCOM2_IO2 is one such example.
> > Given that set of functions, you'd need a mapping table to convert from the
> > logical functions seen by the pinctrl subsystem to the HW values that need
> > to be written into registers. For example, the Tegra pinctrl drivers work
> > this way.
> > 
> > In that case, each (pinctrl) function could only be selected on a specific
> > subset of all pins/groups, and so you'd probably need a table-based
> > implementation of "get pins for function".
> 
> Thanks for giving me some examples. Let's take a look at these drivers.
> My concern is that I didnn't want to have many and/or big tables in my
> driver. I will have to update it for a new SoC even if the pin
> controller is the same. I prefer to have it in the device as we did
> before and as some drivers continue to do.
> 
> > 
> > >- I have to give the groups which can achieve a function so I will have
> > >128 groups for each function. It means 128 x 7 = 896 groups.
> > 
> > I 

Re: [PATCH] Staging: fbtft: Add support for the Ultrachip UC1611 LCD controller

[Sudip Mukherjee]

On Tue, Jul 14, 2015 at 03:26:12AM +0200, Henri Chain wrote:
> This is a driver chip for 240x160 4-bit greyscale LCDs.
> It is capable of 4-wire (8 bit) or 3-wire (9 bit) SPI that have both been
> tested. (It also has a 6800 or 8080-style parallel interface, but I have
> not included support for it.)
> 
> Signed-off-by: Henri Chain 
> ---

> +}
> +
> +static void set_addr_win(struct fbtft_par *par, int xs, int ys, int xe, int 
> ye)
> +{
> + fbtft_par_dbg(DEBUG_SET_ADDR_WIN, par,
> + "%s(xs=%d, ys=%d, xe=%d, ye=%d)\n", __func__, xs, ys, xe, ye);
checkpatch complains:
Alignment should match open parenthesis.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] checkpatch: Improve SUSPECT_CODE_INDENT test

[Joe Perches]

Many lines exist like

if (foo)
bar;

where the tabbed indentation of the branch is not
one more than the "if" line above it.

checkpatch should emit a warning on those lines.

Miscellenea:

o Remove comments from branch blocks
o Skip blank lines in block

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 90e1edc..4748b83 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3067,15 +3067,22 @@ sub process {
 
substr($s, 0, length($c), '');
 
-   # Make sure we remove the line prefixes as we have
-   # none on the first line, and are going to readd them
-   # where necessary.
-   $s =~ s/\n./\n/gs;
+   # remove inline comments
+   $s =~ s/$;/ /g;
+   $c =~ s/$;/ /g;
 
# Find out how long the conditional actually is.
my @newlines = ($c =~ /\n/gs);
my $cond_lines = 1 + $#newlines;
 
+   # Make sure we remove the line prefixes as we have
+   # none on the first line, and are going to readd them
+   # where necessary.
+   $s =~ s/\n./\n/gs;
+   while ($s =~ /\n\s+\\\n/) {
+   $cond_lines += $s =~ s/\n\s+\\\n/\n/g;
+   }
+
# We want to check the first line inside the block
# starting at the end of the conditional, so remove:
#  1) any blank line termination
@@ -3141,8 +3148,10 @@ sub process {
 
#print "line<$line> prevline<$prevline> indent<$indent> 
sindent<$sindent> check<$check> continuation<$continuation> s<$s> 
cond_lines<$cond_lines> stat_real<$stat_real> stat<$stat>\n";
 
-   if ($check && (($sindent % 8) != 0 ||
-   ($sindent <= $indent && $s ne ''))) {
+   if ($check && $s ne '' &&
+   (($sindent % 8) != 0 ||
+($sindent < $indent) ||
+($sindent > $indent + 8))) {
WARN("SUSPECT_CODE_INDENT",
 "suspect code indent for conditional 
statements ($indent, $sindent)\n" . $herecurr . "$stat_real\n");
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Jul 14

[Stephen Rothwell]

Hi all,

Changes since 20150713:

The net-next tree gained a conflict against Linus' tree.

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The drm-misc tree gained a build failure so I used the version from
next-20150713.

The akpm tree regained an old build failure for which I applied the
fix patch.

Non-merge commits (relative to Linus' tree): 1542
 1366 files changed, 79279 insertions(+), 23098 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 for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 223 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

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 Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (f760b87f8f12 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off 
warning)
Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg())
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (bc0195aad0da Linux 4.2-rc2)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1)
Merging sparc/master (4a10a91756ef Merge branch 'upstream' of 
git://git.infradead.org/users/pcmoore/audit)
Merging net/master (cee9f6d0186a Merge tag 'linux-can-fixes-for-4.2-20150712' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can)
Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at 
start of day.)
Merging sound-current/for-linus (d1f15e06b2af ALSA: hda - Fix a wrong busy 
check in alt PCM open)
Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during 
alignment reordering)
Merging wireless-drivers/master (7865598ec24a ath9k_hw: fix device ID check for 
AR956x)
Merging driver-core.current/driver-core-linus (bc0195aad0da Linux 4.2-rc2)
Merging tty.current/tty-linus (bc0195aad0da Linux 4.2-rc2)
Merging usb.current/usb-linus (d4669bb1427c Merge tag 'fixes-for-v4.2-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (b2e2c94b878b usb: gadget: f_midi: fix error 
recovery path)
Merging usb-serial-fixes/usb-linus (d23f47d4927f USB: serial: Destroy 
serial_minors IDR on module exit)
Merging staging.current/staging-linus (8c5dfdbbebf5 Merge tag 
'iio-fixes-for-4.2b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (bc0195aad0da Linux 4.2-rc2)
Merging input-current/for-linus (dbf3c370862d Revert "Input: synaptics - 
allocate 3 slots to keep stability in image sensors")
Merging crypto-current/master (030f4e968741 crypto: nx - Fix reentrancy bugs)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (758556bdc1c8 module: Fix load_module() error path)
Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible 
timeout)
Merging kselftest-fixes/fixes (d770e558e219 Linux 4.2-rc1)
Merging backlight-fixes/for

Re: [patch 18/19] gpio/msm-v2: Avoid redundant lookup of irq_data

[Jiang Liu]

On 2015/7/14 13:28, Ilia Mirkin wrote:
> 
> On Jul 13, 2015 4:42 PM, "Thomas Gleixner"  > wrote:
>>
>> It's pretty silly to do
>>
>>  irq_data *d = irq_get_irq_data(irq_data->irq);
>>
>> because that results in d = irq_data, but goes through a lookup of the
>> irq_data. Use irq_data directly.
>>
>> Signed-off-by: Thomas Gleixner  >
>> Cc: Linus Walleij  >
>> Cc: Alexandre Courbot mailto:gnu...@gmail.com>>
>> Cc: Jiang Liu  >
>> Cc: linux-g...@vger.kernel.org 
>> ---
>>  drivers/gpio/gpio-msm-v2.c |   18 +-
>>  1 file changed, 5 insertions(+), 13 deletions(-)
>>
>> Index: tip/drivers/gpio/gpio-msm-v2.c
>> ===
>> --- tip.orig/drivers/gpio/gpio-msm-v2.c
>> +++ tip/drivers/gpio/gpio-msm-v2.c
>> @@ -187,14 +187,6 @@ static int msm_gpio_to_irq(struct gpio_c
>> return irq_create_mapping(domain, offset);
>>  }
>>
>> -static inline int msm_irq_to_gpio(struct gpio_chip *chip, unsigned irq)
>> -{
>> -   struct irq_data *irq_data = irq_get_irq_data(irq);
>> -
>> -   return irq_data->hwirq;
>> -}
>> -
>> -
>>  /* For dual-edge interrupts in software, since the hardware has no
>>   * such support:
>>   *
>> @@ -238,7 +230,7 @@ static void msm_gpio_update_dual_edge_po
>>w
>>  static void msm_gpio_irq_ack(struct irq_data *d)
>>  {
>> -   int gpio = msm_irq_to_gpio(_gpio.gpio_chip, d->irq);
>> +   int gpio = d->hw_irq;
> 
> Does this build? It was hwirq above, not hw_irq.

Yeah, should be hwirq.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Documentation: mm: fix location of extfrag_index

[Rabin Vincent]

/proc/extfrag_index does not exist.  This file is in debugfs.  Fix the
description of extfrag_threshold to reflect this.

Signed-off-by: Rabin Vincent 
---
 Documentation/sysctl/vm.txt |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 9832ec5..9c3f2f8 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -225,11 +225,11 @@ with your system.  To disable them, echo 4 (bit 3) into 
drop_caches.
 extfrag_threshold
 
 This parameter affects whether the kernel will compact memory or direct
-reclaim to satisfy a high-order allocation. /proc/extfrag_index shows what
-the fragmentation index for each order is in each zone in the system. Values
-tending towards 0 imply allocations would fail due to lack of memory,
-values towards 1000 imply failures are due to fragmentation and -1 implies
-that the allocation will succeed as long as watermarks are met.
+reclaim to satisfy a high-order allocation. The extfrag/extfrag_index file in
+debugfs shows what the fragmentation index for each order is in each zone in
+the system. Values tending towards 0 imply allocations would fail due to lack
+of memory, values towards 1000 imply failures are due to fragmentation and -1
+implies that the allocation will succeed as long as watermarks are met.
 
 The kernel will not compact memory in a zone if the
 fragmentation index is <= extfrag_threshold. The default value is 500.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rhashtable] WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:301 __debug_object_init()

[Fengguang Wu]

rg/pub/scm/linux/kernel/git/davem/net-next
> git bisect good 1d9c5d79e6e4385aea6f69c23ba543717434ed70  # 09:14 22+ 
>  0  Merge branch 'for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching
> git bisect good 29afc4e9a408f2304e09c6dd0dbcfbd2356d0faa  # 09:18 22+ 
>  0  Merge branch 'for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
> git bisect  bad fd3e646c87ab3f2ba98aa25394581af27cc78dc5  # 09:27  0- 
> 22  net: act_bpf: fix size mismatch on filter preparation
> git bisect  bad e84448d52190413400663736067f826f28a04ad6  # 09:32  0- 
> 22  xen-netfront: refactor skb slot counting
> git bisect  bad 829a3ada9cc7d4c30fa61f8033403fb6c8f8092a  # 09:38  0- 
>  1  geneve: Simplify locking.
> git bisect good a4c9ea5e8fec680134d22aa99b54d1cd8c226ebd  # 09:42 22+ 
> 12  geneve: Add Geneve GRO support
> git bisect good 255047b0dca31e6b8ce254481a0b65d559d2ebb8  # 09:46 20+ 
>  0  Bluetooth: Add timing information to SMP test case runs
> git bisect good 354f473ee2c5d01c1cf90f747f95218ee3e73e95  # 09:52 22+ 
>  0  ath9k: fix typo
> git bisect good d312da293f787e1b19c57acb58e8c1b171c4a04a  # 09:59 22+ 
>  0  ixgbe: convert to CYCLECOUNTER_MASK macro.
> git bisect good b8e1943e9f754219bcfb40bac4a605b5348acb25  # 10:03 22+ 
>  8  rhashtable: Factor out bucket_tail() function
> git bisect  bad f89bd6f87a53ce5a7d60662429591ebac2745c10  # 10:08  0- 
> 22  rhashtable: Supports for nulls marker
> git bisect good 113948d841e8d78039e5dbbb5248f5b73e99eafa  # 10:12 22+ 
> 13  spinlock: Add spin_lock_bh_nested()
> git bisect  bad 97defe1ecf868b8127f8e62395499d6a06e4c4b1  # 10:16  0- 
> 22  rhashtable: Per bucket locks & deferred expansion/shrinking
> # first bad commit: [97defe1ecf868b8127f8e62395499d6a06e4c4b1] rhashtable: 
> Per bucket locks & deferred expansion/shrinking
> git bisect good 113948d841e8d78039e5dbbb5248f5b73e99eafa  # 10:19 66+ 
> 27  spinlock: Add spin_lock_bh_nested()
> # extra tests with DEBUG_INFO
> git bisect  bad 97defe1ecf868b8127f8e62395499d6a06e4c4b1  # 10:25  0- 
> 66  rhashtable: Per bucket locks & deferred expansion/shrinking
> # extra tests on HEAD of linux-devel/devel-spot-201507122014
> git bisect good 3afd2c3f65a385c405a084d80431c84b103cb6df  # 10:28 66+ 
> 49  0day head guard for 'devel-spot-201507122014'
> # extra tests on tree/branch linus/master
> git bisect good f760b87f8f12eb262f14603e65042996fe03720e  # 10:33 66+ 
>  0  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> # extra tests on tree/branch linus/master
> git bisect good f760b87f8f12eb262f14603e65042996fe03720e  # 10:33 66+ 
>  0  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> # extra tests on tree/branch next/master
> git bisect good 2eb62d762a2112579f259903e62ba18d16c51f66  # 10:36 66+ 
> 20  Add linux-next specific files for 20150713
> 
> 
> This script may reproduce the error.
> 
> 
> #!/bin/bash
> 
> kernel=$1
> initrd=yocto-minimal-x86_64.cgz
> 
> wget --no-clobber 
> https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
> 
> kvm=(
>   qemu-system-x86_64
>   -enable-kvm
>   -cpu Haswell,+smep,+smap
>   -kernel $kernel
>   -initrd $initrd
>   -m 256
>   -smp 1
>   -device e1000,netdev=net0
>   -netdev user,id=net0
>   -boot order=nc
>   -no-reboot
>   -watchdog i6300esb
>   -rtc base=localtime
>   -serial stdio
>   -display none
>   -monitor null 
> )
> 
> append=(
>   hung_task_panic=1
>   earlyprintk=ttyS0,115200
>   systemd.log_level=err
>   debug
>   apic=debug
>   sysrq_always_enabled
>   rcupdate.rcu_cpu_stall_timeout=100
>   panic=-1
>   softlockup_panic=1
>   nmi_watchdog=panic
>   oops=panic
>   load_ramdisk=2
>   prompt_ramdisk=0
>   console=ttyS0,115200
>   console=tty0
>   vga=normal
>   root=/dev/ram0
>   rw
>   drbd.minor_count=8
> )
> 
> "${kvm[@]}" --append "${append[*]}"
> 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/lkp  Intel Corporation

> early console in setup code
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Linux version 3.19.0-rc2-00323-g97def

[rhashtable] WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:301 __debug_object_init()

[Fengguang Wu]

9:52 22+  
0  ath9k: fix typo
git bisect good d312da293f787e1b19c57acb58e8c1b171c4a04a  # 09:59 22+  
0  ixgbe: convert to CYCLECOUNTER_MASK macro.
git bisect good b8e1943e9f754219bcfb40bac4a605b5348acb25  # 10:03 22+  
8  rhashtable: Factor out bucket_tail() function
git bisect  bad f89bd6f87a53ce5a7d60662429591ebac2745c10  # 10:08  0- 
22  rhashtable: Supports for nulls marker
git bisect good 113948d841e8d78039e5dbbb5248f5b73e99eafa  # 10:12 22+ 
13  spinlock: Add spin_lock_bh_nested()
git bisect  bad 97defe1ecf868b8127f8e62395499d6a06e4c4b1  # 10:16  0- 
22  rhashtable: Per bucket locks & deferred expansion/shrinking
# first bad commit: [97defe1ecf868b8127f8e62395499d6a06e4c4b1] rhashtable: Per 
bucket locks & deferred expansion/shrinking
git bisect good 113948d841e8d78039e5dbbb5248f5b73e99eafa  # 10:19 66+ 
27  spinlock: Add spin_lock_bh_nested()
# extra tests with DEBUG_INFO
git bisect  bad 97defe1ecf868b8127f8e62395499d6a06e4c4b1  # 10:25  0- 
66  rhashtable: Per bucket locks & deferred expansion/shrinking
# extra tests on HEAD of linux-devel/devel-spot-201507122014
git bisect good 3afd2c3f65a385c405a084d80431c84b103cb6df  # 10:28 66+ 
49  0day head guard for 'devel-spot-201507122014'
# extra tests on tree/branch linus/master
git bisect good f760b87f8f12eb262f14603e65042996fe03720e  # 10:33 66+  
0  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
# extra tests on tree/branch linus/master
git bisect good f760b87f8f12eb262f14603e65042996fe03720e  # 10:33 66+  
0  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
# extra tests on tree/branch next/master
git bisect good 2eb62d762a2112579f259903e62ba18d16c51f66  # 10:36 66+ 
20  Add linux-next specific files for 20150713


This script may reproduce the error.


#!/bin/bash

kernel=$1
initrd=yocto-minimal-x86_64.cgz

wget --no-clobber 
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd

kvm=(
qemu-system-x86_64
-enable-kvm
-cpu Haswell,+smep,+smap
-kernel $kernel
-initrd $initrd
-m 256
-smp 1
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null 
)

append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
systemd.log_level=err
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)

"${kvm[@]}" --append "${append[*]}"


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation
early console in setup code
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.19.0-rc2-00323-g97defe1 (kbuild@lkp-ib03) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Tue Jul 14 10:14:59 CST 2015
[0.00] Command line: hung_task_panic=1 earlyprintk=ttyS0,115200 
systemd.log_level=err debug apic=debug sysrq_always_enabled 
rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 
console=ttyS0,115200 console=tty0 vga=normal  root=/dev/ram0 rw 
link=/kbuild-tests/run-queue/kvm/x86_64-randconfig-a0-07122340/linux-devel:devel-spot-201507122014:97defe1ecf868b8127f8e62395499d6a06e4c4b1:bisect-linux-1/.vmlinuz-97defe1ecf868b8127f8e62395499d6a06e4c4b1-20150714101515-19-ivb41
 branch=linux-devel/devel-spot-201507122014 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-a0-07122340/gcc-4.9/97defe1ecf868b8127f8e62395499d6a06e4c4b1/vmlinuz-3.19.0-rc2-00323-g97defe1
 drbd.minor_count=8
[0.00] KERNEL supported cpus:
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] CPU: vendor_id 'GenuineIntel' unknown, using generic init.
[0.00] CPU: Your system may be unstable.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0ffd] usable
[0.00] BIOS-e820: [mem 0x0ffe-0x0fff] reserved
[0.00] BIOS-e820: [mem 0

[PATCH v3 3/5] ARM: mediatek: add smp bringup code

[Yingjoe Chen]

Add support for booting secondary CPUs on mt6589, mt8127
and mt8135.

Signed-off-by: Yingjoe Chen 
---
 arch/arm/mach-mediatek/Makefile  |   3 +
 arch/arm/mach-mediatek/platsmp.c | 144 +++
 2 files changed, 147 insertions(+)
 create mode 100644 arch/arm/mach-mediatek/platsmp.c

diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
index 43e619f..2116460 100644
--- a/arch/arm/mach-mediatek/Makefile
+++ b/arch/arm/mach-mediatek/Makefile
@@ -1 +1,4 @@
+ifeq ($(CONFIG_SMP),y)
+obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
+endif
 obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
diff --git a/arch/arm/mach-mediatek/platsmp.c b/arch/arm/mach-mediatek/platsmp.c
new file mode 100644
index 000..a5bc108
--- /dev/null
+++ b/arch/arm/mach-mediatek/platsmp.c
@@ -0,0 +1,144 @@
+/*
+ * arch/arm/mach-mediatek/platsmp.c
+ *
+ * Copyright (c) 2014 Mediatek Inc.
+ * Author: Shunli Wang 
+ * Yingjoe Chen 
+ *
+ * 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 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.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MTK_MAX_CPU8
+#define MTK_SMP_REG_SIZE   0x1000
+
+struct mtk_smp_boot_info {
+   unsigned long smp_base;
+   unsigned int jump_reg;
+   unsigned int core_keys[MTK_MAX_CPU - 1];
+   unsigned int core_regs[MTK_MAX_CPU - 1];
+};
+
+static const struct mtk_smp_boot_info mtk_mt8135_tz_boot = {
+   0x80002000, 0x3fc,
+   { 0x534c4131, 0x4c415332, 0x41534c33 },
+   { 0x3f8, 0x3f8, 0x3f8 },
+};
+
+static const struct mtk_smp_boot_info mtk_mt6589_boot = {
+   0x10002000, 0x34,
+   { 0x534c4131, 0x4c415332, 0x41534c33 },
+   { 0x38, 0x3c, 0x40 },
+};
+
+static const struct of_device_id mtk_tz_smp_boot_infos[] __initconst = {
+   { .compatible   = "mediatek,mt8135", .data = _mt8135_tz_boot },
+   { .compatible   = "mediatek,mt8127", .data = _mt8135_tz_boot },
+};
+
+static const struct of_device_id mtk_smp_boot_infos[] __initconst = {
+   { .compatible   = "mediatek,mt6589", .data = _mt6589_boot },
+};
+
+static void __iomem *mtk_smp_base;
+static const struct mtk_smp_boot_info *mtk_smp_info;
+
+static int mtk_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+   if (!mtk_smp_base)
+   return -EINVAL;
+
+   if (!mtk_smp_info->core_keys[cpu-1])
+   return -EINVAL;
+
+   writel_relaxed(mtk_smp_info->core_keys[cpu-1],
+   mtk_smp_base + mtk_smp_info->core_regs[cpu-1]);
+
+   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+   return 0;
+}
+
+static void __init __mtk_smp_prepare_cpus(unsigned int max_cpus, int trustzone)
+{
+   int i, num;
+   const struct of_device_id *infos;
+
+   if (trustzone) {
+   num = ARRAY_SIZE(mtk_tz_smp_boot_infos);
+   infos = mtk_tz_smp_boot_infos;
+   } else {
+   num = ARRAY_SIZE(mtk_smp_boot_infos);
+   infos = mtk_smp_boot_infos;
+   }
+
+   /* Find smp boot info for this SoC */
+   for (i = 0; i < num; i++) {
+   if (of_machine_is_compatible(infos[i].compatible)) {
+   mtk_smp_info = infos[i].data;
+   break;
+   }
+   }
+
+   if (!mtk_smp_info) {
+   pr_err("%s: Device is not supported\n", __func__);
+   return;
+   }
+
+   if (trustzone) {
+   if (memblock_reserve(mtk_smp_info->smp_base, MTK_SMP_REG_SIZE)) 
{
+   pr_err("%s: Can't reserve smp memory\n", __func__);
+   return;
+   }
+   mtk_smp_base = phys_to_virt(mtk_smp_info->smp_base);
+   } else {
+   mtk_smp_base = ioremap(mtk_smp_info->smp_base, 
MTK_SMP_REG_SIZE);
+   if (!mtk_smp_base) {
+   pr_err("%s: Can't remap %lx\n", __func__,
+   mtk_smp_info->smp_base);
+   return;
+   }
+   }
+
+   /*
+* write the address of slave startup address into the system-wide
+* jump register
+*/
+   writel_relaxed(virt_to_phys(secondary_startup_arm),
+   mtk_smp_base + mtk_smp_info->jump_reg);
+}
+
+static void __init mtk_tz_smp_prepare_cpus(unsigned int max_cpus)
+{
+   __mtk_smp_prepare_cpus(max_cpus, 1);
+}
+
+static void __init mtk_smp_prepare_cpus(unsigned int max_cpus)
+{
+   __mtk_smp_prepare_cpus(max_cpus, 0);
+}
+
+static struct smp_operations mt81xx_tz_smp_ops __initdata = {
+   .smp_prepare_cpus = 

[PATCH v3 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

[Yingjoe Chen]

Add arch timer node to enable arch-timer support. MT8135 firmware
doesn't correctly setup arch-timer frequency and CNTVOFF, add
properties to workaround this.

This also set cpu enable-method to enable SMP.

Signed-off-by: Yingjoe Chen 
---
 arch/arm/boot/dts/mt8135.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index 0aba9eb..0264d2e 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -44,6 +44,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "mediatek,mt81xx-tz-smp";
 
cpu0: cpu@0 {
device_type = "cpu";
@@ -96,6 +97,21 @@
 
};
 
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   clock-frequency = <1300>;
+   arm,cpu-registers-not-fw-configured;
+   };
+
soc {
#address-cells = <2>;
#size-cells = <2>;
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 5/5] ARM: dts: mt8127: enable basic SMP bringup for mt8127

[Yingjoe Chen]

Add arch timer node to enable arch-timer support. MT8127 firmware
doesn't correctly setup arch-timer frequency and CNTVOFF, add
properties to workaround this.

This also set cpu enable-method to enable SMP.

Signed-off-by: Yingjoe Chen 
---
 arch/arm/boot/dts/mt8127.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index ca3402e..fae84ee 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -23,6 +23,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "mediatek,mt81xx-tz-smp";
 
cpu@0 {
device_type = "cpu";
@@ -72,6 +73,21 @@
 };
};
 
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   clock-frequency = <1300>;
+   arm,cpu-registers-not-fw-configured;
+   };
+
soc {
#address-cells = <2>;
#size-cells = <2>;
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/5] devicetree: bindings: add new SMP enable method Mediatek SoC

[Yingjoe Chen]

This commit add new cpu enable method "mediatek,mt65xx-smp" and
"mediatek,mt81xx-tz-smp".

Signed-off-by: Yingjoe Chen 
---
 Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index d6b794c..d58eb45 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -195,6 +195,8 @@ nodes to be present and contain the properties described 
below.
"marvell,armada-380-smp"
"marvell,armada-390-smp"
"marvell,armada-xp-smp"
+   "mediatek,mt6589-smp"
+   "mediatek,mt81xx-tz-smp"
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/5] ARM: mediatek: enable gpt6 on boot up to make arch timer working

[Yingjoe Chen]

From: Matthias Brugger 

We enable GTP6 which ungates the arch timer clock.
In the future this should be done in the bootloader.

Signed-off-by: Matthias Brugger 
Signed-off-by: Yingjoe Chen 
---
 arch/arm/mach-mediatek/mediatek.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/mach-mediatek/mediatek.c 
b/arch/arm/mach-mediatek/mediatek.c
index a954900..19dc738 100644
--- a/arch/arm/mach-mediatek/mediatek.c
+++ b/arch/arm/mach-mediatek/mediatek.c
@@ -16,6 +16,32 @@
  */
 #include 
 #include 
+#include 
+#include 
+#include 
+
+
+#define GPT6_CON_MT65xx 0x10008060
+#define GPT_ENABLE  0x31
+
+static void __init mediatek_timer_init(void)
+{
+   void __iomem *gpt_base;
+
+   if (of_machine_is_compatible("mediatek,mt6589") ||
+   of_machine_is_compatible("mediatek,mt8135") ||
+   of_machine_is_compatible("mediatek,mt8127")) {
+   /* turn on GPT6 which ungates arch timer clocks */
+   gpt_base = ioremap(GPT6_CON_MT65xx, 0x04);
+
+   /* enable clock and set to free-run */
+   writel(GPT_ENABLE, gpt_base);
+   iounmap(gpt_base);
+   }
+
+   of_clk_init(NULL);
+   clocksource_of_init();
+};
 
 static const char * const mediatek_board_dt_compat[] = {
"mediatek,mt6589",
@@ -27,4 +53,5 @@ static const char * const mediatek_board_dt_compat[] = {
 
 DT_MACHINE_START(MEDIATEK_DT, "Mediatek Cortex-A7 (Device Tree)")
.dt_compat  = mediatek_board_dt_compat,
+   .init_time  = mediatek_timer_init,
 MACHINE_END
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/nsfs.c: In function 'nsfs_show_path':
fs/nsfs.c:145:2: error: void value not ignored as it ought to be
  return seq_printf(seq, "%s:[%lu]", ns_ops->name, inode->i_ino);
  ^
fs/nsfs.c:146:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^

Caused by patch

  "fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void"

from the akpm tree interacting with commit

  75509fd88fbd ("nsfs: Add a show_path method to fix mountinfo")

from the userns tree (which has reappeared).

I have applied the same fix patch from last time:

From: Stephen Rothwell 
Subject: nsfs: fix for seq_printf() API change
Date: Thu, 25 Jun 2015 17:41:14 +1000

Signed-off-by: Stephen Rothwell 
Cc: Joe Perches 
Cc: Al Viro 
Cc: Steven Rostedt 
Signed-off-by: Andrew Morton 
---

 fs/nsfs.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff -puN 
fs/nsfs.c~fs-seq_file-convert-int-seq_vprint-seq_printf-etc-returns-to-void-fix 
fs/nsfs.c
--- 
a/fs/nsfs.c~fs-seq_file-convert-int-seq_vprint-seq_printf-etc-returns-to-void-fix
+++ a/fs/nsfs.c
@@ -142,7 +142,8 @@ static int nsfs_show_path(struct seq_fil
struct inode *inode = d_inode(dentry);
const struct proc_ns_operations *ns_ops = dentry->d_fsdata;
 
-   return seq_printf(seq, "%s:[%lu]", ns_ops->name, inode->i_ino);
+   seq_printf(seq, "%s:[%lu]", ns_ops->name, inode->i_ino);
+   return 0;
 }
 
 static const struct super_operations nsfs_ops = {

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpFJbjnEebnD.pgp
Description: OpenPGP digital signature

[PATCH v3 0/5] Add SMP bringup support for mt65xx socs

[Yingjoe Chen]

This series add SMP brinup support for MediaTek SoCs. This is based
on v4.2-rc1 and Matthias' next branch (for dts parts).

There are similar but different SMP bringup up methods on MediaTek
mt65xx and mt81xx. On MT8135 & MT8127, system boots with a trustzone
firmware. Others, like MT6589, doesn't have trustzone, and run kernel
directly in secure world.

Patch 1 enable arch timer support.
Patch 2,3 add support for cpu enable-method "mediatek,mt6589-smp" and
"mediatek,mt81xx-tz-smp", which support Mediatek SMP bringup for non-TZ
and TZ platform.
Patch 4,5 finally enable SMP bringup for mt8135 and mt8127.

Changes in v3:
- The first 2 patches in v2 are merged in v4.2-rc1.
- Patch 3~4 in v2 are moved to another series [1]
- platsmp.c changes based on Stephen's suggestion
- Change cpu enable-method name to "mediatek,mt6589-smp"

Changes in v2:
- Fix boot issue for THUMB2 kernel.
- Not enable GPT_CLK_EVT when setup to fix GPT spurious interrupt issue
- Change platsmp.c according to Matthias' suggestion
http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000714.html

v1:
http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000528.html

[1]
http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001544.html

Matthias Brugger (1):
  ARM: mediatek: enable gpt6 on boot up to make arch timer working

Yingjoe Chen (4):
  devicetree: bindings: add new SMP enable method Mediatek SoC
  ARM: mediatek: add smp bringup code
  ARM: dts: mt8135: enable basic SMP bringup for mt8135
  ARM: dts: mt8127: enable basic SMP bringup for mt8127

 Documentation/devicetree/bindings/arm/cpus.txt |   2 +
 arch/arm/boot/dts/mt8127.dtsi  |  16 +++
 arch/arm/boot/dts/mt8135.dtsi  |  16 +++
 arch/arm/mach-mediatek/Makefile|   3 +
 arch/arm/mach-mediatek/mediatek.c  |  27 +
 arch/arm/mach-mediatek/platsmp.c   | 144 +
 6 files changed, 208 insertions(+)
 create mode 100644 arch/arm/mach-mediatek/platsmp.c


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[driver-core] BUG: unable to handle kernel NULL pointer dereference at (null)

[Fengguang Wu]

[1.389082] FS:  () GS:8221c000() 
knlGS:
[1.390864] CS:  0010 DS:  ES:  CR0: 80050033
[1.391926] CR2:  CR3: 0e195000 CR4: 001407f0
[1.393139] Stack:
[1.393816]  81530640 88000f86fd18 88000f859c60 
88000f95b810
[1.395765]  88000f86fd68 82265b80  
88000f86fd48
[1.397674]  81598f7c 81f69ddc 82217388 
82217388
[1.399630] Call Trace:
[1.400322]  [] ? regulator_get_dependencies+0x40/0xa0
[1.401498]  [] fwnode_get_dependencies+0x2c/0x80
[1.402649]  [] driver_probe_device+0x91/0x390
[1.403774]  [] __driver_attach+0x8b/0x90
[1.404844]  [] ? driver_probe_device+0x390/0x390
[1.405969]  [] bus_for_each_dev+0x5f/0x90
[1.407052]  [] driver_attach+0x19/0x20
[1.408087]  [] bus_add_driver+0x19f/0x220
[1.409156]  [] ? acpi_fan_driver_init+0x14/0x14
[1.410281]  [] driver_register+0x5b/0xe0
[1.411387]  [] acpi_processor_driver_init+0x1c/0x38
[1.412733]  [] do_one_initcall+0xe6/0x176
[1.413954]  [] kernel_init_freeable+0x11a/0x1a2
[1.415097]  [] ? rest_init+0x80/0x80
[1.416119]  [] kernel_init+0x9/0xe0
[1.417137]  [] ret_from_fork+0x3f/0x70
[1.418498]  [] ? rest_init+0x80/0x80
[1.419817] Code: f6 81 c0 1a ce 81 20 75 eb c6 42 01 00 0f b6 10 f6 82 c0 
1a ce 81 20 74 10 48 83 c0 01 0f b6 10 f6 82 c0 1a ce 81 20 75 f0 5d c3 <80> 3f 
00 55 48 89 e5 74 11 48 89 f8 48 83 c0 01 80 38 00 75 f7 
[1.427642] RIP  [] strlen+0x0/0x20
[1.428818]  RSP 
[1.430067] CR2: 
[1.431426] ---[ end trace 28b7a0eec161cbd6 ]---
[1.433101] Kernel panic - not syncing: Fatal exception

git bisect start ac88d9d7d03289e6eed00aacb150be2006440613 
d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 --
git bisect  bad c22ab4ff1cde7fff6310e73b56577e6600332756  # 03:55  0- 
22  Merge 'asoc/topic/sti-sas' into devel-catchup-201507132204
git bisect  bad d28b5211e1e1a083f4da2b89b37387efc26e12ba  # 04:00  0- 
24  Merge 'amirv/for-upstream' into devel-catchup-201507132204
git bisect good 61d57c2425ceb47f590bce11cfa8971d6f6bcc7c  # 04:04 22+  
0  0day base guard for 'devel-catchup-201507132204'
git bisect  bad eacd810bfdb7b26bfa4505962ecf6dffa4791070  # 04:09  0- 
22  Merge 'tomeu/ordered-probing-v3' into devel-catchup-201507132204
git bisect good 7cac38d31c07d3956069826d7b09982f0fa96709  # 04:14 22+  
0  Merge remote-tracking branch 'crypto/master'
git bisect good 5b9297ef5b989c5953300bf2436dc91878744cff  # 04:19 22+  
0  Merge remote-tracking branch 'spi/for-next'
git bisect good 8b663bdf57db00902f1dd75437642fc0307ffe09  # 04:25 22+  
0  Merge remote-tracking branch 'vhost/linux-next'
git bisect good cf0e4cc63804a86ee1b5b8afcce573916aec33fa  # 04:37 22+  
3  ipc/msg.c: use freezable blocking call
git bisect good a3aa7cdc2e95a936ba8dd5b00ebfadb35a4e4c1b  # 04:45 22+  
2  Merge remote-tracking branch 'livepatching/for-next'
git bisect good 0b3190184e0d555c9c00b0cb5a7dc0ede7083386  # 05:25 22+  
4  i2c: core: Have clients point to their firmware nodes
git bisect good 19a4ff36c057acf4a1ce1e4ccbccfbb500b976e2  # 05:35 22+  
0  ASoC: tegra: register dependency parser for firmware nodes
git bisect  bad 46a31d43e6a6605b98701e54878e631f9d590cb3  # 05:38  0- 
22  get_deps: add locking
git bisect  bad 0feb05fe8f72af493547562f754f228843cda97b  # 05:43  0- 
22  dd.c: move check_dependencies out of critical area
git bisect  bad 4cbaa3b798e10e931cb30e3ce6327e226d778f8c  # 05:46  0- 
24  dd.c: don't check for dependencies to self
git bisect  bad 240d94dae48c0e526898bb54639622ca897323c9  # 05:49  0- 
22  driver-core: probe dependencies before probing
# first bad commit: [240d94dae48c0e526898bb54639622ca897323c9] driver-core: 
probe dependencies before probing
git bisect good 19a4ff36c057acf4a1ce1e4ccbccfbb500b976e2  # 05:51 66+  
2  ASoC: tegra: register dependency parser for firmware nodes
# extra tests with DEBUG_INFO
git bisect  bad 240d94dae48c0e526898bb54639622ca897323c9  # 05:54  0- 
66  driver-core: probe dependencies before probing
# extra tests on HEAD of linux-devel/devel-catchup-201507132204
git bisect  bad ac88d9d7d03289e6eed00aacb150be2006440613  # 05:55  0- 
13  0day head guard for 'devel-catchup-201507132204'
# extra tests on tree/branch tomeu/ordered-probing-v3
git bisect  bad 0d5684a2c08daec5870ebf0ca7e50307d6a9c6e1  # 08:09  0- 
66  fwnode_remove_dependency_parser
# extra tests on tree/branch linus/master
git bisect good f760b87f8f12eb262f14603e65042996fe03720e  # 08:19 66+  
0  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
# extra tests on tree/branch next/master
git bisect good 2eb62d762a2112579f259903e62ba18d16c51f66  # 08:27 66+  
0  Add linux-next specific files for 20

Re: [PATCH] gpu/drm/amdgpu: Include only if CONFIG_DEBUG_FS is set

[Alex Deucher]

On Mon, Jul 13, 2015 at 7:03 AM, Alexander Kuleshov
 wrote:
> We have no need to include  if the CONFIG_DEBUG_FS option
> is not set.
>

This patch breaks the build with debugfs enabled.

Alex

> Signed-off-by: Alexander Kuleshov 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index ba46be3..23dbfa4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -27,7 +27,6 @@
>   */
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -44,2 +43,2 @@
>  #include "vi.h"
>  #include "bif/bif_4_1_d.h"
>
> +#ifdef CONFIG_DEBUG_FS
> +#include 
> +#endif
> +
>  static int amdgpu_debugfs_regs_init(struct amdgpu_device *adev);
>  static void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev);
>
> --
> 2.5.0-rc1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mmap()ed AF_NETLINK: lockdep and sleep-in-atomic warnings

[Cong Wang]

On Mon, Jul 13, 2015 at 6:18 AM, Kirill A. Shutemov
 wrote:
> Hi,
>
> This simple test-case trigers few locking asserts in kernel:
>
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #define SOL_NETLINK 270
>
> int main(int argc, char **argv)
> {
> unsigned int block_size = 16 * 4096;
> struct nl_mmap_req req = {
> .nm_block_size  = block_size,
> .nm_block_nr= 64,
> .nm_frame_size  = 16384,
> .nm_frame_nr= 64 * block_size / 16384,
> };
> unsigned int ring_size;
> int fd;
>
> fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
> if (setsockopt(fd, SOL_NETLINK, NETLINK_RX_RING, , sizeof(req)) < 
> 0)
> exit(1);
> if (setsockopt(fd, SOL_NETLINK, NETLINK_TX_RING, , sizeof(req)) < 
> 0)
> exit(1);
>
> ring_size = req.nm_block_nr * req.nm_block_size;
> mmap(NULL, 2 * ring_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> return 0;
> }
>
> +++ exited with 0 +++
> [2.500126] BUG: sleeping function called from invalid context at 
> /home/kas/git/public/linux-mm/kernel/locking/mutex.c:616
> [2.501328] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
> [2.501997] 3 locks held by init/1:
> [2.502380]  #0:  (reboot_mutex){+.+...}, at: [] 
> SyS_reboot+0xa9/0x220
> [2.503328]  #1:  ((reboot_notifier_list).rwsem){.+.+..}, at: 
> [] __blocking_notifier_call_chain+0x39/0x70
> [2.504659]  #2:  (rcu_callback){..}, at: [] 
> rcu_do_batch.isra.49+0x160/0x10c0
> [2.505724] Preemption disabled at:[] __delay+0xf/0x20
> [2.506443]
> [2.506612] CPU: 1 PID: 1 Comm: init Not tainted 4.1.0-9-gbddf4c4818e0 
> #253
> [2.507378] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> Debian-1.8.2-1 04/01/2014
> [2.508386]  88017b3d8000 88027bc03c38 81929ceb 
> 0102
> [2.509233]   88027bc03c68 81085a9d 
> 0002
> [2.510057]  81ca2a20 0268  
> 88027bc03c98
> [2.510882] Call Trace:
> [2.511146][] dump_stack+0x4f/0x7b
> [2.511763]  [] ___might_sleep+0x16d/0x270
> [2.512476]  [] __might_sleep+0x4d/0x90
> [2.513071]  [] mutex_lock_nested+0x2f/0x430
> [2.513683]  [] ? _raw_spin_unlock_irqrestore+0x5d/0x80
> [2.514385]  [] ? __this_cpu_preempt_check+0x13/0x20
> [2.515066]  [] netlink_set_ring+0x1ed/0x350
> [2.515694]  [] ? netlink_undo_bind+0x70/0x70
> [2.516411]  [] netlink_sock_destruct+0x80/0x150
> [2.517070]  [] __sk_free+0x1d/0x160
> [2.517607]  [] sk_free+0x19/0x20
> [2.518118]  [] deferred_put_nlk_sk+0x20/0x30
> [2.518735]  [] rcu_do_batch.isra.49+0x79c/0x10c0

Caused by:

commit 21e4902aea80ef35afc00ee8d2abdea4f519b7f7
Author: Thomas Graf 
Date:   Fri Jan 2 23:00:22 2015 +0100

netlink: Lockless lookup with RCU grace period in socket release

Defers the release of the socket reference using call_rcu() to
allow using an RCU read-side protected call to rhashtable_lookup()

This restores behaviour and performance gains as previously
introduced by e341694 ("netlink: Convert netlink_lookup() to use
RCU protected hash table") without the side effect of severely
delayed socket destruction.

Signed-off-by: Thomas Graf 
Signed-off-by: David S. Miller 


We can't hold mutex lock in a rcu callback, perhaps we could
defer the mmap ring cleanup to a workqueue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2.

[Stephen Warren]

On 07/11/2015 01:51 AM, Thomas Gleixner wrote:
> On Fri, 10 Jul 2015, Stephen Warren wrote:
>> On 07/07/2015 03:13 PM, Eric Anholt wrote:
>>> +static struct arm_local_intc intc  __read_mostly;
>>
>> It'd be nice to give everything (types, functions, variables) a
>> consistent symbol prefix; bcm2836_arm_irqchip_ sounds like a good
>> bikeshed to me, but perhaps just propagating the above arm_local_ to the
>> functions too would be good, although that seems to risk symbol name
>> collisions with other ARM SoCs.
> 
> Which is irrelevant because its static.

Except if you want to look up a symbol name without having to qualify it
by filename.

Or, does e.g. gdb require statics always be qualified even if they're
globally unique?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] irqchip: Add documentation for the bcm2836 interrupt controller.

[Stephen Warren]

On 07/11/2015 12:01 AM, Eric Anholt wrote:
> Stephen Warren  writes:
> 
>> On 07/07/2015 03:13 PM, Eric Anholt wrote:
>>> This is a new per-cpu root interrupt controller on the
>>> Raspberry Pi 2, which will chain to the bcm2835 interrupt
>>> controller for peripheral interrupts.
>> 
>>> diff --git
>>> a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
>>> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
>>
>>>
>>> 
+local_intc: local_intc {
>> 
>>> +   interrupt-parent = <_intc>;
>> 
>> I think that property shouldn't be there?
> 
> If you don't have it there, the core finds the interrupt-parent in
> the parent node, and waits for that one before initializing (which
> is in turn waiting for us).  Note that for original 2835, you're
> finding the parent node as well.

Ah yes. It does indeed look like it's typical that the root IRQ
controller points at itself.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] net: ieee802154: Remove redundant spi driver bus initialization

[Marcel Holtmann]

Hi Antonio,

> In ancient times it was necessary to manually initialize the bus
> field of an spi_driver to spi_bus_type. These days this is done in
> spi_register_driver(), so we can drop the manual assignment.
> 
> Signed-off-by: Antonio Borneo 
> To: Alan Ott 
> To: Alexander Aring 
> To: Varka Bhadram 
> To: linux-w...@vger.kernel.org
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ieee802154/cc2520.c   | 1 -
> drivers/net/ieee802154/mrf24j40.c | 1 -
> 2 files changed, 2 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-misc tree

[Archit Taneja]

Hi,

On 07/14/2015 08:22 AM, Stephen Rothwell wrote:

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 
'virtio_pci_kick_out_firmware_fb':
drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of 
function 'drm_fb_helper_remove_conflicting_framebuffers' 
[-Werror=implicit-function-declaration]
   drm_fb_helper_remove_conflicting_framebuffers(ap, "virtiodrmfb",
   ^

Caused by commit

   7bd870e7b1c8 ("drm/virtio: Use new drm_fb_helper functions")

I have used the drm-misc tree from next-20150713 for today.

(That commit said "COMPILE TESTED ONLY"  :-()


My bad. The commit messages were for a slightly older version.
I'll fix this, and the warnings in the other mail.

Thanks,
Archit


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irqchip: bcm2835: Add FIQ support

[Stephen Warren]

On 07/11/2015 09:26 AM, Noralf Trønnes wrote:
> 
> Den 11.07.2015 06:09, skrev Stephen Warren:
>> (Sorry for the slow reply; I was on vacation)
>>
>> On 06/18/2015 07:32 AM, Noralf Trønnes wrote:
>>> Den 18.06.2015 04:26, skrev Stephen Warren:
 On 06/12/2015 11:26 AM, Noralf Trønnes wrote:
> Add a duplicate irq range with an offset on the hwirq's so the
> driver can detect that enable_fiq() is used.
> Tested with downstream dwc_otg USB controller driver.
 This basically looks OK, but a few comments/thoughts:
 b) Doesn't the driver need to refuse some operation (handler
 registration, IRQ setup, IRQ enable, ...?) for more than 1 IRQ in the
 FIQ range, since the FIQ control register only allows routing 1 IRQ to
 FIQ.
>>> claim_fiq() protects the FIQ. See d) answer below.
>> That assumes the IRQ is "accessed" via the fiq-specific APIs. Since this
>> patch changes the IRQ domain from having n IRQs to having 2*n IRQs, and
>> doesn't do anything special to prevent clients from using IRQs n..2n-1
>> via the existing IRQ APIs, it's quite possible the a buggy client would.
> 
> Yes, but doesn't this apply to all irq use, using the wrong one doesn't
> work.
> If FIQ's where in more common use, we might have seen a FIQ IRQ flag
> instead
> of special FIQ irqs.
> 
>> (From another email):
> c) The DT binding needs updating to describe the extra IRQs:
>
>> Documentation/devicetree/bindings/interrupt-controller/brcm,bcm28armctrl-ic.txt
>>
 Ok.
>>> I have seconds thoughts on this:
>>> This patch does not change the DT bindings so I don't see what update
>>> I should make. This patch only adds support for the Linux way of
>>> handling FIQ's through enable_fiq(). It doesn't change how interrupts
>>> are described in the DT.
>> The intention of the patch may not be to expand the set of IRQs
>> available via DT, but it does in practice. I think you need to add a
>> custom of_xlate for the IRQ domain to ensure that only IRQs 0..n-1 can
>> be translated from DT, and not IRQs n..2n-1. If you do that, then I
>> agree that no DT binding update should be required.
> 
> armctrl_xlate() maps to the same hwirqs as before. This patch adds a
> new range of hwirqs at the end of the "real" hwirq range.
> It's not possible to get to these FIQ shadow hwirqs through DT.

What prevents a DT from (incorrectly) referencing the extra hwirqs?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] serial: samsung: Remove redundant DEBUG_LL check

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> On 13.07.2015 20:18, Javier Martinez Canillas wrote:
> > Commit 84f57d9e3685 ("tty: serial/samsung: fix modular build") fixed
> > build issues when the driver was built as a module. One of those was
> > that printascii is only accessible when the driver is built-in.
> >
> > But there is no need to check for defined(CONFIG_DEBUG_LL) since the
> > SERIAL_SAMSUNG_DEBUG Kconfig symbol already depends on DEBUG_LL.
> >
> > Signed-off-by: Javier Martinez Canillas 

Acked-by: Kukjin Kim 

Thanks,
Kukjin

> >
> > ---
> >
> >  drivers/tty/serial/samsung.c | 1 -
> >  1 file changed, 1 deletion(-)
> 
> Although this redundancy is not harmful the patch seems fine, so:
> Reviewed-by: Krzysztof Kozlowski 
> 
> Best regards,
> Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] DocBook: Avoid stdout junk with no man pages to compress

[Ulf Magnusson]

On Tue, Jul 14, 2015 at 6:27 AM, Ulf Magnusson  wrote:
> On Mon, Jul 13, 2015 at 2:46 AM, Ulf Magnusson  
> wrote:
>> On Sun, Jul 12, 2015 at 04:36:53PM -0700, Jim Davis wrote:
>>> On Sun, Jul 12, 2015 at 2:59 PM, Ulf Magnusson  
>>> wrote:
>>> > gzip would run as 'gzip -f' when no uncompressed man pages were found,
>>> > making it compress the (empty) stdin to stdout.
>>>
>>> > --- a/Documentation/DocBook/Makefile
>>> > +++ b/Documentation/DocBook/Makefile
>>> > @@ -56,7 +56,7 @@ htmldocs: $(HTML)
>>> >
>>> >  MAN := $(patsubst %.xml, %.9, $(BOOKS))
>>> >  mandocs: $(MAN)
>>> > -   find $(obj)/man -name '*.9' | xargs gzip -f
>>> > +   find $(obj)/man -name '*.9' -exec gzip -f {} \;
>>> >
>>> >  installmandocs: mandocs
>>> > mkdir -p /usr/local/man/man9/
>>>
>>> That does get rid of the binary burp, but 'xargs gzip -f'  has been in
>>> the Makefile since January, and gzipping '\n' just started recently.
>>> So what's changed?
>>>
>>
>> No idea. I just assumed it had been broken since then, since the version
>> before d56fcf299fb4 (DocBook: Do not exceed argument list limit) looked
>> for *.9 files before running gzip:
>>
>> mandocs: $(MAN)
>> $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
>>
>>> It looks like, for whatever reason, make installmandocs always ends up
>>> rerunning mandocs -- there's now a 'GEN  Documentation
>>> Docbook//v4l2.xml' printed, and that extra mandocs invocation is where
>>> the problematic second invocation of find is coming from.  I won't
>>> pretend to understand the Makefile flow to guess at why that's
>>> happening, but obviously 'make mandocs; make installmandocs' shouldn't
>>> need to regenerate things already generated.
>>
>> I won't pretend to understand the Makefile flow either. Guess it might
>> be worth looking into v4l2.xml as well then. Could be some directory
>> shenanigans going on judging from the '//'.
>>
>
> I looked into it some more, and I'm now fairly certain that 'mandocs' always
> runs its recipe regardless of the status of the prerequisites. Changing the
> top-level Makefile to do
>
> $(Q)$(MAKE) --debug=v $(build)=Documentation/DocBook $@
>
> and running 'make mandocs', you see some FORCEs in the output, which -- unless
> my make fu is weak -- causes all the targets above that to always be 
> considered
> out of date:
>
> File 'mandocs' does not exist.
>  Considering target file 'Documentation/DocBook/z8530book.9'.
>Considering target file 'Documentation/DocBook/z8530book.xml'.
>  ...
>  Considering target file 'FORCE'.
>   File 'FORCE' does not exist.
>   Finished prerequisites of target file 'FORCE'.
>  Must remake target 'FORCE'.
>  Successfully remade target file 'FORCE'.
>  ...
>Must remake target 'Documentation/DocBook/z8530book.xml'.
>  ...
> Must remake target 'mandocs'.

Had forgotten that 'mandocs' is a phony target too. That alone makes it always
run its recipe when it's a prerequisite of some target that's run.

>
>
> Re. the 'GEN  Documentation Docbook//v4l2.xml', I think the problem is the
> following rule in Documentation/DocBook/media/Makefile:
>
> $(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES)
> @$($(quiet)gen_xml)
> @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/)
> @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/)
>
> ./Documentation/DocBook/v4l2.xml is a symlink, so make compares the
> modification time of the symlink *target* (which is never updated) against the
> image (*.png, *.gif, etc.) files in $(OBJIMGFILES). Updating the symlink 
> itself
> won't change that modification time, so that's why it always runs.
>
> Passing --check-symlink-times to make so that it also looks at the 
> modification
> time of the symlink seems to change a bunch of other stuff in the output too.
> Maybe there's other problems lurking here as well.
>
>>>
>>> In any event,
>>>
>>> Tested-by: Jim Davis 
>>>
>>> Jim
>>
>> I just noticed the commit message only mentions the alternative
>> solutions and not the implemented solution. Could send a v2 that fixes
>> that, but I'll wait for more comments first.
>>
>> Cheers,
>> Ulf
>
> Cheers,
> Ulf

Cheers,
Ulf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] EDAC, MCE, AMD: Don't emit 'CE' for Deferred error

[Borislav Petkov]

On Mon, Jul 13, 2015 at 06:53:02AM -0500, Aravind Gopalakrishnan wrote:
> Currently, we also display 'CE' for a Deferred error.
> like so-
> [Hardware Error]: CPU:0 (15:2:0)
> MC4_STATUS[Over|CE|MiscV|-|AddrV|Deferred|-|UECC]: 0xdc04b00095080813
> 
> When the 'UC' bit on MCx_STATUS register is clear, the error status
> is either a Corrected error or Deferred error as determined by the
> 'Deferred' bit.
> 
> Refer AMD Error Scope Hierarchy table in a newer BKDG
> (example: 49125_15h_Models_30h-3Fh_BKDG.pdf, section "RAS Features")
> for clarification.
> 
> Therefore, fix the output to not disply 'CE'
> 
> Signed-off-by: Aravind Gopalakrishnan 
> ---
>  drivers/edac/mce_amd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] arm64: dts: mt8173: add timer node

[Daniel Kurtz]

On Tue, Jul 14, 2015 at 12:26 PM, Daniel Kurtz  wrote:
> On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen  
> wrote:
>> From: Daniel Kurtz 
>>
>> Add device node to enable GPT timer. This timer will be
>> used as sched clock source.
>>
>> Signed-off-by: Daniel Kurtz 
>> Signed-off-by: Eddie Huang 
>> Signed-off-by: Yingjoe Chen 
>
> This binding needs documentation.

Whoops.  I just found it at:
Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt

>
>> ---
>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 0696f8f..04bdd8f 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -219,6 +219,15 @@
>> reg = <0 0x10007000 0 0x100>;
>> };
>>
>> +   timer: timer@10008000 {
>> +   compatible = "mediatek,mt8173-timer",
>> +"mediatek,mt6577-timer";
>> +   reg = <0 0x10008000 0 0x1000>;
>> +   interrupts = ;
>> +   clocks = < CLK_INFRA_CLK_13M>,
>> +< CLK_TOP_RTC_SEL>;
>
> Why two clocks?  The driver only uses one.
> Please use a clock-names property.
>
> Thanks,
> -Dan
>
>> +   };
>> +
>> pwrap: pwrap@1000d000 {
>> compatible = "mediatek,mt8173-pwrap";
>> reg = <0 0x1000d000 0 0x1000>;
>> --
>> 1.8.1.1.dirty
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] DocBook: Avoid stdout junk with no man pages to compress

[Ulf Magnusson]

On Mon, Jul 13, 2015 at 2:46 AM, Ulf Magnusson  wrote:
> On Sun, Jul 12, 2015 at 04:36:53PM -0700, Jim Davis wrote:
>> On Sun, Jul 12, 2015 at 2:59 PM, Ulf Magnusson  
>> wrote:
>> > gzip would run as 'gzip -f' when no uncompressed man pages were found,
>> > making it compress the (empty) stdin to stdout.
>>
>> > --- a/Documentation/DocBook/Makefile
>> > +++ b/Documentation/DocBook/Makefile
>> > @@ -56,7 +56,7 @@ htmldocs: $(HTML)
>> >
>> >  MAN := $(patsubst %.xml, %.9, $(BOOKS))
>> >  mandocs: $(MAN)
>> > -   find $(obj)/man -name '*.9' | xargs gzip -f
>> > +   find $(obj)/man -name '*.9' -exec gzip -f {} \;
>> >
>> >  installmandocs: mandocs
>> > mkdir -p /usr/local/man/man9/
>>
>> That does get rid of the binary burp, but 'xargs gzip -f'  has been in
>> the Makefile since January, and gzipping '\n' just started recently.
>> So what's changed?
>>
>
> No idea. I just assumed it had been broken since then, since the version
> before d56fcf299fb4 (DocBook: Do not exceed argument list limit) looked
> for *.9 files before running gzip:
>
> mandocs: $(MAN)
> $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
>
>> It looks like, for whatever reason, make installmandocs always ends up
>> rerunning mandocs -- there's now a 'GEN  Documentation
>> Docbook//v4l2.xml' printed, and that extra mandocs invocation is where
>> the problematic second invocation of find is coming from.  I won't
>> pretend to understand the Makefile flow to guess at why that's
>> happening, but obviously 'make mandocs; make installmandocs' shouldn't
>> need to regenerate things already generated.
>
> I won't pretend to understand the Makefile flow either. Guess it might
> be worth looking into v4l2.xml as well then. Could be some directory
> shenanigans going on judging from the '//'.
>

I looked into it some more, and I'm now fairly certain that 'mandocs' always
runs its recipe regardless of the status of the prerequisites. Changing the
top-level Makefile to do

$(Q)$(MAKE) --debug=v $(build)=Documentation/DocBook $@

and running 'make mandocs', you see some FORCEs in the output, which -- unless
my make fu is weak -- causes all the targets above that to always be considered
out of date:

File 'mandocs' does not exist.
 Considering target file 'Documentation/DocBook/z8530book.9'.
   Considering target file 'Documentation/DocBook/z8530book.xml'.
 ...
 Considering target file 'FORCE'.
  File 'FORCE' does not exist.
  Finished prerequisites of target file 'FORCE'.
 Must remake target 'FORCE'.
 Successfully remade target file 'FORCE'.
 ...
   Must remake target 'Documentation/DocBook/z8530book.xml'.
 ...
Must remake target 'mandocs'.


Re. the 'GEN  Documentation Docbook//v4l2.xml', I think the problem is the
following rule in Documentation/DocBook/media/Makefile:

$(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES)
@$($(quiet)gen_xml)
@(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/)
@(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/)

./Documentation/DocBook/v4l2.xml is a symlink, so make compares the
modification time of the symlink *target* (which is never updated) against the
image (*.png, *.gif, etc.) files in $(OBJIMGFILES). Updating the symlink itself
won't change that modification time, so that's why it always runs.

Passing --check-symlink-times to make so that it also looks at the modification
time of the symlink seems to change a bunch of other stuff in the output too.
Maybe there's other problems lurking here as well.

>>
>> In any event,
>>
>> Tested-by: Jim Davis 
>>
>> Jim
>
> I just noticed the commit message only mentions the alternative
> solutions and not the implemented solution. Could send a v2 that fixes
> that, but I'll wait for more comments first.
>
> Cheers,
> Ulf

Cheers,
Ulf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] arm64: dts: mt8173: add timer node

[Daniel Kurtz]

On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen  wrote:
> From: Daniel Kurtz 
>
> Add device node to enable GPT timer. This timer will be
> used as sched clock source.
>
> Signed-off-by: Daniel Kurtz 
> Signed-off-by: Eddie Huang 
> Signed-off-by: Yingjoe Chen 

This binding needs documentation.

> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..04bdd8f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -219,6 +219,15 @@
> reg = <0 0x10007000 0 0x100>;
> };
>
> +   timer: timer@10008000 {
> +   compatible = "mediatek,mt8173-timer",
> +"mediatek,mt6577-timer";
> +   reg = <0 0x10008000 0 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_INFRA_CLK_13M>,
> +< CLK_TOP_RTC_SEL>;

Why two clocks?  The driver only uses one.
Please use a clock-names property.

Thanks,
-Dan

> +   };
> +
> pwrap: pwrap@1000d000 {
> compatible = "mediatek,mt8173-pwrap";
> reg = <0 0x1000d000 0 0x1000>;
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/2] spi: add dual parallel & stacked mode support in Zynq MPSoC GQSPI controller

[Harini Katakam]

Hi Thomas,

On Mon, Jul 13, 2015 at 3:34 PM,   wrote:
> Hello Ranjit:
>
>> What is dual parallel mode?
>> ---
>> ZynqMP GQSPI controller supports Dual Parallel mode with following
>> functionalities:
>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>> 2) Chip selects and clock are shared to both the flash devices
>> 3) This mode is targeted for faster read/write speed and also doubles
> the size
>> 4) Commands/data can be transmitted/received from both the
> devices(mirror),
>>or only upper or only lower flash memory devices.
>> 5) Data arrangement:
>>With stripe enabled,
>>Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>
> In the dual-parallel configuration, odd and even _bits_ of each byte are
> distributed over the flash chips; I am assuming this works just as in Zynq
> QSPI (apparently, the TRM for ZynqMP isn't out yet).
>
> Striping seems to be a different mechanism, though. Can you explain it a
> bit more? Also, the wording seems to indicate that it belongs to
> dual-stacked rather than dual-parallel.

This differs between Zynq and ZynqMP.
Bytes are alternated between the two flash devices in ZynqMP.
In Zynq, bits were alternated.
This is dual parallel because both the chips can be selected at the same time
and have two separate data bus connected. One of the two can be done:
1. Enable Stripe - data bytes 0,2,4... to one flash and data bytes
1,3,5.. to the other
This is typically used for read and write memory operations.
2. Disable Stripe (Mirror) - all the bytes are sent to both flash devices.
This is typically used for control operations such as WriteEnable etc.

>
>> Suggestions on MTD layer support
>> 
>> In order to add above two specified modes, we may required to get some
>> support from MTD layer.
>>
>> I'm trying to list the dependencies as follows:
>> 1) Support for two flashes
>> 2) Enable/Disable data stripe as and when required.
>> 3) May need to update read_sr() to get status of both flashes
>> 4) May also need to update read_fsr() to get status of both flashes
>> 5) Adjustment of offset value based on the parallel/stacked mode
> configuration
>> 6) Setting either parallel or stacked mode during the scan process.
>> 7) In case of stacked mode, is there a MTD concatenation support?
>
> In addition to 5), the MTD driver using a dual-parallel QSPI flash has to
> 5a) add padding at the start of data for unaligned addresses,
> 5b) add padding at the end of data for unaligned lengths.

In dual-parallel in ZynqMP, we no longer stripe bits, eliminating
the need for padding unaligned lengths.

Regards,
Harini

>
> Best regards,
> Thomas Betker
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][v2] ARM: ls1021a: dtsi: Add crypto node alias in device tree

[Ruchika Gupta]

U-boot patches up the device tree crypto node for the era property.

Signed-off-by: Ruchika Gupta 
---
Changes from v1:
Rearranged the crypto node in alphabetic sorted order as suggested by Shawn 

 arch/arm/boot/dts/ls1021a.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..42dffae 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -53,6 +53,7 @@
interrupt-parent = <>;
 
aliases {
+   crypto = 
serial0 = 
serial1 = 
serial2 = 
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mtd: Expand the ecc placement locations to 1216

[Punnaiah Choudary Kalluri]

Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
So, increasing the maximum ecc placement locations to 1216

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v2:
- Corrected the oobsize in commit message and code from 1260 to 1216
- Aligned the new values to userspace values
---
 include/linux/mtd/mtd.h|2 +-
 include/uapi/mtd/mtd-abi.h |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index f17fa75..1fd3cc6 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -95,7 +95,7 @@ struct mtd_oob_ops {
 };
 
 #define MTD_MAX_OOBFREE_ENTRIES_LARGE  32
-#define MTD_MAX_ECCPOS_ENTRIES_LARGE   640
+#define MTD_MAX_ECCPOS_ENTRIES_LARGE   1216
 /*
  * Internal ECC layout control structure. For historical reasons, there is a
  * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 763bb69..c4d592c 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -220,8 +220,8 @@ struct nand_oobfree {
__u32 length;
 };
 
-#define MTD_MAX_OOBFREE_ENTRIES8
-#define MTD_MAX_ECCPOS_ENTRIES 64
+#define MTD_MAX_OOBFREE_ENTRIES32
+#define MTD_MAX_ECCPOS_ENTRIES 1216
 /*
  * OBSOLETE: ECC layout control structure. Exported to user-space via ioctl
  * ECCGETLAYOUT for backwards compatbility and should not be mistaken as a
-- 
1.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 1/1] kernel/power/autosleep.c: check for pm_suspend() return before queueing suspend again

[Nitish Ambastha]

On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki  wrote:
> On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
>> Prevent tight loop for suspend-resume when some
>> devices failed to suspend
>
> This *still* doesn't explain what problem you're *really* trying to address.
>
> Even if a driver returns an error code from one of its suspend callbacks,
> you should get final_count == initial_count in the final check and we'll
> schedule the timeout.
>
> So there is a failure scenarion you're trying to address where that check is
> not sufficient, but you're not saying what the scenario is.
>
As I mentioned earlier, if some driver failed to suspend, and during
resume if *somebody* called pm_stay_awake() or pm_wakeup_event()
meantime, and then pm_relax(), final_count and initial_count will not
be the same in try_to_suspend(). We observed this behavior with
battery monitor thread on being restarted

In these scenarios, it will be considered a *valid wakeup* event and
it will try to queue suspend immediately, though the actual reason of
resume was driver returning error code.
For such scenarios, event count may not always be safe way to identify.

> Quite frankly, it seems to me that you're trying to hide a spurious wakeup.
>
>
>> If some devices failed to suspend, we monitor this
>> error in try_to_suspend(). pm_suspend() is already
>> an 'int' returning function, how about checking return
>> from pm_suspend() before queueing suspend again?
>>
>> For devices which do not register for pending events,
>> this will prevent tight loop for suspend-resume in
>> suspend abort scenarios due to device suspend failures
>>
>> Signed-off-by: Nitish Ambastha 
>> ---
>> v2: Rearranged code to make wait entry shared with
>> existing one as suggested by Pavel Machek 
>> Corrected log level from pr_info to pr_err for failure log
>> Added return check for hibernate()
>>
>> v3: Restructured code as suggested by Rafael J Wysocki 
>>
>>  kernel/power/autosleep.c |   20 +---
>>  1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c
>> index 9012ecf..e458d0c 100644
>> --- a/kernel/power/autosleep.c
>> +++ b/kernel/power/autosleep.c
>> @@ -26,6 +26,7 @@ static struct wakeup_source *autosleep_ws;
>>  static void try_to_suspend(struct work_struct *work)
>>  {
>>   unsigned int initial_count, final_count;
>> + int error;
>>
>>   if (!pm_get_wakeup_count(_count, true))
>>   goto out;
>> @@ -42,23 +43,20 @@ static void try_to_suspend(struct work_struct *work)
>>   mutex_unlock(_lock);
>>   return;
>>   }
>> - if (autosleep_state >= PM_SUSPEND_MAX)
>> - hibernate();
>> - else
>> - pm_suspend(autosleep_state);
>>
>> - mutex_unlock(_lock);
>> + error = autosleep_state < PM_SUSPEND_MAX ?
>> + pm_suspend(autosleep_state) : hibernate();
>>
>> - if (!pm_get_wakeup_count(_count, false))
>> - goto out;
>> + mutex_unlock(_lock);
>>
>>   /*
>> -  * If the wakeup occured for an unknown reason, wait to prevent the
>> -  * system from trying to suspend and waking up in a tight loop.
>> +  * If some devices failed to suspend or if the wakeup ocurred
>> +  * for an unknown reason, wait to prevent the system from
>> +  * trying to suspend and waking up in a tight loop.
>>*/
>> - if (final_count == initial_count)
>> + if (error || (pm_get_wakeup_count(_count, false)
>> + && (final_count == initial_count)))
>>   schedule_timeout_uninterruptible(HZ / 2);
>> -
>>   out:
>>   queue_up_suspend_work();
>>  }
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/39] bpf tools: Collect eBPF programs from their own sections

[Wangnan (F)]

On 2015/7/14 3:51, Arnaldo Carvalho de Melo wrote:

Em Fri, Jul 10, 2015 at 11:07:53AM +0800, Wangnan (F) escreveu:

On 2015/7/9 23:58, Arnaldo Carvalho de Melo wrote:

Em Thu, Jul 09, 2015 at 12:35:05PM +, Wang Nan escreveu:

This patch collects all programs in an object file into an array of
'struct bpf_program' for further processing. That structure is for
representing each eBPF program. 'bpf_prog' should be a better name, but
it has been used by linux/filter.h. Although it is a kernel space name,
I still prefer to call it 'bpf_program' to prevent possible confusion.

bpf_program__new() creates a new 'struct bpf_program' object. It first
init a variable in stack using __bpf_program__new(), then if success,
enlarges obj->programs array and copy the new object in.

Signed-off-by: Wang Nan 
Acked-by: Alexei Starovoitov 
Cc: Brendan Gregg 
Cc: Daniel Borkmann 
Cc: David Ahern 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Kaixu Xia 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1435716878-189507-13-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
  tools/lib/bpf/libbpf.c | 117 +
  1 file changed, 117 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 9b016c0..3b717de 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -78,12 +78,27 @@ void libbpf_set_print(libbpf_print_fn_t warn,
  # define LIBBPF_ELF_C_READ_MMAP ELF_C_READ
  #endif
+/*
+ * bpf_prog should be a better name but it has been used in
+ * linux/filter.h.
+ */
+struct bpf_program {
+   /* Index in elf obj file, for relocation use. */
+   int idx;
+   char *section_name;
+   struct bpf_insn *insns;
+   size_t insns_cnt;
+};
+
  struct bpf_object {
char license[64];
u32 kern_version;
void *maps_buf;
size_t maps_buf_sz;
+   struct bpf_program *programs;
+   size_t nr_programs;
+
/*
 * Information when doing elf related work. Only valid if fd
 * is valid.
@@ -100,6 +115,84 @@ struct bpf_object {
  };
  #define obj_elf_valid(o)  ((o)->efile.elf)
+static void bpf_program__clear(struct bpf_program *prog)
+{
+   if (!prog)
+   return;
+
+   zfree(>section_name);
+   zfree(>insns);
+   prog->insns_cnt = 0;
+   prog->idx = -1;
+}

So in perf land we use 'bpf_program__exit()' as the counterpart of
bpf_program__init(), i.e. one just initializes fields, allocating
memory for 'struct bpf_program' members, but does not allocates the
struct bpf_program itself, because sometimes we embed it inside other
structs, or we have it in arrays, as you do.

So, to keep that convention, please rename bpf_program__clear() to
bpf_program__exit() and the next function, __bpf_program__new() to
bpf_program__init(), with 'struct bpf_program *prog' as the first
parameter.

To speed things up, from now on, when I see such stuff, I will do the
changes, put them in a branch with a commiter note, and wait for your
Ack (or not, if you disagree with something).

One more comment below.


+
+static int
+__bpf_program__new(void *data, size_t size, char *name, int idx,
+  struct bpf_program *prog)
+{
+   if (size < sizeof(struct bpf_insn)) {
+   pr_warning("corrupted section '%s'\n", name);
+   return -EINVAL;
+   }
+
+   bzero(prog, sizeof(*prog));
+
+   prog->section_name = strdup(name);
+   if (!prog->section_name) {
+   pr_warning("failed to alloc name for prog %s\n",
+  name);
+   goto errout;
+   }
+
+   prog->insns = malloc(size);
+   if (!prog->insns) {
+   pr_warning("failed to alloc insns for %s\n", name);
+   goto errout;
+   }
+   prog->insns_cnt = size / sizeof(struct bpf_insn);
+   memcpy(prog->insns, data,
+  prog->insns_cnt * sizeof(struct bpf_insn));
+   prog->idx = idx;
+
+   return 0;
+errout:
+   bpf_program__clear(prog);
+   return -ENOMEM;
+}
+
+static struct bpf_program *
+bpf_program__new(struct bpf_object *obj, void *data, size_t size,
+char *name, int idx)

This, as well, is not a 'bpf_program' method, it is a 'struct
bpf_object' one, that will manipulate 'struct bpf_object' internal
state, changing its struct members to get space for an extra bpf_program
that was initialized on the stack, if the initialization of such
bpf_program went well, or bail out otherwise.

So I suggest you rename this to:

int bpf_object__add_program(struct bpf_object *obj, void *data, size_t size, 
char *name, int idx)

And probably move that debug that uses prog->section_name to just after
the realloc, here in this function.

I will look at the other patches after lunch, thanks for providing the
git tree, I will try and use it before looking at the 

Re: [PATCH 06/39] bpf tools: Create eBPF maps defined in an object file

[Wangnan (F)]

On 2015/7/14 3:54, Arnaldo Carvalho de Melo wrote:

Em Thu, Jul 09, 2015 at 12:35:09PM +, Wang Nan escreveu:




+static int
+bpf_object__create_maps(struct bpf_object *obj)
+{
+   unsigned int i;
+   size_t nr_maps;
+   int *pfd;
+
+   nr_maps = obj->maps_buf_sz / sizeof(struct bpf_map_def);
+   if (!obj->maps_buf || !nr_maps) {
+   pr_debug("don't need create maps for %s\n",
+obj->path);
+   return 0;
+   }
+
+   obj->map_fds = malloc(sizeof(int) * nr_maps);
+   if (!obj->map_fds) {
+   pr_warning("realloc perf_bpf_map_fds failed\n");
+   return -ENOMEM;
+   }
+   obj->nr_map_fds = nr_maps;
+
+   /* fill all fd with -1 */
+   memset(obj->map_fds, 0xff, sizeof(int) * nr_maps);

Huh? Each entry is an int... If you want to set it all to -1, why don't
you do it as:

memset(obj->map_fds, -1, sizeof(int) * nr_maps);

That way we can even remove that comment :) Doing it, please let me know
if this has some magic twist that makes it be right as-is, if so, please
provide a better comment.


Yes, it should be better.

Thank you,


- Arnaldo


+
+   pfd = obj->map_fds;
+   for (i = 0; i < nr_maps; i++) {
+   struct bpf_map_def def;
+
+   def = *(struct bpf_map_def *)(obj->maps_buf +
+   i * sizeof(struct bpf_map_def));
+
+   *pfd = bpf_create_map(def.type,
+ def.key_size,
+ def.value_size,
+ def.max_entries);
+   if (*pfd < 0) {
+   size_t j;
+   int err = *pfd;
+
+   pr_warning("failed to create map: %s\n",
+  strerror(errno));
+   for (j = 0; j < i; j++)
+   zclose(obj->map_fds[j]);
+   obj->nr_map_fds = 0;
+   zfree(>map_fds);
+   return err;
+   }
+   pr_debug("create map: fd=%d\n", *pfd);
+   pfd++;
+   }
+
+   zfree(>maps_buf);
+   obj->maps_buf_sz = 0;
+   return 0;
+}
+
  static int bpf_object__collect_reloc(struct bpf_object *obj)
  {
int i, err;
@@ -671,6 +736,42 @@ struct bpf_object *bpf_object__open_buffer(void *obj_buf,
return __bpf_object__open("[buffer]", obj_buf, obj_buf_sz);
  }
  
+int bpf_object__unload(struct bpf_object *obj)

+{
+   size_t i;
+
+   if (!obj)
+   return -EINVAL;
+
+   for (i = 0; i < obj->nr_map_fds; i++)
+   zclose(obj->map_fds[i]);
+   zfree(>map_fds);
+   obj->nr_map_fds = 0;
+
+   return 0;
+}
+
+int bpf_object__load(struct bpf_object *obj)
+{
+   if (!obj)
+   return -EINVAL;
+
+   if (obj->loaded) {
+   pr_warning("object should not be loaded twice\n");
+   return -EINVAL;
+   }
+
+   obj->loaded = true;
+   if (bpf_object__create_maps(obj))
+   goto out;
+
+   return 0;
+out:
+   bpf_object__unload(obj);
+   pr_warning("failed to load object '%s'\n", obj->path);
+   return -EINVAL;
+}
+
  void bpf_object__close(struct bpf_object *obj)
  {
size_t i;
@@ -679,6 +780,7 @@ void bpf_object__close(struct bpf_object *obj)
return;
  
  	bpf_object__elf_finish(obj);

+   bpf_object__unload(obj);
  
  	zfree(>maps_buf);
  
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h

index 6e75acd..3e69600 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -30,6 +30,10 @@ struct bpf_object *bpf_object__open_buffer(void *obj_buf,
   size_t obj_buf_sz);
  void bpf_object__close(struct bpf_object *object);
  
+/* Load/unload object into/from kernel */

+int bpf_object__load(struct bpf_object *obj);
+int bpf_object__unload(struct bpf_object *obj);
+
  /*
   * We don't need __attribute__((packed)) now since it is
   * unnecessary for 'bpf_map_def' because they are all aligned.
--
1.8.3.4



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] e1000e: Move e1000e_disable_aspm_locked() inside CONFIG_PM

[Michael Ellerman]

e1000e_disable_aspm_locked() is only used in __e1000_resume() which is
inside CONFIG_PM. So when CONFIG_PM=n we get a "defined but not used"
warning for e1000e_disable_aspm_locked().

Move it inside the existing CONFIG_PM block to avoid the warning.

Signed-off-by: Michael Ellerman 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 89d788d8f263..f1d7fe2ea183 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6439,6 +6439,7 @@ static void e1000e_disable_aspm(struct pci_dev *pdev, u16 
state)
__e1000e_disable_aspm(pdev, state, 0);
 }
 
+#ifdef CONFIG_PM
 /**
  * e1000e_disable_aspm_locked   Disable ASPM states.
  * @pdev: pointer to PCI device struct
@@ -6452,7 +6453,6 @@ static void e1000e_disable_aspm_locked(struct pci_dev 
*pdev, u16 state)
__e1000e_disable_aspm(pdev, state, 1);
 }
 
-#ifdef CONFIG_PM
 static int __e1000_resume(struct pci_dev *pdev)
 {
struct net_device *netdev = pci_get_drvdata(pdev);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Greg Kroah-Hartman]

On Mon, Jul 13, 2015 at 10:51:00PM -0400, Oleg Drokin wrote:
> 
> On Jul 13, 2015, at 10:46 PM, Greg Kroah-Hartman wrote:
> 
> > On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
> >> From: Oleg Drokin 
> >> 
> >> It's just a fancy libcfs_debug_mb module parameter wrapper,
> >> so just add debug buffer size check and resizing and the same
> >> functionality now would be accessible via
> >> /sys/module/libcfs/parameters/libcfs_debug_mb
> >> 
> >> Also add a symlink for backwards compatibility.
> >> 
> >> Signed-off-by: Oleg Drokin 
> >> ---
> >> drivers/staging/lustre/lustre/libcfs/debug.c | 37 
> >> ++--
> >> drivers/staging/lustre/lustre/libcfs/module.c| 32 ++--
> >> drivers/staging/lustre/lustre/libcfs/tracefile.c | 12 
> >> drivers/staging/lustre/lustre/libcfs/tracefile.h |  1 -
> >> 4 files changed, 37 insertions(+), 45 deletions(-)
> >> 
> >> diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
> >> b/drivers/staging/lustre/lustre/libcfs/debug.c
> >> index 5ae7b65..e4c7129 100644
> >> --- a/drivers/staging/lustre/lustre/libcfs/debug.c
> >> +++ b/drivers/staging/lustre/lustre/libcfs/debug.c
> >> @@ -57,8 +57,39 @@ module_param(libcfs_debug, int, 0644);
> >> MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
> >> EXPORT_SYMBOL(libcfs_debug);
> >> 
> >> +static int libcfs_param_debug_mb_set(const char *val,
> >> +   const struct kernel_param *kp)
> >> +{
> >> +  int rc;
> >> +  unsigned num;
> >> +
> >> +  rc = kstrtouint(val, 0, );
> >> +  if (rc == -EINVAL)
> >> +  return -EINVAL;
> >> +
> >> +  if (!*((unsigned int *)kp->arg)) {
> >> +  *((unsigned int *)kp->arg) = num;
> >> +  return 0;
> >> +  }
> >> +
> >> +  rc = cfs_trace_set_debug_mb(num);
> >> +
> >> +  if (!rc)
> >> +  *((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
> >> +
> >> +  return rc;
> >> +}
> >> +
> >> +static struct kernel_param_ops param_ops_debugmb = {
> >> +  .set = libcfs_param_debug_mb_set,
> >> +  .get = param_get_uint,
> >> +};
> >> +
> >> +#define param_check_debugmb(name, p) \
> >> +  __param_check(name, p, unsigned int)
> >> +
> >> static unsigned int libcfs_debug_mb;
> >> -module_param(libcfs_debug_mb, uint, 0644);
> >> +module_param(libcfs_debug_mb, debugmb, 0644);
> > 
> > module_param wants a variable type as the second option, not a variable
> > name, how is this working?
> 
> debugmb IS the type, that I just declared above.
> See all the param_ops_XXX and param_check_XXX thing?

Ah, missed that, sorry, my fault.

Ok, I see you resent this with a better comment, thanks for that, I'll
go queue it up now.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] livepatch: klp_disable_func returnes once it does not satisfy the condition

[Josh Poimboeuf]

On Tue, Jul 14, 2015 at 11:15:37AM +0800, Minfei Huang wrote:
> From: Minfei Huang 
> 
> It is more better that klp_disable_func returnes immediately, if
> func->state and func->old_addr do not satisfy the condition.
> 
> We should robust the livepatch code, although the above situation never
> happen in current code path.
> 
> Signed-off-by: Minfei Huang 
> ---
>  kernel/livepatch/core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index c40ebcc..6e53441 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -348,8 +348,10 @@ static void klp_disable_func(struct klp_func *func)
>  {
>   struct klp_ops *ops;
>  
> - WARN_ON(func->state != KLP_ENABLED);
> - WARN_ON(!func->old_addr);
> + if (WARN_ON(func->state != KLP_ENABLED))
> + return;
> + if (WARN_ON(!func->old_addr))
> + return;
>  
>   ops = klp_find_ops(func->old_addr);
>   if (WARN_ON(!ops))

Acked-by: Josh Poimboeuf 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] ARM: dts: vfxxx: Include support for esdhc0 functionality.

[Shawn Guo]

On Wed, Jul 08, 2015 at 04:51:06PM -0400, Cory Tusar wrote:
> Extend the existing Vybrid eSDHC devicetree implementation to also
> describe the esdhc0 functional block.
> 
> Tested on a custom VF610-based board with a Toshiba THGBM1G5D2EBAI7 eMMC
> module attached to esdhc0.
> 
> Signed-off-by: Cory Tusar 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation

[Punnaiah Choudary Kalluri]

Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v3:
- None
Changes in v2:
- None
---
 .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  |   61 
 1 files changed, 61 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..e4f92b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,61 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible: Should be "xlnx,zynqmp-dma-1.0"
+- #dma-cells: Should be <1>, a single cell holding a line request number
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt
+- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+  gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
+   descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+   source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+   dst descriptor payload are marked Non-coherent
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2 values
+ i.e 1,2,4,8 and 16
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 values
+ i.e 1,2,4,8 and 16
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+   compatible = "xlnx,zynqmp-dma-1.0";
+   reg = <0x0 0xFD50 0x1000>;
+   #dma_cells = <1>;
+   interrupt-parent = <>;
+   interrupts = <0 117 4>;
+   xlnx,bus-width = <128>;
+   xlnx,include-sg;
+   xlnx,overfetch;
+   xlnx,ratectrl = <0>;
+   xlnx,src-issue = <16>;
+   xlnx,desc-axi-cohrnt;
+   xlnx,src-axi-cohrnt;
+   xlnx,dst-axi-cohrnt;
+   xlnx,desc-axi-qos = <0>;
+   xlnx,desc-axi-cache = <0>;
+   xlnx,src-axi-qos = <0>;
+   xlnx,src-axi-cache = <2>;
+   xlnx,dst-axi-qos = <0>;
+   xlnx,dst-axi-cache = <2>;
+   xlnx,src-burst-len = <4>;
+   xlnx,dst-burst-len = <4>;
+};
-- 
1.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/2] dma: Add Xilinx zynqmp dma engine driver support

[Punnaiah Choudary Kalluri]

Added the basic driver for zynqmp dma engine used in Zynq
UltraScale+ MPSoC. The initial release of this driver supports
only memory to memory transfers.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v3:
- Modified the zynqmp_dma_chan_is_idle function return type to bool
Changes in v2:
- Corrected the function header documentation
- Framework expects bus-width value in bytes. so, fixed it.
- Removed magic numbers for bus-width
---
 drivers/dma/Kconfig |6 +
 drivers/dma/xilinx/Makefile |1 +
 drivers/dma/xilinx/zynqmp_dma.c | 1216 +++
 3 files changed, 1223 insertions(+), 0 deletions(-)
 create mode 100644 drivers/dma/xilinx/zynqmp_dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index bda2cb0..d5b57fc 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -410,6 +410,12 @@ config XILINX_VDMA
  channels, Memory Mapped to Stream (MM2S) and Stream to
  Memory Mapped (S2MM) for the data transfers.
 
+config XILINX_ZYNQMP_DMA
+   tristate "Xilinx ZynqMP DMA Engine"
+   select DMA_ENGINE
+   help
+ Enable support for Xilinx ZynqMP DMA engine in Zynq UltraScale+ MPSoC.
+
 config DMA_SUN6I
tristate "Allwinner A31 SoCs DMA support"
depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..95469dc 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
new file mode 100644
index 000..cfb169a
--- /dev/null
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -0,0 +1,1216 @@
+/*
+ * DMA driver for Xilinx ZynqMP DMA Engine
+ *
+ * Copyright (C) 2015 Xilinx, Inc. All rights reserved.
+ *
+ * This program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+
+/* Register Offsets */
+#define ISR0x100
+#define IMR0x104
+#define IER0x108
+#define IDS0x10C
+#define CTRL0  0x110
+#define CTRL1  0x114
+#define STATUS 0x11C
+#define DATA_ATTR  0x120
+#define DSCR_ATTR  0x124
+#define SRC_DSCR_WRD0  0x128
+#define SRC_DSCR_WRD1  0x12C
+#define SRC_DSCR_WRD2  0x130
+#define SRC_DSCR_WRD3  0x134
+#define DST_DSCR_WRD0  0x138
+#define DST_DSCR_WRD1  0x13C
+#define DST_DSCR_WRD2  0x140
+#define DST_DSCR_WRD3  0x144
+#define SRC_START_LSB  0x158
+#define SRC_START_MSB  0x15C
+#define DST_START_LSB  0x160
+#define DST_START_MSB  0x164
+#define TOTAL_BYTE 0x188
+#define RATE_CTRL  0x18C
+#define IRQ_SRC_ACCT   0x190
+#define IRQ_DST_ACCT   0x194
+#define CTRL2  0x200
+
+/* Interrupt registers bit field definitions */
+#define DMA_DONE   BIT(10)
+#define AXI_WR_DATABIT(9)
+#define AXI_RD_DATABIT(8)
+#define AXI_RD_DST_DSCRBIT(7)
+#define AXI_RD_SRC_DSCRBIT(6)
+#define IRQ_DST_ACCT_ERR   BIT(5)
+#define IRQ_SRC_ACCT_ERR   BIT(4)
+#define BYTE_CNT_OVRFL BIT(3)
+#define DST_DSCR_DONE  BIT(2)
+#define INV_APBBIT(0)
+
+/* Control 0 register bit field definitions */
+#define OVR_FETCH  BIT(7)
+#define POINT_TYPE_SG  BIT(6)
+#define RATE_CTRL_EN   BIT(3)
+
+/* Control 1 register bit field definitions */
+#define SRC_ISSUE  GENMASK(4, 0)
+
+/* Channel status register bit field definitions */
+#define STATUS_BUSY0x2
+
+/* Data Attribute register bit field definitions */
+#define ARBURSTGENMASK(27, 26)
+#define ARCACHEGENMASK(25, 22)
+#define ARCACHE_OFST   22
+#define ARQOS  GENMASK(21, 18)
+#define ARQOS_OFST 18
+#define ARLEN  GENMASK(17, 14)
+#define ARLEN_OFST 14
+#define AWBURST

Re: [PATCH v1 0/7] fsl-quadspi: Allow additional device combinations.

[Shawn Guo]

On Wed, Jul 08, 2015 at 04:21:14PM -0400, Cory Tusar wrote:
> Cory Tusar (7):
>   ARM: dts: vf610: Add missing QuadSPI register mapping and names.
>   ARM: dts: vfxxx: Include support for qspi1 functionality.

Applied these two, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [of] 649e0a77e28:

[Rob Herring]

On Mon, Jul 13, 2015 at 9:37 PM, Huang Ying  wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 649e0a77e28a7796bf62bfda0fe3f2aee094bd58 ("of: make unittest select 
> OF_EARLY_FLATTREE instead of depend on it")
>
> The following new message in kernel log may make end user confuse.
>
> [2.775617] device-tree: Duplicate name in testcase-data, renamed to 
> "duplicate-name#1"

This should probably be after the next line.

> [2.779463] ### dt-test ### start of unittest - you will see error messages

Is "you will see error messages" not clear enough?

We could prefix every message to make it clearer. Unit tests often
print error messages and typically should not be enabled on production
kernels.

Rob

> [2.780294] /testcase-data/phandle-tests/consumer-a: could not get 
> #phandle-cells-missing for /testcase-data/phandle-tests/provider1
> [2.781341] /testcase-data/phandle-tests/consumer-a: could not get 
> #phandle-cells-missing for /testcase-data/phandle-tests/provider1
> [2.782394] /testcase-data/phandle-tests/consumer-a: could not find phandle
> [2.783001] /testcase-data/phandle-tests/consumer-a: could not find phandle
> [2.783622] /testcase-data/phandle-tests/consumer-a: arguments longer than 
> property
> [2.784333] /testcase-data/phandle-tests/consumer-a: arguments longer than 
> property
>
>
> Thanks,
> Ying Huang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/5] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS

[Daniel Kurtz]

On Tue, Jul 14, 2015 at 10:45 AM, James Liao  wrote:
> Hi Daniel,
>
> On Mon, 2015-07-13 at 22:46 +0800, Daniel Kurtz wrote:
>
>> > +static const struct clk_ops mtk_ref2usb_tx_ops = {
>> > +   .is_prepared= mtk_ref2usb_tx_is_prepared,
>> > +   .prepare= mtk_ref2usb_tx_prepare,
>> > +   .unprepare  = mtk_ref2usb_tx_unprepare,
>> > +};
>>
>> Burying the implementation of this special "mtk_ref2usb" clock in
>> clk-mt8173,c seems a bit awkward.
>> Can you please move it to its own file, like mediatek/clk-usb.c?
>
> Do you mean clk/mediatek/clk-usb.c?
>
> This clock is a MT8173 specific clock, which may not be reused by other
> SoCs. So I think it's not necessary to move it to a separated file.

Yes, this is a wrapper for a type of clock.  I think it would be
better in its own file, rather than embedded in clk-mt8173.c, which is
more about enumerating and initializing the clock tree.

Perhaps today it is only used for mt8173, but that may not be the case
in the future.

-Dan


>
>> > +
>> > +static struct clk *mtk_clk_register_ref2usb_tx(const char *name,
>> > +   const char *parent_name, void __iomem *reg)
>> > +{
>> > +   struct mtk_ref2usb_tx *tx;
>> > +   struct clk_init_data init = {};
>> > +   struct clk *clk;
>> > +
>> > +   tx = kzalloc(sizeof(*tx), GFP_KERNEL);
>> > +   if (!tx)
>> > +   return ERR_PTR(-ENOMEM);
>> > +
>> > +   tx->base_addr = reg;
>> > +   tx->hw.init = 
>> > +
>> > +   init.name = name;
>> > +   init.ops = _ref2usb_tx_ops;
>> > +   init.parent_names = _name;
>> > +   init.num_parents = 1;
>> > +
>> > +   clk = clk_register(NULL, >hw);
>> > +
>> > +   if (IS_ERR(clk)) {
>> > +   pr_err("Failed to register clk %s: %ld\n", name, 
>> > PTR_ERR(clk));
>> > +   kfree(tx);
>> > +   }
>> > +
>> > +   return clk;
>> > +}
>> > +
>> > +struct mtk_apmixed_ex {
>> > +   int id;
>> > +   const char *name;
>> > +   const char *parent;
>> > +   u32 reg_ofs;
>> > +};
>> > +
>> > +#define APMIXED_EX(_id, _name, _parent, _reg_ofs) {\
>> > +   .id = _id,  \
>> > +   .name = _name,  \
>> > +   .parent = _parent,  \
>> > +   .reg_ofs = _reg_ofs,\
>> > +   }
>> > +
>> > +static const struct mtk_apmixed_ex apmixed_ex[] = {
>>
>> __initconst
>
> OK. I'll fix it in next patch.
>
>> > +   APMIXED_EX(CLK_APMIXED_REF2USB_TX, "ref2usb_tx", "clk26m", 0x8),
>> > +};
>> > +
>> > +static void __init mtk_clk_register_apmixedsys_special(struct device_node 
>> > *node,
>> > +   struct clk_onecell_data *clk_data)
>> > +{
>> > +   void __iomem *base;
>> > +   struct clk *clk;
>> > +   int i;
>> > +
>> > +   base = of_iomap(node, 0);
>> > +   if (!base) {
>> > +   pr_err("%s(): ioremap failed\n", __func__);
>> > +   return;
>> > +   }
>> > +
>> > +   for (i = 0; i < ARRAY_SIZE(apmixed_ex); i++) {
>> > +   const struct mtk_apmixed_ex *ape = _ex[i];
>> > +
>> > +   clk = mtk_clk_register_ref2usb_tx(ape->name, ape->parent,
>> > +   base + 
>> > ape->reg_ofs);
>> > +
>> > +   if (IS_ERR(clk)) {
>> > +   pr_err("Failed to register clk %s: %ld\n", 
>> > ape->name,
>> > +   PTR_ERR(clk));
>> > +   continue;
>> > +   }
>> > +
>> > +   clk_data->clks[CLK_APMIXED_REF2USB_TX] = clk;
>>
>> This works assuming ARRAY_SIZE(apmixed_ex) == 1.
>> Either remove the loop since it is unnecessary, or do:
>>   clk_data->clks[ape->id] = clk;
>
> It should be "clk_data->clks[ape->id] = clk". I'll fix it in next patch.
>
>
> Best regards,
>
> James
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] staging/lustre/libcfs: remove unused portal_enter_debugger variable

[green]

From: Dmitry Eremin 

Remove portal_enter_debugger because it's not used any more.

Signed-off-by: Dmitry Eremin 
---
 drivers/staging/lustre/lustre/libcfs/debug.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
b/drivers/staging/lustre/lustre/libcfs/debug.c
index 1cc714c..6346887 100644
--- a/drivers/staging/lustre/lustre/libcfs/debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/debug.c
@@ -215,9 +215,6 @@ EXPORT_SYMBOL(libcfs_debug_binary);
 unsigned int libcfs_stack = 3 * THREAD_SIZE / 4;
 EXPORT_SYMBOL(libcfs_stack);
 
-static unsigned int portal_enter_debugger;
-EXPORT_SYMBOL(portal_enter_debugger);
-
 unsigned int libcfs_catastrophe;
 EXPORT_SYMBOL(libcfs_catastrophe);
 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] Lustre: remaining bits of sysctl debugfs migration

[green]

From: Oleg Drokin 

Rediffed the last few patches as per Greg's instructions.
Also Added a folow on fix for the uint_min_max param to
properly take into account kstrtouint range of error return values.

Please consider.

Dmitry Eremin (2):
  staging/lustre/libcfs: get rid of
debugfs/lnet/console_{min,max}_delay_centisecs
  staging/lustre/libcfs: remove unused portal_enter_debugger variable

Oleg Drokin (2):
  staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb
  staging/lustre/libcfs: Fix kstrtouint return value check fix

 drivers/staging/lustre/lustre/libcfs/debug.c | 114 ---
 drivers/staging/lustre/lustre/libcfs/module.c| 114 ++-
 drivers/staging/lustre/lustre/libcfs/tracefile.c |  12 ---
 drivers/staging/lustre/lustre/libcfs/tracefile.h |   1 -
 4 files changed, 109 insertions(+), 132 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[green]

From: Oleg Drokin 

It's just a fancy libcfs_debug_mb module parameter wrapper,
so just add debug buffer size check and resizing and the same
functionality now would be accessible via
/sys/module/libcfs/parameters/libcfs_debug_mb

Also add a symlink for backwards compatibility.

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/libcfs/debug.c | 40 ++--
 drivers/staging/lustre/lustre/libcfs/module.c| 32 ++-
 drivers/staging/lustre/lustre/libcfs/tracefile.c | 12 ---
 drivers/staging/lustre/lustre/libcfs/tracefile.h |  1 -
 4 files changed, 40 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
b/drivers/staging/lustre/lustre/libcfs/debug.c
index 5ae7b65..995a1e3 100644
--- a/drivers/staging/lustre/lustre/libcfs/debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/debug.c
@@ -57,8 +57,42 @@ module_param(libcfs_debug, int, 0644);
 MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
 EXPORT_SYMBOL(libcfs_debug);
 
+static int libcfs_param_debug_mb_set(const char *val,
+const struct kernel_param *kp)
+{
+   int rc;
+   unsigned num;
+
+   rc = kstrtouint(val, 0, );
+   if (rc < 0)
+   return rc;
+
+   if (!*((unsigned int *)kp->arg)) {
+   *((unsigned int *)kp->arg) = num;
+   return 0;
+   }
+
+   rc = cfs_trace_set_debug_mb(num);
+
+   if (!rc)
+   *((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
+
+   return rc;
+}
+
+/* While debug_mb setting look like unsigned int, in fact
+ * it needs quite a bunch of extra processing, so we define special
+ * debugmb parameter type with corresponding methods to handle this case */
+static struct kernel_param_ops param_ops_debugmb = {
+   .set = libcfs_param_debug_mb_set,
+   .get = param_get_uint,
+};
+
+#define param_check_debugmb(name, p) \
+   __param_check(name, p, unsigned int)
+
 static unsigned int libcfs_debug_mb;
-module_param(libcfs_debug_mb, uint, 0644);
+module_param(libcfs_debug_mb, debugmb, 0644);
 MODULE_PARM_DESC(libcfs_debug_mb, "Total debug buffer size.");
 EXPORT_SYMBOL(libcfs_debug_mb);
 
@@ -437,8 +471,10 @@ int libcfs_debug_init(unsigned long bufsize)
}
rc = cfs_tracefile_init(max);
 
-   if (rc == 0)
+   if (rc == 0) {
libcfs_register_panic_notifier();
+   libcfs_debug_mb = cfs_trace_get_debug_mb();
+   }
 
return rc;
 }
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c 
b/drivers/staging/lustre/lustre/libcfs/module.c
index 8e228ae..acfe778 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -550,31 +550,6 @@ static int proc_daemon_file(struct ctl_table *table, int 
write,
 __proc_daemon_file);
 }
 
-static int __proc_debug_mb(void *data, int write,
-  loff_t pos, void __user *buffer, int nob)
-{
-   if (!write) {
-   char tmpstr[32];
-   int  len = snprintf(tmpstr, sizeof(tmpstr), "%d",
-   cfs_trace_get_debug_mb());
-
-   if (pos >= len)
-   return 0;
-
-   return cfs_trace_copyout_string(buffer, nob, tmpstr + pos,
-  "\n");
-   }
-
-   return cfs_trace_set_debug_mb_usrstr(buffer, nob);
-}
-
-static int proc_debug_mb(struct ctl_table *table, int write,
-void __user *buffer, size_t *lenp, loff_t *ppos)
-{
-   return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_debug_mb);
-}
-
 static int proc_console_max_delay_cs(struct ctl_table *table, int write,
 void __user *buffer, size_t *lenp,
 loff_t *ppos)
@@ -790,11 +765,6 @@ static struct ctl_table lnet_table[] = {
.proc_handler = _daemon_file,
},
{
-   .procname = "debug_mb",
-   .mode = 0644,
-   .proc_handler = _debug_mb,
-   },
-   {
.procname = "force_lbug",
.data = NULL,
.maxlen   = 0,
@@ -833,6 +803,8 @@ struct lnet_debugfs_symlink_def lnet_debugfs_symlinks[] = {
  "/sys/module/libcfs/parameters/libcfs_panic_on_lbug"},
{ "libcfs_console_backoff",
  "/sys/module/libcfs/parameters/libcfs_console_backoff"},
+   { "debug_mb",
+ "/sys/module/libcfs/parameters/libcfs_debug_mb"},
{},
 };
 
diff --git a/drivers/staging/lustre/lustre/libcfs/tracefile.c 
b/drivers/staging/lustre/lustre/libcfs/tracefile.c
index 6ee2adc..effa2af 100644
--- a/drivers/staging/lustre/lustre/libcfs/tracefile.c
+++ b/drivers/staging/lustre/lustre/libcfs/tracefile.c
@@ -937,18 +937,6 @@ int cfs_trace_set_debug_mb(int mb)
return 0;
 }
 

[PATCH 4/4] staging/lustre/libcfs: Fix kstrtouint return value check fix

[green]

From: Oleg Drokin 

Apparently kstrtouint could return not just -EINVAL, but also -ERANGE,
so make sure we just check the return value for something negative.

Noticed by Dan Carpenter 

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/libcfs/debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
b/drivers/staging/lustre/lustre/libcfs/debug.c
index 6346887..e93f556 100644
--- a/drivers/staging/lustre/lustre/libcfs/debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/debug.c
@@ -185,7 +185,7 @@ static int param_set_uint_minmax(const char *val,
if (!val)
return -EINVAL;
ret = kstrtouint(val, 0, );
-   if (ret == -EINVAL || num < min || num > max)
+   if (ret < 0 || num < min || num > max)
return -EINVAL;
*((unsigned int *)kp->arg) = num;
return 0;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] staging/lustre/libcfs: get rid of debugfs/lnet/console_{min,max}_delay_centisecs

[green]

From: Dmitry Eremin 

They are just fancy module parameters wrappers,
so just the same functionality now would be accessible via
/sys/module/libcfs/parameters/libcfs_console_{min,max}_delay

Also install compatibility symlinks

Signed-off-by: Dmitry Eremin 
Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/libcfs/debug.c  | 69 --
 drivers/staging/lustre/lustre/libcfs/module.c | 82 ++-
 2 files changed, 68 insertions(+), 83 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
b/drivers/staging/lustre/lustre/libcfs/debug.c
index 995a1e3..1cc714c 100644
--- a/drivers/staging/lustre/lustre/libcfs/debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/debug.c
@@ -106,16 +106,75 @@ module_param(libcfs_console_ratelimit, uint, 0644);
 MODULE_PARM_DESC(libcfs_console_ratelimit, "Lustre kernel debug console 
ratelimit (0 to disable)");
 EXPORT_SYMBOL(libcfs_console_ratelimit);
 
+static int param_set_delay_minmax(const char *val,
+ const struct kernel_param *kp,
+ long min, long max)
+{
+   long d;
+   int sec;
+   int rc;
+
+   rc = kstrtoint(val, 0, );
+   if (rc)
+   return -EINVAL;
+
+   d = cfs_time_seconds(sec) / 100;
+   if (d < min || d > max)
+   return -EINVAL;
+
+   *((unsigned int *)kp->arg) = d;
+
+   return 0;
+}
+
+static int param_get_delay(char *buffer, const struct kernel_param *kp)
+{
+   unsigned int d = *(unsigned int *)kp->arg;
+
+   return sprintf(buffer, "%u", (unsigned int)cfs_duration_sec(d * 100));
+}
+
 unsigned int libcfs_console_max_delay;
-module_param(libcfs_console_max_delay, uint, 0644);
-MODULE_PARM_DESC(libcfs_console_max_delay, "Lustre kernel debug console max 
delay (jiffies)");
 EXPORT_SYMBOL(libcfs_console_max_delay);
-
 unsigned int libcfs_console_min_delay;
-module_param(libcfs_console_min_delay, uint, 0644);
-MODULE_PARM_DESC(libcfs_console_min_delay, "Lustre kernel debug console min 
delay (jiffies)");
 EXPORT_SYMBOL(libcfs_console_min_delay);
 
+static int param_set_console_max_delay(const char *val,
+  const struct kernel_param *kp)
+{
+   return param_set_delay_minmax(val, kp,
+ libcfs_console_min_delay, INT_MAX);
+}
+
+static struct kernel_param_ops param_ops_console_max_delay = {
+   .set = param_set_console_max_delay,
+   .get = param_get_delay,
+};
+
+#define param_check_console_max_delay(name, p) \
+   __param_check(name, p, unsigned int)
+
+module_param(libcfs_console_max_delay, console_max_delay, 0644);
+MODULE_PARM_DESC(libcfs_console_max_delay, "Lustre kernel debug console max 
delay (jiffies)");
+
+static int param_set_console_min_delay(const char *val,
+  const struct kernel_param *kp)
+{
+   return param_set_delay_minmax(val, kp,
+ 1, libcfs_console_max_delay);
+}
+
+static struct kernel_param_ops param_ops_console_min_delay = {
+   .set = param_set_console_min_delay,
+   .get = param_get_delay,
+};
+
+#define param_check_console_min_delay(name, p) \
+   __param_check(name, p, unsigned int)
+
+module_param(libcfs_console_min_delay, console_min_delay, 0644);
+MODULE_PARM_DESC(libcfs_console_min_delay, "Lustre kernel debug console min 
delay (jiffies)");
+
 static int param_set_uint_minmax(const char *val,
 const struct kernel_param *kp,
 unsigned int min, unsigned int max)
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c 
b/drivers/staging/lustre/lustre/libcfs/module.c
index acfe778..0ed2658 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -550,72 +550,6 @@ static int proc_daemon_file(struct ctl_table *table, int 
write,
 __proc_daemon_file);
 }
 
-static int proc_console_max_delay_cs(struct ctl_table *table, int write,
-void __user *buffer, size_t *lenp,
-loff_t *ppos)
-{
-   int rc, max_delay_cs;
-   struct ctl_table dummy = *table;
-   long d;
-
-   dummy.data = _delay_cs;
-   dummy.proc_handler = _dointvec;
-
-   if (!write) { /* read */
-   max_delay_cs = cfs_duration_sec(libcfs_console_max_delay * 100);
-   rc = proc_dointvec(, write, buffer, lenp, ppos);
-   return rc;
-   }
-
-   /* write */
-   max_delay_cs = 0;
-   rc = proc_dointvec(, write, buffer, lenp, ppos);
-   if (rc < 0)
-   return rc;
-   if (max_delay_cs <= 0)
-   return -EINVAL;
-
-   d = cfs_time_seconds(max_delay_cs) / 100;
-   if (d == 0 || d < libcfs_console_min_delay)
-   return -EINVAL;
-   libcfs_console_max_delay = d;
-
- 

[PATCH V4 1/1] usb:serial:f81534 add F81532/534 driver

[Peter Hung]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

Features:
1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
2. Support Baudrate from B50 to B150 (excluding B100).
3. The RTS signal can be transformed their behavior with
   configuration by default ioctl TIOCGRS485/TIOCSRS485
   (for RS232/RS485/RS422 with transceiver)

   If the driver setting with SER_RS485_ENABLED, the RTS signal will
   high with not in TX and low with in TX.

   If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
   the RTS signal will low with not in TX and high with in TX.

4. There are 4x3 output-only ic pins to control transceiver mode.
   It's can be controlled via gpiolib. We could found the gpio
   number from /sys/class/tty/ttyUSB[x]/device/gpiochap[yyy] where
   x is F81532/534 serial port and yyy is gpiochip number.

   After we found chip number, we can export 3 gpios(M2/M1/M0) per
   serial port by
  echo yyy > /sys/class/gpio/export
  echo yyy+1 > /sys/class/gpio/export
  echo yyy+2 > /sys/class/gpio/export

   then we can control it with
  echo [M0 value] > /sys/class/gpio/gpio[yyy]/value
  echo [M1 value] > /sys/class/gpio/gpio[yyy+1]/value
  echo [M2 value] > /sys/class/gpio/gpio[yyy+2]/value
   which M0/M1/M2 as your desired value, value is only 0 or 1.

   When configure complete, It's a must to free all gpio by
  echo yyy > /sys/class/gpio/unexport
  echo yyy+1 > /sys/class/gpio/unexport
  echo yyy+2 > /sys/class/gpio/unexport

   The driver will "save" gpio configure after we release
   all gpio of a serial port.

   For examples to change mode & gpio with F81532/534
   Evalaution Board.

   F81532 EVB
  port0: F81437 (RS232 only)
  port1: F81439 (RS232/RS485/RS422 ... etc.)
   F81534 EVB
  port0/1: F81437 (RS232 only)
  port2/3: F81439 (RS232/RS485/RS422 ... etc.)

  1. RS232 Mode (Default IC Mode)
 1. Set struct serial_rs485 flags "without" SER_RS485_ENABLED
(control F81532/534 RTS control)
 2. Set M2/M1/M0 as 0/0/1
(control F81532/534 output pin to control transceiver mode)

  2. RS485 Mode (RTS Low when TX Mode)
 1. Set struct serial_rs485 flags with SER_RS485_ENABLED
 2. Set M2/M1/M0 as 0/1/0

  3. RS485 Mode (RTS High when TX Mode)
 1. Set struct serial_rs485 flags with SER_RS485_ENABLED and
SER_RS485_RTS_ON_SEND
 2. Set M2/M1/M0 as 0/1/1

  4. RS422 Mode
 1. The RTS mode is dont care.
 2. Set M2/M1/M0 as 0/0/0

   Please reference https://bitbucket.org/hpeter/fintek-general/src/
   with f81534/tools to get set_gpio.c & set_mode.c. Please use it
   carefully.

Changelog
v4
1. clearify f81534_process_read_urb() with
   f81534_process_per_serial_block(). (referenced from mxuport.c)
2. We limited f81534_write() max tx kfifo with 124Bytes.
   Original subsystem is designed for auto tranmiting fifo data
   if available. But we must wait for tx_empty for next tx data
   (H/W design).

   With this kfifo size limit, we can use generic subsystem api with
   f81534_write(). When usb_serial_generic_write_start() called after
   first write URB complete, the fifo will no data. The generic
   subsystem of write will go to idle state. Until we received TX_EMPTY
   and release write spinlock, the fifo will fill max 124Bytes by
   following f81534_write().

v3
1. Migrate read, write and some routine from custom code to usbserial
   subsystem callback function.
2. Use more defines to replece magic numbers to make it meaningful
3. Make more comments as document in source code.

v2
1. v1 version submit to staging tree, but Greg KH advised me to
   cleanup source code & re-submit it to correct subsystem
2. Remove all custom ioctl commands

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/Kconfig  |   10 +
 drivers/usb/serial/Makefile |1 +
 drivers/usb/serial/f81534.c | 3315 +++
 3 files changed, 3326 insertions(+)
 create mode 100644 drivers/usb/serial/f81534.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..0642864 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -255,6 +255,16 @@ config USB_SERIAL_F81232
  To compile this driver as a module, choose M here: the
  module will be called f81232.
 
+config USB_SERIAL_F8153X
+   tristate "USB Fintek F81532/534 Multi-Ports Serial Driver"
+   help
+ Say Y here if you want to use the Fintek F81532/534 Multi-Ports
+ usb to serial adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called f81534.
+
+
 config USB_SERIAL_GARMIN
tristate "USB Garmin GPS driver"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..9e43b7b 100644
--- 

[PATCH] livepatch: klp_disable_func returnes once it does not satisfy the condition

[Minfei Huang]

From: Minfei Huang 

It is more better that klp_disable_func returnes immediately, if
func->state and func->old_addr do not satisfy the condition.

We should robust the livepatch code, although the above situation never
happen in current code path.

Signed-off-by: Minfei Huang 
---
 kernel/livepatch/core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index c40ebcc..6e53441 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -348,8 +348,10 @@ static void klp_disable_func(struct klp_func *func)
 {
struct klp_ops *ops;
 
-   WARN_ON(func->state != KLP_ENABLED);
-   WARN_ON(!func->old_addr);
+   if (WARN_ON(func->state != KLP_ENABLED))
+   return;
+   if (WARN_ON(!func->old_addr))
+   return;
 
ops = klp_find_ops(func->old_addr);
if (WARN_ON(!ops))
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v5 0/3] Make eBPF programs output data to perf

[Alexei Starovoitov]

On 7/13/15 6:59 PM, He Kuang wrote:

This version we output bpf trace events in a hex array, the results
for three u64 integers in previous sample changed to this:

   dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 01 00
   00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00


typo in the above. It's not 3 u64 integers, but variable number of u8.

Whole thing looks good.
I've acked patch 3.
Hopefully Steven can review patches 1 and 2.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v5 3/3] bpf: Introduce function for outputing trace event data

[Alexei Starovoitov]

On 7/13/15 6:59 PM, He Kuang wrote:

There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.

This patch adds a new trace event to establish infrastruction for bpf to
output data to perf. Userspace perf tools can detect and use this event
as using the existing tracepoint events.

New bpf trace event entry in debugfs:

  /sys/kernel/debug/tracing/events/bpf/bpf_output_data

Userspace perf tools detect the new tracepoint event as:

  bpf:bpf_output_data  [Tracepoint event]

Data in ring-buffer of perf events added to this event will be polled
out, sample types and other attributes can be adjusted to those events
directly without touching the original kprobe events.

The bpf helper function gives eBPF program ability to output data as
perf sample event. This helper simple call the new trace event and
userspace perf tools can record the BPF ftrace event to collect those
records.

Signed-off-by: He Kuang


Looks good to me.
Acked-by: Alexei Starovoitov 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build warnings after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

drivers/gpu/drm/bochs/bochs_fbdev.c: In function 'bochsfb_create':
drivers/gpu/drm/bochs/bochs_fbdev.c:63:17: warning: unused variable 'device' 
[-Wunused-variable]
  struct device *device = >pdev->dev;
 ^

Caused by commit

  394111a2b303 ("drm/boschs: Use new drm_fb_helper functions")

drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create':
drivers/gpu/drm/cirrus/cirrus_fbdev.c:247:1: warning: label 'out_iounmap' 
defined but not used [-Wunused-label]
 out_iounmap:
 ^

Caused by commit
  fd6ab591ce15 ("drm/cirrus: Use new drm_fb_helper functions")

drivers/gpu/drm/ast/ast_fb.c: In function 'astfb_create':
drivers/gpu/drm/ast/ast_fb.c:196:17: warning: unused variable 'device' 
[-Wunused-variable]
  struct device *device = >pdev->dev;
 ^

Caused by commit

  6f4900cd28c9 ("drm/ast: Use new drm_fb_helper functions")

drivers/gpu/drm/gma500/framebuffer.c: In function 'psbfb_create':
drivers/gpu/drm/gma500/framebuffer.c:346:17: warning: unused variable 'device' 
[-Wunused-variable]
  struct device *device = >pdev->dev;
 ^

Caused by commit

  3b9a13e85365 ("drm/gma500: Use new drm_fb_helper functions")

drivers/gpu/drm/mgag200/mgag200_fb.c: In function 'mgag200fb_create':
drivers/gpu/drm/mgag200/mgag200_fb.c:232:1: warning: label 'out' defined but 
not used [-Wunused-label]
 out:
 ^
drivers/gpu/drm/mgag200/mgag200_fb.c:169:17: warning: unused variable 'device' 
[-Wunused-variable]
  struct device *device = >pdev->dev;
 ^

Caused by commit

  53ebb642ccba ("drm/mgag200: Use new drm_fb_helper functions")

drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c: In function 'amdgpufb_create':
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:206:9: warning: passing argument 1 of 
'PTR_ERR' makes pointer from integer without a cast
   ret = PTR_ERR(ret);
 ^
In file included from arch/x86/include/asm/processor.h:31:0,
 from arch/x86/include/asm/thread_info.h:49,
 from include/linux/thread_info.h:54,
 from arch/x86/include/asm/preempt.h:6,
 from include/linux/preempt.h:64,
 from include/linux/spinlock.h:50,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:26:
include/linux/err.h:28:33: note: expected 'const void *' but argument is of 
type 'int'
 static inline long __must_check PTR_ERR(__force const void *ptr)
 ^
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:182:17: warning: unused variable 
'device' [-Wunused-variable]
  struct device *device = >pdev->dev;
 ^
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c: In function 'amdgpu_fbdev_destroy':
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:283:18: warning: unused variable 'info' 
[-Wunused-variable]
  struct fb_info *info;
  ^

Caused by commit

  9d70561ba3b1 ("drm/amdgpu: Use new drm_fb_helper functions")

drivers/gpu/drm/udl/udl_fb.c: In function 'udlfb_create':
drivers/gpu/drm/udl/udl_fb.c:479:17: warning: unused variable 'device' 
[-Wunused-variable]
  struct device *device = dev->dev;
 ^

Caused by commit

  457959f2ed5f ("drm/udl: Use new drm_fb_helper functions")

drivers/gpu/drm/radeon/radeon_fb.c: In function 'radeonfb_create':
drivers/gpu/drm/radeon/radeon_fb.c:230:17: warning: unused variable 'device' 
[-Wunused-variable]
  struct device *device = >pdev->dev;
 ^

Caused by commit

  4bc29bb98bae ("drm/radeon: Use new drm_fb_helper functions")

drivers/gpu/drm/nouveau/nouveau_fbcon.c: In function 'nouveau_fbcon_create':
drivers/gpu/drm/nouveau/nouveau_fbcon.c:322:18: warning: unused variable 'pdev' 
[-Wunused-variable]
  struct pci_dev *pdev = dev->pdev;
  ^

Caused by commit

  237fc6452ca5 ("drm/nouveau: Use new drm_fb_helper functions")

I think "COMPILE TESTED ONLY" should at least include eliminating such
warnings ...
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpN_1eI6CvrY.pgp
Description: OpenPGP digital signature

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Greg Kroah-Hartman]

On Mon, Jul 13, 2015 at 10:45:36PM -0400, Oleg Drokin wrote:
> 
> On Jul 13, 2015, at 10:43 PM, Greg Kroah-Hartman wrote:
> 
> > On Wed, Jul 08, 2015 at 11:45:59AM +0300, Dan Carpenter wrote:
> >> On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
> >>> +static int libcfs_param_debug_mb_set(const char *val,
> >>> +  const struct kernel_param *kp)
> >>> +{
> >>> + int rc;
> >>> + unsigned num;
> >>> +
> >>> + rc = kstrtouint(val, 0, );
> >>> + if (rc == -EINVAL)
> >>> + return -EINVAL;
> >> 
> >> Presumably, this is root only so using num uninitialized is not an
> >> information leak.
> > 
> > But it's not good, this should be a check for rc < 0 to make sure.
> > 
> > Oleg, can you send a follow-on patch to fix this up?
> 
> Sure.
> Do you want it now or should I wait till you merge my previous bunch?

I already merged your previous bunch :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] mtd: nand: Add support for Arasan Nand Flash Controller

[punnaiah choudary kalluri]

Hi Brian,

 Any further review comments on this patch ?
Could you consider this driver for 4.3 version if you think the
changes are fine.?

Regards,
Punnaiah

On Fri, May 22, 2015 at 11:49 PM, Punnaiah Choudary Kalluri
 wrote:
> Added the basic driver for Arasan Nand Flash Controller used in
> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
> correction.
>
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
> Chnages in v3:
> - Removed unused variables
> - Avoided busy loop and used jifies based implementation
> - Fixed compiler warnings "right shift count >= width of type"
> - Removed unneeded codei and improved error reporting
> - Added onfi version check to ensure reading the valid address cycles
> Changes in v2:
> - Added missing of.h to avoid kbuild system report error
> ---
>  drivers/mtd/nand/Kconfig  |7 +
>  drivers/mtd/nand/Makefile |1 +
>  drivers/mtd/nand/arasan_nfc.c |  873 
> +
>  3 files changed, 881 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/mtd/nand/arasan_nfc.c
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 5897d8d..64e497c 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -530,4 +530,11 @@ config MTD_NAND_HISI504
> help
>   Enables support for NAND controller on Hisilicon SoC Hip04.
>
> +config MTD_NAND_ARASAN
> +   tristate "Support for Arasan Nand Flash controller"
> +   depends on MTD_NAND
> +   help
> + Enables the driver for the Arasan Nand Flash controller on
> + Zynq UltraScale+ MPSoC.
> +
>  endif # MTD_NAND
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 582bbd05..fd863ea 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY)   += xway_nand.o
>  obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)   += bcm47xxnflash/
>  obj-$(CONFIG_MTD_NAND_SUNXI)   += sunxi_nand.o
>  obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o
> +obj-$(CONFIG_MTD_NAND_ARASAN)  += arasan_nfc.o
>
>  nand-objs := nand_base.o nand_bbt.o nand_timings.o
> diff --git a/drivers/mtd/nand/arasan_nfc.c b/drivers/mtd/nand/arasan_nfc.c
> new file mode 100644
> index 000..fbf543c
> --- /dev/null
> +++ b/drivers/mtd/nand/arasan_nfc.c
> @@ -0,0 +1,873 @@
> +/*
> + * Arasan Nand Flash Controller Driver
> + *
> + * Copyright (C) 2014 - 2015 Xilinx, Inc.
> + *
> + * 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; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME"arasan_nfc"
> +#define EVNT_TIMEOUT   1000
> +#define STATUS_TIMEOUT 2000
> +
> +#define PKT_OFST   0x00
> +#define MEM_ADDR1_OFST 0x04
> +#define MEM_ADDR2_OFST 0x08
> +#define CMD_OFST   0x0C
> +#define PROG_OFST  0x10
> +#define INTR_STS_EN_OFST   0x14
> +#define INTR_SIG_EN_OFST   0x18
> +#define INTR_STS_OFST  0x1C
> +#define READY_STS_OFST 0x20
> +#define DMA_ADDR1_OFST 0x24
> +#define FLASH_STS_OFST 0x28
> +#define DATA_PORT_OFST 0x30
> +#define ECC_OFST   0x34
> +#define ECC_ERR_CNT_OFST   0x38
> +#define ECC_SPR_CMD_OFST   0x3C
> +#define ECC_ERR_CNT_1BIT_OFST  0x40
> +#define ECC_ERR_CNT_2BIT_OFST  0x44
> +#define DMA_ADDR0_OFST 0x50
> +
> +#define PKT_CNT_SHIFT  12
> +
> +#define ECC_ENABLE BIT(31)
> +#define DMA_EN_MASKGENMASK(27, 26)
> +#define DMA_ENABLE 0x2
> +#define DMA_EN_SHIFT   26
> +#define PAGE_SIZE_MASK GENMASK(25, 23)
> +#define PAGE_SIZE_SHIFT23
> +#define PAGE_SIZE_512  0
> +#define PAGE_SIZE_1K   5
> +#define PAGE_SIZE_2K   1
> +#define PAGE_SIZE_4K   2
> +#define PAGE_SIZE_8K   3
> +#define PAGE_SIZE_16K  4
> +#define CMD2_SHIFT 8
> +#define ADDR_CYCLES_SHIFT  28
> +
> +#define XFER_COMPLETE  BIT(2)
> +#define READ_READY BIT(1)
> +#define WRITE_READYBIT(0)
> +#define MBIT_ERROR BIT(3)
> +#define ERR_INTRPT BIT(4)
> +
> +#define PROG_PGRD  BIT(0)
> +#define PROG_ERASE BIT(2)
> +#define PROG_STATUS

Re: [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB

[Pan Xinhui]

hi, Rafael,
let me do more explanation :)

On 2015年07月14日 10:09, Pan Xinhui wrote:
> hi, Rafael,
>   thanks for you reply :)
> On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
>> On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
>>> hi, Rafeal
>>> thanks for your reply. :)
>>>
>>> On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
 Hi,

 On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui  wrote:
>
> If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
> cpb is not needed. Add ifdef around it.
>
> Signed-off-by: Pan Xinhui 
> ---
>  drivers/cpufreq/acpi-cpufreq.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c 
> b/drivers/cpufreq/acpi-cpufreq.c
> index e7fcaa6..314a19e 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct cpufreq_policy 
> *policy)
>  static struct freq_attr *acpi_cpufreq_attr[] = {
> _freq_attr_scaling_available_freqs,
> _cpus,
> +#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
> NULL,   /* this is a placeholder for cpb, do not remove */
> +#endif

 Adding the ifdef here doesn't change anything, because the next NULL
 will play the role of the one you've just #ifdefed and the structure
 will be filled with zeros from that point on anyway.

>>> Yes, adding ifdef here does not change any binary codes. But I want to make 
>>> the codes more readable. :)
>>> Patch author has noticed two *NULL* here would confuse people, especially 
>>> who first read this acpi-cpufreq.c file
>>> From code style point, it would be better to have #ifdef around it. 
>>
>> Not really.
>>
>> Why don't you simply drop *both* NULLs?
>>
> Just like string end with *NULL* :)
> 
> 1021 static int cpufreq_add_dev_interface(struct cpufreq_policy *policy,
> 1022  struct device *dev)
> 1023 {
> 1024 struct freq_attr **drv_attr;
> 1025 int ret = 0;
> 1026 
> 1027 /* set up files for this cpu device */
> 1028 drv_attr = cpufreq_driver->attr;
> 1029 while (drv_attr && *drv_attr) {
> 1030 ret = sysfs_create_file(>kobj, &((*drv_attr)->attr));
> 1031 if (ret)
> 1032 return ret;
> 1033 drv_attr++;
> 1034 }
> If struct freq_attr *acpi_cpufreq_attr[] did not end with NULL, line 1033 
> will access invalid data area.
> If *drv_attr(the data after struct freq_attr * array[]) happened to be not 
> NULL. panic may hit in sysfs_create_file :(
> So at least one *NULL* must be in the end of freq_attr *array[].
> 
> Actually in acpi-cpufreq.c, in acpi_cpufreq_init function.
>  957 struct freq_attr **iter;
>  958 
>  959 pr_debug("adding sysfs entry for cpb\n");
>  960 
>  961 for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
>  962 ;
>  963 
>  964 /* make sure there is a terminator behind it */
>  965 if (iter[1] == NULL)
>  966 *iter = 
>  967 }
> line965, check of iter[1] is not needed. Maybe the patch author was afraid of 
> an unexpected remove of first *NULL*.
> It might be a better solution to add ifdef CONFIG_X86_ACPI_CPUFREQ_CPB around 
> that *NULL*, and remove this !iter[1] check.
> 
According to line 961, the for loop, patch author assume the first *NULL* may 
be *at any index* of struct freq_attr *acpi_cpufreq_attr[].

But according to line 965, and the comment also says *a terminator behind it*. 
patch author assume the first *NULL* is *just right before* the second *NULL* 
which acts as a terminator.
The logic is incorrect. :(
Why not just
+   /* there must be two NULL in the end of acpi_cpufreq_attr[] */
+   struct freq_attr **iter = 
_cpufreq_attr[sizeof(acpi_cpufreq_attr) - 2];
+   if (!WARN_ON(iter[0] || iter[1]))

I don't like that codes assume the index of first *NULL*, so maybe removing 
line 965, the check if iter[1] == NULL, is more correct and beautiful :)


thanks
xinhui

> thanks
> xinhui
> 
>>
>>>
 You'd need to #ifdef it in the struct freq_attr definition, but I'm
 not sure it's worth the effort.

>>>
>>> struct freq_attr *cpb* is defined in #ifdef section. :)
>>
>> Ah, OK.
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[chunfeng yun]

hi Roger,

On Fri, 2015-07-10 at 11:31 +0300, Roger Quadros wrote:
> Hi,
> 
> On 08/07/15 12:41, Chunfeng Yun wrote:
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/usb/mt8173-xhci.txt| 27 
> > ++
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..94cec94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,27 @@
> > +MT65XX xhci
> > +
> > +The device node for Mediatek SOC usb3.0 host controller
> > +
> > +Required properties:
> > + - compatible : supports "mediatek,mt8173-xhci"
> > + - reg: Offset and length of registers
> > + - interrupts : Interrupt mode, number and trigger mode
> > + - reg-vusb33-supply:  regulator of usb avdd3.3v
> > + - reg-vbus-supply : regulator of vbus;
> 
> General trend is to use -supply.
> We already know it is a regulator so no need to add "reg-"
> 
> So those two can be
> 
> vusb33-supply:
> vbus-supply:
> 
I will adjust it later, thanks a lot
> 
> > + - usb-phy : the phy that xhci will bind
> > + - usb3-lpm-capable: supports USB3 LPM
> > + - clocks : must support all clocks that xhci needs
> > + - clock-names: should be "sys_mac" for sys and mac clocks
> > +
> > +Example:
> > +usb: usb30@1127 {
> > +   compatible = "mediatek,mt8173-xhci";
> > +   reg = <0 0x1127 0 0x1000>;
> > +   interrupts = ;
> > +   reg-vusb33-supply = <_vusb_reg>;
> > +   reg-vbus-supply = <_p1_vbus>;
> > +   usb-phy = <>;
> > +   usb3-lpm-capable;
> > +   clocks = < CLK_TOP_USB30_SEL>;
> > +   clock-names = "sys_mac";
> > +};
> > 
> 
> cheers,
> -roger


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[chunfeng yun]

hi Roger,

On Fri, 2015-07-10 at 11:31 +0300, Roger Quadros wrote:
> Hi,
> 
> On 08/07/15 12:41, Chunfeng Yun wrote:
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/usb/mt8173-xhci.txt| 27 
> > ++
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..94cec94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,27 @@
> > +MT65XX xhci
> > +
> > +The device node for Mediatek SOC usb3.0 host controller
> > +
> > +Required properties:
> > + - compatible : supports "mediatek,mt8173-xhci"
> > + - reg: Offset and length of registers
> > + - interrupts : Interrupt mode, number and trigger mode
> > + - reg-vusb33-supply:  regulator of usb avdd3.3v
> > + - reg-vbus-supply : regulator of vbus;
> 
> General trend is to use -supply.
> We already know it is a regulator so no need to add "reg-"
> 
> So those two can be
> 
> vusb33-supply:
> vbus-supply:
> 
I will adjust it later, thanks a lot

> 
> > + - usb-phy : the phy that xhci will bind
> > + - usb3-lpm-capable: supports USB3 LPM
> > + - clocks : must support all clocks that xhci needs
> > + - clock-names: should be "sys_mac" for sys and mac clocks
> > +
> > +Example:
> > +usb: usb30@1127 {
> > +   compatible = "mediatek,mt8173-xhci";
> > +   reg = <0 0x1127 0 0x1000>;
> > +   interrupts = ;
> > +   reg-vusb33-supply = <_vusb_reg>;
> > +   reg-vbus-supply = <_p1_vbus>;
> > +   usb-phy = <>;
> > +   usb3-lpm-capable;
> > +   clocks = < CLK_TOP_USB30_SEL>;
> > +   clock-names = "sys_mac";
> > +};
> > 
> 
> cheers,
> -roger


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: dts: ls1021a: add wakeup device ftm0 node for ls1021a

[Shawn Guo]

On Mon, Jul 06, 2015 at 10:38:39AM +0800, Alison Wang wrote:
> From: Wang Dongsheng 
> 
> Add ftm0 node, cause of ftm0 can be set as a alarm before system
> going to deep sleep.
> 
> Signed-off-by: Wang Dongsheng 

Since you're forwarding the patch, you should add your SoB.  Also, for
sake of consistency, please use "ARM: " as subject prefix for all
patches sent to me.

Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: lustre: fix whitespace coding style issues in libcfs/module.c

[Greg KH]

On Mon, Jul 13, 2015 at 10:10:46PM +0200, Lukasz Janyst wrote:
> This is a patch to the libcfs/module.c file fixing whitespace warnings
> found by checkpatch.pl.

This patch no longer applies to my tree due to other patches sent right
before yours.  Can you rebase it on the staging-testing branch of
staging.git and resend?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Oleg Drokin]

On Jul 13, 2015, at 10:49 PM, Greg Kroah-Hartman wrote:

> On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
>> From: Oleg Drokin 
>> 
>> It's just a fancy libcfs_debug_mb module parameter wrapper,
>> so just add debug buffer size check and resizing and the same
>> functionality now would be accessible via
>> /sys/module/libcfs/parameters/libcfs_debug_mb
>> 
>> Also add a symlink for backwards compatibility.
>> 
>> Signed-off-by: Oleg Drokin 
>> ---
>> drivers/staging/lustre/lustre/libcfs/debug.c | 37 
>> ++--
>> drivers/staging/lustre/lustre/libcfs/module.c| 32 ++--
>> drivers/staging/lustre/lustre/libcfs/tracefile.c | 12 
>> drivers/staging/lustre/lustre/libcfs/tracefile.h |  1 -
>> 4 files changed, 37 insertions(+), 45 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
>> b/drivers/staging/lustre/lustre/libcfs/debug.c
>> index 5ae7b65..e4c7129 100644
>> --- a/drivers/staging/lustre/lustre/libcfs/debug.c
>> +++ b/drivers/staging/lustre/lustre/libcfs/debug.c
>> @@ -57,8 +57,39 @@ module_param(libcfs_debug, int, 0644);
>> MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
>> EXPORT_SYMBOL(libcfs_debug);
>> 
>> +static int libcfs_param_debug_mb_set(const char *val,
>> + const struct kernel_param *kp)
>> +{
>> +int rc;
>> +unsigned num;
>> +
>> +rc = kstrtouint(val, 0, );
>> +if (rc == -EINVAL)
>> +return -EINVAL;
>> +
>> +if (!*((unsigned int *)kp->arg)) {
>> +*((unsigned int *)kp->arg) = num;
>> +return 0;
>> +}
>> +
>> +rc = cfs_trace_set_debug_mb(num);
>> +
>> +if (!rc)
>> +*((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
>> +
>> +return rc;
>> +}
>> +
>> +static struct kernel_param_ops param_ops_debugmb = {
>> +.set = libcfs_param_debug_mb_set,
>> +.get = param_get_uint,
>> +};
>> +
>> +#define param_check_debugmb(name, p) \
>> +__param_check(name, p, unsigned int)
>> +
>> static unsigned int libcfs_debug_mb;
>> -module_param(libcfs_debug_mb, uint, 0644);
>> +module_param(libcfs_debug_mb, debugmb, 0644);
> 
> I'll stop here in the patch series, please fix this up and resend the
> remaining 3.

I'll fix up the EINVAL comparison.
I am just trying to see wht is it you want me to fix with the debugmb type, you 
don't like the name? Abetter suggestion?

Bye,
Oleg--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 
'virtio_pci_kick_out_firmware_fb':
drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of 
function 'drm_fb_helper_remove_conflicting_framebuffers' 
[-Werror=implicit-function-declaration]
  drm_fb_helper_remove_conflicting_framebuffers(ap, "virtiodrmfb",
  ^

Caused by commit

  7bd870e7b1c8 ("drm/virtio: Use new drm_fb_helper functions")

I have used the drm-misc tree from next-20150713 for today.

(That commit said "COMPILE TESTED ONLY"  :-()
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpwe_gmd_lHu.pgp
Description: OpenPGP digital signature

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Oleg Drokin]

On Jul 13, 2015, at 10:46 PM, Greg Kroah-Hartman wrote:

> On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
>> From: Oleg Drokin 
>> 
>> It's just a fancy libcfs_debug_mb module parameter wrapper,
>> so just add debug buffer size check and resizing and the same
>> functionality now would be accessible via
>> /sys/module/libcfs/parameters/libcfs_debug_mb
>> 
>> Also add a symlink for backwards compatibility.
>> 
>> Signed-off-by: Oleg Drokin 
>> ---
>> drivers/staging/lustre/lustre/libcfs/debug.c | 37 
>> ++--
>> drivers/staging/lustre/lustre/libcfs/module.c| 32 ++--
>> drivers/staging/lustre/lustre/libcfs/tracefile.c | 12 
>> drivers/staging/lustre/lustre/libcfs/tracefile.h |  1 -
>> 4 files changed, 37 insertions(+), 45 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
>> b/drivers/staging/lustre/lustre/libcfs/debug.c
>> index 5ae7b65..e4c7129 100644
>> --- a/drivers/staging/lustre/lustre/libcfs/debug.c
>> +++ b/drivers/staging/lustre/lustre/libcfs/debug.c
>> @@ -57,8 +57,39 @@ module_param(libcfs_debug, int, 0644);
>> MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
>> EXPORT_SYMBOL(libcfs_debug);
>> 
>> +static int libcfs_param_debug_mb_set(const char *val,
>> + const struct kernel_param *kp)
>> +{
>> +int rc;
>> +unsigned num;
>> +
>> +rc = kstrtouint(val, 0, );
>> +if (rc == -EINVAL)
>> +return -EINVAL;
>> +
>> +if (!*((unsigned int *)kp->arg)) {
>> +*((unsigned int *)kp->arg) = num;
>> +return 0;
>> +}
>> +
>> +rc = cfs_trace_set_debug_mb(num);
>> +
>> +if (!rc)
>> +*((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
>> +
>> +return rc;
>> +}
>> +
>> +static struct kernel_param_ops param_ops_debugmb = {
>> +.set = libcfs_param_debug_mb_set,
>> +.get = param_get_uint,
>> +};
>> +
>> +#define param_check_debugmb(name, p) \
>> +__param_check(name, p, unsigned int)
>> +
>> static unsigned int libcfs_debug_mb;
>> -module_param(libcfs_debug_mb, uint, 0644);
>> +module_param(libcfs_debug_mb, debugmb, 0644);
> 
> module_param wants a variable type as the second option, not a variable
> name, how is this working?

debugmb IS the type, that I just declared above.
See all the param_ops_XXX and param_check_XXX thing?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Greg Kroah-Hartman]

On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> It's just a fancy libcfs_debug_mb module parameter wrapper,
> so just add debug buffer size check and resizing and the same
> functionality now would be accessible via
> /sys/module/libcfs/parameters/libcfs_debug_mb
> 
> Also add a symlink for backwards compatibility.
> 
> Signed-off-by: Oleg Drokin 
> ---
>  drivers/staging/lustre/lustre/libcfs/debug.c | 37 
> ++--
>  drivers/staging/lustre/lustre/libcfs/module.c| 32 ++--
>  drivers/staging/lustre/lustre/libcfs/tracefile.c | 12 
>  drivers/staging/lustre/lustre/libcfs/tracefile.h |  1 -
>  4 files changed, 37 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
> b/drivers/staging/lustre/lustre/libcfs/debug.c
> index 5ae7b65..e4c7129 100644
> --- a/drivers/staging/lustre/lustre/libcfs/debug.c
> +++ b/drivers/staging/lustre/lustre/libcfs/debug.c
> @@ -57,8 +57,39 @@ module_param(libcfs_debug, int, 0644);
>  MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
>  EXPORT_SYMBOL(libcfs_debug);
>  
> +static int libcfs_param_debug_mb_set(const char *val,
> +  const struct kernel_param *kp)
> +{
> + int rc;
> + unsigned num;
> +
> + rc = kstrtouint(val, 0, );
> + if (rc == -EINVAL)
> + return -EINVAL;
> +
> + if (!*((unsigned int *)kp->arg)) {
> + *((unsigned int *)kp->arg) = num;
> + return 0;
> + }
> +
> + rc = cfs_trace_set_debug_mb(num);
> +
> + if (!rc)
> + *((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
> +
> + return rc;
> +}
> +
> +static struct kernel_param_ops param_ops_debugmb = {
> + .set = libcfs_param_debug_mb_set,
> + .get = param_get_uint,
> +};
> +
> +#define param_check_debugmb(name, p) \
> + __param_check(name, p, unsigned int)
> +
>  static unsigned int libcfs_debug_mb;
> -module_param(libcfs_debug_mb, uint, 0644);
> +module_param(libcfs_debug_mb, debugmb, 0644);

I'll stop here in the patch series, please fix this up and resend the
remaining 3.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Greg Kroah-Hartman]

On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> It's just a fancy libcfs_debug_mb module parameter wrapper,
> so just add debug buffer size check and resizing and the same
> functionality now would be accessible via
> /sys/module/libcfs/parameters/libcfs_debug_mb
> 
> Also add a symlink for backwards compatibility.
> 
> Signed-off-by: Oleg Drokin 
> ---
>  drivers/staging/lustre/lustre/libcfs/debug.c | 37 
> ++--
>  drivers/staging/lustre/lustre/libcfs/module.c| 32 ++--
>  drivers/staging/lustre/lustre/libcfs/tracefile.c | 12 
>  drivers/staging/lustre/lustre/libcfs/tracefile.h |  1 -
>  4 files changed, 37 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
> b/drivers/staging/lustre/lustre/libcfs/debug.c
> index 5ae7b65..e4c7129 100644
> --- a/drivers/staging/lustre/lustre/libcfs/debug.c
> +++ b/drivers/staging/lustre/lustre/libcfs/debug.c
> @@ -57,8 +57,39 @@ module_param(libcfs_debug, int, 0644);
>  MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
>  EXPORT_SYMBOL(libcfs_debug);
>  
> +static int libcfs_param_debug_mb_set(const char *val,
> +  const struct kernel_param *kp)
> +{
> + int rc;
> + unsigned num;
> +
> + rc = kstrtouint(val, 0, );
> + if (rc == -EINVAL)
> + return -EINVAL;
> +
> + if (!*((unsigned int *)kp->arg)) {
> + *((unsigned int *)kp->arg) = num;
> + return 0;
> + }
> +
> + rc = cfs_trace_set_debug_mb(num);
> +
> + if (!rc)
> + *((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
> +
> + return rc;
> +}
> +
> +static struct kernel_param_ops param_ops_debugmb = {
> + .set = libcfs_param_debug_mb_set,
> + .get = param_get_uint,
> +};
> +
> +#define param_check_debugmb(name, p) \
> + __param_check(name, p, unsigned int)
> +
>  static unsigned int libcfs_debug_mb;
> -module_param(libcfs_debug_mb, uint, 0644);
> +module_param(libcfs_debug_mb, debugmb, 0644);

module_param wants a variable type as the second option, not a variable
name, how is this working?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/7] This series adds pinctrl drivers for UniPhier SoC family.

[Masahiro Yamada]

1/7: core support code commonly used for all the pinctrl drivers.
2/7-7/7: driver for each SoC



Masahiro Yamada (7):
  pinctrl: UniPhier: add UniPhier pinctrl core support
  pinctrl: UniPhier: add UniPhier PH1-LD4 pinctrl driver
  pinctrl: UniPhier: add UniPhier PH1-Pro4 pinctrl driver
  pinctrl: UniPhier: add UniPhier PH1-sLD8 pinctrl driver
  pinctrl: UniPhier: add UniPhier PH1-Pro5 pinctrl driver
  pinctrl: UniPhier: add UniPhier ProXstream2 pinctrl driver
  pinctrl: UniPhier: add UniPhier PH1-LD6b pinctrl driver

 drivers/pinctrl/Kconfig  |1 +
 drivers/pinctrl/Makefile |1 +
 drivers/pinctrl/uniphier/Kconfig |   32 +
 drivers/pinctrl/uniphier/Makefile|8 +
 drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c   |  886 
 drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c  | 1274 ++
 drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c  | 1554 ++
 drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c  | 1346 +++
 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c  |  794 +++
 drivers/pinctrl/uniphier/pinctrl-proxstream2.c   | 1269 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c |  684 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  |  217 +++
 12 files changed, 8066 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/Kconfig
 create mode 100644 drivers/pinctrl/uniphier/Makefile
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-proxstream2.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/5] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS

[James Liao]

Hi Daniel,

On Mon, 2015-07-13 at 22:46 +0800, Daniel Kurtz wrote:

> > +static const struct clk_ops mtk_ref2usb_tx_ops = {
> > +   .is_prepared= mtk_ref2usb_tx_is_prepared,
> > +   .prepare= mtk_ref2usb_tx_prepare,
> > +   .unprepare  = mtk_ref2usb_tx_unprepare,
> > +};
> 
> Burying the implementation of this special "mtk_ref2usb" clock in
> clk-mt8173,c seems a bit awkward.
> Can you please move it to its own file, like mediatek/clk-usb.c?

Do you mean clk/mediatek/clk-usb.c?

This clock is a MT8173 specific clock, which may not be reused by other
SoCs. So I think it's not necessary to move it to a separated file.

> > +
> > +static struct clk *mtk_clk_register_ref2usb_tx(const char *name,
> > +   const char *parent_name, void __iomem *reg)
> > +{
> > +   struct mtk_ref2usb_tx *tx;
> > +   struct clk_init_data init = {};
> > +   struct clk *clk;
> > +
> > +   tx = kzalloc(sizeof(*tx), GFP_KERNEL);
> > +   if (!tx)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   tx->base_addr = reg;
> > +   tx->hw.init = 
> > +
> > +   init.name = name;
> > +   init.ops = _ref2usb_tx_ops;
> > +   init.parent_names = _name;
> > +   init.num_parents = 1;
> > +
> > +   clk = clk_register(NULL, >hw);
> > +
> > +   if (IS_ERR(clk)) {
> > +   pr_err("Failed to register clk %s: %ld\n", name, 
> > PTR_ERR(clk));
> > +   kfree(tx);
> > +   }
> > +
> > +   return clk;
> > +}
> > +
> > +struct mtk_apmixed_ex {
> > +   int id;
> > +   const char *name;
> > +   const char *parent;
> > +   u32 reg_ofs;
> > +};
> > +
> > +#define APMIXED_EX(_id, _name, _parent, _reg_ofs) {\
> > +   .id = _id,  \
> > +   .name = _name,  \
> > +   .parent = _parent,  \
> > +   .reg_ofs = _reg_ofs,\
> > +   }
> > +
> > +static const struct mtk_apmixed_ex apmixed_ex[] = {
> 
> __initconst

OK. I'll fix it in next patch.

> > +   APMIXED_EX(CLK_APMIXED_REF2USB_TX, "ref2usb_tx", "clk26m", 0x8),
> > +};
> > +
> > +static void __init mtk_clk_register_apmixedsys_special(struct device_node 
> > *node,
> > +   struct clk_onecell_data *clk_data)
> > +{
> > +   void __iomem *base;
> > +   struct clk *clk;
> > +   int i;
> > +
> > +   base = of_iomap(node, 0);
> > +   if (!base) {
> > +   pr_err("%s(): ioremap failed\n", __func__);
> > +   return;
> > +   }
> > +
> > +   for (i = 0; i < ARRAY_SIZE(apmixed_ex); i++) {
> > +   const struct mtk_apmixed_ex *ape = _ex[i];
> > +
> > +   clk = mtk_clk_register_ref2usb_tx(ape->name, ape->parent,
> > +   base + 
> > ape->reg_ofs);
> > +
> > +   if (IS_ERR(clk)) {
> > +   pr_err("Failed to register clk %s: %ld\n", 
> > ape->name,
> > +   PTR_ERR(clk));
> > +   continue;
> > +   }
> > +
> > +   clk_data->clks[CLK_APMIXED_REF2USB_TX] = clk;
> 
> This works assuming ARRAY_SIZE(apmixed_ex) == 1.
> Either remove the loop since it is unnecessary, or do:
>   clk_data->clks[ape->id] = clk;

It should be "clk_data->clks[ape->id] = clk". I'll fix it in next patch.


Best regards,

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Oleg Drokin]

On Jul 13, 2015, at 10:43 PM, Greg Kroah-Hartman wrote:

> On Wed, Jul 08, 2015 at 11:45:59AM +0300, Dan Carpenter wrote:
>> On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
>>> +static int libcfs_param_debug_mb_set(const char *val,
>>> +const struct kernel_param *kp)
>>> +{
>>> +   int rc;
>>> +   unsigned num;
>>> +
>>> +   rc = kstrtouint(val, 0, );
>>> +   if (rc == -EINVAL)
>>> +   return -EINVAL;
>> 
>> Presumably, this is root only so using num uninitialized is not an
>> information leak.
> 
> But it's not good, this should be a check for rc < 0 to make sure.
> 
> Oleg, can you send a follow-on patch to fix this up?

Sure.
Do you want it now or should I wait till you merge my previous bunch?

Bye,
Oleg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] gpio: UniPhier: add driver for UniPhier GPIO controller

[Masahiro Yamada]

This GPIO controller device is used on UniPhier SoCs.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Use module_platform_driver()

Changes in v2:
  - Fix typos in the comment block

 drivers/gpio/Kconfig |   6 +
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-uniphier.c | 262 +++
 3 files changed, 269 insertions(+)
 create mode 100644 drivers/gpio/gpio-uniphier.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4c9fa58..37cb4f2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -462,6 +462,12 @@ config GPIO_TZ1090_PDC
help
  Say yes here to support Toumaz Xenif TZ1090 PDC GPIOs.
 
+config GPIO_UNIPHIER
+   tristate "UniPhier GPIO"
+   depends on ARCH_UNIPHIER && OF_GPIO
+   help
+ Say yes here to support UniPhier GPIOs.
+
 config GPIO_VF610
def_bool y
depends on ARCH_MXC && SOC_VF610
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f82cd67..3538b0c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_GPIO_TWL6040)  += gpio-twl6040.o
 obj-$(CONFIG_GPIO_TZ1090)  += gpio-tz1090.o
 obj-$(CONFIG_GPIO_TZ1090_PDC)  += gpio-tz1090-pdc.o
 obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
+obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o
 obj-$(CONFIG_GPIO_VF610)   += gpio-vf610.o
 obj-$(CONFIG_GPIO_VIPERBOARD)  += gpio-viperboard.o
 obj-$(CONFIG_GPIO_VR41XX)  += gpio-vr41xx.o
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
new file mode 100644
index 000..1afacaa
--- /dev/null
+++ b/drivers/gpio/gpio-uniphier.c
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Unfortunately, the hardware specification adopts weird GPIO pin labeling.
+ * The ports are named as
+ *   PORT00,  PORT01,  PORT02,  ..., PORT07,
+ *   PORT10,  PORT11,  PORT12,  ..., PORT17,
+ *   PORT20,  PORT21,  PORT22,  ..., PORT27,
+ *...
+ *   PORT90,  PORT91,  PORT92,  ..., PORT97,
+ *   PORT100, PORT101, PORT102, ..., PORT107,
+ *...
+ *
+ * The PORTs with 8 or 9 in the one's place are missing, i.e. the one's place
+ * is octal, while the other places are decimal.  If we handle the port numbers
+ * as seen in the hardware documents, the GPIO offsets must be non-contiguous.
+ * It is possible to have sparse GPIO pins, but not handy for GPIO range
+ * mappings, register accessing, etc.
+ *
+ * To make things simpler (for driver and device tree implementation), this
+ * driver takes contiguously-numbered GPIO offsets.  GPIO consumers should make
+ * sure to convert the PORT number into the one that fits in this driver.
+ * The conversion logic is very easy math, for example,
+ *   PORT15  -->  GPIO offset 13   (8 * 1 + 5)
+ *   PORT123 -->  GPIO offset 99   (8 * 12 + 3)
+ */
+#define UNIPHIER_GPIO_PORTS_PER_BANK   8
+#define UNIPHIER_GPIO_BANK_MASK\
+   ((1UL << (UNIPHIER_GPIO_PORTS_PER_BANK)) - 1)
+
+#define UNIPHIER_GPIO_REG_DATA 0   /* data */
+#define UNIPHIER_GPIO_REG_DIR  4   /* direction (1:in, 0:out) */
+
+struct uniphier_gpio_priv {
+   struct of_mm_gpio_chip mmchip;
+   spinlock_t lock;
+};
+
+static unsigned uniphier_gpio_bank_to_reg(unsigned bank, unsigned reg_type)
+{
+   unsigned reg;
+
+   reg = (bank + 1) * 8 + reg_type;
+
+   /*
+* Unfortunately, there is a register hole at offset 0x90-0x9f.
+* Add 0x10 when crossing the hole.
+*/
+   if (reg >= 0x90)
+   reg += 0x10;
+
+   return reg;
+}
+
+static void uniphier_gpio_bank_write(struct gpio_chip *chip,
+unsigned bank, unsigned reg_type,
+unsigned mask, unsigned value)
+{
+   struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
+   struct uniphier_gpio_priv *priv;
+   unsigned long flags;
+   unsigned reg;
+   u32 tmp;
+
+   if (!mask)
+   return;
+
+   priv = container_of(mmchip, struct uniphier_gpio_priv, mmchip);
+
+   reg = uniphier_gpio_bank_to_reg(bank, reg_type);
+
+   /*
+* Note
+* regmap_update_bits() should not be used here.
+*
+* The DATA registers return the current readback of pins, not the
+* previously written data when they are configured as "input".
+   

[PATCH v2 1/7] pinctrl: UniPhier: add UniPhier pinctrl core support

[Masahiro Yamada]

The core support for the pinctrl drivers for all the UniPhier SoCs.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - drop vogus THIS_MODULE because this file is always built-in
  - drop vogus "include  because this file is
always built-in

 drivers/pinctrl/Kconfig  |   1 +
 drivers/pinctrl/Makefile |   1 +
 drivers/pinctrl/uniphier/Kconfig |   8 +
 drivers/pinctrl/uniphier/Makefile|   1 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 684 +++
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  | 217 +++
 6 files changed, 912 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/Kconfig
 create mode 100644 drivers/pinctrl/uniphier/Makefile
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier.h

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 100d9ac..e6362c6 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -240,6 +240,7 @@ source "drivers/pinctrl/samsung/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
 source "drivers/pinctrl/sunxi/Kconfig"
+source "drivers/pinctrl/uniphier/Kconfig"
 source "drivers/pinctrl/vt8500/Kconfig"
 source "drivers/pinctrl/mediatek/Kconfig"
 
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f4216d9..f6710a8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -51,5 +51,6 @@ obj-$(CONFIG_PINCTRL_SAMSUNG) += samsung/
 obj-$(CONFIG_PINCTRL_SH_PFC)   += sh-pfc/
 obj-$(CONFIG_PLAT_SPEAR)   += spear/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
+obj-$(CONFIG_ARCH_UNIPHIER)+= uniphier/
 obj-$(CONFIG_ARCH_VT8500)  += vt8500/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
new file mode 100644
index 000..37e39c8
--- /dev/null
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -0,0 +1,8 @@
+if ARCH_UNIPHIER
+
+config PINCTRL_UNIPHIER_CORE
+   bool
+   select PINMUX
+   select GENERIC_PINCONF
+
+endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
new file mode 100644
index 000..748aa1b
--- /dev/null
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PINCTRL_UNIPHIER_CORE)+= pinctrl-uniphier-core.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
new file mode 100644
index 000..918f3b6
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
@@ -0,0 +1,684 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../core.h"
+#include "../pinctrl-utils.h"
+#include "pinctrl-uniphier.h"
+
+struct uniphier_pinctrl_priv {
+   struct pinctrl_dev *pctldev;
+   struct regmap *regmap;
+   struct uniphier_pinctrl_socdata *socdata;
+};
+
+static int uniphier_pctl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+   struct uniphier_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
+
+   return priv->socdata->groups_count;
+}
+
+static const char *uniphier_pctl_get_group_name(struct pinctrl_dev *pctldev,
+   unsigned selector)
+{
+   struct uniphier_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
+
+   return priv->socdata->groups[selector].name;
+}
+
+static int uniphier_pctl_get_group_pins(struct pinctrl_dev *pctldev,
+   unsigned selector,
+   const unsigned **pins,
+   unsigned *num_pins)
+{
+   struct uniphier_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
+
+   *pins = priv->socdata->groups[selector].pins;
+   *num_pins = priv->socdata->groups[selector].num_pins;
+
+   return 0;
+}
+
+#ifdef CONFIG_DEBUG_FS
+static void uniphier_pctl_pin_dbg_show(struct pinctrl_dev *pctldev,
+  struct seq_file *s, unsigned offset)
+{
+   const struct pinctrl_pin_desc *pin = >desc->pins[offset];
+   const char *pull_dir, *drv_str;
+
+   switch (uniphier_pin_get_pull_dir(pin->drv_data)) {
+   case UNIPHIER_PIN_PULL_UP:
+   pull_dir = "UP";
+   break;
+   case 

[PATCH v2 4/7] pinctrl: UniPhier: add UniPhier PH1-sLD8 pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier PH1-sLD8 SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - sort groups and funcs alphabetically
  - add i2c pin-mux settings
  - sort members of platform_driver
  - change to tristate
  - add THIS_MODULE to pinctrl_desc
  - use module_platform_driver

 drivers/pinctrl/uniphier/Kconfig|   4 +
 drivers/pinctrl/uniphier/Makefile   |   1 +
 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c | 794 
 3 files changed, 799 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index 944803f..f4a21fe 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -13,4 +13,8 @@ config PINCTRL_UNIPHIER_PH1_PRO4
tristate "UniPhier PH1-Pro4 SoC pinctrl driver"
select PINCTRL_UNIPHIER_CORE
 
+config PINCTRL_UNIPHIER_PH1_SLD8
+   tristate "UniPhier PH1-sLD8 SoC pinctrl driver"
+   select PINCTRL_UNIPHIER_CORE
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index b1b597e..3349fff 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PINCTRL_UNIPHIER_CORE) += 
pinctrl-uniphier-core.o
 
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD4) += pinctrl-ph1-ld4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO4)+= pinctrl-ph1-pro4.o
+obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_SLD8)+= pinctrl-ph1-sld8.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c 
b/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
new file mode 100644
index 000..7e9dae5
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
@@ -0,0 +1,794 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+#define DRIVER_NAME "ph1-sld8-pinctrl"
+
+static const struct pinctrl_pin_desc ph1_sld8_pins[] = {
+   UNIPHIER_PINCTRL_PIN(0, "PCA00", UNIPHIER_PIN_IECTRL_NONE,
+15, UNIPHIER_PIN_DRV_4_8,
+15, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(1, "PCA01", UNIPHIER_PIN_IECTRL_NONE,
+16, UNIPHIER_PIN_DRV_4_8,
+16, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(2, "PCA02", UNIPHIER_PIN_IECTRL_NONE,
+17, UNIPHIER_PIN_DRV_4_8,
+17, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(3, "PCA03", UNIPHIER_PIN_IECTRL_NONE,
+18, UNIPHIER_PIN_DRV_4_8,
+18, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(4, "PCA04", UNIPHIER_PIN_IECTRL_NONE,
+19, UNIPHIER_PIN_DRV_4_8,
+19, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(5, "PCA05", UNIPHIER_PIN_IECTRL_NONE,
+20, UNIPHIER_PIN_DRV_4_8,
+20, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(6, "PCA06", UNIPHIER_PIN_IECTRL_NONE,
+21, UNIPHIER_PIN_DRV_4_8,
+21, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(7, "PCA07", UNIPHIER_PIN_IECTRL_NONE,
+22, UNIPHIER_PIN_DRV_4_8,
+22, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(8, "PCA08", UNIPHIER_PIN_IECTRL_NONE,
+23, UNIPHIER_PIN_DRV_4_8,
+23, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(9, "PCA09", UNIPHIER_PIN_IECTRL_NONE,
+24, UNIPHIER_PIN_DRV_4_8,
+24, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(10, "PCA10", UNIPHIER_PIN_IECTRL_NONE,
+25, UNIPHIER_PIN_DRV_4_8,
+25, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(11, "PCA11", UNIPHIER_PIN_IECTRL_NONE,
+26, UNIPHIER_PIN_DRV_4_8,
+26, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(12, "PCA12", UNIPHIER_PIN_IECTRL_NONE,
+27, UNIPHIER_PIN_DRV_4_8,
+27, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(13, "PCA13", UNIPHIER_PIN_IECTRL_NONE,
+

[PATCH v2 2/7] pinctrl: UniPhier: add UniPhier PH1-LD4 pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier PH1-LD4 SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - sort groups and funcs alphabetically
  - add missing "emmc_dat8" group
  - add i2c pin-mux settings
  - sort members of platform_driver
  - change to tristate
  - add THIS_MODULE to pinctrl_desc
  - use module_platform_driver

 drivers/pinctrl/uniphier/Kconfig   |   4 +
 drivers/pinctrl/uniphier/Makefile  |   2 +
 drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c | 886 +
 3 files changed, 892 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index 37e39c8..78d25df 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -5,4 +5,8 @@ config PINCTRL_UNIPHIER_CORE
select PINMUX
select GENERIC_PINCONF
 
+config PINCTRL_UNIPHIER_PH1_LD4
+   tristate "UniPhier PH1-LD4 SoC pinctrl driver"
+   select PINCTRL_UNIPHIER_CORE
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index 748aa1b..b4bd042 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -1 +1,3 @@
 obj-$(CONFIG_PINCTRL_UNIPHIER_CORE)+= pinctrl-uniphier-core.o
+
+obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD4) += pinctrl-ph1-ld4.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c 
b/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
new file mode 100644
index 000..7beb87e
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
@@ -0,0 +1,886 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+#define DRIVER_NAME "ph1-ld4-pinctrl"
+
+static const struct pinctrl_pin_desc ph1_ld4_pins[] = {
+   UNIPHIER_PINCTRL_PIN(0, "EA1", UNIPHIER_PIN_IECTRL_NONE,
+8, UNIPHIER_PIN_DRV_4_8,
+8, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(1, "EA2", UNIPHIER_PIN_IECTRL_NONE,
+9, UNIPHIER_PIN_DRV_4_8,
+9, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(2, "EA3", UNIPHIER_PIN_IECTRL_NONE,
+10, UNIPHIER_PIN_DRV_4_8,
+10, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(3, "EA4", UNIPHIER_PIN_IECTRL_NONE,
+11, UNIPHIER_PIN_DRV_4_8,
+11, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(4, "EA5", UNIPHIER_PIN_IECTRL_NONE,
+12, UNIPHIER_PIN_DRV_4_8,
+12, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(5, "EA6", UNIPHIER_PIN_IECTRL_NONE,
+13, UNIPHIER_PIN_DRV_4_8,
+13, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(6, "EA7", UNIPHIER_PIN_IECTRL_NONE,
+14, UNIPHIER_PIN_DRV_4_8,
+14, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(7, "EA8", 0,
+15, UNIPHIER_PIN_DRV_4_8,
+15, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(8, "EA9", 0,
+16, UNIPHIER_PIN_DRV_4_8,
+16, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(9, "EA10", 0,
+17, UNIPHIER_PIN_DRV_4_8,
+17, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(10, "EA11", 0,
+18, UNIPHIER_PIN_DRV_4_8,
+18, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(11, "EA12", 0,
+19, UNIPHIER_PIN_DRV_4_8,
+19, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(12, "EA13", 0,
+20, UNIPHIER_PIN_DRV_4_8,
+20, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(13, "EA14", 0,
+21, UNIPHIER_PIN_DRV_4_8,
+21, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(14, "EA15", 0,
+22, UNIPHIER_PIN_DRV_4_8,
+22, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(15, "ECLK", UNIPHIER_PIN_IECTRL_NONE,
+23, UNIPHIER_PIN_DRV_4_8,
+  

[PATCH v2 7/7] pinctrl: UniPhier: add UniPhier PH1-LD6b pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier PH1-LD6b SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - sort groups and funcs alphabetically
  - add i2c pin-mux settings
  - sort members of platform_driver
  - change to tristate
  - add THIS_MODULE to pinctrl_desc
  - use module_platform_driver

 drivers/pinctrl/uniphier/Kconfig|4 +
 drivers/pinctrl/uniphier/Makefile   |1 +
 drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c | 1274 +++
 3 files changed, 1279 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index 69c5d5f..eab23ef 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -25,4 +25,8 @@ config PINCTRL_UNIPHIER_PROXSTREAM2
tristate "UniPhier ProXstream2 SoC pinctrl driver"
select PINCTRL_UNIPHIER_CORE
 
+config PINCTRL_UNIPHIER_PH1_LD6B
+   tristate "UniPhier PH1-LD6b SoC pinctrl driver"
+   select PINCTRL_UNIPHIER_CORE
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index aed038c..e215b10 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO4) += 
pinctrl-ph1-pro4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_SLD8)+= pinctrl-ph1-sld8.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO5)+= pinctrl-ph1-pro5.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PROXSTREAM2) += pinctrl-proxstream2.o
+obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD6B)+= pinctrl-ph1-ld6b.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c 
b/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
new file mode 100644
index 000..9720e697
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
@@ -0,0 +1,1274 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+#define DRIVER_NAME "ph1-ld6b-pinctrl"
+
+static const struct pinctrl_pin_desc ph1_ld6b_pins[] = {
+   UNIPHIER_PINCTRL_PIN(0, "ED0", UNIPHIER_PIN_IECTRL_NONE,
+0, UNIPHIER_PIN_DRV_4_8,
+0, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(1, "ED1", UNIPHIER_PIN_IECTRL_NONE,
+1, UNIPHIER_PIN_DRV_4_8,
+1, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(2, "ED2", UNIPHIER_PIN_IECTRL_NONE,
+2, UNIPHIER_PIN_DRV_4_8,
+2, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(3, "ED3", UNIPHIER_PIN_IECTRL_NONE,
+3, UNIPHIER_PIN_DRV_4_8,
+3, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(4, "ED4", UNIPHIER_PIN_IECTRL_NONE,
+4, UNIPHIER_PIN_DRV_4_8,
+4, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(5, "ED5", UNIPHIER_PIN_IECTRL_NONE,
+5, UNIPHIER_PIN_DRV_4_8,
+5, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(6, "ED6", UNIPHIER_PIN_IECTRL_NONE,
+6, UNIPHIER_PIN_DRV_4_8,
+6, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(7, "ED7", UNIPHIER_PIN_IECTRL_NONE,
+7, UNIPHIER_PIN_DRV_4_8,
+7, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(8, "XERWE0", UNIPHIER_PIN_IECTRL_NONE,
+8, UNIPHIER_PIN_DRV_4_8,
+8, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(9, "XERWE1", UNIPHIER_PIN_IECTRL_NONE,
+9, UNIPHIER_PIN_DRV_4_8,
+9, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(10, "ERXW", UNIPHIER_PIN_IECTRL_NONE,
+10, UNIPHIER_PIN_DRV_4_8,
+10, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(11, "ES0", UNIPHIER_PIN_IECTRL_NONE,
+11, UNIPHIER_PIN_DRV_4_8,
+11, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(12, "ES1", UNIPHIER_PIN_IECTRL_NONE,
+12, UNIPHIER_PIN_DRV_4_8,
+12, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(13, "ES2", 

[PATCH v2 6/7] pinctrl: UniPhier: add UniPhier ProXstream2 pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier ProXstream2
SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - sort groups and funcs alphabetically
  - add i2c pin-mux settings
  - sort members of platform_driver
  - change to tristate
  - add THIS_MODULE to pinctrl_desc
  - use module_platform_driver

 drivers/pinctrl/uniphier/Kconfig   |4 +
 drivers/pinctrl/uniphier/Makefile  |1 +
 drivers/pinctrl/uniphier/pinctrl-proxstream2.c | 1269 
 3 files changed, 1274 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-proxstream2.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index 89bda60..69c5d5f 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -21,4 +21,8 @@ config PINCTRL_UNIPHIER_PH1_PRO5
tristate "UniPhier PH1-Pro5 SoC pinctrl driver"
select PINCTRL_UNIPHIER_CORE
 
+config PINCTRL_UNIPHIER_PROXSTREAM2
+   tristate "UniPhier ProXstream2 SoC pinctrl driver"
+   select PINCTRL_UNIPHIER_CORE
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index b0cd3e8..aed038c 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD4)  += 
pinctrl-ph1-ld4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO4)+= pinctrl-ph1-pro4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_SLD8)+= pinctrl-ph1-sld8.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO5)+= pinctrl-ph1-pro5.o
+obj-$(CONFIG_PINCTRL_UNIPHIER_PROXSTREAM2) += pinctrl-proxstream2.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-proxstream2.c 
b/drivers/pinctrl/uniphier/pinctrl-proxstream2.c
new file mode 100644
index 000..3f036e2
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-proxstream2.c
@@ -0,0 +1,1269 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+#define DRIVER_NAME "proxstream2-pinctrl"
+
+static const struct pinctrl_pin_desc proxstream2_pins[] = {
+   UNIPHIER_PINCTRL_PIN(0, "ED0", UNIPHIER_PIN_IECTRL_NONE,
+0, UNIPHIER_PIN_DRV_4_8,
+0, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(1, "ED1", UNIPHIER_PIN_IECTRL_NONE,
+1, UNIPHIER_PIN_DRV_4_8,
+1, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(2, "ED2", UNIPHIER_PIN_IECTRL_NONE,
+2, UNIPHIER_PIN_DRV_4_8,
+2, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(3, "ED3", UNIPHIER_PIN_IECTRL_NONE,
+3, UNIPHIER_PIN_DRV_4_8,
+3, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(4, "ED4", UNIPHIER_PIN_IECTRL_NONE,
+4, UNIPHIER_PIN_DRV_4_8,
+4, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(5, "ED5", UNIPHIER_PIN_IECTRL_NONE,
+5, UNIPHIER_PIN_DRV_4_8,
+5, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(6, "ED6", UNIPHIER_PIN_IECTRL_NONE,
+6, UNIPHIER_PIN_DRV_4_8,
+6, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(7, "ED7", UNIPHIER_PIN_IECTRL_NONE,
+7, UNIPHIER_PIN_DRV_4_8,
+7, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(8, "XERWE0", UNIPHIER_PIN_IECTRL_NONE,
+8, UNIPHIER_PIN_DRV_4_8,
+8, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(9, "XERWE1", UNIPHIER_PIN_IECTRL_NONE,
+9, UNIPHIER_PIN_DRV_4_8,
+9, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(10, "ERXW", UNIPHIER_PIN_IECTRL_NONE,
+10, UNIPHIER_PIN_DRV_4_8,
+10, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(11, "ES0", UNIPHIER_PIN_IECTRL_NONE,
+11, UNIPHIER_PIN_DRV_4_8,
+11, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(12, "ES1", UNIPHIER_PIN_IECTRL_NONE,
+12, UNIPHIER_PIN_DRV_4_8,
+12, UNIPHIER_PIN_PULL_DOWN),
+   

[PATCH v2 5/7] pinctrl: UniPhier: add UniPhier PH1-Pro5 pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier PH1-Pro5 SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - sort groups and funcs alphabetically
  - add i2c pin-mux settings
  - sort members of platform_driver
  - change to tristate
  - add THIS_MODULE to pinctrl_desc
  - use module_platform_driver

 drivers/pinctrl/uniphier/Kconfig|4 +
 drivers/pinctrl/uniphier/Makefile   |1 +
 drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c | 1346 +++
 3 files changed, 1351 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index f4a21fe..89bda60 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -17,4 +17,8 @@ config PINCTRL_UNIPHIER_PH1_SLD8
tristate "UniPhier PH1-sLD8 SoC pinctrl driver"
select PINCTRL_UNIPHIER_CORE
 
+config PINCTRL_UNIPHIER_PH1_PRO5
+   tristate "UniPhier PH1-Pro5 SoC pinctrl driver"
+   select PINCTRL_UNIPHIER_CORE
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index 3349fff..b0cd3e8 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PINCTRL_UNIPHIER_CORE) += 
pinctrl-uniphier-core.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD4) += pinctrl-ph1-ld4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO4)+= pinctrl-ph1-pro4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_SLD8)+= pinctrl-ph1-sld8.o
+obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO5)+= pinctrl-ph1-pro5.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c 
b/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c
new file mode 100644
index 000..b35cf4a
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c
@@ -0,0 +1,1346 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program5 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+#define DRIVER_NAME "ph1-pro5-pinctrl"
+
+static const struct pinctrl_pin_desc ph1_pro5_pins[] = {
+   UNIPHIER_PINCTRL_PIN(0, "AEXCKA1", 0,
+0, UNIPHIER_PIN_DRV_4_8,
+0, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(1, "AEXCKA2", 0,
+1, UNIPHIER_PIN_DRV_4_8,
+1, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(2, "CK27EXI", 0,
+2, UNIPHIER_PIN_DRV_4_8,
+2, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(3, "CK54EXI", 0,
+3, UNIPHIER_PIN_DRV_4_8,
+3, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(4, "ED0", UNIPHIER_PIN_IECTRL_NONE,
+4, UNIPHIER_PIN_DRV_4_8,
+4, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(5, "ED1", UNIPHIER_PIN_IECTRL_NONE,
+5, UNIPHIER_PIN_DRV_4_8,
+5, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(6, "ED2", UNIPHIER_PIN_IECTRL_NONE,
+6, UNIPHIER_PIN_DRV_4_8,
+6, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(7, "ED3", UNIPHIER_PIN_IECTRL_NONE,
+7, UNIPHIER_PIN_DRV_4_8,
+7, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(8, "ED4", UNIPHIER_PIN_IECTRL_NONE,
+8, UNIPHIER_PIN_DRV_4_8,
+8, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(9, "ED5", UNIPHIER_PIN_IECTRL_NONE,
+9, UNIPHIER_PIN_DRV_4_8,
+9, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(10, "ED6", UNIPHIER_PIN_IECTRL_NONE,
+10, UNIPHIER_PIN_DRV_4_8,
+10, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(11, "ED7", UNIPHIER_PIN_IECTRL_NONE,
+11, UNIPHIER_PIN_DRV_4_8,
+11, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(12, "XERWE0", UNIPHIER_PIN_IECTRL_NONE,
+12, UNIPHIER_PIN_DRV_4_8,
+12, UNIPHIER_PIN_PULL_UP),
+   UNIPHIER_PINCTRL_PIN(13, "XERWE1", UNIPHIER_PIN_IECTRL_NONE,
+13, UNIPHIER_PIN_DRV_4_8,
+

Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb

[Greg Kroah-Hartman]

On Wed, Jul 08, 2015 at 11:45:59AM +0300, Dan Carpenter wrote:
> On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
> > +static int libcfs_param_debug_mb_set(const char *val,
> > +const struct kernel_param *kp)
> > +{
> > +   int rc;
> > +   unsigned num;
> > +
> > +   rc = kstrtouint(val, 0, );
> > +   if (rc == -EINVAL)
> > +   return -EINVAL;
> 
> Presumably, this is root only so using num uninitialized is not an
> information leak.

But it's not good, this should be a check for rc < 0 to make sure.

Oleg, can you send a follow-on patch to fix this up?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Subject: [v3.19 Regression] x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI

[Jiang Liu]

On 2015/7/14 3:36, Joseph Salisbury wrote:
> Hello Jiang,
> 
> A kernel bug report was opened against Ubuntu [0]. It was found that
> reverting the following commit resolves this bug:
> 
> commit cd68f6bd53cf89d1d5ed889b8af65e9c3574a079
> Author: Jiang Liu 
> Date:   Mon Oct 27 16:11:52 2014 +0800
> 
> x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI
> 
> The regression was introduced as of v3.19-rc1.
> 
> I was hoping to get your feedback, since you are the patch author.  Do
> you think gathering any additional data will help diagnose this issue,
> or would it be best to submit a revert request?
Hi Joseph,
Sorry for the trouble. It would be great if we could get
more information about the bug, such as bug report info, dmesg and
acpidump from the reporting system.
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/7] pinctrl: UniPhier: add UniPhier PH1-Pro4 pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier PH1-Pro4 SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - sort groups and funcs alphabetically
  - add i2c pin-mux settings
  - sort members of platform_driver
  - change to tristate
  - add THIS_MODULE to pinctrl_desc
  - use module_platform_driver

 drivers/pinctrl/uniphier/Kconfig|4 +
 drivers/pinctrl/uniphier/Makefile   |1 +
 drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c | 1554 +++
 3 files changed, 1559 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index 78d25df..944803f 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -9,4 +9,8 @@ config PINCTRL_UNIPHIER_PH1_LD4
tristate "UniPhier PH1-LD4 SoC pinctrl driver"
select PINCTRL_UNIPHIER_CORE
 
+config PINCTRL_UNIPHIER_PH1_PRO4
+   tristate "UniPhier PH1-Pro4 SoC pinctrl driver"
+   select PINCTRL_UNIPHIER_CORE
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index b4bd042..b1b597e 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_PINCTRL_UNIPHIER_CORE)+= pinctrl-uniphier-core.o
 
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD4) += pinctrl-ph1-ld4.o
+obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO4)+= pinctrl-ph1-pro4.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c 
b/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
new file mode 100644
index 000..96921e4
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
@@ -0,0 +1,1554 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This program 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 program5 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+#define DRIVER_NAME "ph1-pro4-pinctrl"
+
+static const struct pinctrl_pin_desc ph1_pro4_pins[] = {
+   UNIPHIER_PINCTRL_PIN(0, "CK24O", UNIPHIER_PIN_IECTRL_NONE,
+0, UNIPHIER_PIN_DRV_4_8,
+0, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(1, "VC27A", UNIPHIER_PIN_IECTRL_NONE,
+1, UNIPHIER_PIN_DRV_4_8,
+1, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(2, "CK27AI", UNIPHIER_PIN_IECTRL_NONE,
+2, UNIPHIER_PIN_DRV_4_8,
+2, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(3, "CK27AO", UNIPHIER_PIN_IECTRL_NONE,
+3, UNIPHIER_PIN_DRV_4_8,
+3, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(4, "CKSEL", UNIPHIER_PIN_IECTRL_NONE,
+4, UNIPHIER_PIN_DRV_4_8,
+4, UNIPHIER_PIN_PULL_UP),
+   UNIPHIER_PINCTRL_PIN(5, "CK27AV", UNIPHIER_PIN_IECTRL_NONE,
+5, UNIPHIER_PIN_DRV_4_8,
+5, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(6, "AEXCKA", UNIPHIER_PIN_IECTRL_NONE,
+6, UNIPHIER_PIN_DRV_4_8,
+6, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(7, "ASEL", UNIPHIER_PIN_IECTRL_NONE,
+7, UNIPHIER_PIN_DRV_4_8,
+7, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(8, "ARCRESET", UNIPHIER_PIN_IECTRL_NONE,
+8, UNIPHIER_PIN_DRV_4_8,
+8, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(9, "ARCUNLOCK", UNIPHIER_PIN_IECTRL_NONE,
+9, UNIPHIER_PIN_DRV_4_8,
+9, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(10, "XSRST", UNIPHIER_PIN_IECTRL_NONE,
+10, UNIPHIER_PIN_DRV_4_8,
+10, UNIPHIER_PIN_PULL_DOWN),
+   UNIPHIER_PINCTRL_PIN(11, "XNMIRQ", UNIPHIER_PIN_IECTRL_NONE,
+11, UNIPHIER_PIN_DRV_4_8,
+11, UNIPHIER_PIN_PULL_UP),
+   UNIPHIER_PINCTRL_PIN(12, "XSCIRQ", UNIPHIER_PIN_IECTRL_NONE,
+12, UNIPHIER_PIN_DRV_4_8,
+12, UNIPHIER_PIN_PULL_UP),
+   UNIPHIER_PINCTRL_PIN(13, "EXTRG", UNIPHIER_PIN_IECTRL_NONE,
+13, UNIPHIER_PIN_DRV_4_8,
+13, UNIPHIER_PIN_PULL_DOWN),
+   

Re: [PATCH] staging: lustre: Deletion of unnecessary checks before three function calls

[Greg Kroah-Hartman]

On Fri, Jun 26, 2015 at 11:23:29PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 26 Jun 2015 23:10:42 +0200

Sorry, I'm not taking any of your patches until you fix this all up.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [of] 649e0a77e28:

[Huang Ying]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 649e0a77e28a7796bf62bfda0fe3f2aee094bd58 ("of: make unittest select 
OF_EARLY_FLATTREE instead of depend on it")

The following new message in kernel log may make end user confuse.

[2.775617] device-tree: Duplicate name in testcase-data, renamed to 
"duplicate-name#1"
[2.779463] ### dt-test ### start of unittest - you will see error messages
[2.780294] /testcase-data/phandle-tests/consumer-a: could not get 
#phandle-cells-missing for /testcase-data/phandle-tests/provider1
[2.781341] /testcase-data/phandle-tests/consumer-a: could not get 
#phandle-cells-missing for /testcase-data/phandle-tests/provider1
[2.782394] /testcase-data/phandle-tests/consumer-a: could not find phandle
[2.783001] /testcase-data/phandle-tests/consumer-a: could not find phandle
[2.783622] /testcase-data/phandle-tests/consumer-a: arguments longer than 
property
[2.784333] /testcase-data/phandle-tests/consumer-a: arguments longer than 
property


Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.1.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y

Re: [PATCH] staging: lustre: mgc: no need to compare bool value

[Greg Kroah-Hartman]

On Tue, Jun 23, 2015 at 04:26:11PM +0200, Luis de Bethencourt wrote:
> Inverting the value of eof is a more direct way of passing to the debugging
> function if eof is false or not.

Really?  I like the explicit-ness of the code as it is today, it's more
obvious what is going on, which is the most important thing.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [x86/entry/64] 62c79204783: 5.9% aim7.jobs-per-min

[Huang Ying]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/entry
commit 62c79204783e188291d880f23d49c02d8c8f498b ("x86/entry/64: When returning 
via SYSRET, POP regs instead of using MOV")


=
tbox_group/testcase/rootfs/kconfig/compiler/load/test:
  lkp-a06/aim7/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/4000/misc_rtns_1

commit: 
  cad8c9e5d6a97898d37b1a8e5cdf838d79ba6e50
  62c79204783e188291d880f23d49c02d8c8f498b

cad8c9e5d6a97898 62c79204783e188291d880f23d 
 -- 
 %stddev %change %stddev
 \  |\  
108044 ±  0%  +5.9% 114416 ±  0%  aim7.jobs-per-min
223.70 ±  0%  -5.6% 211.11 ±  0%  aim7.time.elapsed_time
223.70 ±  0%  -5.6% 211.11 ±  0%  aim7.time.elapsed_time.max
   2113772 ±  0% -83.5% 349283 ±  2%  
aim7.time.involuntary_context_switches
599.10 ±  0%  -2.2% 585.90 ±  0%  aim7.time.system_time
203.87 ±  1%  -4.7% 194.25 ±  0%  aim7.time.user_time
   2113772 ±  0% -83.5% 349283 ±  2%  time.involuntary_context_switches

=
tbox_group/testcase/rootfs/kconfig/compiler/load/test:
  lkp-a06/aim7/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/4000/new_raph

commit: 
  cad8c9e5d6a97898d37b1a8e5cdf838d79ba6e50
  62c79204783e188291d880f23d49c02d8c8f498b

cad8c9e5d6a97898 62c79204783e188291d880f23d 
 -- 
 %stddev %change %stddev
 \  |\  
184357 ±  0% +10.8% 204299 ±  0%  aim7.jobs-per-min
131.71 ±  0%  -9.8% 118.82 ±  0%  aim7.time.elapsed_time
131.71 ±  0%  -9.8% 118.82 ±  0%  aim7.time.elapsed_time.max
   2193692 ±  0% -92.5% 164787 ±  0%  
aim7.time.involuntary_context_switches
 18.86 ±  2% -68.5%   5.94 ±  4%  aim7.time.system_time
435.63 ±  0%  -2.7% 424.04 ±  0%  aim7.time.user_time
 58879 ±  2% -19.5%  47402 ±  2%  
aim7.time.voluntary_context_switches
131.71 ±  0%  -9.8% 118.82 ±  0%  time.elapsed_time
131.71 ±  0%  -9.8% 118.82 ±  0%  time.elapsed_time.max
   2193692 ±  0% -92.5% 164787 ±  0%  time.involuntary_context_switches
 18.86 ±  2% -68.5%   5.94 ±  4%  time.system_time
 58879 ±  2% -19.5%  47402 ±  2%  time.voluntary_context_switches

=
tbox_group/testcase/rootfs/kconfig/compiler/load/test:
  lkp-a06/aim7/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/4000/pipe_cpy

commit: 
  cad8c9e5d6a97898d37b1a8e5cdf838d79ba6e50
  62c79204783e188291d880f23d49c02d8c8f498b

cad8c9e5d6a97898 62c79204783e188291d880f23d 
 -- 
 %stddev %change %stddev
 \  |\  
240551 ±  0% +13.9% 273904 ±  2%  aim7.jobs-per-min
101.42 ±  0% -12.2%  89.04 ±  2%  aim7.time.elapsed_time
101.42 ±  0% -12.2%  89.04 ±  2%  aim7.time.elapsed_time.max
   1981819 ±  0% -93.0% 138430 ±  3%  
aim7.time.involuntary_context_switches
278.03 ±  0%  -6.5% 259.97 ±  2%  aim7.time.system_time
 54936 ±  1% -19.6%  44147 ±  2%  
aim7.time.voluntary_context_switches
101.42 ±  0% -12.2%  89.04 ±  2%  time.elapsed_time
101.42 ±  0% -12.2%  89.04 ±  2%  time.elapsed_time.max
   1981819 ±  0% -93.0% 138430 ±  3%  time.involuntary_context_switches
 54936 ±  1% -19.6%  44147 ±  2%  time.voluntary_context_switches

=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/iterations/nr_threads/disk/fs/filesize/test_size/sync_method/nr_directories/nr_files_per_directory:
  
lkp-sb02/fsmark/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/1x/32t/1HDD/btrfs/9B/400M/fsyncBeforeClose/16d/256fpd

commit: 
  cad8c9e5d6a97898d37b1a8e5cdf838d79ba6e50
  62c79204783e188291d880f23d49c02d8c8f498b

cad8c9e5d6a97898 62c79204783e188291d880f23d 
 -- 
 %stddev %change %stddev
 \  |\  
   2554844 ±  1% -13.1%2221395 ±  1%  fsmark.app_overhead
223789 ±  0% -57.2%  95777 ±  6%  
fsmark.time.involuntary_context_switches
 32.50 ±  1%  +5.4%  34.25 ±  1%  
fsmark.time.percent_of_cpu_this_job_got
   2118350 ±  0%  +5.2%2229178 ±  0%  
fsmark.time.voluntary_context_switches
223789 ±  0% -57.2%  95777 ±  6%  time.involuntary_context_switches
 39831 ±  0%  -9.9%  35903 ±  1%  softirqs.SCHED
 59651 ±  1%  

Re: [PATCH v3 4/4] gpio: brcmstb: support wakeup from S5 cold boot

[Gregory Fong]

On Mon, Jul 13, 2015 at 6:03 AM, Linus Walleij  wrote:
> On Thu, Jun 18, 2015 at 3:00 AM, Gregory Fong  wrote:
>
>> For wake from S5, we need to:
>> - register a reboot handler
>> - set wakeup capability before requesting IRQ so wakeup count is
>>   incremented
>> - mask all GPIO IRQs and clear any pending interrupts during driver
>>   probe to since no driver will yet be registered to handle any IRQs
>>   carried over from boot at that time, and it's possible that the
>>   booted kernel does not request the same IRQ anyway.
>>
>> This means that /sys/.../power/wakeup_count is valid at boot time, and
>> we can properly account for S5 wakeup stats. e.g.:
>>
>>   ### After waking from S5 from a GPIO key
>>   # cat /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup
>>   enabled
>>   # cat 
>> /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup_count
>>   1
>>
>> Signed-off-by: Gregory Fong 
>
> (...)
>> -static int brcmstb_gpio_irq_set_wake(struct irq_data *d, unsigned int 
>> enable)
>> +static int __brcmstb_gpio_irq_set_wake(struct brcmstb_gpio_priv *priv,
>> +   unsigned int enable)
>>  {
>> -   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
>> -   struct brcmstb_gpio_priv *priv = brcmstb_gpio_gc_to_priv(gc);
>> int ret = 0;
>
> I don't usually like to refactor code with __foo wrapper functions with
> underscores or double underscores in front of them.
>
> Is it possible to give this a more unique name?

Sure, just have to come up with a good one :-).

>
>> +   /*
>> +* Mask all interrupts by default, since wakeup interrupts 
>> may
>> +* be retained from S5 cold boot
>> +*/
>> +   bank->bgc.write_reg(reg_base + GIO_MASK(bank->id), 0);
>
> Aha I see, that's some clever code, nice.
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] sched: let __sched_period() use rq's nr_running

[Mike Galbraith]

On Tue, 2015-07-14 at 11:07 +0900, Byungchul Park wrote:

> but.. is there any reason meaningless code should be kept in source? :(
> it also harms readability. of cource, i need to modify my patch a little 
> bit to prevent non-group sched entities from getting large slice.

By all means proceed, I'm not trying to discourage you.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/4] gpio: brcmstb: Add interrupt and wakeup source support

[Gregory Fong]

On Mon, Jul 13, 2015 at 5:58 AM, Linus Walleij  wrote:
> On Thu, Jun 18, 2015 at 3:00 AM, Gregory Fong  wrote:
>
>> Uses the gpiolib irqchip helpers.  For this to work, the irq setup
>> function is called once per bank instead of once per device.  Note
>> that all known uses of this block have a BCM7120 L2 interrupt
>> controller as a parent.  Supports interrupts for all GPIOs.
>>
>> In the IRQ handler, we check for raised IRQs for invalid GPIOs and
>> warn (ratelimited) if they're encountered.
>>
>> Also, several drivers (e.g. gpio-keys) allow for GPIOs to be
>> configured as wakeup sources, and this GPIO controller supports that
>> through a separate interrupt path.
>>
>> The de-facto standard DT property "wakeup-source" is checked, since
>> that indicates whether the GPIO controller hardware can wake.  Uses
>> the IRQCHIP_MASK_ON_SUSPEND irq_chip flag because UPG GIO doesn't have
>> any of its own wakeup source configuration.
>>
>> Aside regarding gpiolib irqchip helpers: It wasn't obvious (to me)
>> that you can have multiple chained irqchips and associated IRQ domains
>> for a single parent IRQ, and as long as the xlate function is written
>> correctly, a GPIO IRQ request end up checking the correct domain and
>> will get associated with the correct IRQ.  What helps make this clear
>> is to read
>>   drivers/gpio/gpiolib-of.c:
>>- of_gpiochip_find_and_xlate()
>>- of_get_named_gpiod_flags()
>>   drivers/gpio/gpiolib.c:
>>- gpiochip_find()
>
> Sorry for the unclarities, this is a bit hairy. Suggestions as to
> how we can make it easier and/or bring code for this into gpiolib
> are welcome. Right now I have a hard time seeing any way to
> make this more generic and helpful :/

I'll see about putting together an update to the documentation
discussing more about the case where you have one IRQ shared by
multiple GPIO banks.

>
> Overall this patch looks real nice. Some nitpicks below.
>
>> @@ -164,6 +398,16 @@ static int brcmstb_gpio_probe(struct platform_device 
>> *pdev)
>> priv->reg_base = reg_base;
>> priv->pdev = pdev;
>>
>> +   if (of_property_read_bool(np, "interrupt-controller")) {
>> +   priv->parent_irq = platform_get_irq(pdev, 0);
>> +   if (priv->parent_irq < 0) {
>
> This should be <= 0 since 0 is NO_IRQ

Will fix.

>
>> +   dev_err(dev, "Couldn't get IRQ");
>> +   return -ENOENT;
>> +   }
>> +   } else {
>> +   priv->parent_irq = -ENOENT;
>> +   }
>
> Why should this code only execute if the node is marked
> "interrupt-controller"? It makes it seem like IRQs cannot arrive
> to it unless it is intended to serve other consumers.
>
> Maybe in practice this is true, but...

If the node does not contain the "interrupt-controller" property, the
hardware does not support GPIO interrupts, and I designed the driver
specifically to allow that to work.
If the node does contain that property, then being unable to complete
IRQ setup is a fatal error, because something is badly misconfigured.

>
>> +   if (priv->parent_irq >= 0) {
>> +   err = brcmstb_gpio_irq_setup(pdev, bank);
>> +   if (err)
>> +   goto fail;
>> +   }
>
> Again 0 is NO_IRQ so this should be > 0 not >= 0.

OK, will change.

Thanks,
Gregory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] sched: let __sched_period() use rq's nr_running

[Byungchul Park]

On Mon, Jul 13, 2015 at 06:25:35PM +0900, Byungchul Park wrote:
> On Mon, Jul 13, 2015 at 10:26:09AM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 10, 2015 at 05:11:30PM +0900, byungchul.p...@lge.com wrote:
> > > From: Byungchul Park 
> > > 
> > > __sched_period() returns a period which a rq can have. the period has to 
> > > be
> > > stretched by the number of task *the rq has*, when nr_running > 
> > > nr_latency.
> > > otherwise, task slice can be very smaller than 
> > > sysctl_sched_min_granularity
> > > depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED.
> > > 
> > > Signed-off-by: Byungchul Park 
> > > ---
> > >  kernel/sched/fair.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 09456fc..8ae7aeb 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -635,7 +635,7 @@ static u64 __sched_period(unsigned long nr_running)
> > >   */
> > >  static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > >  {
> > > - u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq);
> > > + u64 slice = __sched_period(rq_of(cfs_rq)->nr_running + !se->on_rq);
> > >  
> > >   for_each_sched_entity(se) {
> > >   struct load_weight *load;
> > 
> > This really doesn't make sense; look at what that
> > for_each_sched_entity() loop does below this.
> 
> hello,
> 
> for_each_sched_entity() loop is distributing slice to se with consideration
> for both hierarchy and its weight, walking from the passed se to the top rq. 
> 
> i am just talking about how to get a whole period value. my question is 
> "why does it use local cfs's nr_running to get a whole period value?".

i need to modify my patch more, i admit.

but i have a question, do you think it is right to use local cfs's nr_running
to get a whole period value?

> 
> > 
> > I agree that sched_slice() is a difficult proposition in the face of
> > cgroup, but everything is, cgroups suck arse, they make everything hard.
> 
> i don't make an issue of the way for cgroups to work though it already have
> many problems as you said.
> 
> thank you for commenting,
> byungchul
> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Lovely

[Gavin]

My name is Gavin. I'm 45 years old, from the US. I'm in Syria right now 
fighting IS. I want to get to know you better, if I may be so bold. I 
consider myself an easy-going man, and I am currently looking for a 
relationship in which I feel loved. Please tell me more about yourself, 
if you don't mind.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB

[Pan Xinhui]

hi, Rafael,
thanks for you reply :)
On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
> On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
>> hi, Rafeal
>>  thanks for your reply. :)
>>
>> On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
>>> Hi,
>>>
>>> On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui  wrote:

 If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
 cpb is not needed. Add ifdef around it.

 Signed-off-by: Pan Xinhui 
 ---
  drivers/cpufreq/acpi-cpufreq.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/cpufreq/acpi-cpufreq.c 
 b/drivers/cpufreq/acpi-cpufreq.c
 index e7fcaa6..314a19e 100644
 --- a/drivers/cpufreq/acpi-cpufreq.c
 +++ b/drivers/cpufreq/acpi-cpufreq.c
 @@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct cpufreq_policy 
 *policy)
  static struct freq_attr *acpi_cpufreq_attr[] = {
 _freq_attr_scaling_available_freqs,
 _cpus,
 +#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
 NULL,   /* this is a placeholder for cpb, do not remove */
 +#endif
>>>
>>> Adding the ifdef here doesn't change anything, because the next NULL
>>> will play the role of the one you've just #ifdefed and the structure
>>> will be filled with zeros from that point on anyway.
>>>
>> Yes, adding ifdef here does not change any binary codes. But I want to make 
>> the codes more readable. :)
>> Patch author has noticed two *NULL* here would confuse people, especially 
>> who first read this acpi-cpufreq.c file
>> From code style point, it would be better to have #ifdef around it. 
> 
> Not really.
> 
> Why don't you simply drop *both* NULLs?
> 
Just like string end with *NULL* :)

1021 static int cpufreq_add_dev_interface(struct cpufreq_policy *policy,
1022  struct device *dev)
1023 {
1024 struct freq_attr **drv_attr;
1025 int ret = 0;
1026 
1027 /* set up files for this cpu device */
1028 drv_attr = cpufreq_driver->attr;
1029 while (drv_attr && *drv_attr) {
1030 ret = sysfs_create_file(>kobj, &((*drv_attr)->attr));
1031 if (ret)
1032 return ret;
1033 drv_attr++;
1034 }
If struct freq_attr *acpi_cpufreq_attr[] did not end with NULL, line 1033 will 
access invalid data area.
If *drv_attr(the data after struct freq_attr * array[]) happened to be not 
NULL. panic may hit in sysfs_create_file :(
So at least one *NULL* must be in the end of freq_attr *array[].

Actually in acpi-cpufreq.c, in acpi_cpufreq_init function.
 957 struct freq_attr **iter;
 958 
 959 pr_debug("adding sysfs entry for cpb\n");
 960 
 961 for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
 962 ;
 963 
 964 /* make sure there is a terminator behind it */
 965 if (iter[1] == NULL)
 966 *iter = 
 967 }
line965, check of iter[1] is not needed. Maybe the patch author was afraid of 
an unexpected remove of first *NULL*.
It might be a better solution to add ifdef CONFIG_X86_ACPI_CPUFREQ_CPB around 
that *NULL*, and remove this !iter[1] check.

thanks
xinhui

> 
>>
>>> You'd need to #ifdef it in the struct freq_attr definition, but I'm
>>> not sure it's worth the effort.
>>>
>>
>> struct freq_attr *cpb* is defined in #ifdef section. :)
> 
> Ah, OK.
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_display.c

between commit:

  8aa3053bf731 ("drm/i915: fix oops in primary_check_plane")

from the drm-intel-fixes tree and commit:

  da20eabd2c69 ("drm/i915: Split plane updates of crtc->atomic into a helper, 
v2.")

from the drm-intel tree.

I fixed it up (but it probably needs more - see below) and can carry
the fix as necessary.

Daniel, can you please merge your fixes branch into your main branch
(maybe after Linus has merged it) and fix these conflicts correctly as
these conflicts tend to go on and on as the files get changed.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_display.c
index 85ac6d85dc39,00c60c1c5162..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4851,25 -4802,13 +4802,16 @@@ static void intel_crtc_disable_planes(s
  {
struct drm_device *dev = crtc->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_plane *intel_plane;
+   struct drm_plane *p;
int pipe = intel_crtc->pipe;
  
 +  if (!intel_crtc->active)
 +  return;
 +
-   intel_crtc_wait_for_pending_flips(crtc);
- 
-   intel_pre_disable_primary(crtc);
- 
intel_crtc_dpms_overlay_disable(intel_crtc);
-   for_each_intel_plane(dev, intel_plane) {
-   if (intel_plane->pipe == pipe) {
-   struct drm_crtc *from = intel_plane->base.crtc;
  
-   intel_plane->disable_plane(_plane->base,
-  from ?: crtc, true);
-   }
-   }
+   drm_for_each_plane_mask(p, dev, plane_mask)
+   to_intel_plane(p)->disable_plane(p, crtc);
  
/*
 * FIXME: Once we grow proper nuclear flip support out of this we need
@@@ -13382,47 -13751,11 +13757,14 @@@ static void intel_begin_crtc_commit(str
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_plane *intel_plane;
-   struct drm_plane *p;
-   unsigned fb_bits = 0;
- 
-   /* Track fb's for any planes being disabled */
-   list_for_each_entry(p, >mode_config.plane_list, head) {
-   intel_plane = to_intel_plane(p);
- 
-   if (intel_crtc->atomic.disabled_planes &
-   (1 << drm_plane_index(p))) {
-   switch (p->type) {
-   case DRM_PLANE_TYPE_PRIMARY:
-   fb_bits = 
INTEL_FRONTBUFFER_PRIMARY(intel_plane->pipe);
-   break;
-   case DRM_PLANE_TYPE_CURSOR:
-   fb_bits = 
INTEL_FRONTBUFFER_CURSOR(intel_plane->pipe);
-   break;
-   case DRM_PLANE_TYPE_OVERLAY:
-   fb_bits = 
INTEL_FRONTBUFFER_SPRITE(intel_plane->pipe);
-   break;
-   }
  
-   mutex_lock(>struct_mutex);
-   i915_gem_track_fb(intel_fb_obj(p->fb), NULL, fb_bits);
-   mutex_unlock(>struct_mutex);
-   }
-   }
- 
-   if (intel_crtc->atomic.wait_for_flips)
-   intel_crtc_wait_for_pending_flips(crtc);
- 
-   if (intel_crtc->atomic.disable_fbc)
-   intel_fbc_disable(dev);
+   if (!needs_modeset(crtc->state))
+   intel_pre_plane_update(intel_crtc);
  
 +  if (intel_crtc->atomic.disable_ips)
 +  hsw_disable_ips(intel_crtc);
 +
-   if (intel_crtc->atomic.pre_disable_primary)
-   intel_pre_disable_primary(crtc);
- 
-   if (intel_crtc->atomic.update_wm)
+   if (intel_crtc->atomic.update_wm_pre)
intel_update_watermarks(crtc);
  
intel_runtime_pm_get(dev_priv);


pgp_sHi2TeO3k.pgp
Description: OpenPGP digital signature

Re: [PATCH] Staging: android: ion: Fix Style Issue

[Craig Inches]

On Mon, Jul 13, 2015 at 04:42:22AM -0700, Joe Perches wrote:
> On Mon, 2015-07-13 at 17:29 +, Craig wrote:
> > Modified style issue in ion.c. Missing empty line after a definition
> > 
> > Signed-off-by: Craig 
> > ---
> >  drivers/staging/android/ion/ion.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/staging/android/ion/ion.c 
> > b/drivers/staging/android/ion/ion.c
> > index 6f48112..e44f5e6 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
> > *client,
> > struct ion_buffer *buffer;
> > struct dma_buf *dmabuf;
> > bool valid_handle;
> > +
> > DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> >  
> > mutex_lock(>lock);
> 
> checkpatch false positive.
Thanks for the feed back.

> Fixed in checkpatch by
> https://lkml.org/lkml/2015/7/1/383
and the reference to the fix.

Cheers,
Craig 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Peter Chen]

On Mon, Jul 13, 2015 at 12:14:43PM -0700, Andrew Bresticker wrote:
> Hi Roger,
> 
> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros  wrote:
> > Usage model:
> > ---
> >
> > - The OTG controller device is assumed to be the parent of
> > the host and gadget controller. It must call usb_otg_register()
> > before populating the host and gadget devices so that the OTG
> > core is aware that it is an OTG device before the host & gadget
> > register. The OTG controller must provide struct otg_fsm_ops *
> > which will be called by the OTG core depending on OTG bus state.
> 
> I'm wondering if the requirement that the OTG controller be the parent
> of the USB host/device-controllers makes sense.  For some context, I'm
> working on adding dual-role support for Tegra210, specifically on a
> system with USB Type-C.  On Tegra, the USB host-controller and USB
> device-controller are two separate IP blocks (XUSB host and XUSB
> device) with another, separate, IP block (XUSB padctl) for the USB PHY
> and OTG support.  In the non-Type-C case, your OTG framework could
> work well, though it's debatable as to whether or not the XUSB padctl
> device should be a parent to the XUSB host/device-controller devices
> (currently it isn't - it's just a PHY provider).  But in the Type-C
> case, it's an off-chip embedded controller that determines the
> dual-role status of the Type-C port, so the above requirement doesn't
> make sense at all.

Hi Andrew,

I think your problem is how to add your core driver to manage device and
host functionality together, and once you find how (through padctl/type-c
controller) to do it based on current code, it will be clear how to use roger
proposal framework at that time.

Most of current core drivers, we use extcon driver (through gpio) or USB
vbus/id pin (through internal registers) to manager roles.

> 
> My idea was to have the OTG/DRD controller explicitly specify its host
> and device controllers, so in DT, something like:
> 
> otg-controller {
> ...
> device-controller = <_device>;
> host-controller = <_host>;
> ...
> };
> 
> usb_device: usb-device@ {
> ...
> };
> 
> usb_host: usb-host@... {
> ...
> };
> 
> What do you think?
> 
> Thanks,
> Andrew

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] sched: let __sched_period() use rq's nr_running

[Byungchul Park]

On Mon, Jul 13, 2015 at 02:30:38PM +0200, Mike Galbraith wrote:
> On Mon, 2015-07-13 at 20:07 +0900, Byungchul Park wrote:
> 
> > i still think stretching with local cfs's nr_running should be replaced with
> > stretching with a top(=root) level one.
> 
> I think we just can't take 'slice' _too_ seriously.  Not only is it

hello mike, :)

as you said, it is not too much important thing which has to be taken
too seriously, since it would be adjusted by vruntime in cfs.

but.. is there any reason meaningless code should be kept in source? :(
it also harms readability. of cource, i need to modify my patch a little 
bit to prevent non-group sched entities from getting large slice.

thank you,
byungchul

> annoying with cgroups, the scheduler simply doesn't deliver 'slices' in
> the traditional sense, it equalizes vruntimes, planning to do that at
> slice granularity.  FAIR_SLEEPERS doesn't make that planning any easier.
> With a pure compute load and no HR_TICK, what you get is tick
> granularity preemption checkpoints, but having just chewed up a 'slice'
> means nothing if you're still leftmost.  It's all about vruntime, so
> leftmost can have back to back 'slices'.  FAIR_SLEEPERS just increases
> the odds that leftmost WILL take more than one 'slice'.
> 
> (we could perhaps decay deficit after a full slice or such to decrease
> the spread growth that sleepers induce. annoying problem, especially so
> with a gaggle of identical sleepers, as sleep time becomes meaningless,
> there is no differential to equalize.. other than the ones we create..
> but I'm digressing, a lot, time to stop thinking/typing, go do work;)
> 
>   -Mike
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v5 2/3] tools lib traceevent: Add function to get dynamic arrays length

[He Kuang]

To print a trace event with a dynamic array, __print_array(array, len,
element_size) requires the number of items in the array, which can be
got by the helper function __get_dynamic_array_len(), currently it is
not an available function in the function list in process_function().

Add new arg type PRINT_DYNAMIC_ARRAY_LEN which returns the array
length embedded in the __data_loc_##item field to eval_num_arg().

Signed-off-by: He Kuang 
---
 tools/lib/traceevent/event-parse.c | 52 ++
 tools/lib/traceevent/event-parse.h |  1 +
 .../util/scripting-engines/trace-event-python.c|  1 +
 3 files changed, 54 insertions(+)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index cc25f05..55fc3b6c 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -783,6 +783,7 @@ static void free_arg(struct print_arg *arg)
free(arg->bitmask.bitmask);
break;
case PRINT_DYNAMIC_ARRAY:
+   case PRINT_DYNAMIC_ARRAY_LEN:
free(arg->dynarray.index);
break;
case PRINT_OP:
@@ -2655,6 +2656,42 @@ process_dynamic_array(struct event_format *event, struct 
print_arg *arg, char **
 }
 
 static enum event_type
+process_dynamic_array_len(struct event_format *event, struct print_arg *arg,
+ char **tok)
+{
+   struct format_field *field;
+   enum event_type type;
+   char *token;
+
+   if (read_expect_type(EVENT_ITEM, ) < 0)
+   goto out_free;
+
+   arg->type = PRINT_DYNAMIC_ARRAY_LEN;
+
+   /* Find the field */
+   field = pevent_find_field(event, token);
+   if (!field)
+   goto out_free;
+
+   arg->dynarray.field = field;
+   arg->dynarray.index = 0;
+
+   if (read_expected(EVENT_DELIM, ")") < 0)
+   goto out_err;
+
+   type = read_token();
+   *tok = token;
+
+   return type;
+
+ out_free:
+   free_token(token);
+ out_err:
+   *tok = NULL;
+   return EVENT_ERROR;
+}
+
+static enum event_type
 process_paren(struct event_format *event, struct print_arg *arg, char **tok)
 {
struct print_arg *item_arg;
@@ -2901,6 +2938,10 @@ process_function(struct event_format *event, struct 
print_arg *arg,
free_token(token);
return process_dynamic_array(event, arg, tok);
}
+   if (strcmp(token, "__get_dynamic_array_len") == 0) {
+   free_token(token);
+   return process_dynamic_array_len(event, arg, tok);
+   }
 
func = find_func_handler(event->pevent, token);
if (func) {
@@ -3581,6 +3622,17 @@ eval_num_arg(void *data, int size, struct event_format 
*event, struct print_arg
goto out_warning_op;
}
break;
+   case PRINT_DYNAMIC_ARRAY_LEN:
+   offset = pevent_read_number(pevent,
+   data + arg->dynarray.field->offset,
+   arg->dynarray.field->size);
+   /*
+* The actual length of the dynamic array is stored
+* in the top half of the field, and the offset
+* is in the bottom half of the 32 bit field.
+*/
+   val = (unsigned long long)(offset >> 16);
+   break;
case PRINT_DYNAMIC_ARRAY:
/* Without [], we pass the address to the dynamic data */
offset = pevent_read_number(pevent,
diff --git a/tools/lib/traceevent/event-parse.h 
b/tools/lib/traceevent/event-parse.h
index 063b197..94543aa 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -294,6 +294,7 @@ enum print_arg_type {
PRINT_OP,
PRINT_FUNC,
PRINT_BITMASK,
+   PRINT_DYNAMIC_ARRAY_LEN,
 };
 
 struct print_arg {
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index ace2484..d309341 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -253,6 +253,7 @@ static void define_event_symbols(struct event_format *event,
case PRINT_DYNAMIC_ARRAY:
case PRINT_FUNC:
case PRINT_BITMASK:
+   case PRINT_DYNAMIC_ARRAY_LEN:
/* we should warn... */
return;
}
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v5 3/3] bpf: Introduce function for outputing trace event data

[He Kuang]

There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.

This patch adds a new trace event to establish infrastruction for bpf to
output data to perf. Userspace perf tools can detect and use this event
as using the existing tracepoint events.

New bpf trace event entry in debugfs:

 /sys/kernel/debug/tracing/events/bpf/bpf_output_data

Userspace perf tools detect the new tracepoint event as:

 bpf:bpf_output_data  [Tracepoint event]

Data in ring-buffer of perf events added to this event will be polled
out, sample types and other attributes can be adjusted to those events
directly without touching the original kprobe events.

The bpf helper function gives eBPF program ability to output data as
perf sample event. This helper simple call the new trace event and
userspace perf tools can record the BPF ftrace event to collect those
records.

Signed-off-by: He Kuang 
---
 include/trace/events/bpf.h | 30 ++
 include/uapi/linux/bpf.h   |  7 +++
 kernel/trace/bpf_trace.c   | 23 +++
 samples/bpf/bpf_helpers.h  |  2 ++
 4 files changed, 62 insertions(+)
 create mode 100644 include/trace/events/bpf.h

diff --git a/include/trace/events/bpf.h b/include/trace/events/bpf.h
new file mode 100644
index 000..82ace8a
--- /dev/null
+++ b/include/trace/events/bpf.h
@@ -0,0 +1,30 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM bpf
+
+#if !defined(_TRACE_BPF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_BPF_H
+
+#include 
+
+TRACE_EVENT(bpf_output_data,
+
+   TP_PROTO(void *src, int size),
+
+   TP_ARGS(src, size),
+
+   TP_STRUCT__entry(
+   __dynamic_array(u8, buf,size)
+   ),
+
+   TP_fast_assign(
+   memcpy(__get_dynamic_array(buf), src, size);
+   ),
+
+   TP_printk("%s", __print_hex(__get_dynamic_array(buf),
+   __get_dynamic_array_len(buf)))
+);
+
+#endif /* _TRACE_BPF_H */
+
+/* This part must be outside protection */
+#include 
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 29ef6f9..5068ab1 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -249,6 +249,13 @@ enum bpf_func_id {
 * Return: 0 on success
 */
BPF_FUNC_get_current_comm,
+
+   /**
+* int bpf_output_trace_data(void *src, int size)
+* Return: 0 on success
+*/
+   BPF_FUNC_output_trace_data,
+
__BPF_FUNC_MAX_ID,
 };
 
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 88a041a..219f670 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -11,7 +11,10 @@
 #include 
 #include 
 #include 
+
 #include "trace.h"
+#define CREATE_TRACE_POINTS
+#include 
 
 static DEFINE_PER_CPU(int, bpf_prog_active);
 
@@ -79,6 +82,24 @@ static const struct bpf_func_proto bpf_probe_read_proto = {
.arg3_type  = ARG_ANYTHING,
 };
 
+static u64 bpf_output_trace_data(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+   void *src = (void *) (long) r1;
+   int size = (int) r2;
+
+   trace_bpf_output_data(src, size);
+
+   return 0;
+}
+
+static const struct bpf_func_proto bpf_output_trace_data_proto = {
+   .func   = bpf_output_trace_data,
+   .gpl_only   = true,
+   .ret_type   = RET_INTEGER,
+   .arg1_type  = ARG_PTR_TO_STACK,
+   .arg2_type  = ARG_CONST_STACK_SIZE,
+};
+
 /*
  * limited trace_printk()
  * only %d %u %x %ld %lu %lx %lld %llu %llx %p conversion specifiers allowed
@@ -169,6 +190,8 @@ static const struct bpf_func_proto 
*kprobe_prog_func_proto(enum bpf_func_id func
return _map_delete_elem_proto;
case BPF_FUNC_probe_read:
return _probe_read_proto;
+   case BPF_FUNC_output_trace_data:
+   return _output_trace_data_proto;
case BPF_FUNC_ktime_get_ns:
return _ktime_get_ns_proto;
case BPF_FUNC_tail_call:
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index bdf1c16..0aeaebe 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -59,5 +59,7 @@ static int (*bpf_l3_csum_replace)(void *ctx, int off, int 
from, int to, int flag
(void *) BPF_FUNC_l3_csum_replace;
 static int (*bpf_l4_csum_replace)(void *ctx, int off, int from, int to, int 
flags) =
(void *) BPF_FUNC_l4_csum_replace;
+static int (*bpf_output_trace_data)(void *src, int size) =
+   (void *) BPF_FUNC_output_trace_data;
 
 #endif
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: KDBUS breaks 'make installmandocs'

[Ulf Magnusson]

On Mon, Jul 13, 2015 at 05:39:25PM -0700, Greg KH wrote:
> On Sun, Jul 12, 2015 at 08:08:46PM +0200, Ulf Magnusson wrote:
> > Hello,
> > 
> > Tested with next-20150709.
> > 
> > Documentation/kdbus/Makefile lacks an 'installmandocs' target, causing
> > problems for
> > 
> > %docs: scripts_basic FORCE
> > $(Q)$(MAKE) $(build)=scripts build_docproc
> > $(Q)$(MAKE) $(build)=Documentation/DocBook $@
> > $(Q)$(MAKE) $(build)=Documentation/kdbus $@
> > 
> > from the top-level Makefile. It still works, but no KDBUS-related man
> > pages are installed, and the final error isn't reassuring.
> 
> What's the final error?
> 

$ sudo make installmandocs
  GEN Documentation/DocBook//v4l2.xml
find Documentation/DocBook/man -name '*.9' | xargs gzip -f
mkdir -p /usr/local/man/man9/
install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/
make[1]: *** No rule to make target 'installmandocs'.  Stop.
Makefile:1359: recipe for target 'installmandocs' failed
make: *** [installmandocs] Error 2


The "*** No rule to make target 'installmandocs'. Stop." error is
generated for Documentation/kdbus/Makefile. The other man pages still
install fine.

(That "GEN Documentation/DocBook//v4l2.xml" line might be an
unrelated issue. It's from the 'mandocs' prerequisite and shows up even
when the pages are already built.)

> > Documentation/DocBook/Makefile installs man pages into section 9, while
> > KDBUS uses 7. I'm not familiar enough with KDBUS to know what the right
> > thing to do here is.
> 
> I don't know either, perhaps someone on linux-api knows?
> 
> thanks,
> 
> greg k-h

Cheers,
Ulf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v5 1/3] tracing/events: Fix wrong sample output by storing array length instead of size

[He Kuang]

The output result of trace_foo_bar event in traceevent samples is
wrong. This problem can be reproduced as following:

  (Build kernel with SAMPLE_TRACE_EVENTS=m)

  $ insmod trace-events-sample.ko

  $ echo 1 > /sys/kernel/debug/tracing/events/sample-trace/foo_bar/enable

  $ cat /sys/kernel/debug/tracing/trace

  event-sample-980 [000]   43.649559: foo_bar: foo hello 21 0x15
  BIT1|BIT3|0x10 {0x1,0x6f6f6e53,0xff007970,0x} Snoopy
 ^^
 The array length is not right, should be {0x1}.
  (,)

  event-sample-980 [000]   44.653827: foo_bar: foo hello 22 0x16
  BIT2|BIT3|0x10
  {0x1,0x2,0x646e6147,0x666c61,0x,0x,0x750aeffe,0x7}
  ^^
 The array length is not right, should be {0x1,0x2}.
  Gandalf (,)

The event defined in samples/trace_events/trace-events-sample.h uses
this helper function to output dynamic list:

   __print_array(__get_dynamic_array(list),
 __get_dynamic_array_len(list),
 sizeof(int))

Currently, __get_dynamic_array_len() returns the total size of the
array instead of the number of items by referencing the high 16 bits
of entry->data_loc_##item. The element size for calculating the number
of items can not be fetched by referencing fields from __entry, so
macro __get_dynamic_array_len can not return the expected value.

This patch stores array item number instead of the total size in
entry->__data_loc_##item, and makes __get_dynamic_array_len get the
right value directly. Because the function __get_bitmask() is affected
by this change, __bitmask_size is assigned to the array len by
multiplied bitmask type size.

After this patch:

  event-sample-993 [000]   692.348562: foo_bar: foo hello 201
  0xc9 BIT1|BIT4|0xc0 {0x1} Snoopy (,)
  ^
  Array length fixed.

  event-sample-993 [000]   693.349276: foo_bar: foo hello 202
  0xca BIT2|BIT4|0xc0 {0x1,0x2} Gandalf (,)
  ^
  Array length fixed.

Signed-off-by: He Kuang 
---
 include/trace/trace_events.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index 43be3b0..5abe027 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -257,7 +257,8 @@ TRACE_MAKE_SYSTEM_STR();
({  \
void *__bitmask = __get_dynamic_array(field);   \
unsigned int __bitmask_size;\
-   __bitmask_size = __get_dynamic_array_len(field);\
+   __bitmask_size = (__get_dynamic_array_len(field) *  \
+ sizeof(unsigned long));   \
trace_print_bitmask_seq(p, __bitmask, __bitmask_size);  \
})
 
@@ -453,7 +454,7 @@ trace_event_define_fields_##call(struct trace_event_call 
*event_call)   \
__item_length = (len) * sizeof(type);   \
__data_offsets->item = __data_size +\
   offsetof(typeof(*entry), __data);\
-   __data_offsets->item |= __item_length << 16;\
+   __data_offsets->item |= (len) << 16;\
__data_size += __item_length;
 
 #undef __string
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v5 0/3] Make eBPF programs output data to perf

[He Kuang]

Hi,

Previous patch v4 url:
http://thread.gmane.org/gmane.linux.kernel/1993353

This version we output bpf trace events in a hex array, the results
for three u64 integers in previous sample changed to this:

  dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 01 00
  00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00

Users can interpret their own formats and get the result:

  last=0x12dc6aaca7a, cur=0x12dcaec8795, del=0x441bd1b

v3-v4:
 - Change u64 array in trace event to u8.
 - Remove misleading 'perf event' in subject.

Thank you.

He Kuang (3):
  tracing/events: Fix wrong sample output by storing array length
instead of size
  tools lib traceevent: Add function to get dynamic arrays length
  bpf: Introduce function for outputing trace event data

 include/trace/events/bpf.h | 30 +
 include/trace/trace_events.h   |  5 ++-
 include/uapi/linux/bpf.h   |  7 +++
 kernel/trace/bpf_trace.c   | 23 ++
 samples/bpf/bpf_helpers.h  |  2 +
 tools/lib/traceevent/event-parse.c | 52 ++
 tools/lib/traceevent/event-parse.h |  1 +
 .../util/scripting-engines/trace-event-python.c|  1 +
 8 files changed, 119 insertions(+), 2 deletions(-)
 create mode 100644 include/trace/events/bpf.h

-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Remove redundant DEBUG_LL check

[Krzysztof Kozlowski]

On 13.07.2015 20:18, Javier Martinez Canillas wrote:
> Commit 84f57d9e3685 ("tty: serial/samsung: fix modular build") fixed
> build issues when the driver was built as a module. One of those was
> that printascii is only accessible when the driver is built-in.
> 
> But there is no need to check for defined(CONFIG_DEBUG_LL) since the
> SERIAL_SAMSUNG_DEBUG Kconfig symbol already depends on DEBUG_LL.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/tty/serial/samsung.c | 1 -
>  1 file changed, 1 deletion(-)

Although this redundancy is not harmful the patch seems fine, so:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

[Hidehiro Kawai]

Hello Eric and Daniel,

(2015/07/14 5:26), dwal...@fifo99.com wrote:
> On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
>> Hidehiro Kawai  writes:
>>
>>> You can call panic notifiers and kmsg dumpers before kdump by
>>> specifying "crash_kexec_post_notifiers" as a boot parameter.
>>> However, it doesn't make sense if kdump is not available.  In that
>>> case, disable "crash_kexec_post_notifiers" boot parameter so that
>>> you can't change the value of the parameter.
>>
>> Nacked-by: "Eric W. Biederman" 
>>
>> You are confusing kexec on panic and CONFIG_CRASH_DUMP
>> which is about the tools for reading the state of the previous kernel.

You are right.  I mistook the meaning of CONFIG_CRASH_DUMP.

> I think it would make sense if he just replaced "kdump" with "kexec".

If a user specified crash_kexec_post_notifiers option with kexec
being totally disabled, it just disables notifier and kmsg dumper calls
(please see PATCH 3/3). So as Daniel said, I also think it makes sense
to hide crash_kexec_post_notifiers option if kexec is disabled.

Regards,

-- 
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/