RE: [lkp] [f2fs] 9f88450ff1: stderr.mount:wrong_fs_type,bad_option,bad_superblock_on/dev/sda3

[Chao Yu]

Hi Ying Huang,

> -Original Message-
> From: kernel test robot [mailto:ying.hu...@linux.intel.com]
> Sent: Monday, December 14, 2015 3:06 PM
> To: Chao Yu
> Cc: l...@01.org; LKML; 0day robot
> Subject: [lkp] [f2fs] 9f88450ff1:
> stderr.mount:wrong_fs_type,bad_option,bad_superblock_on/dev/sda3
> 
> FYI, we noticed the below changes on
> 
> https://github.com/0day-ci/linux
> Chao-Yu/f2fs-clean-up-node-page-updating-flow/20151211-161235
> commit 9f88450ff18d8bd577ff431318f7ae00034465c0 ("f2fs: do more integrity 
> verification for
> superblock")
> 
> 
> After your commit, our mounting f2fs partition operations will fail with
> following error message.  But I have no dmesg now.  Do you need it?

Thanks for the report! Could you please share dmesg and some info (e.g. size..)
about storage device '/dev/sda3'.

Thanks,

> 
> mount: wrong fs type, bad option, bad superblock on /dev/sda3,
>missing codepage or helper program, or other error
> 
>In some cases useful info is found in syslog - try
>dmesg | tail or so.
> 
> 
> To reproduce:
> 
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
> 
> 
> 
> 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: touchscreen: edt-ft5x06: Prevent DMA driver from mapping an area on stack

[maitysanchayan]

Hello,

On 15-12-12 20:42:37, Dmitry Torokhov wrote:
> On Sat, Dec 12, 2015 at 06:13:55PM +0100, Wolfram Sang wrote:
> > 
> > > Frankly speaking I do not know where the fix should actually be. I2C IMX
> > > driver somehow taking care of this or the users of I2C, touchscreen 
> > > drivers
> > > in this case. In my opinion, the fix should be with the touchscreen driver
> > > however I did like to have feedback or hear opinions on what is the 
> > > accepted
> > > solution to this.
> > 
> > There is no accepted solution to this yet :( DMA is/was still too rare for
> > a serious discussion about this. There is also [1] and probably more...
> > 
> > [1]  http://patchwork.ozlabs.org/patch/220137/
> 
> I believe vast majority of i2c client drivers do not expect that the
> transfer buffer they supply in i2c messages are supposed to be DMAable
> (unlike USB and SPI buses that had that requirement from the beginning).
> 
> I won't be applying this patch unless we decide that I2C changes the
> rules.

Understood. Thanks for the clarifications Dmitry and Wolfram.

- Sanchayan.
--
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 0/24] kernel: add a netlink interface to get information about processes (v2)

[Andrew Vagin]

On Thu, Dec 03, 2015 at 03:20:30PM -0800, Andy Lutomirski wrote:
> On Tue, Nov 24, 2015 at 7:18 AM, Andrew Vagin  wrote:
> > Hello Everybody,
> >
> > Sorry for the long delay. I wanted to resurrect this thread.
> >
> > Andy suggested to create a new syscall instead of using netlink
> > interface.
> >> Would it make more sense to have a new syscall instead?  You could
> >> even still use nlattr formatting for the syscall results.
> >
> > I tried to implement it to understand how it looks like. Here is my
> > version:
> > https://github.com/avagin/linux-task-diag/blob/task_diag_syscall/kernel/task_diag.c#L665
> > I could not invent a better interfaces for it than using netlink
> > messages as arguments. I know it looks weird.
> >
> > I could not say that I understood why a new system call is better
> > than using a netlink socket, so I tried to solve the problem which
> > were mentioned for the netlink interface.
> >
> > The magor question was how to support pid and user namespaces in task_diag.
> > I think I found a good and logical solution.
> >
> > As for pidns, we can use scm credentials, which is connected to each
> > socket message. They contain requestor’s pid and we can get a pid
> > namespace from it. In this case, we get a good feature to specify a pid
> > namespace without entering into it. For that, an user need to specify
> > any process from this pidns in an scm message.
> 
> That seems a little messy.  A process can't currently move into
> another pidns, but how do you make sure you have any pid at all that
> belongs to the reference pidns?  You can, of course, always use your
> own pid, but that still seems odd to me.

There is your pid by default, you need to do nothing for that.
If we look at containers or sandboxes, we ussualy know PID of
the init process.


> 
> >
> > As for credentials, we can get them from file->f_cred. In this case we
> > are able to create a socket and decrease permissions of the current
> > process, but the socket will work as before. It’s the common behaviour for
> > file descriptors.
> 
> Slightly off-topic, but this netlink is really rather bad as an
> example of how fds can be used as capabilities (in the real capability
> sense, not the Linux capabilities sense).  You call socket and get a
> socket.  That socket captures f_cred.  Then you drop privs, and you
> assume that the socket you're holding on to retains the right to do
> certain things.
> 
> This breaks pretty badly when, through things such as this patch set,
> existing code that creates netlink sockets suddenly starts capturing
> brand-new rights that didn't exist as part of a netlink socket before.

Sorry, I don't understand this part. Could you eloborate? Maybe give an
example.

I always think that it's a feature, that we can create a descriptor and
drop capabilities of the process or send this descriptor to an
unprivilieged process.

I think this part may be critical for understanding your point of view.
Thanks.

> 
> From my perspective, netlink is a lot like ioctl, only without the
> meaningful fd that you're calling it on.  So why is it better than
> syscalls?  I'll grant that it comes with nice (?) buffering machinery.

The nice buffering machinery is one of the reasons. Another reason is
that netlink is a ready interface for this sort of task, so we can avoid
code duplacation.

> 
> > * Netlink is designed for such type of workloads. It allows to expand
> >   the interface and save backward compatibility. It allows to generates
> >   packets with a different set of parameters.
> > * If we use a file descriptor, we can create it and decrease
> >   capabilities of the current process. It's a good feature which will be
> >   unavailable if we decide to create a system call.
> 
> If this is actually a real goal and it matters, then I'd suggest doing
> it right.  Make a way to create an fd that represents a pidns and,
> specifically, the right to query non-secret properties of the
> processes in the pidns.

I will think. Thank you for comments.

> 
> --Andy
--
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] Staging: comedi: fix block comments coding style issue in comedi.h

[maomao xu]

Fix up block comments to make a trailing */ on a separate line

Signed-off-by: maomao xu 
---
 drivers/staging/comedi/comedi.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index 66edda1..ec5e59c 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -895,7 +895,8 @@ enum amplc_dio_ts_clock_src {
 };
 
 /* Values for setting a gate source with INSN_CONFIG_SET_GATE_SRC for
- * 8254 counter subdevices on Amplicon DIO boards (amplc_dio200 driver). */
+ * 8254 counter subdevices on Amplicon DIO boards (amplc_dio200 driver).
+ */
 enum amplc_dio_gate_source {
AMPLC_DIO_GAT_VCC,  /* internal high logic level */
AMPLC_DIO_GAT_GND,  /* internal low logic level */
-- 
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: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver

[Pavel Fedin]

 Hello!

> THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES
> 
> Series v5 got merged in kgene/for-next but due to last moment change before 
> pull
> these patches were not accepted during 4.3 merge window.After that 
> kgene/for-next
> got rebased over 4.4-rc1 these patches got dropped into another branch and 
> till
> date not included to for-next.

 I will not strictly require it because i'd like to move on with this somehow, 
and if this gets merged, i'm fine with it, but if you
happen to send v6, may be you should include this small bit:

http://www.spinics.net/lists/linux-samsung-soc/msg49008.html

 ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
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] spi: dts: sun4i: Add support for hardware-based wait time between words

[Marcus Weseloh]

Hi,

2015-12-14 2:29 GMT+01:00 Rob Herring :
> On Mon, Dec 14, 2015 at 12:04:11AM +0100, Marcus Weseloh wrote:
>> Adds a new property "spi-word-wait-ns" to the spi-bus binding that allows
[...]
>> diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt 
>> b/Documentation/devicetree/bindings/spi/spi-bus.txt
>> index bbaa857..2d6034f 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-bus.txt
>> +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
>> @@ -61,6 +61,8 @@ contain the following properties.
>>used for MOSI. Defaults to 1 if not present.
>>  - spi-rx-bus-width - (optional) The bus width(number of data wires) that
>>used for MISO. Defaults to 1 if not present.
>> +- spi-word-wait-ns - (optional) Hardware based delay between transmission of
>> +  words in nanoseconds
>
> Could be a software delay if the h/w doesn't support delays.

Of course, I was still trapped in my sun4i specific thinking. Will
remove the hardware reference.

[...]
>> + /* Setup wait time between words */
>> + of_property_read_u32(spi->dev.of_node, "spi-word-wait-ns",
>> +  _ns);
>
> Read this in probe and save the value rather than fetching every
> transfer.

But this is a slave property I'm using here. If I read and store it in
probe in the spi-sun4i driver, I won't have access to the slave node
property, will I?

Cheers,

Marcus
--
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 08/10] drivers/pci: make host/pcie-xilinx.c explicitly non-modular

[Michal Simek]

On 13.12.2015 02:41, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/pci/host/Kconfig:config PCIE_XILINX
> drivers/pci/host/Kconfig:   bool "Xilinx AXI PCIe host bridge support"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.  This
> makes xilinx_pcie_free_irq_domain orphaned so we remove it too.

Right.

Acked-by: Michal Simek 

Thanks,
Michal
--
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/3] x86: Add support for guest DMA dirty page tracking

[Yang Zhang]

On 2015/12/14 13:46, Alexander Duyck wrote:

On Sun, Dec 13, 2015 at 9:22 PM, Yang Zhang  wrote:

On 2015/12/14 12:54, Alexander Duyck wrote:


On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang 
wrote:


On 2015/12/14 5:28, Alexander Duyck wrote:



This patch set is meant to be the guest side code for a proof of concept
involving leaving pass-through devices in the guest during the warm-up
phase of guest live migration.  In order to accomplish this I have added
a
new function called dma_mark_dirty that will mark the pages associated
with
the DMA transaction as dirty in the case of either an unmap or a
sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
the stop-and-copy phase, however allowing the device to be present
should
significantly improve the performance of the guest during the warm-up
period.

This current implementation is very preliminary and there are number of
items still missing.  Specifically in order to make this a more complete
solution we need to support:
1.  Notifying hypervisor that drivers are dirtying DMA pages received
2.  Bypassing page dirtying when it is not needed.



Shouldn't current log dirty mechanism already cover them?



The guest has no way of currently knowing that the hypervisor is doing
dirty page logging, and the log dirty mechanism currently has no way
of tracking device DMA accesses.  This change is meant to bridge the
two so that the guest device driver will force the SWIOTLB DMA API to
mark pages written to by the device as dirty.



OK. This is what we called "dummy write mechanism". Actually, this is just a
workaround before iommu dirty bit ready. Eventually, we need to change to
use the hardware dirty bit. Besides, we may still lost the data if dma
happens during/just before stop and copy phase.


Right, this is a "dummy write mechanism" in order to allow for entry
tracking.  This only works completely if we force the hardware to
quiesce via a hot-plug event before we reach the stop-and-copy phase
of the migration.

The IOMMU dirty bit approach is likely going to have a significant
number of challenges involved.  Looking over the driver and the data
sheet it looks like the current implementation is using a form of huge
pages in the IOMMU, as such we will need to tear that down and replace
it with 4K pages if we don't want to dirty large regions with each DMA


Yes, we need to split the huge page into small pages to get the small 
dirty range.



transaction, and I'm not sure that is something we can change while
DMA is active to the affected regions.  In addition the data sheet


what changes do you mean?


references the fact that the page table entries are stored in a
translation cache and in order to sync things up you have to
invalidate the entries.  I'm not sure what the total overhead would be
for invalidating something like a half million 4K pages to migrate a
guest with just 2G of RAM, but I would think that might be a bit


Do you mean the cost of submit the flush request or the performance 
impaction due to IOTLB miss? For the former, we have domain-selective 
invalidation. For the latter, it would be acceptable since live 
migration shouldn't last too long.



expensive given the fact that IOMMU accesses aren't known for being
incredibly fast when invalidating DMA on the host.

- Alex




--
best regards
yang
--
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.3 23/71] net: thunder: Check for driver data in nicvf_remove()

[Pavel Fedin]

 Hello!

 It's good to apply this to stable, however IMHO commit message should be 
changed. Actually, this was fix for a fix, so in theory
5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206 and 
7750130d93decff06120df0d8ea024ff8a038a21 should have been squashed together. 
You can
take a commit message from 5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206, it better 
explains what was actually done and why.
 There's also a clean patch: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg87010.html, which was 
not applied because v1 was
already applied and David doesn't revert commits.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, December 12, 2015 11:06 PM
> To: linux-kernel@vger.kernel.org
> Cc: Greg Kroah-Hartman; sta...@vger.kernel.org; Pavel Fedin; David S. Miller
> Subject: [PATCH 4.3 23/71] net: thunder: Check for driver data in 
> nicvf_remove()
> 
> 4.3-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Pavel Fedin 
> 
> [ Upstream commit 7750130d93decff06120df0d8ea024ff8a038a21 ]
> 
> In some cases the crash is caused by nicvf_remove() being called from
> outside. For example, if we try to feed the device to vfio after the
> probe has failed for some reason. So, move the check to better place.
> 
> Signed-off-by: Pavel Fedin 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/net/ethernet/cavium/thunder/nicvf_main.c |   10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1583,8 +1583,14 @@ err_disable_device:
>  static void nicvf_remove(struct pci_dev *pdev)
>  {
>   struct net_device *netdev = pci_get_drvdata(pdev);
> - struct nicvf *nic = netdev_priv(netdev);
> - struct net_device *pnetdev = nic->pnicvf->netdev;
> + struct nicvf *nic;
> + struct net_device *pnetdev;
> +
> + if (!netdev)
> + return;
> +
> + nic = netdev_priv(netdev);
> + pnetdev = nic->pnicvf->netdev;
> 
>   /* Check if this Qset is assigned to different VF.
>* If yes, clean primary and all secondary Qsets.
> 


--
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/2] zram: Less checks in zram_bvec_write() after error detection

[Julia Lawall]

> I suggest to make the affected exception handling a bit more efficient.
> Such source code fine-tuning has got a few special consequences.

Exception handling is by definition exceptional, and thus its efficiency 
is rarely important.  What is important is that it should be correct, and 
ideally clearly correct, so that someone can check its correctness easily.  
Optimizations, if they have any effect at all, typically make the 
correctness less obvious.

julia
--
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 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Chanwoo Choi]

Hi Krzysztof and Myungjoo,

On 2015년 12월 11일 17:03, Krzysztof Kozlowski wrote:
> On 11.12.2015 16:52, Chanwoo Choi wrote:
>> Dear MyungJoo,
>>
>> Almost device tree patches in this series are reviewed by Exynos maintainer.
>> Could you please review this series?
> 
> Are there any objections to merging DT patches through Samsung-soc?
> 
> Looking at the code, there are no dependencies between DT and drivers,
> right?

Yes.
There is no dependency between exynos-bus.c patches and DT patches.
If the design concept of exynos-bus.c don't be changed,
there is no problem to merge the DT patches to samsung-soc tree.

Best Regards,
Chanwoo Choi

> 
> Best regards,
> Krzysztof
> 
>>
>> Best Regards,
>> Chanwoo Choi
>>
>> On 2015년 12월 11일 14:07, Chanwoo Choi wrote:
>>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
>>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
>>> have the common architecture for bus between DRAM and sub-blocks in SoC.
>>> This driver can support the generic bus frequency driver for Exynos SoCs.
>>>
>>> In devicetree, Each bus block has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> [linux.amoon: Tested on Odroid U3]
>>> Tested-by: Anand Moon 
>>> ---
>>>  drivers/devfreq/Kconfig |  15 ++
>>>  drivers/devfreq/Makefile|   1 +
>>>  drivers/devfreq/exynos/Makefile |   1 +
>>>  drivers/devfreq/exynos/exynos-bus.c | 449 
>>> 
>>>  4 files changed, 466 insertions(+)
>>>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

--
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] regmap: flat: introduce register striding to save some memories

[Xiubo Li]

Throughout the regcache-flat code, for the flat cache array, the
actual register address offsets are used to index the values, and
this will waste some memory spaces.

For example, on 64-BIT platform, device A has three registers:
register offsets: {0x00, 0x08, 0x10}
max_register: 0x10
regsiter striding: 8

And the size of flat cache memory space will be:
(max_register + 1 ) * sizeof(unsigned int) =
(0x10 + 1) * sizeof(unsigned int) = 17 * 8 = 136 Bytes

Since map->reg_stride has been introduced and all extant register
addresses are a multiple of this value, it could use the address
offsets divide by the stride to determine the index.

Then the size of flat cache memory space will be:
(max_register / reg_stride + 1 ) * sizeof(unsigned int) =
(0x10 / 8 + 1) * sizeof(unsigned int) = 3 * 8 = 24 Bytes

And the bigger of the striding value, there will be more memory
space wasted. After introducing the register striding here can
save some memeories for the system.

Signed-off-by: Xiubo Li 
---
 drivers/base/regmap/regcache-flat.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/base/regmap/regcache-flat.c 
b/drivers/base/regmap/regcache-flat.c
index 686c9e0..160d636 100644
--- a/drivers/base/regmap/regcache-flat.c
+++ b/drivers/base/regmap/regcache-flat.c
@@ -19,17 +19,19 @@
 static int regcache_flat_init(struct regmap *map)
 {
int i;
-   unsigned int *cache;
+   unsigned int index, *cache;
 
-   map->cache = kcalloc(map->max_register + 1, sizeof(unsigned int),
-GFP_KERNEL);
+   map->cache = kcalloc(map->max_register / map->reg_stride + 1,
+sizeof(unsigned int), GFP_KERNEL);
if (!map->cache)
return -ENOMEM;
 
cache = map->cache;
 
-   for (i = 0; i < map->num_reg_defaults; i++)
-   cache[map->reg_defaults[i].reg] = map->reg_defaults[i].def;
+   for (i = 0; i < map->num_reg_defaults; i++) {
+   index =  map->reg_defaults[i].reg / map->reg_stride;
+   cache[index] = map->reg_defaults[i].def;
+   }
 
return 0;
 }
@@ -45,9 +47,10 @@ static int regcache_flat_exit(struct regmap *map)
 static int regcache_flat_read(struct regmap *map,
  unsigned int reg, unsigned int *value)
 {
+   unsigned int index = reg / map->reg_stride;
unsigned int *cache = map->cache;
 
-   *value = cache[reg];
+   *value = cache[index];
 
return 0;
 }
@@ -55,9 +58,10 @@ static int regcache_flat_read(struct regmap *map,
 static int regcache_flat_write(struct regmap *map, unsigned int reg,
   unsigned int value)
 {
+   unsigned int index = reg / map->reg_stride;
unsigned int *cache = map->cache;
 
-   cache[reg] = value;
+   cache[index] = value;
 
return 0;
 }
-- 
1.8.3.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: linux-next: manual merge of the drm-misc tree with Linus' tree

[Thomas Hellstrom]

On 12/14/2015 02:12 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
>   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
>   drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
>   drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
>
> between commit:
>
>   8fbf9d92a7bc ("drm/vmwgfx: Implement the cursor_set2 callback v2")
>
> from Linus' tree and commit:
>
>   f80de66eca65 ("drm/vmwgfx: Drop dummy save/restore hooks")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
FWIW, the fix looks correct to me.

/Thomas

--
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 resend ] tty/n_gsm.c: use gsm->num to remove mux itself from gsm_mux[]

[Pan Xinhui]

From: Pan Xinhui 

There is one filed gsm->num to store mux's index of gsm_mux[]. So use
gsm->num to remove itself from gsm_mux[] instead of the for-loop
traverse in gsm_cleanup_mux().

Signed-off-by: Pan Xinhui 
---
 drivers/tty/n_gsm.c |   14 +-
 1 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 9aff371..cf28054 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2037,18 +2037,14 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm)
 
gsm->dead = 1;
 
-   spin_lock(_mux_lock);
-   for (i = 0; i < MAX_MUX; i++) {
-   if (gsm_mux[i] == gsm) {
-   gsm_mux[i] = NULL;
-   break;
-   }
-   }
-   spin_unlock(_mux_lock);
/* open failed before registering => nothing to do */
-   if (i == MAX_MUX)
+   if (gsm_mux[gsm->num] != gsm)
return;
 
+   spin_lock(_mux_lock);
+   gsm_mux[gsm->num] = NULL;
+   spin_unlock(_mux_lock);
+
/* In theory disconnecting DLCI 0 is sufficient but for some
   modems this is apparently not the case. */
if (dlci) {
-- 
1.7.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/

[lkp] [f2fs] 9f88450ff1: stderr.mount:wrong_fs_type,bad_option,bad_superblock_on/dev/sda3

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Chao-Yu/f2fs-clean-up-node-page-updating-flow/20151211-161235
commit 9f88450ff18d8bd577ff431318f7ae00034465c0 ("f2fs: do more integrity 
verification for superblock")


After your commit, our mounting f2fs partition operations will fail with
following error message.  But I have no dmesg now.  Do you need it?

mount: wrong fs type, bad option, bad superblock on /dev/sda3,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml  # job file is attached in this email
bin/lkp run job.yaml



Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=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_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
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=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# 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=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_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_BROADCAST=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 is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
# CONFIG_NO_HZ_FULL_SYSIDLE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
# CONFIG_RCU_NOCB_CPU_ZERO is not set
CONFIG_RCU_NOCB_CPU_ALL=y
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set

Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection

[SF Markus Elfring]

>> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>> index 47915d7..69d7fcd 100644
>> --- a/drivers/block/zram/zram_drv.c
>> +++ b/drivers/block/zram/zram_drv.c
>> @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct 
>> bio_vec *bvec, u32 index,
>>  size_t clen;
>>  unsigned long handle;
>>  struct page *page;
>> -unsigned char *user_mem, *cmem, *src, *uncmem = NULL;
>> +unsigned char *user_mem, *cmem, *src, *uncmem;
>>  struct zram_meta *meta = zram->meta;
>> -struct zcomp_strm *zstrm = NULL;
>> +struct zcomp_strm *zstrm;
>>  unsigned long alloced_pages;
>>  
>>  page = bvec->bv_page;
>> @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct 
>> bio_vec *bvec, u32 index,
>>   * before to write the changes.
>>   */
>>  uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
>> -if (!uncmem) {
>> -ret = -ENOMEM;
>> -goto out;
>> -}
>> +if (!uncmem)
>> +return -ENOMEM;
> 
> ok.

Thanks for your terse acknowledgement.


>>  ret = zram_decompress_page(zram, uncmem, index);
>>  if (ret)
>> -goto out;
>> +goto free_uncmem;
> 
> here and later, I don't want to split `out' label.

I guess that corresponding software design concerns can evolve a bit.


> you still need to do both 'if zstrm' and 'if is_partial_io' checks anyway, 
> what's the gain?

How are the chances to reduce the number of dispensable sanity checks?


> the more labels we have the trickier it may get.

I hope that more unique jump labels can make the involved exception handling 
also clearer.


>> @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct 
>> bio_vec *bvec, u32 index,
>>  /* Update stats */
>>  atomic64_add(clen, >stats.compr_data_size);
>>  atomic64_inc(>stats.pages_stored);
>> -out:
>> +check_strm:
>>  if (zstrm)
>>  zcomp_strm_release(zram->comp, zstrm);
>> -if (is_partial_io(bvec))
>> +if (is_partial_io(bvec)) {
>> +free_uncmem:
>>  kfree(uncmem);
>> +}
> 
> a label inside of `if'?   no.

Do any more software developers find such an use case interesting?


> keep it the way it is please.

I suggest to make the affected exception handling a bit more efficient.
Such source code fine-tuning has got a few special consequences.

Regards,
Markus
--
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 0/4] scsi: storvsc: Properly support FC hosts

[Dan Carpenter]

Thanks, K. Y.

regards,
dan carpenter

--
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] [lkp] [x86/irq] 4c24cee6b2: IP-Config: Auto-configuration of network failed

[Huang, Ying]

Hi, Jiang,

Jiang Liu  writes:

> Hi Ying,
>   Thanks for reporting this issue. But I couldn't figure
> out what's wrong with this commit. And there's no error or
> warning messages in the attached dmesg file. Are there other
> systems reporting the same issue?

No, there are no other systems reporting the same issue.  I will queue
more tests for make sure this is not a false positive.

Best Regards,
Huang, Ying

> Thanks,
> Gerry
>
> On 2015/12/11 15:49, kernel test robot wrote:
>> FYI, we noticed the below changes on
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
>> commit 4c24cee6b2aeaee3dab896f76fef4fe79d9e4183 ("x86/irq: Enhance
>> __assign_irq_vector() to rollback in case of failure")
>> 
>> 
>> ++++
>> || 6dd7cb991f | 4c24cee6b2 |
>> ++++
>> | boot_successes | 6  | 0  |
>> | boot_failures  | 0  | 8  |
>> | IP-Config:Auto-configuration_of_network_failed | 0  | 6  |
>> | BUG:kernel_boot_hang   | 0  | 2  |
>> ++++
>> 
>> It appears that the Ethernet card doesn't work properly after your patch.
>> 
>> [   15.342990] Waiting up to 110 more seconds for network.
>> [   25.346987] Waiting up to 100 more seconds for network.
>> [   35.350995] Waiting up to 90 more seconds for network.
>> [   45.350993] Waiting up to 80 more seconds for network.
>> [   55.351006] Waiting up to 70 more seconds for network.
>> [   65.350992] Waiting up to 60 more seconds for network.
>> [   75.355017] Waiting up to 50 more seconds for network.
>> [   85.359009] Waiting up to 40 more seconds for network.
>> [   95.363009] Waiting up to 30 more seconds for network.
>> [  305.883015] Waiting up to 20 more seconds for network.
>> [  315.887002] Waiting up to 10 more seconds for network.
>> [  325.887524] Sending DHCP requests .. timed out!
>> [  417.893036] IP-Config: Auto-configuration of network failed
>> [  417.893852] ALSA device list:
>> [  417.894270]   No soundcards found.
>> [  417.899649] Freeing unused kernel memory: 2884K (82574000 - 
>> 82845000)
>> 
>> 
>> Thanks,
>> Ying Huang
>> 
> ___
> LKP mailing list
> l...@lists.01.org
> https://lists.01.org/mailman/listinfo/lkp
--
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 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls

[Dan Carpenter]

Markus, please stop sending these things to rename out labels unless
there is a bug.  CodingStyle allows out labels.

regards,
dan carpenter

--
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 7/7] ARM: dts: add dts files for Hi3519

[xuejiancheng]

Hi Rob,

On 2015/12/12 0:28, Rob Herring wrote:
> On Fri, Dec 11, 2015 at 03:45:21PM +0800, Jiancheng Xue wrote:
>> add dts files for Hi3519
>>
>> Signed-off-by: Jiancheng Xue 
>> ---
>>  arch/arm/boot/dts/Makefile|   2 +
>>  arch/arm/boot/dts/hi3519-demb.dts |  42 +++
>>  arch/arm/boot/dts/hi3519.dtsi | 142 
>> ++
>>  3 files changed, 186 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
>>  create mode 100644 arch/arm/boot/dts/hi3519.dtsi
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 30bbc37..1ff3ed9 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -135,6 +135,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
>>  exynos5800-peach-pi.dtb
>>  dtb-$(CONFIG_ARCH_HI3xxx) += \
>>  hi3620-hi4511.dtb
>> +dtb-$(CONFIG_ARCH_HISI) += \
>> +hi3519-demb.dtb
>>  dtb-$(CONFIG_ARCH_HIX5HD2) += \
>>  hisi-x5hd2-dkb.dtb
>>  dtb-$(CONFIG_ARCH_HIGHBANK) += \
>> diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
>> b/arch/arm/boot/dts/hi3519-demb.dts
>> new file mode 100644
>> index 000..6991ab6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/hi3519-demb.dts
>> @@ -0,0 +1,42 @@
>> +/*
>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +#include "hi3519.dtsi"
>> +
>> +/ {
>> +model = "HiSilicon HI3519 DEMO Board";
>> +compatible = "hisilicon,hi3519";
>> +
>> +aliases {
>> +serial0 = 
>> +};
>> +
>> +memory {
>> +device_type = "memory";
>> +reg = <0x8000 0x4000>;
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
>> +};
>> +
>> +_timer0 {
>> +status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
>> new file mode 100644
>> index 000..50b736e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/hi3519.dtsi
>> @@ -0,0 +1,142 @@
>> +/*
>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + *
>> + */
>> +
>> +#include "skeleton.dtsi"
> 
> Don't include skeleton.dtsi. We've decided it was a bad idea.

OK.

> 
>> +#include 
>> +/ {
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +cpu@0 {
> 
> Single core system? Add the other cpu nodes if not. Adding them doesn't 
> have to be in sync with SMP kernel support.

Hi3519 includes an A7 core and an A17 core. But it will run in AMP mode.
The A17 core is reserved for customers for special use. We can treat the
system as a single core system here.

> 
>> +device_type = "cpu";
>> +compatible = "arm,cortex-a7";
>> +reg = <0>;
>> +};
>> +};
>> +
>> +gic: interrupt-controller@1030 {
>> +compatible = "arm,cortex-a7-gic";
>> +#interrupt-cells = <3>;
>> +interrupt-controller;
>> +reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
>> +};
>> +
>> +soc {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "simple-bus";
>> +interrupt-parent = <>;
>> +ranges;
> 
> Looks like everything is in 0x12xx range, so you should add actual 
> translation here if that's the case.

Other device nodes will be added later which are not in 0x12xx range.

> 
>> +
>> +amba {
> 
> Is this actually a separate bus in the physical design of the chip?
> 
>> +#address-cells = <1>;
>> +#size-cells = 

[PATCH v4 04/20] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[Chanwoo Choi]

This patch adds the DMC (Dynamic Memory Controller) bus frequency node
which includes the devfreq-events and regulator properties. The bus
frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
with ondemand governor.

The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
the DMC block.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250-monk.dts   | 6 ++
 arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 443a35085846..456844a81189 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -156,6 +156,12 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 3e64d5dcdd60..d6bb990ce931 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -147,6 +147,12 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
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/

[PATCH v4 06/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()

[Chanwoo Choi]

This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
which can find the instance of devfreq device by using phandle ("devfreq").

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 drivers/devfreq/devfreq.c | 44 
 include/linux/devfreq.h   |  9 +
 2 files changed, 53 insertions(+)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 15e58779e4c0..78ea4cdaa82c 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "governor.h"
 
 static struct class *devfreq_class;
@@ -686,6 +687,49 @@ struct devfreq *devm_devfreq_add_device(struct device *dev,
 }
 EXPORT_SYMBOL(devm_devfreq_add_device);
 
+#ifdef CONFIG_OF
+/*
+ * devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of devfreq
+ *
+ * return the instance of devfreq device
+ */
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+   struct device_node *node;
+   struct devfreq *devfreq;
+
+   if (!dev)
+   return ERR_PTR(-EINVAL);
+
+   if (!dev->of_node)
+   return ERR_PTR(-EINVAL);
+
+   node = of_parse_phandle(dev->of_node, "devfreq", index);
+   if (!node)
+   return ERR_PTR(-ENODEV);
+
+   mutex_lock(_list_lock);
+   list_for_each_entry(devfreq, _list, node) {
+   if (devfreq->dev.parent
+   && devfreq->dev.parent->of_node == node) {
+   mutex_unlock(_list_lock);
+   return devfreq;
+   }
+   }
+   mutex_unlock(_list_lock);
+
+   return ERR_PTR(-EPROBE_DEFER);
+}
+#else
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
+
 /**
  * devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
  * @dev:   the device to add devfreq feature.
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 95c54578a1b4..cf972befca2b 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -211,6 +211,9 @@ extern int devm_devfreq_register_opp_notifier(struct device 
*dev,
 extern void devm_devfreq_unregister_opp_notifier(struct device *dev,
struct devfreq *devfreq);
 
+extern struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev,
+   int index);
+
 /**
  * devfreq_update_stats() - update the last_status pointer in struct devfreq
  * @df:the devfreq instance whose status needs updating
@@ -322,6 +325,12 @@ static inline void 
devm_devfreq_unregister_opp_notifier(struct device *dev,
 {
 }
 
+static inline struct devfreq *devfreq_get_devfreq_by_phandle(struct device 
*dev,
+   int index)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline int devfreq_update_stats(struct devfreq *df)
 {
return -EINVAL;
-- 
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/

[PATCH v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Chanwoo Choi]

This patch adds the generic exynos bus frequency driver for AMBA AXI bus
of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
have the common architecture for bus between DRAM and sub-blocks in SoC.
This driver can support the generic bus frequency driver for Exynos SoCs.

In devicetree, Each bus block has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 drivers/devfreq/Kconfig |  15 ++
 drivers/devfreq/Makefile|   1 +
 drivers/devfreq/exynos/Makefile |   1 +
 drivers/devfreq/exynos/exynos-bus.c | 449 
 4 files changed, 466 insertions(+)
 create mode 100644 drivers/devfreq/exynos/exynos-bus.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 64281bb2f650..55ec774f794c 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
 
 comment "DEVFREQ Drivers"
 
+config ARM_EXYNOS_BUS_DEVFREQ
+   bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
+   depends on ARCH_EXYNOS
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select DEVFREQ_EVENT_EXYNOS_PPMU
+   select PM_DEVFREQ_EVENT
+   select PM_OPP
+   help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
 config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 5134f9ee983d..375ebbb4fcfb 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
 obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
 
 # DEVFREQ Drivers
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos/
 obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 49bc9175f923..4ec06d322996 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,3 +1,4 @@
 # Exynos DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
 obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos_ppmu.o exynos4_bus.o
 obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos-bus.c 
b/drivers/devfreq/exynos/exynos-bus.c
new file mode 100644
index ..f1bc20839650
--- /dev/null
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -0,0 +1,449 @@
+/*
+ * Generic Exynos Bus frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi 
+ *
+ * This driver support Exynos Bus frequency feature by using
+ * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_SATURATION_RATIO   40
+
+struct exynos_bus {
+   struct device *dev;
+
+   struct devfreq *devfreq;
+   struct devfreq_event_dev **edev;
+   unsigned int edev_count;
+   struct mutex lock;
+
+   struct dev_pm_opp *curr_opp;
+
+   struct regulator *regulator;
+   struct clk *clk;
+   int ratio;
+};
+
+/*
+ * Control the devfreq-event device to get the current state of bus
+ */
+#define exynos_bus_ops_edev(ops)   \
+static int exynos_bus_##ops(struct exynos_bus *bus)\
+{  \
+   int i, ret; \
+   \
+   for (i = 0; i < bus->edev_count; i++) { \
+   if (!bus->edev[i])  \
+   continue;   \
+   ret = devfreq_event_##ops(bus->edev[i]);\
+   if (ret < 0)\
+   return ret; \
+   }   

[PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

This patch-set includes the two features as following. The generic exynos bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the patch-set[2]
with the similiar concept. This is is revised version for exynos bus frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework

Depend on:
- next-20151210 tag of linux-next (master branch).
- Merge the latest devfreq patches on devfreq.git[2] (for-rafael branch).
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
for-rafael)
[2] https://lkml.org/lkml/2015/1/7/872
   : [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver

Changes from v3:
(https://lkml.org/lkml/2015/12/11/75)
- Add the reviewed-by tag from Krzysztof Kozlowski (patch2/3/13/14/15/16/17)
- Fix typo of the description on patch14
- Modify the subject and description of patch17
- Reorder the 'bus_xxx' device tree node alphabetically in 
  both exynos3250-rinato/monk.dts and exynos4412-trats/odroidu3

Changes from v2:
(https://lkml.org/lkml/2015/12/8/869)
- Fix typo on documentation
- Modify the more appropriate sentence on patch description
- Add the detailed description about both parent and passive bus device
- Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
- Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV -> 
825mV)
- Rename OPP nodes as 'opp@'
- Delete the duplicate 'opp-microvolt' property of passive devfreq device
- Reorder the 'bus_xxx' device tree node alphabetically in 
exynos3250-rinato/monk.dts
- Reorder the 'bus_xxx' device tree node alphabetically in 
exynos4412-trats/odroidu3
- Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
  on rinato/monk/trats2/odroid-u3 board
- Add the log message if bus device is registered to devfreq framework 
successfully
- Add the reviewed-by tag from Krzysztof Kozlowski
- Add the tested-by tag from Anand Moon on Odroid U3
- Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS

Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
  when executing regulator_disable() because of only parent
  devfreq device has the regulator instance. After fixing it,
  the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
  after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
  DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
  on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3

Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.

 There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of this difference
among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
unique data of each bus in the devicetree file.

 In devicetree, each bus node has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.

For example,
- The bus of DMC block in exynos3250.dtsi are listed below:

bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <_dmc_opp_table>;
status = "disabled";
};

bus_dmc_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;

opp@5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
opp@1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
opp@13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <825000>;
};
opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
};

- Usage 

[PATCH v4 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Chanwoo Choi]

This patch adds the documentation for generic exynos bus frequency
driver.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 93 ++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
new file mode 100644
index ..e32daef328da
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -0,0 +1,93 @@
+* Generic Exynos Bus frequency device
+
+The Samsung Exynos SoC have many buses for data transfer between DRAM
+and sub-blocks in SoC. Almost Exynos SoC have the common architecture
+for buses. Generally, the each bus of Exynos SoC includes the source clock
+and power line and then is able to change the clock according to the usage
+of each buses on runtime. When gathering the usage of each buses on runtime,
+the driver uses the PPMU (Platform Performance Monitoring Unit) which
+is able to measure the current load of sub-blocks.
+
+There are a little different composition among Exynos SoC because each Exynos
+SoC has the different sub-blocks. So, this difference should be specified
+in devicetree file instead of each device driver. In result, this driver
+is able to support the bus frequency for all Exynos SoCs.
+
+Required properties for bus device:
+- compatible: Should be "samsung,exynos-bus".
+- clock-names : the name of clock used by the bus, "bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- operating-points-v2: the OPP table including frequency/voltage information
+  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- vdd-supply: the regulator to provide the buses with the voltage.
+- devfreq-events: the devfreq-event device to monitor the current utilization
+  of buses.
+
+Optional properties for bus device:
+- exynos,saturation-ratio: the percentage value which is used to calibrate
+   the performance count against total cycle count.
+
+Example1:
+   Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
+   power line (regulator). The MIF (Memory Interface) AXI bus is used to
+   transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
+
+   - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+
+   - MIF bus's frequency/voltage table
+   ---
+   |Lv| Freq   | Voltage |
+   ---
+   |L1| 5  |80   |
+   |L2| 10 |80   |
+   |L3| 134000 |80   |
+   |L4| 20 |825000   |
+   |L5| 40 |875000   |
+   ---
+
+Example2 :
+   The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
+   is listed below:
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = <_dmc CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <80>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <80>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <80>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <875000>;
+   };
+   };
+
+   Usage case to handle the frequency and voltage of bus on runtime
+   in exynos3250-rinato.dts is listed below:
+
+   _dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;  /* VDD_MIF */
+   status = "okay";
+   };
-- 
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/

[PATCH v4 03/20] ARM: dts: Add DMC bus node for Exynos3250

[Chanwoo Choi]

This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 SoC.
The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
SDRAM devices. The bus includes the OPP tables and the source clock for DMC
block.

Following list specifies the detailed relation between the clock and DMC block:
- The source clock of DMC block : div_dmc

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 18e3deffbf48..262b3b1995fd 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -701,6 +701,40 @@
clock-names = "ppmu";
status = "disabled";
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = <_dmc CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <80>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <80>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <80>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <875000>;
+   };
+   };
};
 };
 
-- 
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/

[PATCH v4 07/20] PM / devfreq: Show the related information according to governor type

[Chanwoo Choi]

This patch modifies the following sysfs entry of DEVFREQ framework
because the devfreq device using passive governor don't need the same
information of the devfreq device using rest governor.
- polling_interval: passive gov don't use the sampling rate.
- available_governors : passive gov don't be changed on runtime in this version.
- trans_stat  : passive governor don't support trans_stat in this 
version.

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 drivers/devfreq/devfreq.c | 31 +--
 drivers/devfreq/governor.h|  7 +++
 drivers/devfreq/governor_passive.c|  1 +
 drivers/devfreq/governor_performance.c|  1 +
 drivers/devfreq/governor_powersave.c  |  1 +
 drivers/devfreq/governor_simpleondemand.c |  1 +
 drivers/devfreq/governor_userspace.c  |  1 +
 include/linux/devfreq.h   |  2 ++
 8 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 78ea4cdaa82c..18ad956fec93 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -597,7 +597,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_init;
}
 
-   if (!strncmp(devfreq->governor_name, "passive", 7)) {
+   if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
struct devfreq *parent_devfreq =
((struct devfreq_passive_data *)data)->parent;
 
@@ -963,13 +963,23 @@ static ssize_t available_governors_show(struct device *d,
struct device_attribute *attr,
char *buf)
 {
-   struct devfreq_governor *tmp_governor;
+   struct devfreq *devfreq = to_devfreq(d);
ssize_t count = 0;
 
mutex_lock(_list_lock);
-   list_for_each_entry(tmp_governor, _governor_list, node)
+   if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
count += scnprintf([count], (PAGE_SIZE - count - 2),
-  "%s ", tmp_governor->name);
+  "%s ", devfreq->governor->name);
+   } else {
+   struct devfreq_governor *tmp_governor;
+
+   list_for_each_entry(tmp_governor, _governor_list, node) 
{
+   if (tmp_governor->type == DEVFREQ_GOV_PASSIVE)
+   continue;
+   count += scnprintf([count], (PAGE_SIZE - count - 2),
+  "%s ", tmp_governor->name);
+   }
+   }
mutex_unlock(_list_lock);
 
/* Truncate the trailing space */
@@ -1006,6 +1016,11 @@ static DEVICE_ATTR_RO(target_freq);
 static ssize_t polling_interval_show(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
+   struct devfreq *df = to_devfreq(dev);
+
+   if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+   return sprintf(buf, "Not Supported.\n");
+
return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
 }
 
@@ -1020,6 +1035,9 @@ static ssize_t polling_interval_store(struct device *dev,
if (!df->governor)
return -EINVAL;
 
+   if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+   return -EINVAL;
+
ret = sscanf(buf, "%u", );
if (ret != 1)
return -EINVAL;
@@ -1137,11 +1155,12 @@ static ssize_t trans_stat_show(struct device *dev,
int i, j;
unsigned int max_state = devfreq->profile->max_state;
 
+   if (max_state == 0 || devfreq->governor->type == DEVFREQ_GOV_PASSIVE)
+   return sprintf(buf, "Not Supported.\n");
+
if (!devfreq->stop_polling &&
devfreq_update_status(devfreq, devfreq->previous_freq))
return 0;
-   if (max_state == 0)
-   return sprintf(buf, "Not Supported.\n");
 
len = sprintf(buf, " From  :   To\n");
len += sprintf(buf + len, "   :");
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..43513a58f5bf 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -18,6 +18,13 @@
 
 #define to_devfreq(DEV)container_of((DEV), struct devfreq, dev)
 
+/* Devfreq governor type */
+#define DEVFREQ_GOV_ONDEMAND   0x1
+#define DEVFREQ_GOV_PERFORMANCE0x2
+#define DEVFREQ_GOV_POWERSAVE  0x3
+#define DEVFREQ_GOV_USERSPACE  0x4
+#define DEVFREQ_GOV_PASSIVE0x4
+
 /* Devfreq events */
 #define DEVFREQ_GOV_START  0x1
 #define DEVFREQ_GOV_STOP   0x2
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 7443ae4b92f9..adfdee9a9cd1 100644
--- 

[PATCH v4 08/20] PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor

[Chanwoo Choi]

This patch adds the support of bus frequency feature for sub-blocks which share
the one power line. If each bus depends on the power line, each bus is not able
to change the voltage by oneself. To optimize the power-consumption on runtime,
some buses using the same power line should change the source clock and
regulator at the same time. So, this patch uses the passive governor to support
the bus frequency for all buses which sharing the one power line.

For example,

Exynos3250 include the two power line for AXI buses as following:
: VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller)
  with the power (regulator).
: VDD_INT : INT (Internal) provide the various sub-blocks with the power
  (regulator).

Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC bus
use the power line. So, there is no any depencency between buese. But, in the
case of VDD_INT, various buses share the one power line of VDD_INT. We need to
make the depenency between buses. When using passive governor, there is no
problem to support the bus frequency as DVFS for all buses. One bus should be
operated as the parent bus device which gathering the current load of INT block
and then decides the new frequency with some governors except of passive
governor. After deciding the new frequency by the parent bus device, the rest
bus devices will change the each source clock according to new frequency of the
parent bus device.

- MIF (Memory Interface) block
: VDD_MIF |--- DMC

- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent)
  |--- PERIL
  |--- MFC
  |--- G3D
  |--- RIGHTBUS
  |--- FSYS
  |--- LCD0
  |--- PERIR
  |--- ISP
  |--- CAM

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 drivers/devfreq/Kconfig |   1 +
 drivers/devfreq/exynos/exynos-bus.c | 179 
 2 files changed, 144 insertions(+), 36 deletions(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index d03f635a93e1..88f7cc4539b8 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -79,6 +79,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
depends on ARCH_EXYNOS
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select DEVFREQ_GOV_PASSIVE
select DEVFREQ_EVENT_EXYNOS_PPMU
select PM_DEVFREQ_EVENT
select PM_OPP
diff --git a/drivers/devfreq/exynos/exynos-bus.c 
b/drivers/devfreq/exynos/exynos-bus.c
index f1bc20839650..d1c137ea22ca 100644
--- a/drivers/devfreq/exynos/exynos-bus.c
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -91,7 +91,7 @@ static int exynos_bus_get_event(struct exynos_bus *bus,
 }
 
 /*
- * Must necessary function for devfreq governor
+ * Must necessary function for devfreq simple-ondemand governor
  */
 static int exynos_bus_target(struct device *dev, unsigned long *freq, u32 
flags)
 {
@@ -205,57 +205,74 @@ static void exynos_bus_exit(struct device *dev)
dev_pm_opp_of_remove_table(dev);
 }
 
-static int exynos_bus_parse_of(struct device_node *np,
- struct exynos_bus *bus)
+/*
+ * Must necessary function for devfreq passive governor
+ */
+static int exynos_bus_passive_target(struct device *dev, unsigned long *freq,
+   u32 flags)
 {
-   struct device *dev = bus->dev;
-   unsigned long rate;
-   int i, ret, count, size;
+   struct exynos_bus *bus = dev_get_drvdata(dev);
+   struct dev_pm_opp *new_opp;
+   unsigned long old_freq, new_freq;
+   int ret = 0;
 
-   /* Get the clock to provide each bus with source clock */
-   bus->clk = devm_clk_get(dev, "bus");
-   if (IS_ERR(bus->clk)) {
-   dev_err(dev, "failed to get bus clock\n");
-   return PTR_ERR(bus->clk);
+   /* Get new opp-bus instance according to new bus clock */
+   rcu_read_lock();
+   new_opp = devfreq_recommended_opp(dev, freq, flags);
+   if (IS_ERR_OR_NULL(new_opp)) {
+   dev_err(dev, "failed to get recommed opp instance\n");
+   rcu_read_unlock();
+   return PTR_ERR(new_opp);
}
 
-   ret = clk_prepare_enable(bus->clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to get enable clock\n");
-   return ret;
-   }
+   new_freq = dev_pm_opp_get_freq(new_opp);
+   old_freq = dev_pm_opp_get_freq(bus->curr_opp);
+   rcu_read_unlock();
 
-   /* Get the freq/voltage OPP table to scale the bus frequency */
-   rcu_read_lock();
-   ret = dev_pm_opp_of_add_table(dev);
+   if (old_freq == new_freq)
+   return 0;
+
+   /* Change the frequency according to new OPP level */
+   mutex_lock(>lock);
+
+   ret = clk_set_rate(bus->clk, new_freq);
if (ret < 0) {
-   dev_err(dev, "failed to get OPP table\n");
-  

[PATCH v4 10/20] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line

[Chanwoo Choi]

This patch adds the detailed corrleation between sub-blocks and power line
for Exynos3250, Exynos4210 and Exynos4x12.

Signed-off-by: Chanwoo Choi 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index a251f9120561..f3a32b310dc7 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -51,6 +51,57 @@ Optional properties only for parent bus device:
 - exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
 
+Detailed correlation between sub-blocks and power line according to Exynos SoC:
+- In case of Exynos3250, there are two power line as following:
+   VDD_MIF |--- DMC
+
+   VDD_INT |--- LEFTBUS (parent device)
+   |--- PERIL
+   |--- MFC
+   |--- G3D
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- FSYS
+   |--- LCD0
+   |--- PERIR
+   |--- ISP
+   |--- CAM
+
+- In case of Exynos4210, there is one power line as following:
+   VDD_INT |--- DMC (parent device)
+   |--- LEFTBUS
+   |--- PERIL
+   |--- MFC(L)
+   |--- G3D
+   |--- TV
+   |--- LCD0
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- MFC(R)
+   |--- CAM
+   |--- FSYS
+   |--- GPS
+   |--- LCD0
+   |--- LCD1
+
+- In case of Exynos4x12, there are two power line as following:
+   VDD_MIF |--- DMC
+
+   VDD_INT |--- LEFTBUS (parent device)
+   |--- PERIL
+   |--- MFC(L)
+   |--- G3D
+   |--- TV
+   |--- IMAGE
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- MFC(R)
+   |--- CAM
+   |--- FSYS
+   |--- GPS
+   |--- LCD0
+   |--- ISP
+
 Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
-- 
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/

[PATCH v4 12/20] MAINTAINERS: Add samsung bus frequency driver entry

[Chanwoo Choi]

This patch adds the 'SAMSUNG BUS FREQUENCY DRIVER' entry to review the
patches as supporter. Patches will be picked up by DEVFREQ maintainer
on devfreq git repository.

Signed-off-by: Chanwoo Choi 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ff2d20173d98..89e645688a3c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3434,6 +3434,15 @@ F:   drivers/devfreq/devfreq-event.c
 F: include/linux/devfreq-event.h
 F: Documentation/devicetree/bindings/devfreq/event/
 
+SAMSUNG BUS FREQUENCY DRIVER
+M: Chanwoo Choi 
+L: linux...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
+S: Supported
+F: drivers/devfreq/exynos/exynos-bus.c
+F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+
 DEVICE NUMBER REGISTRY
 M: Torben Mathiasen 
 W: http://lanana.org/docs/device-list/index.html
-- 
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/

[PATCH v4 15/20] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
  When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4x12.dtsi | 106 ++
 1 file changed, 106 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index 99a0f4ca3d47..e5173107ed44 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -349,6 +349,112 @@
opp-hz = /bits/ 64 <26700>;
};
};
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_display: bus_display {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK160>;
+   clock-names = "bus";
+   operating-points-v2 = <_display_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK133>;
+   clock-names = "bus";
+   operating-points-v2 = <_fsys_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peri: bus_peri {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peri_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <90>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <925000>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <95>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <100>;
+   };
+   };
+
+   bus_display_opp_table: opp_table4 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   };
+   };
+
+   bus_fsys_opp_table: opp_table5 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   };
+
+   bus_peri_opp_table: opp_table6 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   };
 };
 
  {
-- 
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/

[PATCH v4 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210

[Chanwoo Choi]

This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has
one power line for all buses to translate data between DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- DMC/ACP clock for DMC (Dynamic Memory Controller)
- ACLK200 clock for LCD0
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD0/LCD1
- ACLK133 clock for FSYS/GPS
- GDL/GDR clock for LEFTBUS/RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210.dtsi | 159 ++
 1 file changed, 159 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index c1cb8df6da07..2d9b02967105 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -257,6 +257,165 @@
power-domains = <_lcd1>;
#iommu-cells = <0>;
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_acp: bus_acp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACP>;
+   clock-names = "bus";
+   operating-points-v2 = <_acp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peri: bus_peri {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peri_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK133>;
+   clock-names = "bus";
+   operating-points-v2 = <_fsys_opp_table>;
+   status = "disabled";
+   };
+
+   bus_display: bus_display {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK160>;
+   clock-names = "bus";
+   operating-points-v2 = <_display_opp_table>;
+   status = "disabled";
+   };
+
+   bus_lcd0: bus_lcd0 {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK200>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <1025000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <105>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <115>;
+   };
+   };
+
+   bus_acp_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   };
+   };
+
+   bus_peri_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@500 {
+   opp-hz = /bits/ 64 <500>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   };
+
+   bus_fsys_opp_table: opp_table4 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1000 {
+   opp-hz = /bits/ 64 

[PATCH v4 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Chanwoo Choi]

THis patch adds the bus device tree nodes for both MIF (Memory) and INT
(Internal) block to enable the bus frequency.

The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
bus is parent device in INT block using VDD_INT.

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 +
 arch/arm/boot/dts/exynos4412-trats2.dts | 47 +
 2 files changed, 94 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 7bd65026761e..cb7e54df6a23 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -109,6 +109,53 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_acp {
+   devfreq = <_dmc>;
+   status = "okay";
+};
+
+_c2c {
+   devfreq = <_dmc>;
+   status = "okay";
+};
+
+_leftbus {
+   devfreq-events = <_leftbus_3>, <_rightbus_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_rightbus {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_display {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_fsys {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_peri {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 92438eb6eec6..9f33c651e37a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -289,6 +289,53 @@
status = "okay";
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_acp {
+   devfreq = <_dmc>;
+   status = "okay";
+};
+
+_c2c {
+   devfreq = <_dmc>;
+   status = "okay";
+};
+
+_leftbus {
+   devfreq-events = <_leftbus_3>, <_rightbus_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_rightbus {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_display {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_fsys {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_peri {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
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/

[PATCH v4 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Chanwoo Choi]

This patch adds the bus device-tree nodes of INT (internal) block
to enable the bus frequency scaling. The following sub-blocks share
the VDD_INT power source:
- LEFTBUS (parent device)
- RIGHTBUS
- PERIL
- LCD0
- FSYS
- MCUISP / ISP
- MFC

The LEFTBUS is parent device with devfreq ondemand governor
and the rest of devices depend on the LEFTBUS device.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 2a1c22598fdc..c29d5533ec1f 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -154,6 +154,47 @@
status = "okay";
 };
 
+_leftbus {
+   devfreq-events = <_leftbus_3>, <_rightbus_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_rightbus {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_lcd0 {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_fsys {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mcuisp {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_isp {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_peril {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
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/

[PATCH v4 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
Exynos3250 has following AXI buses to translate data between
DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK400 clock for MCUISP
- ACLK266 clock for ISP
- ACLK200 clock for FSYS
- ACLK160 clock for LCD0
- ACLK100 clock for PERIL
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250.dtsi | 147 ++
 1 file changed, 147 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 262b3b1995fd..5cc98cf13173 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -735,6 +735,153 @@
opp-microvolt = <875000>;
};
};
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_lcd0: bus_lcd0 {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_160>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_200>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mcuisp: bus_mcuisp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_400_MCUISP>;
+   clock-names = "bus";
+   operating-points-v2 = <_mcuisp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_isp: bus_isp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_266>;
+   clock-names = "bus";
+   operating-points-v2 = <_isp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peril: bus_peril {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peril_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <90>;
+   };
+   opp@8000 {
+   opp-hz = /bits/ 64 <8000>;
+   opp-microvolt = <90>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <100>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <100>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <100>;
+   };
+   };
+
+   bus_mcuisp_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   };
+   

[PATCH v4 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU nodes

[Chanwoo Choi]

This patch adds the exynos4412-ppmu-common.dtsi to remove duplicate PPMU nodes
because exynos3250-rinato/monk, exynos4412-trats2/odroidu3 has the same
PPMU device tree node.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250-monk.dts   | 41 +---
 arch/arm/boot/dts/exynos3250-rinato.dts | 41 +---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  1 +
 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi   | 50 +
 arch/arm/boot/dts/exynos4412-trats2.dts | 41 +---
 5 files changed, 54 insertions(+), 120 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 456844a81189..a4e525e5e6e4 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -14,6 +14,7 @@
 
 /dts-v1/;
 #include "exynos3250.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
 #include 
 #include 
 #include 
@@ -464,46 +465,6 @@
status = "okay";
 };
 
-_dmc0 {
-   status = "okay";
-
-   events {
-   ppmu_dmc0_3: ppmu-event3-dmc0 {
-   event-name = "ppmu-event3-dmc0";
-   };
-   };
-};
-
-_dmc1 {
-   status = "okay";
-
-   events {
-   ppmu_dmc1_3: ppmu-event3-dmc1 {
-   event-name = "ppmu-event3-dmc1";
-   };
-   };
-};
-
-_leftbus {
-   status = "okay";
-
-   events {
-   ppmu_leftbus_3: ppmu-event3-leftbus {
-   event-name = "ppmu-event3-leftbus";
-   };
-   };
-};
-
-_rightbus {
-   status = "okay";
-
-   events {
-   ppmu_rightbus_3: ppmu-event3-rightbus {
-   event-name = "ppmu-event3-rightbus";
-   };
-   };
-};
-
  {
clock-frequency = <2400>;
 };
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index d6bb990ce931..2a1c22598fdc 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -14,6 +14,7 @@
 
 /dts-v1/;
 #include "exynos3250.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
 #include 
 #include 
 #include 
@@ -641,46 +642,6 @@
status = "okay";
 };
 
-_dmc0 {
-   status = "okay";
-
-   events {
-   ppmu_dmc0_3: ppmu-event3-dmc0 {
-   event-name = "ppmu-event3-dmc0";
-   };
-   };
-};
-
-_dmc1 {
-   status = "okay";
-
-   events {
-   ppmu_dmc1_3: ppmu-event3-dmc1 {
-   event-name = "ppmu-event3-dmc1";
-   };
-   };
-};
-
-_leftbus {
-   status = "okay";
-
-   events {
-   ppmu_leftbus_3: ppmu-event3-leftbus {
-   event-name = "ppmu-event3-leftbus";
-   };
-   };
-};
-
-_rightbus {
-   status = "okay";
-
-   events {
-   ppmu_rightbus_3: ppmu-event3-rightbus {
-   event-name = "ppmu-event3-rightbus";
-   };
-   };
-};
-
  {
clock-frequency = <2400>;
 };
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 395c3ca9601e..cda1ec86dfba 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include "exynos4412.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
 #include 
 
 / {
diff --git a/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi 
b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
new file mode 100644
index ..16e4b77d8cb1
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Device tree sources for Exynos4412 PPMU common device tree
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Chanwoo Choi 
+ *
+ * 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.
+ */
+
+_dmc0 {
+   status = "okay";
+
+   events {
+  ppmu_dmc0_3: ppmu-event3-dmc0 {
+  event-name = "ppmu-event3-dmc0";
+  };
+   };
+};
+
+_dmc1 {
+   status = "okay";
+
+   events {
+  ppmu_dmc1_3: ppmu-event3-dmc1 {
+  event-name = "ppmu-event3-dmc1";
+  };
+   };
+};
+
+_leftbus {
+   status = "okay";
+
+   events {
+  ppmu_leftbus_3: ppmu-event3-leftbus {
+  event-name = "ppmu-event3-leftbus";
+  };
+   };
+};
+
+_rightbus {
+   status = "okay";
+
+   events {
+  ppmu_rightbus_3: ppmu-event3-rightbus {
+  event-name = "ppmu-event3-rightbus";
+  };
+   };

[PATCH v4 19/20] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3

[Chanwoo Choi]

This patch expands the voltage range of buck1/3 regulator due to as following:
- MIF (Memory Interface) bus frequency needs the range of '900 - 1050 mV'.
- INT (Internal) bus frequency needs the range of '900 - 1000 mV'.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index cda1ec86dfba..7bd65026761e 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -356,8 +356,8 @@
 
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <105>;
regulator-always-on;
regulator-boot-on;
};
@@ -372,7 +372,7 @@
 
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
-   regulator-min-microvolt = <100>;
+   regulator-min-microvolt = <90>;
regulator-max-microvolt = <100>;
regulator-always-on;
regulator-boot-on;
-- 
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/

[PATCH v4 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Chanwoo Choi]

This patch adds the bus nodes using VDD_MIF for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data
between DRAM and DMC/ACP/C2C.

Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4x12.dtsi | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index 84a23f962946..99a0f4ca3d47 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -281,6 +281,74 @@
clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
#iommu-cells = <0>;
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_acp: bus_acp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACP>;
+   clock-names = "bus";
+   operating-points-v2 = <_acp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_c2c: bus_c2c {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_C2C>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <90>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <90>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <90>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <95>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <105>;
+   };
+   };
+
+   bus_acp_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   };
+   };
 };
 
  {
-- 
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/

[PATCH v4 05/20] PM / devfreq: Add new passive governor

[Chanwoo Choi]

This patch adds the new passive governor for DEVFREQ framework. The following
governors are already present and used for DVFS (Dynamic Voltage and Frequency
Scaling) drivers. The following governors are independently used for one device
driver which don't give the influence to other device drviers and also don't
receive the effect from other device drivers.
- ondemand / performance / powersave / userspace

The passive governor depends on operation of parent driver with specific
governos extremely and is not able to decide the new frequency by oneself.
According to the decided new frequency of parent driver with governor,
the passive governor uses it to decide the appropriate frequency for own
device driver. The passive governor must need the following information
from device tree:
- the source clock and OPP tables
- the instance of parent device

For exameple,
there are one more devfreq device drivers which need to change their source
clock according to their utilization on runtime. But, they share the same
power line (e.g., regulator). So, specific device driver is operated as parent
with ondemand governor and then the rest device driver with passive governor
is influenced by parent device.

Suggested-by: Myungjoo Ham 
Signed-off-by: Chanwoo Choi 
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon 
---
 drivers/devfreq/Kconfig|   9 
 drivers/devfreq/Makefile   |   1 +
 drivers/devfreq/devfreq.c  |  47 
 drivers/devfreq/governor_passive.c | 108 +
 include/linux/devfreq.h|  15 ++
 5 files changed, 180 insertions(+)
 create mode 100644 drivers/devfreq/governor_passive.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 55ec774f794c..d03f635a93e1 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
  Otherwise, the governor does not change the frequnecy
  given at the initialization.
 
+config DEVFREQ_GOV_PASSIVE
+   tristate "Passive"
+   help
+ Sets the frequency by other governors (simple_ondemand, performance,
+ powersave, usersapce) of a parent devfreq device. This governor
+ always has the dependency on the chosen frequency from paired
+ governor. This governor does not change the frequency by oneself
+ through sysfs entry.
+
 comment "DEVFREQ Drivers"
 
 config ARM_EXYNOS_BUS_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 375ebbb4fcfb..f81c313b4b79 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)   += 
governor_simpleondemand.o
 obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)  += governor_performance.o
 obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
 obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
+obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)  += governor_passive.o
 
 # DEVFREQ Drivers
 obj-$(CONFIG_ARCH_EXYNOS)  += exynos/
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 984c5e9e7bdd..15e58779e4c0 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -190,6 +190,31 @@ static struct devfreq_governor 
*find_devfreq_governor(const char *name)
 
 /* Load monitoring helper functions for governors use */
 
+static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq)
+{
+   struct devfreq *passive;
+   unsigned long rate;
+   int ret;
+
+   list_for_each_entry(passive, >passive_dev_list, passive_node) {
+   if (!passive->governor)
+   continue;
+   rate = freq;
+
+   ret = passive->governor->get_target_freq(passive, );
+   if (ret)
+   return ret;
+
+   ret = passive->profile->target(passive->dev.parent, , 0);
+   if (ret)
+   return ret;
+
+   passive->previous_freq = rate;
+   }
+
+   return 0;
+}
+
 /**
  * update_devfreq() - Reevaluate the device and configure frequency.
  * @devfreq:   the devfreq instance.
@@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
 
+   if (!list_empty(>passive_dev_list)
+   && devfreq->previous_freq > freq)
+   update_devfreq_passive(devfreq, freq);
+
err = devfreq->profile->target(devfreq->dev.parent, , flags);
if (err)
return err;
 
+   if (!list_empty(>passive_dev_list)
+   && devfreq->previous_freq < freq)
+   update_devfreq_passive(devfreq, freq);
+
if (devfreq->profile->freq_table)
if (devfreq_update_status(devfreq, freq))
dev_err(>dev,
@@ -442,6 +475,10 @@ static void _remove_devfreq(struct devfreq *devfreq)

[PATCH v4 11/20] PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver

[Chanwoo Choi]

This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/Kconfig  |   22 -
 drivers/devfreq/exynos/Makefile  |2 -
 drivers/devfreq/exynos/exynos4_bus.c | 1055 --
 drivers/devfreq/exynos/exynos4_bus.h |  110 
 drivers/devfreq/exynos/exynos5_bus.c |  431 --
 drivers/devfreq/exynos/exynos_ppmu.c |  119 
 drivers/devfreq/exynos/exynos_ppmu.h |   86 ---
 7 files changed, 1825 deletions(-)
 delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
 delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
 delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
 delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
 delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 88f7cc4539b8..e82b1d8cd200 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -91,28 +91,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
  and adjusts the operating frequencies and voltages with OPP support.
  This does not yet operate with optimal voltages.
 
-config ARM_EXYNOS4_BUS_DEVFREQ
-   bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
-   depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
!ARCH_MULTIPLATFORM
-   select DEVFREQ_GOV_SIMPLE_ONDEMAND
-   select PM_OPP
-   help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
-config ARM_EXYNOS5_BUS_DEVFREQ
-   tristate "ARM Exynos5250 Bus DEVFREQ Driver"
-   depends on SOC_EXYNOS5250
-   select DEVFREQ_GOV_SIMPLE_ONDEMAND
-   select PM_OPP
-   help
- This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int).
- It reads PPMU counters of memory controllers and adjusts the
- operating frequencies and voltages with OPP support.
-
 config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
depends on ARCH_TEGRA_124_SOC
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 4ec06d322996..bc695ad81c7d 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,4 +1,2 @@
 # Exynos DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos_ppmu.o exynos4_bus.o
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da9509205169..
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham 
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * 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.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT   120 /* 1.2V */
-
-enum exynos4_busf_type {
-   TYPE_BUSF_EXYNOS4210,
-   TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO   40
-
-enum busclk_level_idx {
-   LV_0 = 0,
-   LV_1,
-   LV_2,
-   LV_3,
-   LV_4,
-   _LV_END
-};
-
-enum exynos_ppmu_idx {
-   PPMU_DMC0,
-   PPMU_DMC1,
-   PPMU_END,
-};
-
-#define EX4210_LV_MAX  LV_2
-#define EX4x12_LV_MAX  LV_4
-#define EX4210_LV_NUM  (LV_2 + 1)
-#define EX4x12_LV_NUM  (LV_4 + 1)
-
-/**
- * struct busfreq_opp_info - opp information for bus
- * @rate:  Frequency in hertz
- * @volt:  Voltage in microvolts corresponding to this OPP
- */
-struct busfreq_opp_info {
-   unsigned long rate;
-   unsigned long volt;
-};
-
-struct busfreq_data {
-   enum exynos4_busf_type type;
-   struct device *dev;
-   struct devfreq *devfreq;
-   bool disabled;
-   struct regulator *vdd_int;
-   struct regulator *vdd_mif; /* Exynos4412/4212 only */
-   struct busfreq_opp_info curr_oppinfo;
-   struct busfreq_ppmu_data ppmu_data;
-
-   struct 

[PATCH v4 09/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor

[Chanwoo Choi]

This patch updates the documentation for passive bus devices and adds the
detailed example of Exynos3250.

Signed-off-by: Chanwoo Choi 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 250 -
 1 file changed, 247 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index e32daef328da..a251f9120561 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -8,22 +8,46 @@ of each buses on runtime. When gathering the usage of each 
buses on runtime,
 the driver uses the PPMU (Platform Performance Monitoring Unit) which
 is able to measure the current load of sub-blocks.
 
+The Exynos SoC includes the various sub-blocks which have the each AXI bus.
+The each AXI bus has the owned source clock but, has not the only owned
+power line. The power line might be shared among one more sub-blocks.
+So, we can divide into two type of device as the role of each sub-block.
+There are two type of bus devices as following:
+- parent bus device
+- passive bus device
+
+Basically, parent and passive bus device share the same power line.
+The parent bus device can only change the voltage of shared power line
+and the rest bus devices (passive bus device) depend on the decision of
+the parent bus device. If there are three blocks which share the VDD_xxx
+power line, Only one block should be parent device and then the rest blocks
+should depend on the parent device as passive device.
+
+   VDD_xxx |--- A block (parent)
+   |--- B block (passive)
+   |--- C block (passive)
+
 There are a little different composition among Exynos SoC because each Exynos
 SoC has the different sub-blocks. So, this difference should be specified
 in devicetree file instead of each device driver. In result, this driver
 is able to support the bus frequency for all Exynos SoCs.
 
-Required properties for bus device:
+Required properties for all bus devices:
 - compatible: Should be "samsung,exynos-bus".
 - clock-names : the name of clock used by the bus, "bus".
 - clocks : phandles for clock specified in "clock-names" property.
 - operating-points-v2: the OPP table including frequency/voltage information
   to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+
+Required properties only for parent bus device:
 - vdd-supply: the regulator to provide the buses with the voltage.
 - devfreq-events: the devfreq-event device to monitor the current utilization
   of buses.
 
-Optional properties for bus device:
+Required properties only for passive bus device:
+- devfreq: the parent bus device.
+
+Optional properties only for parent bus device:
 - exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
 
@@ -32,7 +56,20 @@ Example1:
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
 
-   - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+   - MIF (Memory Interface) block
+   : VDD_MIF |--- DMC (Dynamic Memory Controller)
+
+   - INT (Internal) block
+   : VDD_INT |--- LEFTBUS (parent device)
+ |--- PERIL
+ |--- MFC
+ |--- G3D
+ |--- RIGHTBUS
+ |--- FSYS
+ |--- LCD0
+ |--- PERIR
+ |--- ISP
+ |--- CAM
 
- MIF bus's frequency/voltage table
---
@@ -45,6 +82,24 @@ Example1:
|L5| 40 |875000   |
---
 
+   - INT bus's frequency/voltage table
+   --
+   |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL  ||VDD_INT |
+   | name|   |LCD0|   |   |   |||
+   | |   |FSYS|   |   |   |||
+   | |   |MFC |   |   |   |||
+   --
+   |Mode |*parent|passive |passive|passive|passive|||
+   --
+   |Lv   |Frequency   ||Voltage |
+   --
+   |L1   |5  |5   |5  |5  |5  ||90  |
+   |L2   |8  |8   |8  |8  |8  ||90  |
+   |L3   |10 |10  |10 |10 |10 ||100 |
+   |L4   |134000 |134000  |20 |20 |   ||100 |
+   |L5   |20 |20  |40 |30 |   ||100 |
+   --
+
 Example2 :
The bus of DMC (Dynamic Memory Controller) block in 

Re: [lkp] [x86/irq] 4c24cee6b2: IP-Config: Auto-configuration of network failed

[Jiang Liu]

Hi Ying,
Thanks for reporting this issue. But I couldn't figure
out what's wrong with this commit. And there's no error or
warning messages in the attached dmesg file. Are there other
systems reporting the same issue?
Thanks,
Gerry

On 2015/12/11 15:49, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
> commit 4c24cee6b2aeaee3dab896f76fef4fe79d9e4183 ("x86/irq: Enhance 
> __assign_irq_vector() to rollback in case of failure")
> 
> 
> ++++
> || 6dd7cb991f | 4c24cee6b2 |
> ++++
> | boot_successes | 6  | 0  |
> | boot_failures  | 0  | 8  |
> | IP-Config:Auto-configuration_of_network_failed | 0  | 6  |
> | BUG:kernel_boot_hang   | 0  | 2  |
> ++++
> 
> It appears that the Ethernet card doesn't work properly after your patch.
> 
> [   15.342990] Waiting up to 110 more seconds for network.
> [   25.346987] Waiting up to 100 more seconds for network.
> [   35.350995] Waiting up to 90 more seconds for network.
> [   45.350993] Waiting up to 80 more seconds for network.
> [   55.351006] Waiting up to 70 more seconds for network.
> [   65.350992] Waiting up to 60 more seconds for network.
> [   75.355017] Waiting up to 50 more seconds for network.
> [   85.359009] Waiting up to 40 more seconds for network.
> [   95.363009] Waiting up to 30 more seconds for network.
> [  305.883015] Waiting up to 20 more seconds for network.
> [  315.887002] Waiting up to 10 more seconds for network.
> [  325.887524] Sending DHCP requests .. timed out!
> [  417.893036] IP-Config: Auto-configuration of network failed
> [  417.893852] ALSA device list:
> [  417.894270]   No soundcards found.
> [  417.899649] Freeing unused kernel memory: 2884K (82574000 - 
> 82845000)
> 
> 
> 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] sched/fair: fix mul overflow on 32-bit systems

[Yuyang Du]

On Fri, Dec 11, 2015 at 05:57:51PM +, Morten Rasmussen wrote:
> > >>> if (atomic_long_read(_rq->removed_load_avg)) {
> > >>> -   long r = atomic_long_xchg(_rq->removed_load_avg, 0);
> > >>> +   s64 r = atomic_long_xchg(_rq->removed_load_avg, 0);
> > >>> sa->load_avg = max_t(long, sa->load_avg - r, 0);
> > >>> sa->load_sum = max_t(s64, sa->load_sum - r * 
> > >>> LOAD_AVG_MAX, 0);
> > >>
> > >> This makes sense, because sched_avg::load_sum is u64.
> 
> A single removed nice=-20 task should be sufficient to cause the
> overflow.

Oh yes, it was a wreck, sorry.
 
> > >>> if (atomic_long_read(_rq->removed_util_avg)) {
> > >>> -   long r = atomic_long_xchg(_rq->removed_util_avg, 0);
> > >>> +   s64 r = atomic_long_xchg(_rq->removed_util_avg, 0);
> > >>> sa->util_avg = max_t(long, sa->util_avg - r, 0);
> > >>> sa->util_sum = max_t(s32, sa->util_sum - r * 
> > >>> LOAD_AVG_MAX, 0);
> > >>> }
> > >>
> > >> However sched_avg::util_sum is u32, so this is still wrecked.
> > > 
> > > I seems to have wrecked that in:
> > > 
> > >   006cdf025a33 ("sched/fair: Optimize per entity utilization tracking")
> > > 
> > > maybe just make util_load u64 too?
> 
> It isn't as bad, but the optimization does increase the normal range
> (not guaranteed) for util_sum from 47742 to
> scale_down(SCHED_LOAD_SCALE)*47742 (= 1024*47742, unless you mess with
> the scaling).
> 
> > Is there any guarantee that the final result of expression 'util_sum - r * 
> > LOAD_AVG_MAX' always can be represented by s32?
> > 
> > If yes, than we could just do this:
> > max_t(s32, (u64)sa->util_sum - r * LOAD_AVG_MAX, 0)
> 
> In most cases 'r' shouldn't exceed 1024 and util_sum not significantly
> exceed 1024*47742, but in extreme cases like spawning lots of new tasks
> it may potentially overflow 32 bit. Newly created tasks contribute
> 1024*47742 each to the rq util_sum, which means that more than ~87 new
> tasks on a single rq will get us in trouble I think.
> 
> Without Peter's optimization referenced above, that number should
> increase to ~87k tasks as each task only contributed 47742 before, but
> 'r' could still cause 32-bit overflow if we remove more than ~87 newly
> created tasks in one go. But I'm not sure if that is a situation we
> should worry about?
> 
> I think we have to either make util_sum u64 too or look at the
> optimizations again.

Both can workaround the issue with additional overhead. But I suspectthey
will end up going in the wrong direction for util_avg. The question is a
big util_sum (much bigger than 1024) may not be in a right range for it
to be used in load balancing.

The problem is that it is not so good to initiate a new task's util_avg
to 1024. At least, it makes much less sense than a new task's load_avg
being initiated to its full weight. Because the top util_avg should be
well bounded by 1024 - the CPU's full utilization.

So, maybe give the initial util_sum to an average of its cfs_rq, like:
cfs_rq->avg.util_sum / cfs_rq->load.weight * task->load.weight

And make sure that initial value's is bounded on various conditions.


Thanks,
Yuyang 
--
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/RFT PATCH] watchdog: Move watchdog device creation to watchdog_dev.c

[Guenter Roeck]

On 12/13/2015 02:02 PM, Damien Riegel wrote:

On Mon, Dec 07, 2015 at 09:41:03PM +0100, Wim Van Sebroeck wrote:

Hi All,


On 12/07/2015 08:15 AM, Damien Riegel wrote:

On Sun, Dec 06, 2015 at 11:51:41AM -0800, Guenter Roeck wrote:

The watchdog character device s currently created in
watchdog_dev.c, and the watchdog device in watchdog_core.c. This
results in cross-dependencies, as the device creation needs to
know the watchdog character device number.

On top of that, the watchdog character device is created before
the watchdog device is created. This can result in race conditions
if the watchdog device node is accessed before the watchdog device
has been created.

To solve the problem, move watchdog device creation into
watchdog_dev.c, and create the watchdog device prior to creating
its device node. Also move device class creation into
watchdog_dev.c, since this is now the only place where the
watchdog class is needed.

Inspired by an earlier patch set from Damien Riegel.

Cc: Damien Riegel 
Signed-off-by: Guenter Roeck  --- Hi Damien,

I think this approach would be a bit better. The watchdog device
isn't really used in the watchdog core code, so it is better
created in watchdog_dev.c. That also fits well with other pending
changes, such as sysfs attribute support, and my attempts to move
the ref/unref functions completely into the watchdog core. As a
side effect, it also cleans up the error path in
__watchdog_register_device().

What do you think ?


Hi Guenter,

Like the idea, but I don't really get the separation. For instance,
you move watchdog_class in watchdog_dev.c but you keep watchdog_ida
in watchdog_core.c whereas it is only used for device
creation/deletion.


The class is watchdog driver internal, and it is device related, so
I think it made sense to move it to watchdog_dev.c. On top of that,
it will be needed there if/when we introduce sysfs attributes.

The watchdog id can be determined by obtaining an id using ida, or
it can be provided through the watchdog alias. The operation to get
it is not device related, and it is not straightforward to obtain
it, so I thought it makes sense to keep the code in watchdog_core.c.

Of course a lot of it is personal preference.



Let me go back to how I saw the design when I created the generic
watchdog framework: When using watchdog device drivers we need to be
able to support the /dev/watchdog system. I also foresaw that we
should have a sysfs interface and I saw the future for watchdog
devices that you should be able to choose between the 2 different
systems. You should be able to use only the /dev/watchdog interfacing,
but you should also be able to use both a sysfs interface and a
/dev/watchdog interface and it should even be possible to have only a
sysfs interface in certain embedded devices. So that's why I split the
watchdog framework over 3 files: core code, the /dev/watchdog
interfacing and the sysfs code. Since I want to have compiled code
small enough when choosing either /Dev/watchdog or sysfs or both this
sounded the most logical thing to do (Unless you have a single file
full of #ifdef-ery that becomes unreadable).

So I do not agree to have sysfs code in watchdog_dev.c . It belongs in
watchdog_sysfs.c imho. If someone has a better idea, I'll be glad to
listen to it and see what the benefits are. But I want a clean system
for excluding both /dev/ (current watchdog_dev.c) and/or sysfs
(watchdog_sysfs.c) in the future. Off-course the current behaviour is
to have the /dev/ interface and have the option to add sysfs
attributes.


I agree that keeping sysfs code separate makes sense, as someone might
want to not use it.


I am not really sure about that. I don't recall a similar concern with
any other subsystem.

Anyway, sure, we can move the code to another file. Sure, we can add a
configuration option. That means we'll also need to make several functions
non-static, and possibly move some functions out of watchdog_dev.c
into yet another file. But we'll need some guidance for that and an idea
what is going to be acceptable.


The question is: can we make the /dev/watchdog entries optional ? That
would break the compatibility, right? Imho, it would be saner to keep
only one way to interact with watchdogs (ie. keep /dev/watchdog as is
and don't make it optional, and sysfs read-only and eventually
optional). I think that question should be answered before we can decide
how we want to split the code between watchdog_dev.c and watchdog_core.c



All I know for my part is that all pending structural enhancements in one
way or another depend on the assumption that the character device and the
sysfs (kernel) device both exist. I have not been able to find any code
in the kernel where cdev_add is not associated with device_create, so I
don't even know if cdev_add without device_create is even possible.
The current code in watchdog_dev.c definitely depends on watchdog->dev,
though not deeply (it uses it for some dev_ messages). If that dependency

linux-next: Tree for Dec 14

[Stephen Rothwell]

Hi all,

Changes since 20151211:

The net-next tree gained a conflict against the pci tree.

The drm-misc tree gained conflicts against the drm-intel and Linus' trees.

The block tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 5241
 5871 files changed, 211929 insertions(+), 90370 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), I do an x86_64 modules_install followed by builds
for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc,
sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 231 trees (counting Linus' and 36 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 (fc89182834db Merge tag 'nfs-for-4.4-3' of 
git://git.linux-nfs.org/projects/trondmy/linux-nfs)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (3d84ba362b60 ARC: dw2 unwind: Reinstante 
unwinding out of modules)
Merging arm-current/fixes (f5e985580978 ARM: 8475/1: SWP emulation: Restore 
original *data when failed)
Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2)
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 (dc9c41bd9ece Revert "powerpc/eeh: Don't unfreeze 
PHB PE after reset")
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (2c302e7e4105 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging net/master (6d13cab4abec Merge branch 'mpls-fixes')
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless 
unnitialized variable warnings)
Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups 
on boot)
Merging mac80211/master (b7bb11000860 rfkill: copy the name into the rfkill 
struct)
Merging sound-current/for-linus (5328e1ea87fb ALSA: hda/ca0132 - quirk for 
Alienware 17 2015)
Merging pci-current/for-linus (5bd242f824e2 Revert "PCI: hisi: Add HiSilicon 
SoC Hip05 PCIe driver")
Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3)
Merging tty.current/tty-linus (9ce119f318ba tty: Fix GPF in flush_to_ldisc())
Merging usb.current/usb-linus (ad87e03213b5 USB: add quirk for devices with 
broken LPM)
Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no 
DMA controller set)
Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon 
flash loader USB ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (9225c0b7b976 staging: lustre: 
echo_copy.._lsm() dereferences userland pointers directly)
Merging char-misc.current/char-misc-linus (e8c77bda05e5 fpga manager: Fix 
firmware resource leak on error)
Merging input-current/for-linus (fd18ab89166a Input: sun4i-lradc-keys - fix 
typo in binding documentation)
Merging crypto-current/master (70d906bc1750 crypto: skcipher - Copy iv from 
desc even for 0-len walks)
Merging ide/master (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (ae5515d66362 Revert: "vfio: Include No-IOMMU 

Re: [git pull] drm for 4.4-rc1

[Stefan Lippers-Hollmann]

Hi

On 2015-12-10, Daniel Vetter wrote:
> On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote:
> > On 2015-11-09, Dave Airlie wrote:
[...]
> > This patch seems to introduce a regression for i915 in Linus' 
> > v4.4-rc4-60-g9a0f76f, relative to v4.3 (and 4.3.1), on a sandy-bridge 
> > (Intel DH67CL) system with a single HDMI connected monitor (Medion MD20094)
> > attached. Immediately after the modeswitch, the monitor switches off and 
> > stays off. Nothing catches my eyes in dmesg or Xorg.0.log, but bisecting 
> > the issue points me at:
> > 
> > 237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit
> > commit 237ed86c693d8a8e4db476976aeb30df4deac74b
> > Author: Sonika Jindal 
> > Date:   Tue Sep 15 09:44:20 2015 +0530
> > 
> > drm/i915: Check live status before reading edid
[...]

This is strange, after connecting a different monitor (Fujitsu-Siemens 
Scaleoview D19-1) as a second screen via DVI, both monitors came up fine
and even after removing it (and reverting everything to the status quo 
ante), this HDMI connected Medion MD20094 monitor continues to work on
the previously broken sandy-bridge DH67CL mainboard.
Despite this problem being 100% reproducable and bisectable before, 
including multiple power cycles and replacing the HDMI cable, I have not 
been able to reproduce the issue again.

> A few things to test:
> - How does that screen fare on a working machine? Would tell us if the
>   issue is with the sink or the source.

It is working fine on a Baytrail-D (ASRock Q1900DC-ITX) and an ivy-bridge
(Gigabyte GA-H77M-D3H r1.1) system - and now on the previously affected
sandy-bridge system (Intel DH67CL) as well.

> - Please boot up with drm.debug=0xe on a working and broken kernel, grab
>   dmesg for both.

dmesg-v4.4-rc4-113-g0bd0f1e-working.gz is attached, unfortunately I'm no
longer able to reproduce the previous failure (tested with easy of the
bisection steps, identical kernel binaries as before, and v4.4-rc5 as 
well), so I can't provide a broken trace.

> - Extending the timeout magic might be worth a shot like in the below
>   patch. Crank up retry if it doesn't help.
[...]

I can only imagine that it was right beyond the brink of the timeout 
before and something had a lasting, but probably subtile, effect on the 
timing after temporarily connecting the second screen; it is working now.

On 2015-12-10, Jani Nikula wrote:
[...]
> The very first thing to do is to ensure you've tried v4.4-rc4, which
> contains

I tested both plain v4.4-rc4 and v4.4-rc4-60-g9a0f76f

> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a
> Author: Imre Deak 
> Date:   Fri Nov 27 18:55:29 2015 +0200
> 
> drm/i915: take a power domain reference while checking the HDMI live 
> status

both containing this patch.


Thanks a lot and sorry for your trouble, I'll report back if anything
changes - or if I can reproduce the problem again.

Regards
Stefan Lippers-Hollmann

dmesg-v4.4-rc4-113-g0bd0f1e-working.gz
Description: application/gzip

[lkp] [fs] 2e9d30b4bd: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018

[kernel test robot]

FYI, we noticed the below changes on

git://internal_merge_and_test_tree 
revert-8ecb4258a962d2c917ed21e677a7032711c925bb-2e9d30b4bd5f390796313567371b70fbf1966e73
commit 2e9d30b4bd5f390796313567371b70fbf1966e73 ("fs: make hugetlbfs/inode.c 
explicitly non-modular")


++++
|| cb5bdfcd1a | 2e9d30b4bd |
++++
| boot_successes | 2  | 0  |
| boot_failures  | 10 | 10 |
| IP-Config:Auto-configuration_of_network_failed | 10 | 2  |
| BUG:unable_to_handle_kernel| 0  | 8  |
| Oops   | 0  | 8  |
| RIP:__lock_acquire | 0  | 8  |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 8  |
| backtrace:do_mount | 0  | 8  |
| backtrace:SyS_mount| 0  | 8  |
++++



[9.212200] systemd-sysv-generator[126]: Ignoring K02urandom symlink in 
rc6.d, not generating urandom.service.
[9.212226] systemd-sysv-generator[126]: Ignoring K07hwclock.sh symlink in 
rc6.d, not generating hwclock.service.
[9.212258] systemd-sysv-generator[126]: Ignoring K01watchdog symlink in 
rc6.d, not generating watchdog.service.
[9.597704] BUG: unable to handle kernel NULL pointer dereference at 
0018
[9.599081] IP: [] __lock_acquire+0x160/0x1a3f
[9.600030] PGD 1b6a7067 PUD 1b711067 PMD 0 
[9.600942] Oops:  [#1] PREEMPT DEBUG_PAGEALLOC 
[9.601890] Modules linked in:
[9.602481] CPU: 0 PID: 139 Comm: mount Not tainted 4.4.0-rc4-9-g2e9d30b 
#1
[9.603625] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[9.604965] task: 88001bcc ti: 88001b72 task.ti: 
88001b72
[9.615944] RIP: 0010:[]  [] 
__lock_acquire+0x160/0x1a3f
[9.617290] RSP: 0018:88001b723890  EFLAGS: 00010002
[9.618092] RAX: 0046 RBX:  RCX: 
[9.619104] RDX:  RSI:  RDI: 0018
[9.620116] RBP: 88001b723960 R08: 0001 R09: 0001
[9.621157] R10: 88001b723980 R11: 1e27 R12: 
[9.622170] R13: 88001bcc R14: 0018 R15: 0001
[9.623175] FS:  7f77a46bb840() GS:9322() 
knlGS:
[9.624416] CS:  0010 DS:  ES:  CR0: 80050033
[9.625264] CR2: 0018 CR3: 1b703000 CR4: 06f0
[9.626268] Stack:
[9.626673]  0400 0002 88001bcc 
0002
[9.628089]  9297f5b7 0001 8800 

[9.629496]  88001bcc 8800 928ae160 
88001bcc
[9.630941] Call Trace:
[9.631404]  [] ? deactivate_slab+0x41c/0x919
[9.632286]  [] ? mark_held_locks+0x5e/0x74
[9.633136]  [] ? get_page_from_freelist+0x819/0xd4f
[9.634082]  [] lock_acquire+0x121/0x1c2
[9.634904]  [] ? lock_acquire+0x121/0x1c2
[9.635739]  [] ? deactivate_slab+0x41c/0x919
[9.636622]  [] _raw_spin_lock+0x32/0x41
[9.637453]  [] ? deactivate_slab+0x41c/0x919
[9.638316]  [] deactivate_slab+0x41c/0x919
[9.639162]  [] ? print_context_stack+0x6a/0xb6
[9.640040]  [] ? preempt_count_sub+0x34/0x3f
[9.640945]  [] ? dump_trace+0x28a/0x2a2
[9.641761]  [] ? hugetlbfs_alloc_inode+0x99/0xcc
[9.642667]  [] ? hugetlbfs_alloc_inode+0x99/0xcc
[9.643571]  [] ? save_stack_trace+0x2a/0x45
[9.61]  [] ? set_track+0x63/0xd9
[9.645247]  [] ___slab_alloc+0x60b/0x658
[9.646226]  [] ? deactivate_slab+0x5/0x919
[9.647112]  [] ? ___slab_alloc+0x60b/0x658
[9.648123]  [] ? hugetlbfs_alloc_inode+0x99/0xcc
[9.649058]  [] ? __lock_is_held+0x3b/0x56
[9.649917]  [] __slab_alloc+0x44/0x78
[9.650955]  [] ? ___slab_alloc+0x5/0x658
[9.651942]  [] ? __slab_alloc+0x44/0x78
[9.653128]  [] ? hugetlbfs_alloc_inode+0x99/0xcc
[9.654030]  [] kmem_cache_alloc+0xb0/0x2e5
[9.654864]  [] ? hugetlbfs_alloc_inode+0x99/0xcc
[9.655749]  [] ? hugetlbfs_parse_options+0x2ae/0x2ae
[9.656911]  [] hugetlbfs_alloc_inode+0x99/0xcc
[9.657785]  [] ? hugetlbfs_parse_options+0x2ae/0x2ae
[9.658963]  [] alloc_inode+0x1d/0x94
[9.659745]  [] new_inode_pseudo+0x11/0x58
[9.660580]  [] new_inode+0x16/0x2d
[9.661396]  [] hugetlbfs_fill_super+0x168/0x237
[9.662310]  [] mount_nodev+0x64/0xa1
[9.663106]  [] hugetlbfs_mount+0x18/0x1a
[9.663943]  [] 

Re: percpu irq APIs and perf

[Vineet Gupta]

On Friday 11 December 2015 11:28 PM, Marc Zyngier wrote:
>>> But auto-enabling cannot be done from a single CPU. It can only be done
>>> >> from the core that is going to be delivered that interrupt. This
>>> >> requires access to registers that are simply not available to other CPUs.
>> > 
>> > I'm not talking about eliminating enable_percpu_irq() call from all cores 
>> > and
>> > still getting the auto-enable semantics. What I mean is doing the 
>> > equivalent of
>> > 
>> >  irq_set_status_flags(irq, IRQ_NOAUTOEN);
>> > 
>> > from within request_percpu_irq_xxx() based on an additional arg (vs. doing 
>> > it
>> > aprioiri outside).
>> > 
>> > OTOH, thinking a bit more abt this, I think the current semantics of 
>> > auto-disable
>> > w/o any arg is just fine. Most percpu irqs in general purpose drivers 
>> > would want
>> > the auto-disable anyways. Only for core irws such as timer / IPI etc do we 
>> > want
>> > auto-enable.
> So assuming we can do this (forgetting about any form of HW limitation):
> CPU0 request the per-CPU IRQ with an AUTOEN flag. What happens on CPU1?
> Are you expecting it to immediately be able to take interrupts? What
> handler data gets passed to it?

Right - autoen=true will only help on CPU0. Others will still need to call 
enable
- for register tinkling etc. A true autoen API should have done that across the
board which it clearly can't and hence is pointless.

Thx,
-Vineet
--
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 v4 09/16] perf tools: Enable indices setting syntax for BPF maps

[Alexei Starovoitov]

On Mon, Dec 14, 2015 at 12:39:40PM +0800, Wangnan (F) wrote:
> 
> And what do you think about the BPF function prototype? Should we put them
> into kernel headers? What about::
> +#define DEFINE_BPF_FUNC(rettype, name, arglist...) static rettype
> (*name)(arglist) = (void *)BPF_FUNC_##name

tldr: let's keep it as a part of user headers until better
solution found.

frankly
static void *(*bpf_map_lookup_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_lookup_elem;
was llvm hack that I thought will be fixed quickly.
That was the easiest way to make C/llvm/bpf_loader to agree on
passing 'bpf_call #num' insn into the kernel.
It works, but it works only with -O2 and higher.
At lower optimization levels llvm generates load of constant
into register and indirect call by register, so that's not suitable
as clean api. bcc with clang::rewriter can solve it, but we don't
want to always depend on that, so currently it's a status quo.
Don't mess with what ain't broken.

--
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/3] x86: Add support for guest DMA dirty page tracking

[Alexander Duyck]

On Sun, Dec 13, 2015 at 9:22 PM, Yang Zhang  wrote:
> On 2015/12/14 12:54, Alexander Duyck wrote:
>>
>> On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang 
>> wrote:
>>>
>>> On 2015/12/14 5:28, Alexander Duyck wrote:


 This patch set is meant to be the guest side code for a proof of concept
 involving leaving pass-through devices in the guest during the warm-up
 phase of guest live migration.  In order to accomplish this I have added
 a
 new function called dma_mark_dirty that will mark the pages associated
 with
 the DMA transaction as dirty in the case of either an unmap or a
 sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
 DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
 the stop-and-copy phase, however allowing the device to be present
 should
 significantly improve the performance of the guest during the warm-up
 period.

 This current implementation is very preliminary and there are number of
 items still missing.  Specifically in order to make this a more complete
 solution we need to support:
 1.  Notifying hypervisor that drivers are dirtying DMA pages received
 2.  Bypassing page dirtying when it is not needed.

>>>
>>> Shouldn't current log dirty mechanism already cover them?
>>
>>
>> The guest has no way of currently knowing that the hypervisor is doing
>> dirty page logging, and the log dirty mechanism currently has no way
>> of tracking device DMA accesses.  This change is meant to bridge the
>> two so that the guest device driver will force the SWIOTLB DMA API to
>> mark pages written to by the device as dirty.
>
>
> OK. This is what we called "dummy write mechanism". Actually, this is just a
> workaround before iommu dirty bit ready. Eventually, we need to change to
> use the hardware dirty bit. Besides, we may still lost the data if dma
> happens during/just before stop and copy phase.

Right, this is a "dummy write mechanism" in order to allow for entry
tracking.  This only works completely if we force the hardware to
quiesce via a hot-plug event before we reach the stop-and-copy phase
of the migration.

The IOMMU dirty bit approach is likely going to have a significant
number of challenges involved.  Looking over the driver and the data
sheet it looks like the current implementation is using a form of huge
pages in the IOMMU, as such we will need to tear that down and replace
it with 4K pages if we don't want to dirty large regions with each DMA
transaction, and I'm not sure that is something we can change while
DMA is active to the affected regions.  In addition the data sheet
references the fact that the page table entries are stored in a
translation cache and in order to sync things up you have to
invalidate the entries.  I'm not sure what the total overhead would be
for invalidating something like a half million 4K pages to migrate a
guest with just 2G of RAM, but I would think that might be a bit
expensive given the fact that IOMMU accesses aren't known for being
incredibly fast when invalidating DMA on the host.

- Alex
--
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] tty/n_gsm.c: use gsm->num to remove mux itself from gsm_mux[]

[xinhui]

Hi, Greg
Thanks for your kind reply :)

On 2015/12/13 14:47, Greg Kroah-Hartman wrote:

On Fri, Nov 27, 2015 at 11:41:03AM +0800, xinhui wrote:

There is one filed gsm->num to store mux's index of gsm_mux[]. So use
gsm->num to remove itself from gsm_mux[] instead of the for-loop
traverse in gsm_cleanup_mux().

Signed-off-by: Pan Xinhui 


Your "From:" line in the email needs to match your signed-off-by: line,
please fix up your email client to do this properly so that your patches
can be accepted.



I will fix it ASAP. Thank you!

thanks
xinhui

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 V2 net-next] drivers/net: fix eisa_driver probe section mismatch

[David Miller]

From: Fabian Frederick 
Date: Sat, 12 Dec 2015 18:24:38 +0100

> Some eisa_driver structures used __init probe functions which generates
> a warning and could crash if function is called after being deleted.
> 
> Signed-off-by: Fabian Frederick 

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/

Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

[Yang Zhang]

On 2015/12/14 12:54, Alexander Duyck wrote:

On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang  wrote:

On 2015/12/14 5:28, Alexander Duyck wrote:


This patch set is meant to be the guest side code for a proof of concept
involving leaving pass-through devices in the guest during the warm-up
phase of guest live migration.  In order to accomplish this I have added a
new function called dma_mark_dirty that will mark the pages associated
with
the DMA transaction as dirty in the case of either an unmap or a
sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
the stop-and-copy phase, however allowing the device to be present should
significantly improve the performance of the guest during the warm-up
period.

This current implementation is very preliminary and there are number of
items still missing.  Specifically in order to make this a more complete
solution we need to support:
1.  Notifying hypervisor that drivers are dirtying DMA pages received
2.  Bypassing page dirtying when it is not needed.



Shouldn't current log dirty mechanism already cover them?


The guest has no way of currently knowing that the hypervisor is doing
dirty page logging, and the log dirty mechanism currently has no way
of tracking device DMA accesses.  This change is meant to bridge the
two so that the guest device driver will force the SWIOTLB DMA API to
mark pages written to by the device as dirty.


OK. This is what we called "dummy write mechanism". Actually, this is 
just a workaround before iommu dirty bit ready. Eventually, we need to 
change to use the hardware dirty bit. Besides, we may still lost the 
data if dma happens during/just before stop and copy phase.





The two mechanisms referenced above would likely require coordination with
QEMU and as such are open to discussion.  I haven't attempted to address
them as I am not sure there is a consensus as of yet.  My personal
preference would be to add a vendor-specific configuration block to the
emulated pci-bridge interfaces created by QEMU that would allow us to
essentially extend shpc to support guest live migration with pass-through
devices.

The functionality in this patch set is currently disabled by default.  To
enable it you can select "SWIOTLB page dirtying" from the "Processor type
and features" menu.



Only SWIOTLB is supported?


Yes.  For right now this only supports SWIOTLB.  The assumption here
is that SWIOTLB is in use for most cases where an IOMMU is not
present.  If an IOMMU is present in a virtualized guest then most
likely the IOMMU might be able to provide a separate mechanism for
dirty page tracking.

- Alex




--
best regards
yang
--
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 V1 4/4] tool/perf: Add sample_reg_mask to include all perf_regs regs

[Anju T]

From: Madhavan Srinivasan 

Add sample_reg_mask array with pt_regs registers.
This is needed for printing supported regs ( -I? option).

Signed-off-by: Madhavan Srinivasan 
---
 tools/perf/arch/powerpc/util/Build   |  1 +
 tools/perf/arch/powerpc/util/perf_regs.c | 48 
 2 files changed, 49 insertions(+)
 create mode 100644 tools/perf/arch/powerpc/util/perf_regs.c

diff --git a/tools/perf/arch/powerpc/util/Build 
b/tools/perf/arch/powerpc/util/Build
index 7b8b0d1..3deb1bc 100644
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,5 +1,6 @@
 libperf-y += header.o
 libperf-y += sym-handling.o
+libperf-y += perf_regs.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
diff --git a/tools/perf/arch/powerpc/util/perf_regs.c 
b/tools/perf/arch/powerpc/util/perf_regs.c
new file mode 100644
index 000..0b0ec65
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -0,0 +1,48 @@
+#include "../../perf.h"
+#include "../../util/perf_regs.h"
+
+const struct sample_reg sample_reg_masks[] = {
+   SMPL_REG(gpr0, PERF_REG_POWERPC_GPR0),
+   SMPL_REG(gpr1, PERF_REG_POWERPC_GPR1),
+   SMPL_REG(gpr2, PERF_REG_POWERPC_GPR2),
+   SMPL_REG(gpr3, PERF_REG_POWERPC_GPR3),
+   SMPL_REG(gpr4, PERF_REG_POWERPC_GPR4),
+   SMPL_REG(gpr5, PERF_REG_POWERPC_GPR5),
+   SMPL_REG(gpr6, PERF_REG_POWERPC_GPR6),
+   SMPL_REG(gpr7, PERF_REG_POWERPC_GPR7),
+   SMPL_REG(gpr8, PERF_REG_POWERPC_GPR8),
+   SMPL_REG(gpr9, PERF_REG_POWERPC_GPR9),
+   SMPL_REG(gpr10, PERF_REG_POWERPC_GPR10),
+   SMPL_REG(gpr11, PERF_REG_POWERPC_GPR11),
+   SMPL_REG(gpr12, PERF_REG_POWERPC_GPR12),
+   SMPL_REG(gpr13, PERF_REG_POWERPC_GPR13),
+   SMPL_REG(gpr14, PERF_REG_POWERPC_GPR14),
+   SMPL_REG(gpr15, PERF_REG_POWERPC_GPR15),
+   SMPL_REG(gpr16, PERF_REG_POWERPC_GPR16),
+   SMPL_REG(gpr17, PERF_REG_POWERPC_GPR17),
+   SMPL_REG(gpr18, PERF_REG_POWERPC_GPR18),
+   SMPL_REG(gpr19, PERF_REG_POWERPC_GPR19),
+   SMPL_REG(gpr20, PERF_REG_POWERPC_GPR20),
+   SMPL_REG(gpr21, PERF_REG_POWERPC_GPR21),
+   SMPL_REG(gpr22, PERF_REG_POWERPC_GPR22),
+   SMPL_REG(gpr23, PERF_REG_POWERPC_GPR23),
+   SMPL_REG(gpr24, PERF_REG_POWERPC_GPR24),
+   SMPL_REG(gpr25, PERF_REG_POWERPC_GPR25),
+   SMPL_REG(gpr26, PERF_REG_POWERPC_GPR26),
+   SMPL_REG(gpr27, PERF_REG_POWERPC_GPR27),
+   SMPL_REG(gpr28, PERF_REG_POWERPC_GPR28),
+   SMPL_REG(gpr29, PERF_REG_POWERPC_GPR29),
+   SMPL_REG(gpr30, PERF_REG_POWERPC_GPR30),
+   SMPL_REG(gpr31, PERF_REG_POWERPC_GPR31),
+   SMPL_REG(nip, PERF_REG_POWERPC_NIP),
+   SMPL_REG(msr, PERF_REG_POWERPC_MSR),
+   SMPL_REG(orig_r3, PERF_REG_POWERPC_ORIG_R3),
+   SMPL_REG(ctr, PERF_REG_POWERPC_CTR),
+   SMPL_REG(link, PERF_REG_POWERPC_LNK),
+   SMPL_REG(xer, PERF_REG_POWERPC_XER),
+   SMPL_REG(ccr, PERF_REG_POWERPC_CCR),
+   SMPL_REG(trap, PERF_REG_POWERPC_TRAP),
+   SMPL_REG(dar, PERF_REG_POWERPC_DAR),
+   SMPL_REG(dsisr, PERF_REG_POWERPC_DSISR),
+   SMPL_REG_END
+};
-- 
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 07/10] drivers/pci: make host/pcie-rcar.c explicitly non-modular

[Simon Horman]

On Sat, Dec 12, 2015 at 08:41:54PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/pci/host/Kconfig:config PCI_RCAR_GEN2_PCIE
> drivers/pci/host/Kconfig:   bool "Renesas R-Car PCIe controller"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> We don't have to disallow a driver unbind, since that is already
> done for us in this driver.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
> 
> Cc: Simon Horman 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Acked-by: Simon Horman 

--
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 05/10] drivers/pci: make host/pci-rcar-gen2.c explicitly non-modular

[Simon Horman]

On Sat, Dec 12, 2015 at 08:41:52PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/pci/host/Kconfig:config PCI_RCAR_GEN2
> drivers/pci/host/Kconfig:   bool "Renesas R-Car Gen2 Internal PCI 
> controller"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> We don't have to disallow a driver unbind, since that is already
> done for us in this driver.
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> We don't replace module.h with init.h since the file already has that.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
> 
> Cc: Simon Horman 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Acked-by: Simon Horman 

--
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 V6 0/4] perf/powerpc: Add ability to sample intr machine state in powerpc

[Anju T]

This short patch series adds the ability to sample the interrupted
machine state for each hardware sample.

To test this patchset,
Eg:

$ perf record -I?   # list supported registers 

output:

available registers: gpr0 gpr1 gpr2 gpr3 gpr4 gpr5 gpr6 gpr7 gpr8 gpr9 gpr10 
gpr11 gpr12 gpr13 gpr14 gpr15 gpr16 gpr17 gpr18 gpr19 gpr20 gpr21 gpr22 gpr23 
gpr24 gpr25 gpr26 gpr27 gpr28 gpr29 gpr30 gpr31 nip msr orig_r3 ctr link xer 
ccr trap dar dsisr
usage: perf record [] []
or: perf record [] --  []
 -I, --intr-regs[=]
sample selected machine registers on interrupt, use -I ? to list register names


$ perf record -I ls   # record machine state at interrupt
$ perf script -D  # read the perf.data file

Samplfdoutput obtained for this patchset/ output looks like as follows:

178329381464 0x138 [0x180]: PERF_RECORD_SAMPLE(IP, 0x1): 7803/7803: 
0xc000fd9c period: 1 addr: 0
... intr regs: mask 0x3ff ABI 64-bit
 gpr0  0xc01a6420
 gpr1  0xc01e4df039b0
 gpr2  0xc0cdd100
 gpr3  0x1
 gpr4  0xc01e4a96d000
 gpr5  0x29854255ba
 gpr6  0xc00ffa3050b8
 gpr7  0x0
 gpr8  0x0
 gpr9  0x0
 gpr10 0x0
 gpr11 0x0
 gpr12 0x24022822
 gpr13 0xcfe03000
 gpr14 0x0
 gpr15 0xc0d763f8
 gpr16 0x0
 gpr17 0xc01e4ddcf000
 gpr18 0x0
 gpr19 0xc00ffa305000
 gpr20 0xc01e4df038c0
 gpr21 0xc01e40ed7a00
 gpr22 0xc00aa28c
 gpr23 0xc0cdd100
 gpr24 0x0
 gpr25 0xc0cdd100
 gpr26 0xc01e4df038b0
 gpr27 0xfeae
 gpr28 0xc01e4df03880
 gpr29 0xc0dce900
 gpr30 0xc01e4df03890
 gpr31 0xc01e355c7a30
 nip   0xc01a62d8
 msr   0x90009032
 orig_r3 0xc01a6320
 ctr   0xc00a7be0
 lnk   0xc01a6428
 xer   0x0
 ccr   0x24022888
 trap  0xf01
 dar   0xc01e40ed7a00
 dsisr 0x3000c006004
 ... thread: :7803:7803
 .. dso: /root/.debug/.build-id/d0/eb47b06c0d294143af13c50616f638c2d88658
   :7803  7803   178.329381:  1 cycles:  c000fd9c 
.arch_local_irq_restore (/boot/vmlinux)


Changes from V5:

- Enabled perf_sample_regs_user also in this patch set.Functions added in 
   arch/powerpc/perf/perf_regs.c
- Added Maddy's patch to this patchset for enabling -I? option which will
  list the supported register names.


Changes from V4:

- Removed the softe and MQ from all patches
- Switch case is replaced with an array in the 3rd patch

Changes from V3:

- Addressed the comments by Sukadev regarding the nits in the descriptions.
- Modified the subject of first patch.
- Included the sample output in the 3rd patch also.

Changes from V2:

- tools/perf/config/Makefile is moved to the patch tools/perf.
- The patchset is reordered.
- perf_regs_load() function is used for the dwarf unwind test.Since it is not 
required here,
  it is removed from tools/perf/arch/powerpc/include/perf_regs.h
- PERF_REGS_POWERPC_RESULT is removed.

Changes from V1:

- Solved the name missmatch issue in the from and signed-off field of the patch 
series.
- Added necessary comments in the 3rd patch ie perf/powerpc ,as suggested by 
Maddy.


Anju T (3):
  perf/powerpc: assign an id to each powerpc register
  perf/powerpc: add support for sampling intr machine state
  tools/perf: Map the ID values with register names

Madhavan Srinivasan (1):
  tool/perf: Add sample_reg_mask to include all perf_regs regs

 arch/powerpc/Kconfig|  1 +
 arch/powerpc/include/uapi/asm/perf_regs.h   | 49 +
 arch/powerpc/perf/Makefile  |  1 +
 arch/powerpc/perf/perf_regs.c   | 85 +
 tools/perf/arch/powerpc/include/perf_regs.h | 65 ++
 tools/perf/arch/powerpc/util/Build  |  1 +
 tools/perf/arch/powerpc/util/perf_regs.c| 48 
 tools/perf/config/Makefile  |  5 ++
 8 files changed, 255 insertions(+)
 create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
 create mode 100644 arch/powerpc/perf/perf_regs.c
 create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
 create mode 100644 tools/perf/arch/powerpc/util/perf_regs.c

-- 
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 V6 1/4] perf/powerpc: assign an id to each powerpc register

[Anju T]

The enum definition assigns an 'id' to each register in "struct pt_regs"
of arch/powerpc. The order of these values in the enum definition are
based on the corresponding macros in arch/powerpc/include/uapi/asm/ptrace.h.

Signed-off-by: Anju T 
Reviewed-by  : Madhavan Srinivasan 
---
 arch/powerpc/include/uapi/asm/perf_regs.h | 49 +++
 1 file changed, 49 insertions(+)
 create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h

diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h 
b/arch/powerpc/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..cfbd068
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -0,0 +1,49 @@
+#ifndef _ASM_POWERPC_PERF_REGS_H
+#define _ASM_POWERPC_PERF_REGS_H
+
+enum perf_event_powerpc_regs {
+   PERF_REG_POWERPC_GPR0,
+   PERF_REG_POWERPC_GPR1,
+   PERF_REG_POWERPC_GPR2,
+   PERF_REG_POWERPC_GPR3,
+   PERF_REG_POWERPC_GPR4,
+   PERF_REG_POWERPC_GPR5,
+   PERF_REG_POWERPC_GPR6,
+   PERF_REG_POWERPC_GPR7,
+   PERF_REG_POWERPC_GPR8,
+   PERF_REG_POWERPC_GPR9,
+   PERF_REG_POWERPC_GPR10,
+   PERF_REG_POWERPC_GPR11,
+   PERF_REG_POWERPC_GPR12,
+   PERF_REG_POWERPC_GPR13,
+   PERF_REG_POWERPC_GPR14,
+   PERF_REG_POWERPC_GPR15,
+   PERF_REG_POWERPC_GPR16,
+   PERF_REG_POWERPC_GPR17,
+   PERF_REG_POWERPC_GPR18,
+   PERF_REG_POWERPC_GPR19,
+   PERF_REG_POWERPC_GPR20,
+   PERF_REG_POWERPC_GPR21,
+   PERF_REG_POWERPC_GPR22,
+   PERF_REG_POWERPC_GPR23,
+   PERF_REG_POWERPC_GPR24,
+   PERF_REG_POWERPC_GPR25,
+   PERF_REG_POWERPC_GPR26,
+   PERF_REG_POWERPC_GPR27,
+   PERF_REG_POWERPC_GPR28,
+   PERF_REG_POWERPC_GPR29,
+   PERF_REG_POWERPC_GPR30,
+   PERF_REG_POWERPC_GPR31,
+   PERF_REG_POWERPC_NIP,
+   PERF_REG_POWERPC_MSR,
+   PERF_REG_POWERPC_ORIG_R3,
+   PERF_REG_POWERPC_CTR,
+   PERF_REG_POWERPC_LNK,
+   PERF_REG_POWERPC_XER,
+   PERF_REG_POWERPC_CCR,
+   PERF_REG_POWERPC_TRAP,
+   PERF_REG_POWERPC_DAR,
+   PERF_REG_POWERPC_DSISR,
+   PERF_REG_POWERPC_MAX,
+};
+#endif /* _ASM_POWERPC_PERF_REGS_H */
-- 
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 V6 2/4] perf/powerpc: add support for sampling intr machine state

[Anju T]

The perf infrastructure uses a bit mask to find out valid
registers to display. Define a register mask for supported
registers defined in asm/perf_regs.h. The bit positions also
correspond to register IDs which is used by perf infrastructure
to fetch the register values. CONFIG_HAVE_PERF_REGS enables
sampling of the interrupted machine state.

Signed-off-by: Anju T 
Reviewed-by  : Madhavan Srinivasan 
---
 arch/powerpc/Kconfig  |  1 +
 arch/powerpc/perf/Makefile|  1 +
 arch/powerpc/perf/perf_regs.c | 85 +++
 3 files changed, 87 insertions(+)
 create mode 100644 arch/powerpc/perf/perf_regs.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9a7057e..c4ce60d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_PERF_EVENTS
+   select HAVE_PERF_REGS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select ARCH_WANT_IPC_PARSE_VERSION
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index f9c083a..2f2d3d2 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -8,6 +8,7 @@ obj64-$(CONFIG_PPC_PERF_CTRS)   += power4-pmu.o ppc970-pmu.o 
power5-pmu.o \
   power8-pmu.o
 obj32-$(CONFIG_PPC_PERF_CTRS)  += mpc7450-pmu.o
 
+obj-$(CONFIG_PERF_EVENTS)  += perf_regs.o
 obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
 obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
 
diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
new file mode 100644
index 000..d32581763
--- /dev/null
+++ b/arch/powerpc/perf/perf_regs.c
@@ -0,0 +1,85 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
+
+#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
+
+static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR0, gpr[0]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR1, gpr[1]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR2, gpr[2]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR3, gpr[3]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR4, gpr[4]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR5, gpr[5]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR6, gpr[6]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR7, gpr[7]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR8, gpr[8]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR9, gpr[9]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR10, gpr[10]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR11, gpr[11]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR12, gpr[12]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR13, gpr[13]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR14, gpr[14]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR15, gpr[15]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR16, gpr[16]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR17, gpr[17]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR18, gpr[18]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR19, gpr[19]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR20, gpr[20]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR21, gpr[21]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR22, gpr[22]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR23, gpr[23]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR24, gpr[24]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR25, gpr[25]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR26, gpr[26]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR27, gpr[27]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR28, gpr[28]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR29, gpr[29]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR30, gpr[30]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_GPR31, gpr[31]),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_NIP, nip),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_MSR, msr),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_ORIG_R3, orig_gpr3),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_CTR, ctr),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_LNK, link),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_XER, xer),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_CCR, ccr),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_TRAP, trap),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_DAR, dar),
+   PT_REGS_OFFSET(PERF_REG_POWERPC_DSISR, dsisr),
+};
+
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+   if (WARN_ON_ONCE(idx >= PERF_REG_POWERPC_MAX))
+   return 0;
+
+   return regs_get_register(regs, pt_regs_offset[idx]);
+}
+
+int perf_reg_validate(u64 mask)
+{
+   if (!mask || mask & REG_RESERVED)
+   return -EINVAL;
+   return 0;
+}
+
+u64 perf_reg_abi(struct task_struct *task)
+{
+   return PERF_SAMPLE_REGS_ABI_64;
+}
+
+void perf_get_regs_user(struct perf_regs *regs_user,
+   struct pt_regs *regs,
+

[PATCH V6 3/4] tools/perf: Map the ID values with register names

[Anju T]

Map ID values with corresponding register names. These names are then
displayed when user issues perf record with the -I option
followed by perf report/script with -D option.

To test this patchset,
Eg:

$ perf record -I ls   # record machine state at interrupt
$ perf script -D  # read the perf.data file

Sample output obtained for this patch / output looks like as follows:

178329381464 0x138 [0x180]: PERF_RECORD_SAMPLE(IP, 0x1): 7803/7803: 
0xc000fd9c period: 1 addr: 0
... intr regs: mask 0x3ff ABI 64-bit
 gpr0  0xc01a6420
 gpr1  0xc01e4df039b0
 gpr2  0xc0cdd100
 gpr3  0x1
 gpr4  0xc01e4a96d000
 gpr5  0x29854255ba
 gpr6  0xc00ffa3050b8
 gpr7  0x0
 gpr8  0x0
 gpr9  0x0
 gpr10 0x0
 gpr11 0x0
 gpr12 0x24022822
 gpr13 0xcfe03000
 gpr14 0x0
 gpr15 0xc0d763f8
 gpr16 0x0
 gpr17 0xc01e4ddcf000
 gpr18 0x0
 gpr19 0xc00ffa305000
 gpr20 0xc01e4df038c0
 gpr21 0xc01e40ed7a00
 gpr22 0xc00aa28c
 gpr23 0xc0cdd100
 gpr24 0x0
 gpr25 0xc0cdd100
 gpr26 0xc01e4df038b0
 gpr27 0xfeae
 gpr28 0xc01e4df03880
 gpr29 0xc0dce900
 gpr30 0xc01e4df03890
 gpr31 0xc01e355c7a30
 nip   0xc01a62d8
 msr   0x90009032
 orig_r3 0xc01a6320
 ctr   0xc00a7be0
 lnk   0xc01a6428
 xer   0x0
 ccr   0x24022888
 trap  0xf01
 dar   0xc01e40ed7a00
 dsisr 0x3000c006004
 ... thread: :7803:7803
 .. dso: /root/.debug/.build-id/d0/eb47b06c0d294143af13c50616f638c2d88658
   :7803  7803   178.329381:  1 cycles:  c000fd9c 
.arch_local_irq_restore (/boot/vmlinux)


Signed-off-by: Anju T 
Reviewed-by  : Madhavan Srinivasan 
---
 tools/perf/arch/powerpc/include/perf_regs.h | 65 +
 tools/perf/config/Makefile  |  5 +++
 2 files changed, 70 insertions(+)
 create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h

diff --git a/tools/perf/arch/powerpc/include/perf_regs.h 
b/tools/perf/arch/powerpc/include/perf_regs.h
new file mode 100644
index 000..b4f62a3
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -0,0 +1,65 @@
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include 
+#include 
+#include 
+
+#define PERF_REGS_MASK  ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+#define PERF_REGS_MAX   PERF_REG_POWERPC_MAX
+#define PERF_SAMPLE_REGS_ABI   PERF_SAMPLE_REGS_ABI_64
+
+#define PERF_REG_IP PERF_REG_POWERPC_NIP
+#define PERF_REG_SP PERF_REG_POWERPC_R1
+
+static const char *perf_reg_names[] = {
+   [PERF_REG_POWERPC_GPR0] = "gpr0",
+   [PERF_REG_POWERPC_GPR1] = "gpr1",
+   [PERF_REG_POWERPC_GPR2] = "gpr2",
+   [PERF_REG_POWERPC_GPR3] = "gpr3",
+   [PERF_REG_POWERPC_GPR4] = "gpr4",
+   [PERF_REG_POWERPC_GPR5] = "gpr5",
+   [PERF_REG_POWERPC_GPR6] = "gpr6",
+   [PERF_REG_POWERPC_GPR7] = "gpr7",
+   [PERF_REG_POWERPC_GPR8] = "gpr8",
+   [PERF_REG_POWERPC_GPR9] = "gpr9",
+   [PERF_REG_POWERPC_GPR10] = "gpr10",
+   [PERF_REG_POWERPC_GPR11] = "gpr11",
+   [PERF_REG_POWERPC_GPR12] = "gpr12",
+   [PERF_REG_POWERPC_GPR13] = "gpr13",
+   [PERF_REG_POWERPC_GPR14] = "gpr14",
+   [PERF_REG_POWERPC_GPR15] = "gpr15",
+   [PERF_REG_POWERPC_GPR16] = "gpr16",
+   [PERF_REG_POWERPC_GPR17] = "gpr17",
+   [PERF_REG_POWERPC_GPR18] = "gpr18",
+   [PERF_REG_POWERPC_GPR19] = "gpr19",
+   [PERF_REG_POWERPC_GPR20] = "gpr20",
+   [PERF_REG_POWERPC_GPR21] = "gpr21",
+   [PERF_REG_POWERPC_GPR22] = "gpr22",
+   [PERF_REG_POWERPC_GPR23] = "gpr23",
+   [PERF_REG_POWERPC_GPR24] = "gpr24",
+   [PERF_REG_POWERPC_GPR25] = "gpr25",
+   [PERF_REG_POWERPC_GPR26] = "gpr26",
+   [PERF_REG_POWERPC_GPR27] = "gpr27",
+   [PERF_REG_POWERPC_GPR28] = "gpr28",
+   [PERF_REG_POWERPC_GPR29] = "gpr29",
+   [PERF_REG_POWERPC_GPR30] = "gpr30",
+   [PERF_REG_POWERPC_GPR31] = "gpr31",
+   [PERF_REG_POWERPC_NIP] = "nip",
+   [PERF_REG_POWERPC_MSR] = "msr",
+   [PERF_REG_POWERPC_ORIG_R3] = "orig_r3",
+   [PERF_REG_POWERPC_CTR] = "ctr",
+   [PERF_REG_POWERPC_LNK] = "lnk",
+   [PERF_REG_POWERPC_XER] = "xer",
+   [PERF_REG_POWERPC_CCR] = "ccr",
+   [PERF_REG_POWERPC_TRAP] = "trap",
+   [PERF_REG_POWERPC_DAR] = "dar",
+   [PERF_REG_POWERPC_DSISR] = "dsisr"
+};
+
+static inline const char *perf_reg_name(int id)
+{
+
+   return perf_reg_names[id];
+}
+#endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 38a0853..acf0302 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -23,6 +23,11 @@ $(call detected_var,ARCH)
 
 NO_PERF_REGS := 1
 
+# Additional ARCH settings for ppc64
+ifeq ($(ARCH),powerpc)
+   NO_PERF_REGS := 0
+endif
+
 # 

[PATCH 2/2] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous

[Joonsoo Kim]

There is a performance drop report due to hugepage allocation and in there
half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
In that workload, compaction is triggered to make hugepage but most of
pageblocks are un-available for compaction due to pageblock type and
skip bit so compaction usually fails. Most costly operations in this case
is to find valid pageblock while scanning whole zone range. To check
if pageblock is valid to compact, valid pfn within pageblock is required
and we can obtain it by calling pageblock_pfn_to_page(). This function
checks whether pageblock is in a single zone and return valid pfn
if possible. Problem is that we need to check it every time before
scanning pageblock even if we re-visit it and this turns out to
be very expensive in this workload.

Although we have no way to skip this pageblock check in the system
where hole exists at arbitrary position, we can use cached value for
zone continuity and just do pfn_to_page() in the system where hole doesn't
exist. This optimization considerably speeds up in above workload.

Before vs After
Max: 1096 MB/s vs 1325 MB/s
Min: 635 MB/s 1015 MB/s
Avg: 899 MB/s 1194 MB/s

Avg is improved by roughly 30% [2].

Not to disturb the system where compaction isn't triggered, checking will
be done at first compaction invocation.

[1]: http://www.spinics.net/lists/linux-mm/msg97378.html
[2]: https://lkml.org/lkml/2015/12/9/23

Signed-off-by: Joonsoo Kim 
---
 include/linux/mmzone.h |  1 +
 mm/compaction.c| 49 -
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 68cc063..cd3736e 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -521,6 +521,7 @@ struct zone {
 #if defined CONFIG_COMPACTION || defined CONFIG_CMA
/* Set to true when the PG_migrate_skip bits should be cleared */
boolcompact_blockskip_flush;
+   boolcontiguous;
 #endif
 
ZONE_PADDING(_pad3_)
diff --git a/mm/compaction.c b/mm/compaction.c
index 56fa321..ce60b38 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -88,7 +88,7 @@ static inline bool migrate_async_suitable(int migratetype)
  * the first and last page of a pageblock and avoid checking each individual
  * page in a pageblock.
  */
-static struct page *pageblock_pfn_to_page(unsigned long start_pfn,
+static struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
unsigned long end_pfn, struct zone *zone)
 {
struct page *start_page;
@@ -114,6 +114,51 @@ static struct page *pageblock_pfn_to_page(unsigned long 
start_pfn,
return start_page;
 }
 
+static inline struct page *pageblock_pfn_to_page(unsigned long start_pfn,
+   unsigned long end_pfn, struct zone *zone)
+{
+   if (zone->contiguous)
+   return pfn_to_page(start_pfn);
+
+   return __pageblock_pfn_to_page(start_pfn, end_pfn, zone);
+}
+
+static void check_zone_contiguous(struct zone *zone)
+{
+   unsigned long block_start_pfn = zone->zone_start_pfn;
+   unsigned long block_end_pfn;
+   unsigned long pfn;
+
+   /* Already initialized if cached pfn is non-zero */
+   if (zone->compact_cached_migrate_pfn[0] ||
+   zone->compact_cached_free_pfn)
+   return;
+
+   /* Mark that checking is in progress */
+   zone->compact_cached_free_pfn = ULONG_MAX;
+
+   block_end_pfn = ALIGN(block_start_pfn + 1, pageblock_nr_pages);
+   for (; block_start_pfn < zone_end_pfn(zone);
+   block_start_pfn = block_end_pfn,
+   block_end_pfn += pageblock_nr_pages) {
+
+   block_end_pfn = min(block_end_pfn, zone_end_pfn(zone));
+
+   if (!__pageblock_pfn_to_page(block_start_pfn,
+   block_end_pfn, zone))
+   return;
+
+   /* Check validity of pfn within pageblock */
+   for (pfn = block_start_pfn; pfn < block_end_pfn; pfn++) {
+   if (!pfn_valid_within(pfn))
+   return;
+   }
+   }
+
+   /* We confirm that there is no hole */
+   zone->contiguous = true;
+}
+
 #ifdef CONFIG_COMPACTION
 
 /* Do not skip compaction more than 64 times */
@@ -1357,6 +1402,8 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
;
}
 
+   check_zone_contiguous(zone);
+
/*
 * Clear pageblock skip if there were failures recently and compaction
 * is about to be retried after being deferred. kswapd does not do
-- 
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/

[PATCH 1/2] mm/compaction: fix invalid free_pfn and compact_cached_free_pfn

[Joonsoo Kim]

free_pfn and compact_cached_free_pfn are the pointer that remember
restart position of freepage scanner. When they are reset or invalid,
we set them to zone_end_pfn because freepage scanner works in reverse
direction. But, because zone range is defined as [zone_start_pfn,
zone_end_pfn), zone_end_pfn is invalid to access. Therefore, we should
not store it to free_pfn and compact_cached_free_pfn. Instead, we need
to store zone_end_pfn - 1 to them. There is one more thing we should
consider. Freepage scanner scan reversely by pageblock unit. If free_pfn
and compact_cached_free_pfn are set to middle of pageblock, it regards
that sitiation as that it already scans front part of pageblock so we
lose opportunity to scan there. To fix-up, this patch do round_down()
to guarantee that reset position will be pageblock aligned.

Note that thanks to the current pageblock_pfn_to_page() implementation,
actual access to zone_end_pfn doesn't happen until now. But, following
patch will change pageblock_pfn_to_page() so this patch is needed
from now on.

Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 585de54..56fa321 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -200,7 +200,8 @@ static void reset_cached_positions(struct zone *zone)
 {
zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
-   zone->compact_cached_free_pfn = zone_end_pfn(zone);
+   zone->compact_cached_free_pfn =
+   round_down(zone_end_pfn(zone) - 1, pageblock_nr_pages);
 }
 
 /*
@@ -1371,11 +1372,11 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
 */
cc->migrate_pfn = zone->compact_cached_migrate_pfn[sync];
cc->free_pfn = zone->compact_cached_free_pfn;
-   if (cc->free_pfn < start_pfn || cc->free_pfn > end_pfn) {
-   cc->free_pfn = end_pfn & ~(pageblock_nr_pages-1);
+   if (cc->free_pfn < start_pfn || cc->free_pfn >= end_pfn) {
+   cc->free_pfn = round_down(end_pfn - 1, pageblock_nr_pages);
zone->compact_cached_free_pfn = cc->free_pfn;
}
-   if (cc->migrate_pfn < start_pfn || cc->migrate_pfn > end_pfn) {
+   if (cc->migrate_pfn < start_pfn || cc->migrate_pfn >= end_pfn) {
cc->migrate_pfn = start_pfn;
zone->compact_cached_migrate_pfn[0] = cc->migrate_pfn;
zone->compact_cached_migrate_pfn[1] = cc->migrate_pfn;
-- 
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 net-next] hv_netvsc: Fix race condition on Multi-Send Data field

[David Miller]

From: Haiyang Zhang 
Date: Thu, 10 Dec 2015 12:19:35 -0800

> In commit 2a04ae8acb14 ("hv_netvsc: remove locking in netvsc_send()"), the
> locking for MSD (Multi-Send Data) field was removed. This could cause a
> race condition between RNDIS control messages and data packets processing,
> because these two types of traffic are not synchronized.
> This patch fixes this issue by sending control messages out directly
> without reading MSD field.
> 
> Signed-off-by: Haiyang Zhang 
> Reviewed-by: K. Y. Srinivasan 

Applied.
--
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/3] x86: Add support for guest DMA dirty page tracking

[Alexander Duyck]

On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang  wrote:
> On 2015/12/14 5:28, Alexander Duyck wrote:
>>
>> This patch set is meant to be the guest side code for a proof of concept
>> involving leaving pass-through devices in the guest during the warm-up
>> phase of guest live migration.  In order to accomplish this I have added a
>> new function called dma_mark_dirty that will mark the pages associated
>> with
>> the DMA transaction as dirty in the case of either an unmap or a
>> sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
>> DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
>> the stop-and-copy phase, however allowing the device to be present should
>> significantly improve the performance of the guest during the warm-up
>> period.
>>
>> This current implementation is very preliminary and there are number of
>> items still missing.  Specifically in order to make this a more complete
>> solution we need to support:
>> 1.  Notifying hypervisor that drivers are dirtying DMA pages received
>> 2.  Bypassing page dirtying when it is not needed.
>>
>
> Shouldn't current log dirty mechanism already cover them?

The guest has no way of currently knowing that the hypervisor is doing
dirty page logging, and the log dirty mechanism currently has no way
of tracking device DMA accesses.  This change is meant to bridge the
two so that the guest device driver will force the SWIOTLB DMA API to
mark pages written to by the device as dirty.

>> The two mechanisms referenced above would likely require coordination with
>> QEMU and as such are open to discussion.  I haven't attempted to address
>> them as I am not sure there is a consensus as of yet.  My personal
>> preference would be to add a vendor-specific configuration block to the
>> emulated pci-bridge interfaces created by QEMU that would allow us to
>> essentially extend shpc to support guest live migration with pass-through
>> devices.
>>
>> The functionality in this patch set is currently disabled by default.  To
>> enable it you can select "SWIOTLB page dirtying" from the "Processor type
>> and features" menu.
>
>
> Only SWIOTLB is supported?

Yes.  For right now this only supports SWIOTLB.  The assumption here
is that SWIOTLB is in use for most cases where an IOMMU is not
present.  If an IOMMU is present in a virtualized guest then most
likely the IOMMU might be able to provide a separate mechanism for
dirty page tracking.

- Alex
--
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] sched/fair: fix mul overflow on 32-bit systems

[Yuyang Du]

On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote:
> First, I believe in theory util_avg on a cpu should add up to 100% or
> 1024 or whatever. However, recently migrated-in tasks don't have their
> utilization cleared, so if they were quickly migrated again you could
> have up to the number of cpus or so times 100%, which could lead to
> overflow here. This just leads to more questions though:
> 
> The whole removed_util_avg thing doesn't seem to make a ton of sense -
> the code doesn't add util_avg for a migrating task onto
> cfs_rq->avg.util_avg

The code does add util_avg for a migrating task onto cfs_rq->avg.util_avg:

enqueue_entity_load_avg() calls attach_entity_load_avg()

> and doing so would regularly give >100% values (it
> does so on attach/detach where it's less likely to cause issues, but not
> migration). Removing it only makes sense if the task has accumulated all
> that utilization on this cpu, and even then mostly only makes sense if
> this is the only task on the cpu (and then it would make sense to add it
> on migrate-enqueue). The whole add-on-enqueue-migrate,
> remove-on-dequeue-migrate thing comes from /load/, where doing so is a
> more globally applicable approximation than it is for utilization,
> though it could still be useful as a fast-start/fast-stop approximation,
> if the add-on-enqueue part was added. It could also I guess be cleared
> on migrate-in, as basically the opposite assumption (or do something
> like add on enqueue, up to 100% and then set the se utilization to the
> amount actually added or something).
> 
> If the choice was to not do the add/remove thing, then se->avg.util_sum
> would be unused except for attach/detach, which currently do the
> add/remove thing. It's not unreasonable for them, except that currently
> nothing uses anything other than the root's utilization, so migration
> between cgroups wouldn't actually change the relevant util number
> (except it could because changing the cfs_rq util_sum doesn't actually
> do /anything/ unless it's the root, so you'd have to wait until the
> cgroup se actually changed in utilization).
> 
> 
> So uh yeah, my initial impression is "rip it out", but if being
> immediately-correct is important in the case of one task being most of
> the utilization, rather than when it is more evenly distributed, it
> would probably make more sense to instead put in the add-on-enqueue
> code.
--
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 v4 09/16] perf tools: Enable indices setting syntax for BPF maps

[Wangnan (F)]

On 2015/12/14 12:28, Alexei Starovoitov wrote:

On Mon, Dec 14, 2015 at 11:27:36AM +0800, Wangnan (F) wrote:


On 2015/12/12 2:21, Alexei Starovoitov wrote:

On Fri, Dec 11, 2015 at 08:39:35PM +0800, pi3orama wrote:

static u64 (*bpf_ktime_get_ns)(void) =
 (void *)5;
static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
 (void *)6;
static int (*bpf_get_smp_processor_id)(void) =
 (void *)8;
static int (*bpf_perf_event_output)(void *, struct bpf_map_def *, int,
void *, unsigned long) =
 (void *)23;

Where can I get this magical mistery table? Could this be hidden away in
some .h file automagically included in bpf scriptlets so that n00bies
like me don't have to be wtf'ing?


They are function numbers defined in bpf.h and bpf-common.h, but they are Linux
headers. Directly include them causes many error for llvm. Also, the function
prototypes are BPF specific and can't included in Linux source. We should have
a place holds those indices and prototypes together.

wait, what kind of errors?
they are in uapi, so gets installed into /usr/include eventually
and I haven't seen any erros either with gcc or clang.


Sorry. I saw error because I use

#include 

It is okay if I use

#include 

then let's use that instead of copy-paste. thanks


And what do you think about the BPF function prototype? Should we put them
into kernel headers? What about::

diff --git a/include/uapi/linux/bpf_functions.h 
b/include/uapi/linux/bpf_functions.h

new file mode 100644
index 000..3a562d4
--- /dev/null
+++ b/include/uapi/linux/bpf_functions.h
@@ -0,0 +1,2 @@
+DEFINE_BPF_FUNC(void *, map_lookup_elem, void *, void *)
+DEFINE_BPF_FUNC(int, map_update_elem, void *, void *, void *, int)
[SNIP]
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 9ea2d22..2f2f05f 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -133,143 +133,23 @@ union bpf_attr {
};
 } __attribute__((aligned(8)));

+#define DEFINE_BPF_FUNC(rettype, name, arglist...) BPF_FUNC_##name
+
+enum bpf_func_id {
+BPF_FUNC_unspec,
+#include "bpf_functions.h"
+__BPF_FUNC_MAX_ID,
+};
+
+#ifdef __BPF_SOURCE__
+#undef DEFINE_BPF_FUNC
+#define DEFINE_BPF_FUNC(rettype, name, arglist...) static rettype 
(*name)(arglist) = (void *)BPF_FUNC_##name

+#include "bpf_functions.h"
+#endif
 /* integer value in 'imm' field of BPF_CALL instruction selects which 
helper

  * function eBPF program intends to call
  */
 enum bpf_func_id {
-   BPF_FUNC_unspec,
[SNIP]

And when compiling BPF source file we add a __BPF_SOURCE__ directive?

Thank you.

--
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 v4 09/16] perf tools: Enable indices setting syntax for BPF maps

[Alexei Starovoitov]

On Mon, Dec 14, 2015 at 11:27:36AM +0800, Wangnan (F) wrote:
> 
> 
> On 2015/12/12 2:21, Alexei Starovoitov wrote:
> >On Fri, Dec 11, 2015 at 08:39:35PM +0800, pi3orama wrote:
> >>>static u64 (*bpf_ktime_get_ns)(void) =
> >>> (void *)5;
> >>>static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
> >>> (void *)6;
> >>>static int (*bpf_get_smp_processor_id)(void) =
> >>> (void *)8;
> >>>static int (*bpf_perf_event_output)(void *, struct bpf_map_def *, int,
> >>>void *, unsigned long) =
> >>> (void *)23;
> >>>
> >>>Where can I get this magical mistery table? Could this be hidden away in
> >>>some .h file automagically included in bpf scriptlets so that n00bies
> >>>like me don't have to be wtf'ing?
> >>>
> >>They are function numbers defined in bpf.h and bpf-common.h, but they are 
> >>Linux
> >>headers. Directly include them causes many error for llvm. Also, the 
> >>function
> >>prototypes are BPF specific and can't included in Linux source. We should 
> >>have
> >>a place holds those indices and prototypes together.
> >wait, what kind of errors?
> >they are in uapi, so gets installed into /usr/include eventually
> >and I haven't seen any erros either with gcc or clang.
> >
> Sorry. I saw error because I use
> 
> #include 
> 
> It is okay if I use
> 
> #include 

then let's use that instead of copy-paste. 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: [PATCH v2 0/3] Mediatek EFUSE Support

[Daniel Kurtz]

Hi Srinivas,

On Thu, Nov 19, 2015 at 6:46 PM, Andrew-CT Chen
 wrote:
> This patch adds EFUSE support driver which is used by other drivers
> like thermal sensor and HDMI impedance.
>
> There are some efuses these fuses store things like calibration data,
> speed bins.. etc. Drivers like thermal sensor, HDMI impedance would
> read out this data for configuring the driver.
>
> Change in v2:
> 1. Rebase to 4.4-rc1
> 2. Modify the driver Makefile for more consistent with other drivers
> 3. Modify the compatible string to "mediatek,mt8173-efuse" and 
> "mediatek,efuse"

Do you still plan to queue this for v4.5?

>
> Andrew-CT Chen (3):
>   dt-bindings: add document of mediatek efuse driver
>   nvmem: mediatek: Add Mediatek EFUSE driver
>   dts: arm64: Add EFUSE device node
>
>  .../devicetree/bindings/nvmem/mtk-efuse.txt| 36 +
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  5 ++
>  drivers/nvmem/Kconfig  | 11 +++
>  drivers/nvmem/Makefile |  2 +
>  drivers/nvmem/mtk-efuse.c  | 89 
> ++
>  5 files changed, 143 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
>  create mode 100644 drivers/nvmem/mtk-efuse.c
>
> --
> 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/
--
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 01/17] perf build: Remove unnecessary line in Makefile.feature

[Josh Poimboeuf]

This line always silently fails because it doesn't add the 'test-'
prefix to the .bin file.

And it seems to be unnecessary anyway: the line immediately after it
does all the individual feature checks.

Signed-off-by: Josh Poimboeuf 
---
 tools/build/Makefile.feature | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 37ff4c9..b8c31ec 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -101,7 +101,6 @@ ifeq ($(feature-all), 1)
   #
   $(foreach feat,$(FEATURE_TESTS),$(call feature_set,$(feat)))
 else
-  $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" 
LDFLAGS=$(LDFLAGS) -i -j -C $(feature_dir) $(addsuffix .bin,$(FEATURE_TESTS)) 
>/dev/null 2>&1)
   $(foreach feat,$(FEATURE_TESTS),$(call feature_check,$(feat)))
 endif
 
-- 
2.4.3

--
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 00/17] perf tools: Move perf subcommand framework to a library

[Josh Poimboeuf]

Ingo suggested that I factor out the perf subcommand functionality
(originally copied from git) into tools/lib so that it can be used by
stacktool[*] and possibly others.

All the subcommand option handling files have been moved into a new
library named libsubcmd.a, including parse-options.c, run-command.c,
exec_cmd.c, help.c, usage.c, and pager.c.

Patches 1-6 are some assorted cleanups I discovered in the process of
making the patch set.  They're completely separate from the rest of the
patches and can be merged independently.

Patches 7-15 are some cleanups and splitting up of the code related to
the creation of the new library.

Patch 16 does the actual moving of the files and creation of the new
libsubcmd.a library in tools/lib/subcmd.

Patch 17 updates the header guards for the moved .h files.

Based on acme/perf/core.

These patches can also be found in the 'perf-subcmd-v3' branch in the
following repo:

  https://github.com/jpoimboe/linux


[*] https://lkml.kernel.org/r/cover.1445443144.git.jpoim...@redhat.com

v3:
- Remove dependencies on util.h, cache.h, abspath, ctype, strbuf, term,
  usage, wrapper
- Move to a new 'libsubcmd' library in tools/lib/subcmd
- Rebase onto Namhyung's patches which remove the browser dependency
  from parse-options.c
- Get rid of the util_cfg struct in favor of file-specific init
  functions
- Split up the patches better
- Document the fact that parse_options*() can exit
- Convert parse-options.c internal functions to static
- Rename exec_cmd.* to exec-cmd.*
- Add new astrcat() and astrcatf() functions to replace strbuf
- Add some more fixes related to 'make O=' and 'make clean' (though
  a 'make clean' is no longer required and these patches are now
  unrelated to libsubcmd)

v2:
- Fix 'make clean' to remove tests/llvm-src-*.c and other leftover
  files
- Fix description for second-to-last patch

Josh Poimboeuf (17):
  perf build: Remove unnecessary line in Makefile.feature
  tools build: Fix feature Makefile dependencies for 'O='
  perf test: Add Build file to dependencies for llvm-src-*.c
  perf test: remove tarpkg at end of test
  perf build: Fix 'make clean'
  perf build: Rename LIB_PATH -> API_PATH
  perf: Create pager.h
  perf: Remove check for unused PERF_PAGER_IN_USE
  perf: Move help_unknown_cmd() to its own file
  perf: Provide subcmd configuration at runtime
  perf: Remove 'perf' from subcmd function and variable names
  perf: Convert parse-options.c internal functions to static
  perf: Document the fact that parse_options*() may exit
  perf: Remove subcmd dependencies on strbuf
  perf: Finalize subcmd independence
  perf subcmd: Create subcmd library
  tools subcmd: Rename subcmd header include guards

 tools/build/Makefile.feature|   3 +-
 tools/build/feature/Makefile|  95 +-
 tools/lib/subcmd/Build  |   6 +
 tools/lib/subcmd/Makefile   |  48 +
 tools/lib/subcmd/exec-cmd.c | 227 
 tools/lib/subcmd/exec-cmd.h |  16 ++
 tools/{perf/util => lib/subcmd}/help.c  | 170 ++
 tools/{perf/util => lib/subcmd}/help.h  |  13 +-
 tools/{perf/util => lib/subcmd}/pager.c |  24 ++-
 tools/lib/subcmd/pager.h|   9 +
 tools/{perf/util => lib/subcmd}/parse-options.c | 134 --
 tools/{perf/util => lib/subcmd}/parse-options.h |  23 ++-
 tools/{perf/util => lib/subcmd}/run-command.c   |  24 ++-
 tools/{perf/util => lib/subcmd}/run-command.h   |  12 +-
 tools/{perf/util => lib/subcmd}/sigchain.c  |   3 +-
 tools/{perf/util => lib/subcmd}/sigchain.h  |   6 +-
 tools/lib/subcmd/subcmd-util.h  |  91 ++
 tools/perf/Build|   5 +-
 tools/perf/MANIFEST |   1 +
 tools/perf/Makefile.perf|  35 ++--
 tools/perf/arch/x86/util/intel-pt.c |   2 +-
 tools/perf/bench/futex-hash.c   |   2 +-
 tools/perf/bench/futex-lock-pi.c|   2 +-
 tools/perf/bench/futex-requeue.c|   2 +-
 tools/perf/bench/futex-wake-parallel.c  |   2 +-
 tools/perf/bench/futex-wake.c   |   2 +-
 tools/perf/bench/mem-functions.c|   2 +-
 tools/perf/bench/numa.c |   2 +-
 tools/perf/bench/sched-messaging.c  |   2 +-
 tools/perf/bench/sched-pipe.c   |   2 +-
 tools/perf/builtin-annotate.c   |   2 +-
 tools/perf/builtin-bench.c  |   2 +-
 tools/perf/builtin-buildid-cache.c  |   2 +-
 tools/perf/builtin-buildid-list.c   |   2 +-
 tools/perf/builtin-config.c |   2 +-
 tools/perf/builtin-data.c   |   2 +-
 tools/perf/builtin-evlist.c |   2 +-
 tools/perf/builtin-help.c   |  10 +-
 

[PATCH v3 02/17] tools build: Fix feature Makefile dependencies for 'O='

[Josh Poimboeuf]

Signed-off-by: Josh Poimboeuf 
---
 tools/build/Makefile.feature |  2 +-
 tools/build/feature/Makefile | 95 ++--
 2 files changed, 49 insertions(+), 48 deletions(-)

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index b8c31ec..6c0519d 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -7,7 +7,7 @@ endif
 
 feature_check = $(eval $(feature_check_code))
 define feature_check_code
-  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) 
CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) 
$(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) test-$1.bin >/dev/null 
2>/dev/null && echo 1 || echo 0)
+  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) 
CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) 
$(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) $(OUTPUT_FEATURES)test-$1.bin 
>/dev/null 2>/dev/null && echo 1 || echo 0)
 endef
 
 feature_set = $(eval $(feature_set_code))
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index cea04ce9..8fec49d 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -1,4 +1,3 @@
-
 FILES= \
test-all.bin\
test-backtrace.bin  \
@@ -38,38 +37,40 @@ FILES=  \
test-bpf.bin\
test-get_cpuid.bin
 
+OUTPUT_FILES = $(addprefix $(OUTPUT),$(FILES))
+
 CC := $(CROSS_COMPILE)gcc -MD
 PKG_CONFIG := $(CROSS_COMPILE)pkg-config
 
-all: $(FILES)
+all: $(OUTPUT_FILES)
 
-__BUILD = $(CC) $(CFLAGS) -Wall -Werror -o $(OUTPUT)$@ $(patsubst 
%.bin,%.c,$@) $(LDFLAGS)
-  BUILD = $(__BUILD) > $(OUTPUT)$(@:.bin=.make.output) 2>&1
+__BUILD = $(CC) $(CFLAGS) -Wall -Werror -o $@ $(patsubst %.bin,%.c,$(@F)) 
$(LDFLAGS)
+  BUILD = $(__BUILD) > $(@:.bin=.make.output) 2>&1
 
 ###
 
-test-all.bin:
+$(OUTPUT)test-all.bin:
$(BUILD) -fstack-protector-all -O2 -D_FORTIFY_SOURCE=2 -ldw -lelf 
-lnuma -lelf -laudit -I/usr/include/slang -lslang $(shell $(PKG_CONFIG) --libs 
--cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) 
-DPACKAGE='"perf"' -lbfd -ldl -lz -llzma
 
-test-hello.bin:
+$(OUTPUT)test-hello.bin:
$(BUILD)
 
-test-pthread-attr-setaffinity-np.bin:
+$(OUTPUT)test-pthread-attr-setaffinity-np.bin:
$(BUILD) -D_GNU_SOURCE -lpthread
 
-test-stackprotector-all.bin:
+$(OUTPUT)test-stackprotector-all.bin:
$(BUILD) -fstack-protector-all
 
-test-fortify-source.bin:
+$(OUTPUT)test-fortify-source.bin:
$(BUILD) -O2 -D_FORTIFY_SOURCE=2
 
-test-bionic.bin:
+$(OUTPUT)test-bionic.bin:
$(BUILD)
 
-test-libelf.bin:
+$(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
 
-test-glibc.bin:
+$(OUTPUT)test-glibc.bin:
$(BUILD)
 
 DWARFLIBS := -ldw
@@ -77,37 +78,37 @@ ifeq ($(findstring -static,${LDFLAGS}),-static)
 DWARFLIBS += -lelf -lebl -lz -llzma -lbz2
 endif
 
-test-dwarf.bin:
+$(OUTPUT)test-dwarf.bin:
$(BUILD) $(DWARFLIBS)
 
-test-libelf-mmap.bin:
+$(OUTPUT)test-libelf-mmap.bin:
$(BUILD) -lelf
 
-test-libelf-getphdrnum.bin:
+$(OUTPUT)test-libelf-getphdrnum.bin:
$(BUILD) -lelf
 
-test-libnuma.bin:
+$(OUTPUT)test-libnuma.bin:
$(BUILD) -lnuma
 
-test-numa_num_possible_cpus.bin:
+$(OUTPUT)test-numa_num_possible_cpus.bin:
$(BUILD) -lnuma
 
-test-libunwind.bin:
+$(OUTPUT)test-libunwind.bin:
$(BUILD) -lelf
 
-test-libunwind-debug-frame.bin:
+$(OUTPUT)test-libunwind-debug-frame.bin:
$(BUILD) -lelf
 
-test-libaudit.bin:
+$(OUTPUT)test-libaudit.bin:
$(BUILD) -laudit
 
-test-libslang.bin:
+$(OUTPUT)test-libslang.bin:
$(BUILD) -I/usr/include/slang -lslang
 
-test-gtk2.bin:
+$(OUTPUT)test-gtk2.bin:
$(BUILD) $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null)
 
-test-gtk2-infobar.bin:
+$(OUTPUT)test-gtk2-infobar.bin:
$(BUILD) $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null)
 
 grep-libs  = $(filter -l%,$(1))
@@ -119,63 +120,63 @@ PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
 PERL_EMBED_CCOPTS = `perl -MExtUtils::Embed -e ccopts 2>/dev/null`
 FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
 
-test-libperl.bin:
+$(OUTPUT)test-libperl.bin:
$(BUILD) $(FLAGS_PERL_EMBED)
 
-test-libpython.bin:
+$(OUTPUT)test-libpython.bin:
$(BUILD)
 
-test-libpython-version.bin:
+$(OUTPUT)test-libpython-version.bin:
$(BUILD)
 
-test-libbfd.bin:
+$(OUTPUT)test-libbfd.bin:
$(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
 
-test-liberty.bin:
-   $(CC) $(CFLAGS) -Wall -Werror -o $(OUTPUT)$@ test-libbfd.c 
-DPACKAGE='"perf"' $(LDFLAGS) -lbfd -ldl -liberty
+$(OUTPUT)test-liberty.bin:
+   $(CC) $(CFLAGS) -Wall -Werror -o $@ test-libbfd.c -DPACKAGE='"perf"' 
$(LDFLAGS) -lbfd -ldl -liberty
 
-test-liberty-z.bin:
-   $(CC) $(CFLAGS) -Wall -Werror -o 

[PATCH v3 09/17] perf: Move help_unknown_cmd() to its own file

[Josh Poimboeuf]

help_unknown_cmd() is quite perf-specific because it relies on some
perf_config*() functions.  Move it and its supporting functions out into
a separate file so that help.c can be moved to a library.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/Build  |   1 +
 tools/perf/util/help-unknown-cmd.c | 103 +++
 tools/perf/util/help-unknown-cmd.h |   0
 tools/perf/util/help.c | 107 ++---
 tools/perf/util/help.h |   3 ++
 5 files changed, 110 insertions(+), 104 deletions(-)
 create mode 100644 tools/perf/util/help-unknown-cmd.c
 create mode 100644 tools/perf/util/help-unknown-cmd.h

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 65fef59..99b3dae 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -87,6 +87,7 @@ libperf-$(CONFIG_AUXTRACE) += intel-bts.o
 libperf-y += parse-branch-options.o
 libperf-y += parse-regs-options.o
 libperf-y += term.o
+libperf-y += help-unknown-cmd.o
 
 libperf-$(CONFIG_LIBBPF) += bpf-loader.o
 libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
diff --git a/tools/perf/util/help-unknown-cmd.c 
b/tools/perf/util/help-unknown-cmd.c
new file mode 100644
index 000..a0820f1
--- /dev/null
+++ b/tools/perf/util/help-unknown-cmd.c
@@ -0,0 +1,103 @@
+#include "cache.h"
+#include "help.h"
+#include "../builtin.h"
+#include "levenshtein.h"
+
+static int autocorrect;
+static struct cmdnames aliases;
+
+static int perf_unknown_cmd_config(const char *var, const char *value, void 
*cb)
+{
+   if (!strcmp(var, "help.autocorrect"))
+   autocorrect = perf_config_int(var,value);
+   /* Also use aliases for command lookup */
+   if (!prefixcmp(var, "alias."))
+   add_cmdname(, var + 6, strlen(var + 6));
+
+   return perf_default_config(var, value, cb);
+}
+
+static int levenshtein_compare(const void *p1, const void *p2)
+{
+   const struct cmdname *const *c1 = p1, *const *c2 = p2;
+   const char *s1 = (*c1)->name, *s2 = (*c2)->name;
+   int l1 = (*c1)->len;
+   int l2 = (*c2)->len;
+   return l1 != l2 ? l1 - l2 : strcmp(s1, s2);
+}
+
+static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
+{
+   unsigned int i;
+
+   ALLOC_GROW(cmds->names, cmds->cnt + old->cnt, cmds->alloc);
+
+   for (i = 0; i < old->cnt; i++)
+   cmds->names[cmds->cnt++] = old->names[i];
+   zfree(>names);
+   old->cnt = 0;
+}
+
+const char *help_unknown_cmd(const char *cmd)
+{
+   unsigned int i, n = 0, best_similarity = 0;
+   struct cmdnames main_cmds, other_cmds;
+
+   memset(_cmds, 0, sizeof(main_cmds));
+   memset(_cmds, 0, sizeof(main_cmds));
+   memset(, 0, sizeof(aliases));
+
+   perf_config(perf_unknown_cmd_config, NULL);
+
+   load_command_list("perf-", _cmds, _cmds);
+
+   add_cmd_list(_cmds, );
+   add_cmd_list(_cmds, _cmds);
+   qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(main_cmds.names), cmdname_compare);
+   uniq(_cmds);
+
+   if (main_cmds.cnt) {
+   /* This reuses cmdname->len for similarity index */
+   for (i = 0; i < main_cmds.cnt; ++i)
+   main_cmds.names[i]->len =
+   levenshtein(cmd, main_cmds.names[i]->name, 0, 
2, 1, 4);
+
+   qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(*main_cmds.names), levenshtein_compare);
+
+   best_similarity = main_cmds.names[0]->len;
+   n = 1;
+   while (n < main_cmds.cnt && best_similarity == 
main_cmds.names[n]->len)
+   ++n;
+   }
+
+   if (autocorrect && n == 1) {
+   const char *assumed = main_cmds.names[0]->name;
+
+   main_cmds.names[0] = NULL;
+   clean_cmdnames(_cmds);
+   fprintf(stderr, "WARNING: You called a perf program named '%s', 
"
+   "which does not exist.\n"
+   "Continuing under the assumption that you meant '%s'\n",
+   cmd, assumed);
+   if (autocorrect > 0) {
+   fprintf(stderr, "in %0.1f seconds automatically...\n",
+   (float)autocorrect/10.0);
+   poll(NULL, 0, autocorrect * 100);
+   }
+   return assumed;
+   }
+
+   fprintf(stderr, "perf: '%s' is not a perf-command. See 'perf 
--help'.\n", cmd);
+
+   if (main_cmds.cnt && best_similarity < 6) {
+   fprintf(stderr, "\nDid you mean %s?\n",
+   n < 2 ? "this": "one of these");
+
+   for (i = 0; i < n; i++)
+   fprintf(stderr, "\t%s\n", main_cmds.names[i]->name);
+   }
+
+   exit(1);
+}
diff --git a/tools/perf/util/help-unknown-cmd.h 
b/tools/perf/util/help-unknown-cmd.h
new file mode 100644
index 000..e69de29
diff --git a/tools/perf/util/help.c 

[PATCH v3 11/17] perf: Remove 'perf' from subcmd function and variable names

[Josh Poimboeuf]

In preparation for moving exec_cmd.c and run-command.c out of perf and
into a library, remove 'perf' from all the symbol names.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/builtin-help.c |  2 +-
 tools/perf/builtin-script.c   |  8 
 tools/perf/perf.c |  6 +++---
 tools/perf/tests/attr.c   |  2 +-
 tools/perf/util/exec_cmd.c| 20 ++--
 tools/perf/util/exec_cmd.h| 12 ++--
 tools/perf/util/help.c|  4 ++--
 tools/perf/util/run-command.c |  6 +++---
 tools/perf/util/run-command.h |  4 ++--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
index a7d588b..275aa64 100644
--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -407,7 +407,7 @@ static int get_html_page_path(struct strbuf *page_path, 
const char *page)
 #ifndef open_html
 static void open_html(const char *path)
 {
-   execl_perf_cmd("web--browse", "-c", "help.browser", path, NULL);
+   execl_cmd("web--browse", "-c", "help.browser", path, NULL);
 }
 #endif
 
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d259e9a..571016f 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1408,7 +1408,7 @@ static int list_available_scripts(const struct option 
*opt __maybe_unused,
char first_half[BUFSIZ];
char *script_root;
 
-   snprintf(scripts_path, MAXPATHLEN, "%s/scripts", perf_exec_path());
+   snprintf(scripts_path, MAXPATHLEN, "%s/scripts", get_argv_exec_path());
 
scripts_dir = opendir(scripts_path);
if (!scripts_dir)
@@ -1529,7 +1529,7 @@ int find_scripts(char **scripts_array, char 
**scripts_path_array)
if (!session)
return -1;
 
-   snprintf(scripts_path, MAXPATHLEN, "%s/scripts", perf_exec_path());
+   snprintf(scripts_path, MAXPATHLEN, "%s/scripts", get_argv_exec_path());
 
scripts_dir = opendir(scripts_path);
if (!scripts_dir) {
@@ -1587,7 +1587,7 @@ static char *get_script_path(const char *script_root, 
const char *suffix)
char lang_path[MAXPATHLEN];
char *__script_root;
 
-   snprintf(scripts_path, MAXPATHLEN, "%s/scripts", perf_exec_path());
+   snprintf(scripts_path, MAXPATHLEN, "%s/scripts", get_argv_exec_path());
 
scripts_dir = opendir(scripts_path);
if (!scripts_dir)
@@ -1823,7 +1823,7 @@ int cmd_script(int argc, const char **argv, const char 
*prefix __maybe_unused)
scripting_max_stack = itrace_synth_opts.callchain_sz;
 
/* make sure PERF_EXEC_PATH is set for scripts */
-   perf_set_argv_exec_path(perf_exec_path());
+   set_argv_exec_path(get_argv_exec_path());
 
if (argc && !script_name && !rec_script_path && !rep_script_path) {
int live_pipe[2];
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 4d94c80..c0fa9a5 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -183,9 +183,9 @@ static int handle_options(const char ***argv, int *argc, 
int *envchanged)
if (!prefixcmp(cmd, CMD_EXEC_PATH)) {
cmd += strlen(CMD_EXEC_PATH);
if (*cmd == '=')
-   perf_set_argv_exec_path(cmd + 1);
+   set_argv_exec_path(cmd + 1);
else {
-   puts(perf_exec_path());
+   puts(get_argv_exec_path());
exit(0);
}
} else if (!strcmp(cmd, "--html-path")) {
@@ -539,7 +539,7 @@ int main(int argc, const char **argv)
page_size = sysconf(_SC_PAGE_SIZE);
cacheline_size = sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
 
-   cmd = perf_extract_argv0_path(argv[0]);
+   cmd = extract_argv0_path(argv[0]);
if (!cmd)
cmd = "perf-help";
 
diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index b66730e..6337f1c 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -164,7 +164,7 @@ int test__attr(int subtest __maybe_unused)
return run_dir("./tests", "./perf");
 
/* Then installed path. */
-   snprintf(path_dir,  PATH_MAX, "%s/tests", perf_exec_path());
+   snprintf(path_dir,  PATH_MAX, "%s/tests", get_argv_exec_path());
snprintf(path_perf, PATH_MAX, "%s/perf", BINDIR);
 
if (!lstat(path_dir, ) &&
diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
index 84f9dc5..1e8d31f 100644
--- a/tools/perf/util/exec_cmd.c
+++ b/tools/perf/util/exec_cmd.c
@@ -36,7 +36,7 @@ char *system_path(const char *path)
return (char *)path;
 }
 
-const char *perf_extract_argv0_path(const char *argv0)
+const char *extract_argv0_path(const char *argv0)
 {
const char *slash;
 
@@ -55,7 +55,7 @@ const char *perf_extract_argv0_path(const char *argv0)
return argv0;
 }
 
-void 

[PATCH v3 13/17] perf: Document the fact that parse_options*() may exit

[Josh Poimboeuf]

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/parse-options.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/parse-options.h b/tools/perf/util/parse-options.h
index b04190a..fff954e 100644
--- a/tools/perf/util/parse-options.h
+++ b/tools/perf/util/parse-options.h
@@ -151,6 +151,9 @@ struct option {
 /* parse_options() will filter out the processed options and leave the
  * non-option argments in argv[].
  * Returns the number of arguments left in argv[].
+ *
+ * NOTE: parse_options() and parse_options_subcommand() may call exit() in the
+ * case of an error (or for 'special' options like --list-cmds or --list-opts).
  */
 extern int parse_options(int argc, const char **argv,
  const struct option *options,
-- 
2.4.3

--
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 04/17] perf test: remove tarpkg at end of test

[Josh Poimboeuf]

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/tests/make | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index 8ea3dff..c1fbb8e 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -259,7 +259,8 @@ $(run_O):
 tarpkg:
@cmd="$(PERF)/tests/perf-targz-src-pkg $(PERF)"; \
echo "- $@: $$cmd" && echo $$cmd > $@ && \
-   ( eval $$cmd ) >> $@ 2>&1
+   ( eval $$cmd ) >> $@ 2>&1 && \
+   rm -f $@
 
 make_kernelsrc:
@echo "- make -C  tools/perf"
-- 
2.4.3

--
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 12/17] perf: Convert parse-options.c internal functions to static

[Josh Poimboeuf]

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/parse-options.c | 18 +-
 tools/perf/util/parse-options.h |  9 -
 2 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 00a03a9..ac49525 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -367,8 +367,8 @@ static void check_typos(const char *arg, const struct 
option *options)
}
 }
 
-void parse_options_start(struct parse_opt_ctx_t *ctx,
-int argc, const char **argv, int flags)
+static void parse_options_start(struct parse_opt_ctx_t *ctx,
+   int argc, const char **argv, int flags)
 {
memset(ctx, 0, sizeof(*ctx));
ctx->argc = argc - 1;
@@ -385,9 +385,9 @@ static int usage_with_options_internal(const char * const *,
   const struct option *, int,
   struct parse_opt_ctx_t *);
 
-int parse_options_step(struct parse_opt_ctx_t *ctx,
-  const struct option *options,
-  const char * const usagestr[])
+static int parse_options_step(struct parse_opt_ctx_t *ctx,
+ const struct option *options,
+ const char * const usagestr[])
 {
int internal_help = !(ctx->flags & PARSE_OPT_NO_INTERNAL_HELP);
int excl_short_opt = 1;
@@ -496,7 +496,7 @@ exclusive:
return PARSE_OPT_HELP;
 }
 
-int parse_options_end(struct parse_opt_ctx_t *ctx)
+static int parse_options_end(struct parse_opt_ctx_t *ctx)
 {
memmove(ctx->out + ctx->cpidx, ctx->argv, ctx->argc * 
sizeof(*ctx->out));
ctx->out[ctx->cpidx + ctx->argc] = NULL;
@@ -725,9 +725,9 @@ static bool option__in_argv(const struct option *opt, const 
struct parse_opt_ctx
return false;
 }
 
-int usage_with_options_internal(const char * const *usagestr,
-   const struct option *opts, int full,
-   struct parse_opt_ctx_t *ctx)
+static int usage_with_options_internal(const char * const *usagestr,
+  const struct option *opts, int full,
+  struct parse_opt_ctx_t *ctx)
 {
struct option *ordered;
 
diff --git a/tools/perf/util/parse-options.h b/tools/perf/util/parse-options.h
index 2c7ee90..b04190a 100644
--- a/tools/perf/util/parse-options.h
+++ b/tools/perf/util/parse-options.h
@@ -197,15 +197,6 @@ extern int parse_options_usage(const char * const 
*usagestr,
   const char *optstr,
   bool short_opt);
 
-extern void parse_options_start(struct parse_opt_ctx_t *ctx,
-   int argc, const char **argv, int flags);
-
-extern int parse_options_step(struct parse_opt_ctx_t *ctx,
- const struct option *options,
- const char * const usagestr[]);
-
-extern int parse_options_end(struct parse_opt_ctx_t *ctx);
-
 
 /*- some often used options -*/
 extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
-- 
2.4.3

--
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 14/17] perf: Remove subcmd dependencies on strbuf

[Josh Poimboeuf]

Introduce and use new astrcat() and astrcatf() functions which replace
the strbuf functionality for subcmd.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/exec_cmd.c  | 27 +-
 tools/perf/util/help.c  | 14 ++
 tools/perf/util/parse-options.c | 42 +
 tools/perf/util/subcmd-util.h   | 24 +++
 4 files changed, 66 insertions(+), 41 deletions(-)
 create mode 100644 tools/perf/util/subcmd-util.h

diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
index 1e8d31f..d4f6dda 100644
--- a/tools/perf/util/exec_cmd.c
+++ b/tools/perf/util/exec_cmd.c
@@ -3,6 +3,7 @@
 #include "quote.h"
 
 #include 
+#include "subcmd-util.h"
 
 #define MAX_ARGS   32
 #define UNDEFINED  "UNDEFINED"
@@ -26,14 +27,14 @@ void exec_cmd_init(const char *exec_name, const char 
*prefix,
 
 char *system_path(const char *path)
 {
-   struct strbuf d = STRBUF_INIT;
+   char *buf = NULL;
 
if (is_absolute_path(path))
return strdup(path);
 
-   strbuf_addf(, "%s/%s", cfg_prefix, path);
-   path = strbuf_detach(, NULL);
-   return (char *)path;
+   astrcatf(, "%s/%s", cfg_prefix, path);
+
+   return buf;
 }
 
 const char *extract_argv0_path(const char *argv0)
@@ -80,22 +81,22 @@ char *get_argv_exec_path(void)
return system_path(cfg_exec_path);
 }
 
-static void add_path(struct strbuf *out, const char *path)
+static void add_path(char **out, const char *path)
 {
if (path && *path) {
if (is_absolute_path(path))
-   strbuf_addstr(out, path);
+   astrcat(out, path);
else
-   strbuf_addstr(out, make_nonrelative_path(path));
+   astrcat(out, make_nonrelative_path(path));
 
-   strbuf_addch(out, PATH_SEP);
+   astrcat(out, ":");
}
 }
 
 void setup_path(void)
 {
const char *old_path = getenv("PATH");
-   struct strbuf new_path = STRBUF_INIT;
+   char *new_path = NULL;
char *tmp = get_argv_exec_path();
 
add_path(_path, tmp);
@@ -103,13 +104,13 @@ void setup_path(void)
free(tmp);
 
if (old_path)
-   strbuf_addstr(_path, old_path);
+   astrcat(_path, old_path);
else
-   strbuf_addstr(_path, "/usr/local/bin:/usr/bin:/bin");
+   astrcat(_path, "/usr/local/bin:/usr/bin:/bin");
 
-   setenv("PATH", new_path.buf, 1);
+   setenv("PATH", new_path, 1);
 
-   strbuf_release(_path);
+   free(new_path);
 }
 
 static const char **prepare_exec_cmd(const char **argv)
diff --git a/tools/perf/util/help.c b/tools/perf/util/help.c
index 89fc81b..303a347 100644
--- a/tools/perf/util/help.c
+++ b/tools/perf/util/help.c
@@ -2,6 +2,7 @@
 #include "../builtin.h"
 #include "exec_cmd.h"
 #include "help.h"
+#include "subcmd-util.h"
 
 void add_cmdname(struct cmdnames *cmds, const char *name, size_t len)
 {
@@ -119,8 +120,7 @@ static void list_commands_in_dir(struct cmdnames *cmds,
int prefix_len;
DIR *dir = opendir(path);
struct dirent *de;
-   struct strbuf buf = STRBUF_INIT;
-   int len;
+   char *buf = NULL;
 
if (!dir)
return;
@@ -128,8 +128,7 @@ static void list_commands_in_dir(struct cmdnames *cmds,
prefix = "perf-";
prefix_len = strlen(prefix);
 
-   strbuf_addf(, "%s/", path);
-   len = buf.len;
+   astrcatf(, "%s/", path);
 
while ((de = readdir(dir)) != NULL) {
int entlen;
@@ -137,9 +136,8 @@ static void list_commands_in_dir(struct cmdnames *cmds,
if (prefixcmp(de->d_name, prefix))
continue;
 
-   strbuf_setlen(, len);
-   strbuf_addstr(, de->d_name);
-   if (!is_executable(buf.buf))
+   astrcat(, de->d_name);
+   if (!is_executable(buf))
continue;
 
entlen = strlen(de->d_name) - prefix_len;
@@ -149,7 +147,7 @@ static void list_commands_in_dir(struct cmdnames *cmds,
add_cmdname(cmds, de->d_name + prefix_len, entlen);
}
closedir(dir);
-   strbuf_release();
+   free(buf);
 }
 
 void load_command_list(const char *prefix,
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index ac49525..0189f78 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -1,4 +1,5 @@
 #include "util.h"
+#include "subcmd-util.h"
 #include "parse-options.h"
 #include "cache.h"
 #include "header.h"
@@ -7,7 +8,7 @@
 #define OPT_SHORT 1
 #define OPT_UNSET 2
 
-static struct strbuf error_buf = STRBUF_INIT;
+char *error_buf;
 
 static const char *cfg_exec_name = "UNDEFINED";
 
@@ -510,19 +511,18 @@ int parse_options_subcommand(int argc, const char **argv, 
const struct option *o
 
/* build 

[PATCH v3 05/17] perf build: Fix 'make clean'

[Josh Poimboeuf]

Add some missing files to the 'make clean' target.

Reported-by: Jiri Olsa 
Signed-off-by: Josh Poimboeuf 
---
 tools/perf/Makefile.perf | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 929a32b..906c723 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -582,15 +582,16 @@ $(INSTALL_DOC_TARGETS):
 #
 config-clean:
$(call QUIET_CLEAN, config)
-   $(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
+   $(Q)$(MAKE) -C $(srctree)/tools/build/feature/ $(if 
$(OUTPUT),OUTPUT=$(OUTPUT)feature/,) clean >/dev/null
 
 clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean config-clean
$(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_FILE) $(OUTPUT)perf-archive 
$(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
-   $(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name 
'\.*.d' -delete
+   $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name 
'\.*.cmd' -delete -o -name '\.*.d' -delete
$(Q)$(RM) $(OUTPUT).config-detected
$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf 
perf-read-vdso32 perf-read-vdsox32
$(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
*/*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
$(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* \
-   $(OUTPUT)util/intel-pt-decoder/inat-tables.c
+   $(OUTPUT)util/intel-pt-decoder/inat-tables.c $(OUTPUT)fixdep \
+   $(OUTPUT)tests/llvm-src-{base,kbuild,prologue}.c
$(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
$(python-clean)
 
-- 
2.4.3

--
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 15/17] perf: Finalize subcmd independence

[Josh Poimboeuf]

For the files that will be moved to the subcmd library, remove all their
perf-specific includes and duplicate any needed functionality.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/exec_cmd.c  | 75 +
 tools/perf/util/help.c  | 47 +++---
 tools/perf/util/help.h  |  4 ++-
 tools/perf/util/pager.c |  7 +++-
 tools/perf/util/parse-options.c | 68 +++--
 tools/perf/util/parse-options.h |  2 +-
 tools/perf/util/run-command.c   | 16 ++---
 tools/perf/util/run-command.h   |  2 ++
 tools/perf/util/sigchain.c  |  3 +-
 tools/perf/util/subcmd-util.h   | 67 
 tools/perf/util/util.h  | 14 
 11 files changed, 247 insertions(+), 58 deletions(-)

diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
index d4f6dda..4a9292d 100644
--- a/tools/perf/util/exec_cmd.c
+++ b/tools/perf/util/exec_cmd.c
@@ -1,11 +1,15 @@
-#include "cache.h"
-#include "exec_cmd.h"
-#include "quote.h"
-
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include "subcmd-util.h"
+#include "exec_cmd.h"
 
 #define MAX_ARGS   32
+#define PATH_MAX   4096
 #define UNDEFINED  "UNDEFINED"
 
 static const char *argv_exec_path;
@@ -25,6 +29,63 @@ void exec_cmd_init(const char *exec_name, const char *prefix,
cfg_exec_path_env   = exec_path_env;
 }
 
+#define is_dir_sep(c) ((c) == '/')
+
+static size_t strlcpy(char *dest, const char *src, size_t size)
+{
+   size_t ret = strlen(src);
+
+   if (size) {
+   size_t len = (ret >= size) ? size - 1 : ret;
+
+   memcpy(dest, src, len);
+   dest[len] = '\0';
+   }
+
+   return ret;
+}
+
+static int is_absolute_path(const char *path)
+{
+   return path[0] == '/';
+}
+
+static const char *get_pwd_cwd(void)
+{
+   static char cwd[PATH_MAX + 1];
+   char *pwd;
+   struct stat cwd_stat, pwd_stat;
+   if (getcwd(cwd, PATH_MAX) == NULL)
+   return NULL;
+   pwd = getenv("PWD");
+   if (pwd && strcmp(pwd, cwd)) {
+   stat(cwd, _stat);
+   if (!stat(pwd, _stat) &&
+   pwd_stat.st_dev == cwd_stat.st_dev &&
+   pwd_stat.st_ino == cwd_stat.st_ino) {
+   strlcpy(cwd, pwd, PATH_MAX);
+   }
+   }
+   return cwd;
+}
+
+static const char *make_nonrelative_path(const char *path)
+{
+   static char buf[PATH_MAX + 1];
+
+   if (is_absolute_path(path)) {
+   if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+   die("Too long path: %.*s", 60, path);
+   } else {
+   const char *cwd = get_pwd_cwd();
+   if (!cwd)
+   die("Cannot determine the current working directory");
+   if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+   die("Too long path: %.*s", 60, path);
+   }
+   return buf;
+}
+
 char *system_path(const char *path)
 {
char *buf = NULL;
@@ -156,8 +217,10 @@ int execl_cmd(const char *cmd,...)
break;
}
va_end(param);
-   if (MAX_ARGS <= argc)
-   return error("too many args to run %s", cmd);
+   if (MAX_ARGS <= argc) {
+   fprintf(stderr, " Error: too many args to run %s\n", cmd);
+   return -1;
+   }
 
argv[argc] = NULL;
return execv_cmd(argv);
diff --git a/tools/perf/util/help.c b/tools/perf/util/help.c
index 303a347..8169480 100644
--- a/tools/perf/util/help.c
+++ b/tools/perf/util/help.c
@@ -1,8 +1,15 @@
-#include "cache.h"
-#include "../builtin.h"
-#include "exec_cmd.h"
-#include "help.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "subcmd-util.h"
+#include "help.h"
+#include "exec_cmd.h"
 
 void add_cmdname(struct cmdnames *cmds, const char *name, size_t len)
 {
@@ -70,6 +77,28 @@ void exclude_cmds(struct cmdnames *cmds, struct cmdnames 
*excludes)
cmds->cnt = cj;
 }
 
+static void get_term_dimensions(struct winsize *ws)
+{
+   char *s = getenv("LINES");
+
+   if (s != NULL) {
+   ws->ws_row = atoi(s);
+   s = getenv("COLUMNS");
+   if (s != NULL) {
+   ws->ws_col = atoi(s);
+   if (ws->ws_row && ws->ws_col)
+   return;
+   }
+   }
+#ifdef TIOCGWINSZ
+   if (ioctl(1, TIOCGWINSZ, ws) == 0 &&
+   ws->ws_row && ws->ws_col)
+   return;
+#endif
+   ws->ws_row = 25;
+   ws->ws_col = 80;
+}
+
 static void pretty_print_string_list(struct cmdnames *cmds, int longest)
 {
int cols = 1, rows;
@@ -113,6 +142,14 @@ static int is_executable(const char *name)
return st.st_mode & S_IXUSR;
 }
 
+static int 

[PATCH v3 16/17] perf subcmd: Create subcmd library

[Josh Poimboeuf]

Move the subcommand-related files from perf to a new library named
libsubcmd.a.

Since we're moving files anyway, go ahead and rename 'exec_cmd.*' to
'exec-cmd.*' to be consistent with the naming of all the other files.

Signed-off-by: Josh Poimboeuf 
---
 tools/lib/subcmd/Build |  6 +++
 tools/lib/subcmd/Makefile  | 48 ++
 .../util/exec_cmd.c => lib/subcmd/exec-cmd.c}  |  2 +-
 .../util/exec_cmd.h => lib/subcmd/exec-cmd.h}  |  0
 tools/{perf/util => lib/subcmd}/help.c |  2 +-
 tools/{perf/util => lib/subcmd}/help.h |  0
 tools/{perf/util => lib/subcmd}/pager.c|  0
 tools/{perf/util => lib/subcmd}/pager.h|  0
 tools/{perf/util => lib/subcmd}/parse-options.c|  0
 tools/{perf/util => lib/subcmd}/parse-options.h|  0
 tools/{perf/util => lib/subcmd}/run-command.c  |  2 +-
 tools/{perf/util => lib/subcmd}/run-command.h  |  0
 tools/{perf/util => lib/subcmd}/sigchain.c |  0
 tools/{perf/util => lib/subcmd}/sigchain.h |  0
 tools/{perf/util => lib/subcmd}/subcmd-util.h  |  0
 tools/perf/MANIFEST|  1 +
 tools/perf/Makefile.perf   | 20 +++--
 tools/perf/arch/x86/util/intel-pt.c|  2 +-
 tools/perf/bench/futex-hash.c  |  2 +-
 tools/perf/bench/futex-lock-pi.c   |  2 +-
 tools/perf/bench/futex-requeue.c   |  2 +-
 tools/perf/bench/futex-wake-parallel.c |  2 +-
 tools/perf/bench/futex-wake.c  |  2 +-
 tools/perf/bench/mem-functions.c   |  2 +-
 tools/perf/bench/numa.c|  2 +-
 tools/perf/bench/sched-messaging.c |  2 +-
 tools/perf/bench/sched-pipe.c  |  2 +-
 tools/perf/builtin-annotate.c  |  2 +-
 tools/perf/builtin-bench.c |  2 +-
 tools/perf/builtin-buildid-cache.c |  2 +-
 tools/perf/builtin-buildid-list.c  |  2 +-
 tools/perf/builtin-config.c|  2 +-
 tools/perf/builtin-data.c  |  2 +-
 tools/perf/builtin-evlist.c|  2 +-
 tools/perf/builtin-help.c  |  8 ++--
 tools/perf/builtin-inject.c|  2 +-
 tools/perf/builtin-kmem.c  |  2 +-
 tools/perf/builtin-kvm.c   |  2 +-
 tools/perf/builtin-list.c  |  2 +-
 tools/perf/builtin-lock.c  |  2 +-
 tools/perf/builtin-mem.c   |  2 +-
 tools/perf/builtin-probe.c |  2 +-
 tools/perf/builtin-record.c|  2 +-
 tools/perf/builtin-report.c|  2 +-
 tools/perf/builtin-sched.c |  2 +-
 tools/perf/builtin-script.c|  4 +-
 tools/perf/builtin-stat.c  |  2 +-
 tools/perf/builtin-timechart.c |  2 +-
 tools/perf/builtin-top.c   |  2 +-
 tools/perf/builtin-trace.c |  4 +-
 tools/perf/perf.c  |  6 +--
 tools/perf/tests/attr.c|  2 +-
 tools/perf/tests/builtin-test.c|  2 +-
 tools/perf/util/Build  |  6 ---
 tools/perf/util/auxtrace.c |  2 +-
 tools/perf/util/cache.h|  2 +-
 tools/perf/util/cgroup.c   |  2 +-
 tools/perf/util/config.c   |  2 +-
 tools/perf/util/evlist.c   |  2 +-
 tools/perf/util/help-unknown-cmd.c |  2 +-
 tools/perf/util/parse-branch-options.c |  2 +-
 tools/perf/util/parse-events.c |  4 +-
 tools/perf/util/parse-regs-options.c   |  2 +-
 tools/perf/util/sort.h |  2 +-
 64 files changed, 128 insertions(+), 67 deletions(-)
 create mode 100644 tools/lib/subcmd/Build
 create mode 100644 tools/lib/subcmd/Makefile
 rename tools/{perf/util/exec_cmd.c => lib/subcmd/exec-cmd.c} (99%)
 rename tools/{perf/util/exec_cmd.h => lib/subcmd/exec-cmd.h} (100%)
 rename tools/{perf/util => lib/subcmd}/help.c (99%)
 rename tools/{perf/util => lib/subcmd}/help.h (100%)
 rename tools/{perf/util => lib/subcmd}/pager.c (100%)
 rename tools/{perf/util => lib/subcmd}/pager.h (100%)
 rename tools/{perf/util => lib/subcmd}/parse-options.c (100%)
 rename tools/{perf/util => lib/subcmd}/parse-options.h (100%)
 rename tools/{perf/util => lib/subcmd}/run-command.c (99%)
 rename tools/{perf/util => lib/subcmd}/run-command.h (100%)
 rename tools/{perf/util => lib/subcmd}/sigchain.c (100%)
 rename tools/{perf/util => lib/subcmd}/sigchain.h (100%)
 rename tools/{perf/util => 

[PATCH v3 06/17] perf build: Rename LIB_PATH -> API_PATH

[Josh Poimboeuf]

'LIB_PATH' is a misnomer because there are multiple library paths.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/Makefile.perf | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 906c723..388ec64 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -185,13 +185,13 @@ ifneq ($(OUTPUT),)
   TE_PATH=$(OUTPUT)
   BPF_PATH=$(OUTPUT)
 ifneq ($(subdir),)
-  LIB_PATH=$(OUTPUT)/../lib/api/
+  API_PATH=$(OUTPUT)/../lib/api/
 else
-  LIB_PATH=$(OUTPUT)
+  API_PATH=$(OUTPUT)
 endif
 else
   TE_PATH=$(TRACE_EVENT_DIR)
-  LIB_PATH=$(LIB_DIR)
+  API_PATH=$(LIB_DIR)
   BPF_PATH=$(BPF_DIR)
 endif
 
@@ -201,7 +201,7 @@ export LIBTRACEEVENT
 LIBTRACEEVENT_DYNAMIC_LIST = $(TE_PATH)libtraceevent-dynamic-list
 LIBTRACEEVENT_DYNAMIC_LIST_LDFLAGS = -Xlinker 
--dynamic-list=$(LIBTRACEEVENT_DYNAMIC_LIST)
 
-LIBAPI = $(LIB_PATH)libapi.a
+LIBAPI = $(API_PATH)libapi.a
 export LIBAPI
 
 LIBBPF = $(BPF_PATH)libbpf.a
-- 
2.4.3

--
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 07/17] perf: Create pager.h

[Josh Poimboeuf]

Move the 'pager' function prototypes into a new pager.h so that the
pager code can be moved out to a library.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/cache.h | 5 +
 tools/perf/util/pager.h | 7 +++
 2 files changed, 8 insertions(+), 4 deletions(-)
 create mode 100644 tools/perf/util/pager.h

diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 4c2b764..9ca4a58 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -4,6 +4,7 @@
 #include 
 #include "util.h"
 #include "strbuf.h"
+#include "pager.h"
 #include "../perf.h"
 #include "../ui/ui.h"
 
@@ -28,10 +29,6 @@ extern int perf_config_bool(const char *, const char *);
 extern int config_error_nonbool(const char *);
 extern const char *perf_config_dirname(const char *, const char *);
 
-/* pager.c */
-extern void setup_pager(void);
-extern int pager_in_use(void);
-
 char *alias_lookup(const char *alias);
 int split_cmdline(char *cmdline, const char ***argv);
 
diff --git a/tools/perf/util/pager.h b/tools/perf/util/pager.h
new file mode 100644
index 000..2794a83
--- /dev/null
+++ b/tools/perf/util/pager.h
@@ -0,0 +1,7 @@
+#ifndef __PERF_PAGER_H
+#define __PERF_PAGER_H
+
+extern void setup_pager(void);
+extern int pager_in_use(void);
+
+#endif /* __PERF_PAGER_H */
-- 
2.4.3

--
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 17/17] tools subcmd: Rename subcmd header include guards

[Josh Poimboeuf]

Signed-off-by: Josh Poimboeuf 
---
 tools/lib/subcmd/exec-cmd.h  | 6 +++---
 tools/lib/subcmd/help.h  | 6 +++---
 tools/lib/subcmd/pager.h | 6 +++---
 tools/lib/subcmd/parse-options.h | 7 ---
 tools/lib/subcmd/run-command.h   | 6 +++---
 tools/lib/subcmd/sigchain.h  | 6 +++---
 tools/lib/subcmd/subcmd-util.h   | 6 +++---
 7 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/tools/lib/subcmd/exec-cmd.h b/tools/lib/subcmd/exec-cmd.h
index f1bd343..5d08bda 100644
--- a/tools/lib/subcmd/exec-cmd.h
+++ b/tools/lib/subcmd/exec-cmd.h
@@ -1,5 +1,5 @@
-#ifndef __PERF_EXEC_CMD_H
-#define __PERF_EXEC_CMD_H
+#ifndef __SUBCMD_EXEC_CMD_H
+#define __SUBCMD_EXEC_CMD_H
 
 extern void exec_cmd_init(const char *exec_name, const char *prefix,
  const char *exec_path, const char *exec_path_env);
@@ -13,4 +13,4 @@ extern int execl_cmd(const char *cmd, ...);
 extern char *get_argv_exec_path(void);
 extern char *system_path(const char *path);
 
-#endif /* __PERF_EXEC_CMD_H */
+#endif /* __SUBCMD_EXEC_CMD_H */
diff --git a/tools/lib/subcmd/help.h b/tools/lib/subcmd/help.h
index 096c8bc..e145a02 100644
--- a/tools/lib/subcmd/help.h
+++ b/tools/lib/subcmd/help.h
@@ -1,5 +1,5 @@
-#ifndef __PERF_HELP_H
-#define __PERF_HELP_H
+#ifndef __SUBCMD_HELP_H
+#define __SUBCMD_HELP_H
 
 #include 
 
@@ -31,4 +31,4 @@ int is_in_cmdlist(struct cmdnames *c, const char *s);
 void list_commands(const char *title, struct cmdnames *main_cmds,
   struct cmdnames *other_cmds);
 
-#endif /* __PERF_HELP_H */
+#endif /* __SUBCMD_HELP_H */
diff --git a/tools/lib/subcmd/pager.h b/tools/lib/subcmd/pager.h
index d6a591a..8b83714 100644
--- a/tools/lib/subcmd/pager.h
+++ b/tools/lib/subcmd/pager.h
@@ -1,9 +1,9 @@
-#ifndef __PERF_PAGER_H
-#define __PERF_PAGER_H
+#ifndef __SUBCMD_PAGER_H
+#define __SUBCMD_PAGER_H
 
 extern void pager_init(const char *pager_env);
 
 extern void setup_pager(void);
 extern int pager_in_use(void);
 
-#endif /* __PERF_PAGER_H */
+#endif /* __SUBCMD_PAGER_H */
diff --git a/tools/lib/subcmd/parse-options.h b/tools/lib/subcmd/parse-options.h
index 7f0c88d..6ba1859 100644
--- a/tools/lib/subcmd/parse-options.h
+++ b/tools/lib/subcmd/parse-options.h
@@ -1,5 +1,5 @@
-#ifndef __PERF_PARSE_OPTIONS_H
-#define __PERF_PARSE_OPTIONS_H
+#ifndef __SUBCMD_PARSE_OPTIONS_H
+#define __SUBCMD_PARSE_OPTIONS_H
 
 #include 
 #include 
@@ -222,4 +222,5 @@ extern int parse_opt_verbosity_cb(const struct option *, 
const char *, int);
 extern const char *parse_options_fix_filename(const char *prefix, const char 
*file);
 
 void set_option_flag(struct option *opts, int sopt, const char *lopt, int 
flag);
-#endif /* __PERF_PARSE_OPTIONS_H */
+
+#endif /* __SUBCMD_PARSE_OPTIONS_H */
diff --git a/tools/lib/subcmd/run-command.h b/tools/lib/subcmd/run-command.h
index 4a55393..fe2befe 100644
--- a/tools/lib/subcmd/run-command.h
+++ b/tools/lib/subcmd/run-command.h
@@ -1,5 +1,5 @@
-#ifndef __PERF_RUN_COMMAND_H
-#define __PERF_RUN_COMMAND_H
+#ifndef __SUBCMD_RUN_COMMAND_H
+#define __SUBCMD_RUN_COMMAND_H
 
 #include 
 
@@ -57,4 +57,4 @@ int run_command(struct child_process *);
 #define RUN_COMMAND_STDOUT_TO_STDERR 4
 int run_command_v_opt(const char **argv, int opt);
 
-#endif /* __PERF_RUN_COMMAND_H */
+#endif /* __SUBCMD_RUN_COMMAND_H */
diff --git a/tools/lib/subcmd/sigchain.h b/tools/lib/subcmd/sigchain.h
index 959d64e..0c919f2 100644
--- a/tools/lib/subcmd/sigchain.h
+++ b/tools/lib/subcmd/sigchain.h
@@ -1,5 +1,5 @@
-#ifndef __PERF_SIGCHAIN_H
-#define __PERF_SIGCHAIN_H
+#ifndef __SUBCMD_SIGCHAIN_H
+#define __SUBCMD_SIGCHAIN_H
 
 typedef void (*sigchain_fun)(int);
 
@@ -7,4 +7,4 @@ int sigchain_pop(int sig);
 
 void sigchain_push_common(sigchain_fun f);
 
-#endif /* __PERF_SIGCHAIN_H */
+#endif /* __SUBCMD_SIGCHAIN_H */
diff --git a/tools/lib/subcmd/subcmd-util.h b/tools/lib/subcmd/subcmd-util.h
index 321aeb1..fc2e45d 100644
--- a/tools/lib/subcmd/subcmd-util.h
+++ b/tools/lib/subcmd/subcmd-util.h
@@ -1,5 +1,5 @@
-#ifndef __PERF_SUBCMD_UTIL_H
-#define __PERF_SUBCMD_UTIL_H
+#ifndef __SUBCMD_UTIL_H
+#define __SUBCMD_UTIL_H
 
 #include 
 #include 
@@ -88,4 +88,4 @@ static inline int prefixcmp(const char *str, const char 
*prefix)
return (unsigned char)*prefix - (unsigned char)*str;
 }
 
-#endif /* __PERF_SUBCMD_UTIL_H */
+#endif /* __SUBCMD_UTIL_H */
-- 
2.4.3

--
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 08/17] perf: Remove check for unused PERF_PAGER_IN_USE

[Josh Poimboeuf]

PERF_PAGER_IN_USE doesn't seem to be used anywhere, so let's remove it.

This will also make it easier to move pager.c into a separate library.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/util/pager.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c
index 53ef006..7dcbef6 100644
--- a/tools/perf/util/pager.c
+++ b/tools/perf/util/pager.c
@@ -85,11 +85,5 @@ void setup_pager(void)
 
 int pager_in_use(void)
 {
-   const char *env;
-
-   if (spawned_pager)
-   return 1;
-
-   env = getenv("PERF_PAGER_IN_USE");
-   return env ? perf_config_bool("PERF_PAGER_IN_USE", env) : 0;
+   return spawned_pager;
 }
-- 
2.4.3

--
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 03/17] perf test: Add Build file to dependencies for llvm-src-*.c

[Josh Poimboeuf]

Because the Build file writes source code to the generated llvm-src-*.c
files, it should be listed as one of the dependencies, so that any
future changes to the code being echoed won't require a 'make clean'.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/tests/Build | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 0ff8a97..f23fb7e 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -35,21 +35,21 @@ perf-y += llvm.o llvm-src-base.o llvm-src-kbuild.o 
llvm-src-prologue.o
 perf-y += bpf.o
 perf-y += topology.o
 
-$(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c
+$(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build
$(call rule_mkdir)
$(Q)echo '#include ' > $@
$(Q)echo 'const char test_llvm__bpf_base_prog[] =' >> $@
$(Q)sed -e 's/"/\\"/g' -e 's/\(.*\)/"\1\\n"/g' $< >> $@
$(Q)echo ';' >> $@
 
-$(OUTPUT)tests/llvm-src-kbuild.c: tests/bpf-script-test-kbuild.c
+$(OUTPUT)tests/llvm-src-kbuild.c: tests/bpf-script-test-kbuild.c tests/Build
$(call rule_mkdir)
$(Q)echo '#include ' > $@
$(Q)echo 'const char test_llvm__bpf_test_kbuild_prog[] =' >> $@
$(Q)sed -e 's/"/\\"/g' -e 's/\(.*\)/"\1\\n"/g' $< >> $@
$(Q)echo ';' >> $@
 
-$(OUTPUT)tests/llvm-src-prologue.c: tests/bpf-script-test-prologue.c
+$(OUTPUT)tests/llvm-src-prologue.c: tests/bpf-script-test-prologue.c 
tests/Build
$(call rule_mkdir)
$(Q)echo '#include ' > $@
$(Q)echo 'const char test_llvm__bpf_test_prologue_prog[] =' >> $@
-- 
2.4.3

--
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 10/17] perf: Provide subcmd configuration at runtime

[Josh Poimboeuf]

Create init functions for exec_cmd.c, parse-option.c, and pager.c.  This
allows their configuration to be specified at runtime so they can be
split out into a separate library which can be used by other programs.

Signed-off-by: Josh Poimboeuf 
---
 tools/perf/Build|  5 -
 tools/perf/perf.c   |  7 ++-
 tools/perf/util/Build   |  1 -
 tools/perf/util/cache.h |  1 +
 tools/perf/util/exec_cmd.c  | 28 +---
 tools/perf/util/exec_cmd.h  |  3 +++
 tools/perf/util/pager.c |  9 -
 tools/perf/util/pager.h |  2 ++
 tools/perf/util/parse-options.c | 10 +-
 tools/perf/util/parse-options.h |  2 ++
 10 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/tools/perf/Build b/tools/perf/Build
index 2a41217..00c4b8c 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -36,7 +36,10 @@ paths += -DPERF_MAN_PATH="BUILD_STR($(mandir_SQ))"
 
 CFLAGS_builtin-help.o  += $(paths)
 CFLAGS_builtin-timechart.o += $(paths)
-CFLAGS_perf.o  += -DPERF_HTML_PATH="BUILD_STR($(htmldir_SQ))" 
-include $(OUTPUT)PERF-VERSION-FILE
+CFLAGS_perf.o  += -DPERF_HTML_PATH="BUILD_STR($(htmldir_SQ))"  
\
+ -DPERF_EXEC_PATH="BUILD_STR($(perfexecdir_SQ))"   
\
+ -DPREFIX="BUILD_STR($(prefix_SQ))"
\
+ -include $(OUTPUT)PERF-VERSION-FILE
 CFLAGS_builtin-trace.o+= 
-DSTRACE_GROUPS_DIR="BUILD_STR($(STRACE_GROUPS_DIR_SQ))"
 
 libperf-y += util/
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 59ea48c..4d94c80 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -119,7 +119,7 @@ static void commit_pager_choice(void)
 {
switch (use_pager) {
case 0:
-   setenv("PERF_PAGER", "cat", 1);
+   setenv(PERF_PAGER_ENVIRONMENT, "cat", 1);
break;
case 1:
/* setup_pager(); */
@@ -530,6 +530,11 @@ int main(int argc, const char **argv)
const char *cmd;
char sbuf[STRERR_BUFSIZE];
 
+   /* libsubcmd init */
+   exec_cmd_init("perf", PREFIX, PERF_EXEC_PATH, EXEC_PATH_ENVIRONMENT);
+   parse_options_init("perf");
+   pager_init(PERF_PAGER_ENVIRONMENT);
+
/* The page_size is placed in util object. */
page_size = sysconf(_SC_PAGE_SIZE);
cacheline_size = sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 99b3dae..470515b 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -113,7 +113,6 @@ libperf-$(CONFIG_ZLIB) += zlib.o
 libperf-$(CONFIG_LZMA) += lzma.o
 
 CFLAGS_config.o   += -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
-CFLAGS_exec_cmd.o += -DPERF_EXEC_PATH="BUILD_STR($(perfexecdir_SQ))" 
-DPREFIX="BUILD_STR($(prefix_SQ))"
 
 $(OUTPUT)util/parse-events-flex.c: util/parse-events.l 
$(OUTPUT)util/parse-events-bison.c
$(call rule_mkdir)
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 9ca4a58..4b9d7da 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -19,6 +19,7 @@
 #define DEFAULT_PERF_DIR_ENVIRONMENT ".perf"
 #define PERF_DEBUGFS_ENVIRONMENT "PERF_DEBUGFS_DIR"
 #define PERF_TRACEFS_ENVIRONMENT "PERF_TRACEFS_DIR"
+#define PERF_PAGER_ENVIRONMENT "PERF_PAGER"
 
 typedef int (*config_fn_t)(const char *, const char *, void *);
 extern int perf_default_config(const char *, const char *, void *);
diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
index 1099e92..84f9dc5 100644
--- a/tools/perf/util/exec_cmd.c
+++ b/tools/perf/util/exec_cmd.c
@@ -5,19 +5,33 @@
 #include 
 
 #define MAX_ARGS   32
+#define UNDEFINED  "UNDEFINED"
 
 static const char *argv_exec_path;
 static const char *argv0_path;
 
+static const char *cfg_exec_name   = UNDEFINED;
+static const char *cfg_prefix  = UNDEFINED;
+static const char *cfg_exec_path   = UNDEFINED;
+static const char *cfg_exec_path_env   = UNDEFINED;
+
+void exec_cmd_init(const char *exec_name, const char *prefix,
+  const char *exec_path, const char *exec_path_env)
+{
+   cfg_exec_name   = exec_name;
+   cfg_prefix  = prefix;
+   cfg_exec_path   = exec_path;
+   cfg_exec_path_env   = exec_path_env;
+}
+
 char *system_path(const char *path)
 {
-   static const char *prefix = PREFIX;
struct strbuf d = STRBUF_INIT;
 
if (is_absolute_path(path))
return strdup(path);
 
-   strbuf_addf(, "%s/%s", prefix, path);
+   strbuf_addf(, "%s/%s", cfg_prefix, path);
path = strbuf_detach(, NULL);
return (char *)path;
 }
@@ -47,7 +61,7 @@ void perf_set_argv_exec_path(const char *exec_path)
/*
 * Propagate this setting to external programs.
 */
-   setenv(EXEC_PATH_ENVIRONMENT, exec_path, 1);
+   setenv(cfg_exec_path_env, exec_path, 1);
 }
 
 
@@ 

Re: [PATCH 1/2] extcon: arizona: Add device bindings for the micd configurations

[Chanwoo Choi]

Hi Charles,

On 2015년 12월 11일 02:08, Charles Keepax wrote:
> Add device bindings to support configuring the jack detection
> configurations. Each configuration needs to specify the connection of
> the mic det pins, which micbias should be used and the value of the
> micd polarity GPIO required to activate that configuration.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/extcon/extcon-arizona.c | 53 
> +++--
>  1 file changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 8647533..edbf2e1 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1201,7 +1201,54 @@ static void arizona_micd_set_level(struct arizona 
> *arizona, int index,
>   regmap_update_bits(arizona->regmap, reg, mask, level);
>  }
>  
> -static int arizona_extcon_device_get_pdata(struct arizona *arizona)
> +static int arizona_extcon_get_micd_configs(struct device *dev,
> +struct arizona *arizona)
> +{
> + const char * const prop = "wlf,micd-configs";
> + const int entries_per_config = 3;
> + struct arizona_micd_config *micd_configs;
> + int nconfs, ret;
> + int i, j;
> + u32 *vals;
> +
> + nconfs = device_property_read_u32_array(arizona->dev, prop, NULL, 0);
> + if (nconfs <= 0)
> + return 0;
> +
> + vals = kcalloc(nconfs, sizeof(u32), GFP_KERNEL);
> + if (!vals)
> + return -ENOMEM;
> +
> + ret = device_property_read_u32_array(arizona->dev, prop, vals, nconfs);
> + if (ret < 0)
> + goto out;
> +
> + nconfs /= entries_per_config;
> +
> + micd_configs = devm_kzalloc(dev,
> + nconfs * sizeof(struct arizona_micd_range),
> + GFP_KERNEL);
> + if (!micd_configs) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + for (i = 0, j = 0; i < nconfs; ++i) {
> + micd_configs[i].src = vals[j++] ? ARIZONA_ACCDET_SRC : 0;
> + micd_configs[i].bias = vals[j++];
> + micd_configs[i].gpio = vals[j++];
> + }
> +
> + arizona->pdata.micd_configs = micd_configs;
> + arizona->pdata.num_micd_configs = nconfs;
> +
> +out:
> + kfree(vals);
> + return ret;
> +}
> +
> +static int arizona_extcon_device_get_pdata(struct device *dev,
> +struct arizona *arizona)
>  {
>   struct arizona_pdata *pdata = >pdata;
>   unsigned int val = ARIZONA_ACCDET_MODE_HPL;
> @@ -1249,6 +1296,8 @@ static int arizona_extcon_device_get_pdata(struct 
> arizona *arizona)
>   pdata->jd_gpio5_nopull = device_property_read_bool(arizona->dev,
>   "wlf,use-jd2-nopull");
>  
> + arizona_extcon_get_micd_configs(dev, arizona);

You need to check out the return value of arizona_extcon_get_micd_configs().
If arizona_extcon_get_micd_configs() returns the error, 
arizona_extcon_device_get_pdata() don't handle the error case.

> +
>   return 0;
>  }
>  
> @@ -1270,7 +1319,7 @@ static int arizona_extcon_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   if (!dev_get_platdata(arizona->dev))
> - arizona_extcon_device_get_pdata(arizona);
> + arizona_extcon_device_get_pdata(>dev, arizona);
>  
>   info->micvdd = devm_regulator_get(>dev, "MICVDD");
>   if (IS_ERR(info->micvdd)) {
> 

Except for above comment, Looks good to me.
Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

--
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 0/4] Replace tty->closing

[Greg Kroah-Hartman]

On Sun, Dec 13, 2015 at 04:16:36PM -0800, Peter Hurley wrote:
> Greg,
> 
> Would you drop these 4 patches from tty-testing please?

Now dropped.
--
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] usb: gadget: forbid queuing request to a disabled ep

[changbin . du]

From: "Du, Changbin" 

Queue a request to disabled ep  doesn't make sense, and induce caller
make mistakes.

Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive_file_work, mtp queues a request
   to ep. (The mtp driver need improve its synchronization logic!)
3) mtp_function_unbind is invoked and all mtp requests are freed.
4) when udc process the request queued on step 2, will cause kernel
   NULL pointer dereference exception.

Signed-off-by: Du, Changbin 
---
change from v1: add WARN_ON_ONCE message.

---
 include/linux/usb/gadget.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..b566a4b 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct usb_ep *ep,
 static inline int usb_ep_queue(struct usb_ep *ep,
   struct usb_request *req, gfp_t gfp_flags)
 {
+   if (WARN_ON_ONCE(!ep->enabled))
+   return -ESHUTDOWN;
+
return ep->ops->queue(ep, req, gfp_flags);
 }
 
-- 
2.5.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 1/1] fs:ubifs:recovery:fixup UBIFS cannot recover master node issue

[beanhuo]

Dear Richard

> Bean,
> 
> Am 11.12.2015 um 09:26 schrieb Bean Huo 霍斌斌 (beanhuo):
> > For MLC NAND, paired page issue is now a common known issue.
> > This patch is just for master node cannot be recovered while there
> > will two pages be damaged in one single master node block.
> > As for this patch, if there are more than one page data in master node
> > block being damaged, and as long as exist one uncorrupted master node
> > block, master node will be recovered.
> 
> So, this patch is part if a larger patch series to make UBIFS MLC aware?

No, this is not one part of my path series, just a single and dedicated to 
Master node.

> > This patch has been tested on Micron MLC NAND MT29F32G08CBADAWP.
> > Issue descripted:

> > http://lists.infradead.org/pipermail/linux-mtd/2015-November/063016.ht
> > ml
> >
> > Signed-off-by: Bean Huo 
> > ---
> >  fs/ubifs/recovery.c | 75
> > ++---
> >  1 file changed, 49 insertions(+), 26 deletions(-)
> >
> > diff --git a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c index
> > 695fc71..e3154e6 100644
> > --- a/fs/ubifs/recovery.c
> > +++ b/fs/ubifs/recovery.c
> > @@ -128,7 +128,7 @@ static int get_master_node(const struct ubifs_info
> *c, int lnum, void **pbuf,
> > while (offs + UBIFS_MST_NODE_SZ <= c->leb_size) {
> > struct ubifs_ch *ch = buf;
> >
> > -   if (le32_to_cpu(ch->magic) != UBIFS_NODE_MAGIC)
> > +   if (le32_to_cpu(ch->magic) == 0x)
> 
> The purpose of this check was to trigger upon garbage data (including 0xFF).
> Now you only check for 0xFF bytes.
> 
For Master node block, just last page data is valid, so I think( I am limited 
on UBIFS knowledge, maybe I am wrong),
UBIFS should search for last page that not be programed, then search last valid 
master node page.
In case of there is one random data page, but last page of master block is a 
valid master node.
unless we can make sure that don't exist this scenario.
> > break;
> > offs += sz;
> > buf  += sz;
> > @@ -137,37 +137,40 @@ static int get_master_node(const struct
> ubifs_info *c, int lnum, void **pbuf,
> > /* See if there was a valid master node before that */
> > if (offs) {
> > int ret;
> > -
> > +retry:
> > offs -= sz;
> > buf  -= sz;
> > len  += sz;
> > ret = ubifs_scan_a_node(c, buf, len, lnum, offs, 1);
> > -   if (ret != SCANNED_A_NODE && offs) {
> > -   /* Could have been corruption so check one place back */
> > -   offs -= sz;
> > -   buf  -= sz;
> > -   len  += sz;
> > -   ret = ubifs_scan_a_node(c, buf, len, lnum, offs, 1);
> > -   if (ret != SCANNED_A_NODE)
> > -   /*
> > -* We accept only one area of corruption because
> > -* we are assuming that it was caused while
> > -* trying to write a master node.
> > -*/
> > -   goto out_err;
> > -   }
> > -   if (ret == SCANNED_A_NODE) {
> > -   struct ubifs_ch *ch = buf;
> > -
> > -   if (ch->node_type != UBIFS_MST_NODE)
> > +   if (ret != SCANNED_A_NODE) {
> > +   /* Could have been corruption so check more
> > +* place back. We accept two areas of corruption
> > +* because we are assuming that for MLC NAND,it
> > +* was caused while trying to write a lower
> > +* page, upper page being damaged.
> > +*/
> > +   if (offs > 0)
> > +   goto retry;
> > +   else
> > goto out_err;
> > +   }
> > +   if (ret == SCANNED_A_NODE) {
> > +   struct ubifs_ch *ch = buf;
> > +
> > +   if (ch->node_type != UBIFS_MST_NODE) {
> > +   if (offs)
> > +   goto retry;
> > +   else
> > +   goto out_err;
> > +   }
> 
> Here you kill another sanity check.

Here should be what type of check? Can you give me some suggestions?


> > dbg_rcvry("found a master node at %d:%d", lnum, offs);
> > *mst = buf;
> > offs += sz;
> > buf  += sz;
> > len  -= sz;
> > -   }
> > +   }
> > }
> > +
> 
> Useless line break. :)
This will be improved in next version.

> > /* Check for corruption */
> > if (offs < c->leb_size) {
> > if (!is_empty(buf, min_t(int, len, sz))) { @@ -178,10 +181,6 @@
> > 

[PATCH v2] usb: gadget: make usb_ep_enable return -EBUSY if ep has already enabled

[changbin . du]

From: "Du, Changbin" 

When usb_ep_enable on a enabled ep, the configuration of the ep probably
has changed. In this scenario, the ep configuration in hw should be
reprogrammed by udc driver. Hence, it is better to return an error to
inform the caller.

Signed-off-by: Du, Changbin 
---
change from v1: add WARN_ON_ONCE message.

---
 include/linux/usb/gadget.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..b88df2a 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -267,8 +267,12 @@ static inline int usb_ep_enable(struct usb_ep *ep)
 {
int ret;
 
-   if (ep->enabled)
-   return 0;
+   /**
+* An enabled ep may has requests in progress, hence shouldn't
+* reprogram its hw configuration.
+*/
+   if (WARN_ON_ONCE(ep->enabled))
+   return -EBUSY;
 
ret = ep->ops->enable(ep, ep->desc);
if (ret)
-- 
2.5.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 v2] mmc: sdhci: restore behavior when setting VDD via external regulator

[Jisheng Zhang]

Dear Ludovic,

On Fri, 11 Dec 2015 18:06:17 +0100 Ludovic Desroches wrote:

> On Fri, Dec 11, 2015 at 03:48:04PM +0100, Ulf Hansson wrote:
> > + Ludovic (We had some discussions around this code recently as well)
> >   
> 
> Thanks Ulf.
> 
> > On 11 December 2015 at 14:36, Jisheng Zhang  wrote:  
> > > After commit 52221610dd84 ("mmc: sdhci: Improve external VDD regulator
> > > support"), for the VDD is supplied via external regulators, we ignore
> > > the code to convert a VDD voltage request into one of the standard
> > > SDHCI voltage levels, then program it in the SDHCI_POWER_CONTROL. This
> > > brings two issues:
> > >
> > > 1. SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk isn't handled properly any
> > > more.
> > >
> > > 2. What's more, once SDHCI_POWER_ON bit is set, some controllers such
> > > as the sdhci-pxav3 used in marvell berlin SoCs require the voltage
> > > levels programming in the SDHCI_POWER_CONTROL register, even the VDD
> > > is supplied by external regulator.So the host in marvell berlin SoCs
> > > still works fine after the commit.  
> 
> I am not sure to understand this part. You explain that the controller
> in berlin SoC requireis the voltage level programming even if there is an
> external regulator for VDD. I agree this part, I am in the same

plus one more condition ;) -- "once SDHCI_POWER_ON bit is set", that's to say
either not touching SDHCI_POWER_CONTROL register at all or setting 
SDHCI_POWER_ON
bit and voltage level at the same time is fine, but the sdhci-pxav3 in berlin
case can't work if we set SDHCI_POWER_ON but don't program the voltage level
, unfortunately this is true after commit 3cbc6123a93d ("mmc: sdhci: Set
SDHCI_POWER_ON with external vmmc")

> situation with atmel controller. It is not smart to rely on the voltage
> level if we have an external regulator but it follows the sdhci specs.
> 
> That I don't understand is that you say it still works fine after this
> commit... If you need to set the voltage level in the
> SDHCI_POWER_CONTROL register, it is broken by this commit if you declare
> an external regulator.

See above, commit 52221610dd84 doesn't break the host controller, it still
works fine after commit 52221610dd84 but the combination of 52221610dd84 and
3cbc6123a93d do break the host controller.

> 
> > > However, commit 3cbc6123a93d ("mmc:
> > > sdhci: Set SDHCI_POWER_ON with external vmmc") sets the SDHCI_POWER_ON
> > > bit, this would make the host in marvell berlin SoCs won't work any
> > > more with external vmmc.
> > >
> > > This patch restores the behavior when setting VDD through external
> > > regulator by moving the call of mmc_regulator_set_ocr() to the end
> > > of sdhci_set_power() function.
> > >
> > > After this patch, the sdcard on Marvell Berlin SoC boards work again.
> > >
> > > Signed-off-by: Jisheng Zhang 
> > > Fixes: 52221610dd84 ("mmc: sdhci: Improve external VDD ...")
> > > ---
> > > Since v1:
> > >  - add more details about why the sdhci-pxav3 used in marvell berlin
> > >SoCs need this patch.
> > >
> > >  drivers/mmc/host/sdhci.c | 19 ++-
> > >  1 file changed, 6 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > index b48565e..616aa90 100644
> > > --- a/drivers/mmc/host/sdhci.c
> > > +++ b/drivers/mmc/host/sdhci.c
> > > @@ -1274,19 +1274,6 @@ static void sdhci_set_power(struct sdhci_host 
> > > *host, unsigned char mode,
> > > struct mmc_host *mmc = host->mmc;
> > > u8 pwr = 0;
> > >
> > > -   if (!IS_ERR(mmc->supply.vmmc)) {
> > > -   spin_unlock_irq(>lock);
> > > -   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> > > -   spin_lock_irq(>lock);
> > > -
> > > -   if (mode != MMC_POWER_OFF)
> > > -   sdhci_writeb(host, SDHCI_POWER_ON, 
> > > SDHCI_POWER_CONTROL);
> > > -   else
> > > -   sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> > > -
> > > -   return;
> > > -   }
> > > -
> > > if (mode != MMC_POWER_OFF) {
> > > switch (1 << vdd) {
> > > case MMC_VDD_165_195:
> > > @@ -1345,6 +1332,12 @@ static void sdhci_set_power(struct sdhci_host 
> > > *host, unsigned char mode,
> > > if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> > > mdelay(10);
> > > }
> > > +
> > > +   if (!IS_ERR(mmc->supply.vmmc)) {
> > > +   spin_unlock_irq(>lock);
> > > +   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> > > +   spin_lock_irq(>lock);
> > > +   }
> > >  }
> > >
> > >  
> > > /*\
> > > --
> > > 2.6.3
> > >  
> > 
> > My concern with this patch is that it might fix the problem for your
> > SDHCI variant, but will break it for others.
> > I guess we can give it try, unless or until someone reports a problem.
> > 
> > 

Re: [PATCH] hwmon: constify sensor_template_group structures

[Guenter Roeck]

On 12/12/2015 08:36 AM, Julia Lawall wrote:

The sensor_template_group structures are never modified, so declare them as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 


Applied to hwmon-next.

Thanks,
Guenter

--
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.3 00/71] 4.3.3-stable review

[Greg Kroah-Hartman]

On Sun, Dec 13, 2015 at 08:01:31AM -0800, Guenter Roeck wrote:
> On 12/12/2015 12:05 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.3.3 release.
> >There are 71 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Mon Dec 14 20:05:02 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 95 pass: 95 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing all of these and letting me know.

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 v4 09/16] perf tools: Enable indices setting syntax for BPF maps

[Wangnan (F)]

On 2015/12/12 2:21, Alexei Starovoitov wrote:

On Fri, Dec 11, 2015 at 08:39:35PM +0800, pi3orama wrote:

static u64 (*bpf_ktime_get_ns)(void) =
 (void *)5;
static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
 (void *)6;
static int (*bpf_get_smp_processor_id)(void) =
 (void *)8;
static int (*bpf_perf_event_output)(void *, struct bpf_map_def *, int,
void *, unsigned long) =
 (void *)23;

Where can I get this magical mistery table? Could this be hidden away in
some .h file automagically included in bpf scriptlets so that n00bies
like me don't have to be wtf'ing?


They are function numbers defined in bpf.h and bpf-common.h, but they are Linux
headers. Directly include them causes many error for llvm. Also, the function
prototypes are BPF specific and can't included in Linux source. We should have
a place holds those indices and prototypes together.

wait, what kind of errors?
they are in uapi, so gets installed into /usr/include eventually
and I haven't seen any erros either with gcc or clang.


Sorry. I saw error because I use

#include 

It is okay if I use

#include 

Thank you.

--
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] module: Limit line length of module prints

[Rusty Russell]

Laura Abbott  writes:
> On 12/11/2015 01:39 AM, Rusty Russell wrote:
>> Laura Abbott  writes:
>>> print_modules currently uses pr_cont to print all module information.
>>> This has the side effect of printing lots of modules on one very long
>>> line. This makes copy/pasting oopses more effort if manual wrapping is
>>> required. Place a reasonable limit (80 chars) on the number of modules
>>> on each line.
>>>
>>> Signed-off-by: Laura Abbott 
>>> ---
>>> Does this bother anyone else or am I the only one who hates dealing
>>> with the long lines of "Modules linked in"?
>>
>> Never bothered me, but I'm a bit odd :)  I worry more about the effect
>> on machine parsing.
>>
>
> Yes, that was a concern I had as well, but the module list seems to get
> wrapped eventually (although at a much longer length) so it seems like
> if machine parsing can handle one wrap it can handle multiple wraps.

Does it?  I find that code very hard to parse, but seems like something
happens at 1024 chars.

But my testing here doesn't show any such break in dmesg, nor on serial
console.

diff --git a/kernel/module.c b/kernel/module.c
index 912e891e0e2f..f882d9d99844 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3925,6 +3925,12 @@ static const struct file_operations 
proc_modules_operations = {
 
 static int __init proc_modules_init(void)
 {
+   int x;
+   printk("Test of long line:");
+   for (x = 0; x < 1024; x++)
+   pr_cont("%c%c", (x % 26) + 'A', (x % 26) + 'A');
+   pr_cont("\n");
+   
proc_create("modules", 0, NULL, _modules_operations);
return 0;
 }

Confused,
Rusty.
--
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/2] usb: dwc2: add ep enabled flag to avoid double enable/disable

[Du, Changbin]

Hi, Balbi,
Please ignore this patch set. Because we have a fix in gadget API layer.
[PATCH] usb: gadget: forbid queuing request to a disabled ep

> > Enabling an already enabled ep is illegal, because the ep may has trbs
> > running. Reprogram the ep may break running transfer. So udc driver
> > must avoid this happening by return an error -EBUSY. Gadget function
> > driver also should avoid such things, but that is out of udc driver.
> >
> > Similarly, disable a disabled ep makes no sense, but no need return
> > an error here.
> >
> > Signed-off-by: Du, Changbin 
> > ---
> >  drivers/usb/dwc2/core.h   |  1 +
> >  drivers/usb/dwc2/gadget.c | 20 +++-
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > index a66d3cb..cf7eccd 100644
> > --- a/drivers/usb/dwc2/core.h
> > +++ b/drivers/usb/dwc2/core.h
> > @@ -162,6 +162,7 @@ struct dwc2_hsotg_ep {
> > unsigned char   mc;
> > unsigned char   interval;
> >
> > +   unsigned intenabled:1;
> > unsigned inthalted:1;
> > unsigned intperiodic:1;
> > unsigned intisochronous:1;
> > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > index 0abf73c..586bbcd 100644
> > --- a/drivers/usb/dwc2/gadget.c
> > +++ b/drivers/usb/dwc2/gadget.c
> > @@ -2423,6 +2423,7 @@ void dwc2_hsotg_core_init_disconnected(struct
> dwc2_hsotg *hsotg,
> > /* enable, but don't activate EP0in */
> > dwc2_writel(dwc2_hsotg_ep0_mps(hsotg->eps_out[0]-
> >ep.maxpacket) |
> >DXEPCTL_USBACTEP, hsotg->regs + DIEPCTL0);
> > +   hsotg->eps_out[0]->enabled = 1;
> >
> > dwc2_hsotg_enqueue_setup(hsotg);
> >
> > @@ -2680,6 +2681,14 @@ static int dwc2_hsotg_ep_enable(struct usb_ep
> *ep,
> > return -EINVAL;
> > }
> >
> > +   spin_lock_irqsave(>lock, flags);
> > +   if (hs_ep->enabled) {
> > +   dev_warn(hsotg->dev, "%s: ep %s already enabled\n",
> > +   __func__, hs_ep->name);
> 
> this is a rather serious condition. I'd rather use dev_WARN_ONCE():
> 
>   if (dev_WARN_ONCE(hsotg->dev, hs_ep->enabled,
>   "ep %s already enabled\n", hs_ep->name)) {
> 
> --
> balbi
--
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 1/6] acpica: Correct parameter type to acpi_evaluate_dsm

[Jerry Hoemann]

On Mon, Dec 14, 2015 at 03:07:22AM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 14, 2015 at 2:54 AM, Jerry Hoemann  wrote:
> > The ACPI spec speicifies that arguments "Revision ID" and
> > "Function Index" to a _DSM are type "Integer."  Type Integers
> > are 64 bit quantities.
> >
> > The function evaluate_dsm specifies these types as simple "int"
> > which are 32 bits.  Correct type passed to acpi_evaluate_dsm
> > and its callers and derived callers to pass correct type.
> >
> > acpi_check_dsm and acpi_evaluate_dsm_typed had similar issue
> > and were corrected as well.
> >
> > Signed-off-by: Jerry Hoemann 
> 
> The changes look OK to me, but this is not ACPICA material.
> 
> Please change the subject to something like "ACPI / utils: Fix
> acpi_evaluate_dsm() argument type".
> 
> Thanks,
> Rafael

  Will do.  thanks.

-- 

-
Jerry Hoemann  Software Engineer   Hewlett Packard Enterprise
-
--
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] selftests: report proper exit statuses

[Michael Ellerman]

Hi Brian,

On Fri, 2015-12-11 at 15:15 -0800, Brian Norris wrote:

> There are several places where we don't report proper exit statuses, and
> this can have consequences -- for instance, the gen_kselftest_tar.sh
> script might try to produce a tarball for you, even if the 'make' or
> 'make install' steps didn't complete properly.
> 
> This is only an RFC (and really, it's more like a bug report), since I'm
> not really satisfied with my solution.

The changes to the tar script are probably OK.

But in general we do not want to exit after the first failure, which is what
your changes to the for loops would do.

The intention is to build and run as many tests as possible, on as many
architectures and machines as possible. So stopping the build because a header
or library is missing, or stopping the test run because one test fails, is the
exact opposite of what we want to happen.

For example a test might fail because it was written for x86 and doesn't work
on powerpc, if that caused all my powerpc tests to not run, I would be very
unpleased.

> It's probably not exhaustive, and
> there seem to be some major other deficiencies (e.g., verbose/useless
> output during build and run, non-paralle build, shell for-loops sidestep
> some normal 'make' behavior).

The goals for the kernel selftests are to make it as easy as possible to merge
tests, so that as many developers as possible create tests *and* merge them.

The current scheme supports that by not imposing much in the way of build
system requirements, or standards on what is or isn't appropriate output etc.

But if have ideas for improving things while still keeping the requirements on
test code low then I'm all ears.

cheers

--
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] usb: gadget: make usb_ep_enable return -EBUSY if ep has already enabled

[Du, Changbin]

> > When usb_ep_enable on a enabled ep, the configuration of the ep
> probably
> > has changed. In this scenario, the ep configuration in hw should be
> > reprogrammed by udc driver. Hence, it is better to return an error to
> > inform the caller.
> >
> > Signed-off-by: Du, Changbin 
> > ---
> >  include/linux/usb/gadget.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index d813bd2..89f9fdd 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -268,7 +268,7 @@ static inline int usb_ep_enable(struct usb_ep *ep)
> > int ret;
> >
> > if (ep->enabled)
> > -   return 0;
> > +   return -EBUSY;
> 
> While at that, can you add a WARN_ON() as well ?
> 
>   if (WARN_ON(ep->enabled))
>   return -EBUSY;
> 
> --
> balbi
I will update the patch, 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/