Re: [PATCH v5 02/12] mm: migrate: support non-lru movable page migration

[Sergey Senozhatsky]

On (05/09/16 11:20), Minchan Kim wrote:
> +++ b/include/linux/migrate.h
> @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES];
>  
>  #ifdef CONFIG_MIGRATION
>  
> +extern int PageMovable(struct page *page);
> +extern void __SetPageMovable(struct page *page, struct address_space 
> *mapping);
> +extern void __ClearPageMovable(struct page *page);
>  extern void putback_movable_pages(struct list_head *l);
>  extern int migrate_page(struct address_space *,
>   struct page *, struct page *, enum migrate_mode);
>  extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t 
> free,
>   unsigned long private, enum migrate_mode mode, int reason);
> +extern bool isolate_movable_page(struct page *page, isolate_mode_t mode);
> +extern void putback_movable_page(struct page *page);
>  
>  extern int migrate_prep(void);
>  extern int migrate_prep_local(void);

__ClearPageMovable() is under CONFIG_MIGRATION in include/linux/migrate.h,
but zsmalloc checks for CONFIG_COMPACTION.

can we have stub declarations of movable functions for !CONFIG_MIGRATION builds?
otherwise the users (zsmalloc, for example) have to do things like

static void reset_page(struct page *page)
{
#ifdef CONFIG_COMPACTION
__ClearPageMovable(page);
#endif
clear_bit(PG_private, &page->flags);
clear_bit(PG_private_2, &page->flags);
set_page_private(page, 0);
ClearPageHugeObject(page);
page->freelist = NULL;
}

-ss

Re: [RFC 08/13] mm, compaction: simplify contended compaction handling

[Vlastimil Babka]

On 05/13/2016 03:09 PM, Michal Hocko wrote:

>@@ -1564,14 +1564,11 @@ static enum compact_result compact_zone(struct zone 
*zone, struct compact_contro
>trace_mm_compaction_end(start_pfn, cc->migrate_pfn,
>cc->free_pfn, end_pfn, sync, ret);
>
>-   if (ret == COMPACT_CONTENDED)
>-   ret = COMPACT_PARTIAL;
>-
>return ret;
>  }

This took me a while to grasp but then I realized this is correct
because we shouldn't pretend progress when there was none in fact,
especially when __alloc_pages_direct_compact basically replaced this
"fake" COMPACT_PARTIAL by COMPACT_CONTENDED anyway.


Yes. Actually COMPACT_CONTENDED compact_result used to be just for the 
tracepoint, and __alloc_pages_direct_compact used another function 
parameter to signal contention. You changed it with the oom rework so 
COMPACT_CONTENDED result value was used, so this hunk just makes sure 
it's still reported correctly.

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Peter Chen]

On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
> +
> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool 
> connect)
> +{
> + struct usb_udc *udc;
> +
> + mutex_lock(&udc_lock);
> + udc = usb_gadget_to_udc(gadget);
> + if (!udc) {
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> + }
> +
> + if (connect) {
> + if (!gadget->connected)
> + usb_gadget_connect(udc->gadget);
> + } else {
> + if (gadget->connected) {
> + usb_gadget_disconnect(udc->gadget);
> + udc->driver->disconnect(udc->gadget);
> + }
> + }
> +
> + mutex_unlock(&udc_lock);
> +
> + return 0;
> +}
> +

Since this is called for vbus interrupt, why not using
usb_udc_vbus_handler directly, and call udc->driver->disconnect
at usb_gadget_stop.

>   return 0;
> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
>   return -EOPNOTSUPP;
>   }
>  
> + /* In OTG mode we don't support softconnect, but b_bus_req */
> + if (udc->gadget->otg_dev) {
> + dev_err(dev, "soft-connect not supported in OTG mode\n");
> + return -EOPNOTSUPP;
> + }
> +

The soft-connect can be supported at dual-role mode currently, we can
use b_bus_req entry once it is implemented later.

>   if (sysfs_streq(buf, "connect")) {
>   usb_gadget_udc_start(udc);
> - usb_gadget_connect(udc->gadget);
> + usb_udc_connect_control(udc);

This line seems to be not related with this patch.

-- 

Best Regards,
Peter Chen

Re: [patch net-next 01/11] net: hisilicon: add support of acpi for hns-mdio

[Yankejian (Hackim Yim)]

On 2016/5/13 20:59, Andy Shevchenko wrote:
> On Fri, 2016-05-13 at 16:19 +0800, Yisen Zhuang wrote:
>> From: Kejian Yan 
>>
>> hns-mdio needs to register itself to mii-bus. The info of the device
>> can
>> be read by both OF and ACPI.
>> HNS tries to call Linux PHY driver to help access PHY-devices, the HNS
>> hardware topology is as below. The MDIO controller may control several
>> PHY-devices, and each PHY-device connects to a MAC device. The MDIO
>> will
>> be registered to mdiobus, then PHY-devices will register when each mac
>> find PHY device.
>>cpu
>> |
>> |
>>  ---
>> |   |   |
>> |   |   |
>> |  dsaf |
>>MDIO |  MDIO
>> |  ---  |
>> | | | |   | |
>> | | | |   | |
>> |MAC   MAC   MAC MAC|
>> | | | |   | |
>>   | | |   | 
>>  ||||||   ||
>>  PHY   PHY   PHY PHY
>>
>> And the driver can handle reset sequence by _DSD method in DSDT in
>> ACPI case.
>>
>> Signed-off-by: Kejian Yan 
>> Signed-off-by: Yisen Zhuang 
>> ---
>>  drivers/net/ethernet/hisilicon/hns_mdio.c | 145 ++---
>> -
>>  1 file changed, 90 insertions(+), 55 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns_mdio.c
>> b/drivers/net/ethernet/hisilicon/hns_mdio.c
>> index 765ddb3..4b779df 100644
>> --- a/drivers/net/ethernet/hisilicon/hns_mdio.c
>> +++ b/drivers/net/ethernet/hisilicon/hns_mdio.c
>> @@ -7,6 +7,7 @@
>>   * (at your option) any later version.
>>   */
>>  
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -354,64 +355,72 @@ static int hns_mdio_reset(struct mii_bus *bus)
>>  struct hns_mdio_device *mdio_dev = (struct hns_mdio_device
>> *)bus->priv;
>>  int ret;
>>  
>> -if (!mdio_dev->subctrl_vbase) {
>> -dev_err(&bus->dev, "mdio sys ctl reg has not
>> maped\n");
>> -return -ENODEV;
>> -}
>> -
>> -/*1. reset req, and read reset st check*/
>> -ret = mdio_sc_cfg_reg_write(mdio_dev, MDIO_SC_RESET_REQ, 0x1,
>> -MDIO_SC_RESET_ST, 0x1,
>> -MDIO_CHECK_SET_ST);
>> -if (ret) {
>> -dev_err(&bus->dev, "MDIO reset fail\n");
>> -return ret;
>> -}
>> +if (IS_ENABLED(CONFIG_OF) && bus->parent->of_node) {
> Can you keep indentation the same?
>
> Also I suggest to use struct fwnode_handle, and this will be something
> like
>
> if (is_of_node(...))
ok, thanks Andy. i will fix it in next submit

>
>> +if (!mdio_dev->subctrl_vbase) {
>> +dev_err(&bus->dev, "mdio sys ctl reg has not
>> maped\n");
>> +return -ENODEV;
>> +}
>>  
>> -/*2. dis clk, and read clk st check*/
>> -ret = mdio_sc_cfg_reg_write(mdio_dev, MDIO_SC_CLK_DIS,
>> -0x1, MDIO_SC_CLK_ST, 0x1,
>> -MDIO_CHECK_CLR_ST);
>> -if (ret) {
>> -dev_err(&bus->dev, "MDIO dis clk fail\n");
>> -return ret;
>> -}
>> +/*1. reset req, and read reset st check*/
>> +ret = mdio_sc_cfg_reg_write(mdio_dev,
>> MDIO_SC_RESET_REQ, 0x1,
>> +MDIO_SC_RESET_ST, 0x1,
>> +MDIO_CHECK_SET_ST);
>> +if (ret) {
>> +dev_err(&bus->dev, "MDIO reset fail\n");
>> +return ret;
>> +}
>>  
>> -/*3. reset dreq, and read reset st check*/
>> -ret = mdio_sc_cfg_reg_write(mdio_dev, MDIO_SC_RESET_DREQ,
>> 0x1,
>> -MDIO_SC_RESET_ST, 0x1,
>> -MDIO_CHECK_CLR_ST);
>> -if (ret) {
>> -dev_err(&bus->dev, "MDIO dis clk fail\n");
>> -return ret;
>> -}
>> +/*2. dis clk, and read clk st check*/
>> +ret = mdio_sc_cfg_reg_write(mdio_dev,
>> MDIO_SC_CLK_DIS,
>> +0x1, MDIO_SC_CLK_ST, 0x1,
>> +MDIO_CHECK_CLR_ST);
>> +if (ret) {
>> +dev_err(&bus->dev, "MDIO dis clk fail\n");
>> +return ret;
>> +}
>>  
>> -/*4. en clk, and read clk st check*/
>> -ret = mdio_sc_cfg_reg_write(mdio_dev, MDIO_SC_CLK_EN,
>> -0x1, MDIO_SC_CLK_ST, 0x1,
>> -MDIO_CHECK_SET_ST);
>> -if (ret)
>> -dev_err(&bus->dev, "MDIO en clk fail\n");
>> +/*3. reset dreq, and 

Re: [RFC 11/13] mm, compaction: add the ultimate direct compaction priority

[Vlastimil Babka]

On 05/13/2016 03:38 PM, Michal Hocko wrote:

On Tue 10-05-16 09:36:01, Vlastimil Babka wrote:

During reclaim/compaction loop, it's desirable to get a final answer from
unsuccessful compaction so we can either fail the allocation or invoke the OOM
killer. However, heuristics such as deferred compaction or pageblock skip bits
can cause compaction to skip parts or whole zones and lead to premature OOM's,
failures or excessive reclaim/compaction retries.

To remedy this, we introduce a new direct compaction priority called
COMPACT_PRIO_SYNC_FULL, which instructs direct compaction to:

- ignore deferred compaction status for a zone
- ignore pageblock skip hints
- ignore cached scanner positions and scan the whole zone
- use MIGRATE_SYNC migration mode


I do not think we can do MIGRATE_SYNC because fallback_migrate_page
would trigger pageout and we are in the allocation path and so we
could blow up the stack.


Ah, I thought it was just waiting for the writeout to complete, and you 
wanted to introduce another migrate mode to actually do the writeout. 
But looks like I misremembered.



The new priority should get eventually picked up by should_compact_retry() and
this should improve success rates for costly allocations using __GFP_RETRY,


s@__GFP_RETRY@__GFP_REPEAT@


Ah thanks. Depending on the patch timing it might be __GFP_RETRY_HARD in 
the end, right :)



such as hugetlbfs allocations, and reduce some corner-case OOM's for non-costly
allocations.


My testing has shown that even with the current implementation with
deferring, skip hints and cached positions had (close to) 100% success
rate even with close to OOM conditions.


Hmm, I thought you at one point said that ignoring skip hints was a 
large improvement, because the current resetting of them is just too fuzzy.



I am wondering whether this strongest priority should be done only for
!costly high order pages. But we probably want less special cases
between costly and !costly orders.


Yeah, if somebody wants to retry hard, let him.


Signed-off-by: Vlastimil Babka 


Acked-by: Michal Hocko 


---
  include/linux/compaction.h |  1 +
  mm/compaction.c| 15 ---
  2 files changed, 13 insertions(+), 3 deletions(-)


[...]

@@ -1631,7 +1639,8 @@ enum compact_result try_to_compact_pages(gfp_t gfp_mask, 
unsigned int order,
ac->nodemask) {
enum compact_result status;

-   if (compaction_deferred(zone, order)) {
+   if (prio > COMPACT_PRIO_SYNC_FULL
+   && compaction_deferred(zone, order)) {
rc = max_t(enum compact_result, COMPACT_DEFERRED, rc);
continue;
}


Wouldn't it be better to pull the prio check into compaction_deferred
directly? There are more callers and I am not really sure all of them
would behave consistently.


I'll check, thanks.

Crypto Update for 4.7

[Herbert Xu]

Hi Linus:

Here is the crypto update for 4.7:

API:

* Crypto self tests can now be disabled at boot/run time.
* Add async support to algif_aead.

Algorithms:

* A large number of fixes to MPI from Nicolai Stange.
* Performance improvement for HMAC DRBG.

Drivers:

* Use generic crypto engine in omap-des.
* Merge ppc4xx-rng and crypto4xx drivers.
* Fix lockups in sun4i-ss driver by disabling IRQs.
* Add DMA engine support to ccp.
* Reenable talitos hash algorithms.
* Add support for Hisilicon SoC RNG.
* Add basic crypto driver for the MXC SCC.

Others:

* Do not allocate crypto hash tfm in NORECLAIM context in ecryptfs.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus

Ahsan Atta (1):
  crypto: qat - Remove redundant nrbg rings

Amitoj Kaur Chawla (1):
  crypto: n2 - Remove return statement from void function

Baolin Wang (1):
  crypto: omap-des - Integrate with the crypto engine framework

Catalin Vasile (1):
  crypto: caam - fix caam_jr_alloc() ret code

Christian Lamparter (1):
  crypto4xx: integrate ppc4xx-rng into crypto4xx

Colin Ian King (1):
  PKCS#7: fix missing break on OID_sha224 case

Corentin LABBE (1):
  crypto: sun4i-ss - Replace spinlock_bh by spin_lock_irq{save|restore}

Dan Carpenter (3):
  crypto: marvell/cesa - remove unneeded condition
  crypto: mxc-scc - signedness bugs in mxc_scc_ablkcipher_req_init()
  crypto: mxc-scc - fix unwinding in mxc_scc_crypto_register()

Eric Biggers (1):
  crypto: doc - document correct return value for request allocation

Gary R Hook (2):
  crypto: ccp - Register the CCP as a DMA resource
  crypto: ccp - Ensure all dependencies are specified

Herbert Xu (3):
  eCryptfs: Do not allocate hash tfm in NORECLAIM context
  Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
  Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

Horia Geant? (1):
  crypto: talitos - fix ahash algorithms registration

Julia Lawall (2):
  crypto: marvell/cesa - Use dma_pool_zalloc
  crypto: ccp - constify ccp_actions structure

Kefeng Wang (2):
  dt/bindings: Add bindings for hisilicon random number generator
  hwrng: hisi - Add support for Hisilicon SoC RNG

Krzysztof Kozlowski (14):
  hwrng: exynos - Runtime suspend device after init
  hwrng: exynos - Fix unbalanced PM runtime put on timeout error path
  hwrng: exynos - Disable runtime PM on probe failure
  hwrng: exynos - Disable runtime PM on driver unbind
  hwrng: exynos - Enable COMPILE_TEST
  crypto: s5p-sss - Enable COMPILE_TEST
  crypto: s5p-sss - Minor coding cleanups
  crypto: s5p-sss - Handle unaligned buffers
  crypto: s5p-sss - Sort the headers to improve readability
  hwrng: exynos - Fix misspelled Samsung address
  crypto: s5p-sss - Fix use after free of copied input buffer in error path
  crypto: s5p-sss - Remove useless hash interrupt handler
  crypto: s5p-sss - Use common BIT macro
  crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

Marek Szyprowski (1):
  crypto: s5p-sss - fix incorrect usage of scatterlists api

Michal Hocko (1):
  crypto: lzo - get rid of superfluous __GFP_REPEAT

Mike Galbraith (1):
  crypto: ccp - Fix RT breaking #include 

Nicolai Stange (14):
  lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs
  lib/mpi: mpi_write_sgl(): fix style issue with lzero decrement
  lib/mpi: mpi_write_sgl(): purge redundant pointer arithmetic
  lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access
  lib/mpi: mpi_write_sgl(): replace open coded endian conversion
  lib/mpi: mpi_read_buffer(): optimize skipping of leading zero limbs
  lib/mpi: mpi_read_buffer(): replace open coded endian conversion
  lib/mpi: mpi_read_buffer(): fix buffer overflow
  lib/mpi: mpi_read_raw_from_sgl(): replace len argument by nbytes
  lib/mpi: mpi_read_raw_from_sgl(): don't include leading zero SGEs in 
nbytes
  lib/mpi: mpi_read_raw_from_sgl(): purge redundant clearing of nbits
  lib/mpi: mpi_read_raw_from_sgl(): fix nbits calculation
  lib/mpi: mpi_read_raw_from_sgl(): sanitize meaning of indices
  lib/mpi: mpi_read_raw_from_sgl(): fix out-of-bounds buffer access

Paulo Flabiano Smorigo (1):
  crypto: vmx - comply with ABIs that specify vrsave as reserved.

Peter Meerwald (1):
  crypto: omap-des - Improve wording for CRYPTO_DEV_OMAP_DES in Kconfig

Peter Ujfalusi (3):
  crypto: omap-aes - Use dma_request_chan() for requesting DMA channel
  crypto: omap-des - Use dma_request_chan() for requesting DMA channel
  crypto: omap-sham - Use dma_request_chan() for requesting DMA channel

Richard W.M. Jones (1):
  crypto: testmgr - Add a flag allowing the self-tests to be disabled at 
runtime.

Romain Perier (1):
  crypto: marvell/cesa - Improving code readability

Steffen Trumtrar (3):
  D

Re: [PATCH v5 02/12] mm: migrate: support non-lru movable page migration

[Sergey Senozhatsky]

On (05/09/16 11:20), Minchan Kim wrote:
[..]
> +++ b/include/linux/migrate.h
> @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES];
>  
>  #ifdef CONFIG_MIGRATION
>  
> +extern int PageMovable(struct page *page);
> +extern void __SetPageMovable(struct page *page, struct address_space 
> *mapping);
> +extern void __ClearPageMovable(struct page *page);
>  extern void putback_movable_pages(struct list_head *l);
>  extern int migrate_page(struct address_space *,
>   struct page *, struct page *, enum migrate_mode);
>  extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t 
> free,
>   unsigned long private, enum migrate_mode mode, int reason);
> +extern bool isolate_movable_page(struct page *page, isolate_mode_t mode);
> +extern void putback_movable_page(struct page *page);
>  
>  extern int migrate_prep(void);
>  extern int migrate_prep_local(void);

given that some of Movable users can be built as modules, shouldn't
at least some of those symbols be exported via EXPORT_SYMBOL?

-ss

[PATCH v2] ARM64: zynqmp: Use 64bit size cell format

[Michal Simek]

Use 64bit size cell format instead of 32bit for memory
description.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Use ranges for PS amba busses instead of changing them to
  64 size cell

 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 2 +-
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts 
b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index acb0527fdc4a..358089687a69 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -29,7 +29,7 @@
 
memory {
device_type = "memory";
-   reg = <0x0 0x0 0x4000>;
+   reg = <0x0 0x0 0x0 0x4000>;
};
 };
 
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 38c43103d610..cb8f09cb03cf 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -14,7 +14,7 @@
 / {
compatible = "xlnx,zynqmp";
#address-cells = <2>;
-   #size-cells = <1>;
+   #size-cells = <2>;
 
cpus {
#address-cells = <1>;
@@ -75,7 +75,7 @@
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
-   ranges;
+   ranges = <0 0 0 0 0x>;
 
gic: interrupt-controller@f901 {
compatible = "arm,gic-400", "arm,cortex-a15-gic";
@@ -94,7 +94,7 @@
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
-   ranges;
+   ranges = <0 0 0 0 0x>;
 
can0: can@ff06 {
compatible = "xlnx,zynq-can-1.0";
-- 
1.9.1

Re: [PATCH] mm: unhide vmstat_text definition for CONFIG_SMP

[Michal Hocko]

On Wed 11-05-16 10:32:11, Christoph Lameter wrote:
> Subject: Do not build vmstat_refresh if there is no procfs support
> 
> It makes no sense to build functionality into the kernel that
> cannot be used and causes build issues.
> 
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/vmstat.c
> ===
> --- linux.orig/mm/vmstat.c
> +++ linux/mm/vmstat.c
> @@ -1358,7 +1358,6 @@ static const struct file_operations proc
>   .llseek = seq_lseek,
>   .release= seq_release,
>  };
> -#endif /* CONFIG_PROC_FS */
> 
>  #ifdef CONFIG_SMP
>  static struct workqueue_struct *vmstat_wq;

This doesn't work because it makes the whole vmstat_wq depend on
CONFIG_PROC_FS. Which is obviously bad because we both rely on doing the
periodic sync even when counters are not exported to the userspace and
it wound't compile anyway...
-- 
Michal Hocko
SUSE Labs

Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority

[Vlastimil Babka]

On 05/13/2016 04:15 PM, Michal Hocko wrote:

On Tue 10-05-16 09:36:02, Vlastimil Babka wrote:


- should_compact_retry() is only called when should_reclaim_retry() returns
   false. This means that compaction priority cannot get increased as long
   as reclaim makes sufficient progress. Theoretically, reclaim should stop
   retrying for high-order allocations as long as the high-order page doesn't
   exist but due to races, this may result in spurious retries when the
   high-order page momentarily does exist.


This is intentional behavior and I would like to preserve it if it is
possible. For higher order pages should_reclaim_retry retries as long
as there are some eligible high order pages present which are just hidden
by the watermark check. So this is mostly to get us over watermarks to
start carrying about fragmentation. If we race there then nothing really
terrible should happen and we should eventually converge to a terminal
state.

Does this make sense to you?


Yeah it should work, my only worry was that this may get subtly wrong 
(as experience shows us) and due to e.g. slightly different watermark 
checks and/or a corner-case zone such as ZONE_DMA, 
should_reclaim_retry() would keep returning true, even if reclaim 
couldn't/wouldn't help anything. Then compaction would be needlessly 
kept at ineffective priority.


Also my understanding of the initial compaction priorities is to lower 
the latency if fragmentation is just light and there's enough memory. 
Once we start struggling, I don't see much point in not switching to the 
full compaction priority quickly.

Re: [PATCH RESEND 05/12] sh: DeviceTree support update

[Yoshinori Sato]

On Wed, 11 May 2016 01:28:07 +0900,
Rich Felker wrote:
> 
> On Tue, May 10, 2016 at 05:25:36PM +0900, Yoshinori Sato wrote:
> > On Wed, 04 May 2016 12:10:05 +0900,
> > Rich Felker wrote:
> > > 
> > > On Sun, May 01, 2016 at 02:08:29PM +0900, Yoshinori Sato wrote:
> > > > Changes bellow
> > > > - FDT setup timing fix.
> > > > - chosen/bootargs support.
> > > > - zImage support.
> > > > - DT binding helper macro.
> > > > 
> > > > Signed-off-by: Yoshinori Sato 
> > > > ---
> > > >  arch/sh/boards/of-generic.c| 23 
> > > > +++---
> > > >  arch/sh/boot/compressed/head_32.S  |  5 +++--
> > > >  arch/sh/boot/dts/include/dt-bindings   |  1 +
> > > >  arch/sh/kernel/setup.c | 19 
> > > > ++
> > > >  include/dt-bindings/interrupt-controller/sh_intc.h |  2 ++
> > > >  5 files changed, 36 insertions(+), 14 deletions(-)
> > > >  create mode 12 arch/sh/boot/dts/include/dt-bindings
> > > >  create mode 100644 include/dt-bindings/interrupt-controller/sh_intc.h
> > > > 
> > > > diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
> > > > index bf3a166..9570873 100644
> > > > --- a/arch/sh/boards/of-generic.c
> > > > +++ b/arch/sh/boards/of-generic.c
> > > > @@ -112,29 +112,25 @@ static int noopi(void)
> > > > return 0;
> > > >  }
> > > >  
> > > > -static void __init sh_of_mem_reserve(void)
> > > > +static void __init sh_of_mem_init(void)
> > > >  {
> > > > early_init_fdt_reserve_self();
> > > > early_init_fdt_scan_reserved_mem();
> > > >  }
> > > >  
> > > > -static void __init sh_of_time_init(void)
> > > > -{
> > > > -   pr_info("SH generic board support: scanning for clocksource 
> > > > devices\n");
> > > > -   clocksource_probe();
> > > > -}
> > > 
> > > Why did you remove this? Without it you won't get clock
> > > event/clocksource devices from the device tree so the only way to have
> > > a working timer interrupt is if the driver is hard-coded somewhere.
> > 
> > It not needed on Common Clock Framework.
> > tmu define in dts.
> 
> It is needed. clocksources are something completely different from
> "clk"s. A clocksource is the modern source of time data for the kernel
> timekeeping system (without one, you're stuck using jiffies and very
> low-res time), and the probe also gets clock_event_devices which are
> the source of timer interrupts. Without this, unless you have a
> hard-coded source of timer interrupt for the board, you won't get a
> timer interrupt and the kernel will hang early in the boot process.

OK.

> > > >  {
> > > > -   unflatten_device_tree();
> > > > -
> > > > -   board_time_init = sh_of_time_init;
> > > > +   struct device_node *cpu;
> > > > +   int freq;
> > > >  
> > > > sh_mv.mv_name = of_flat_dt_get_machine_name();
> > > > if (!sh_mv.mv_name)
> > > > sh_mv.mv_name = "Unknown SH model";
> > > >  
> > > > sh_of_smp_probe();
> > > > +   cpu = of_find_node_by_name(NULL, "cpu");
> > > > +   if (!of_property_read_u32(cpu, "clock-frequency", &freq))
> > > > +   preset_lpj = freq / 500;
> > > >  }
> > > 
> > > I setup the DT-based pseudo-board to use the generic calibrate-delay
> > > rather than hard-coding lpj. Ideally we could just get rid of bogomips
> > > completely but there are probably still some things using it. Is there
> > > a reason you prefer making up a value for lpj based on the cpu clock
> > > rate?
> > 
> > clockevent initalize after calibrate delay.
> > So don't work interrupt based calibrate.
> 
> Currently, it initializes before, but you removed the probe that
> initializes it (above), clocksource_probe().

OK.

> > > >  static int sh_of_irq_demux(int irq)
> > > > @@ -167,8 +163,7 @@ static struct sh_machine_vector __initmv 
> > > > sh_of_generic_mv = {
> > > > .mv_init_irq= sh_of_init_irq,
> > > > .mv_clk_init= sh_of_clk_init,
> > > > .mv_mode_pins   = noopi,
> > > > -   .mv_mem_init= noop,
> > > > -   .mv_mem_reserve = sh_of_mem_reserve,
> > > > +   .mv_mem_init= sh_of_mem_init,
> > > 
> > > Is there a reason for this renaming? The function seems to be dealing
> > > purely with reserving memory ranges.
> > 
> > mv_mem_reserve too late call in MMU system.
> 
> OK.
> 
> > > > if (!dt_virt || !early_init_dt_scan(dt_virt)) {
> > > > pr_crit("Error: invalid device tree blob"
> > > > @@ -267,8 +276,13 @@ void __ref sh_fdt_init(phys_addr_t dt_phys)
> > > >  
> > > >  void __init setup_arch(char **cmdline_p)
> > > >  {
> > > > +#ifdef CONFIG_OF
> > > > +   unflatten_device_tree();
> > > > +#endif
> > > > enable_mmu();
> > > 
> > > Was this moved to setup_arch to have it before enable_mmu? I think
> > > that makes sense.
> > 
> > early_init_dt_alloc_memory_arch used physical address.
> > It override on sh-specific, can after enable_mmu.
> > But I don't feel an ad

Re: [PATCH] mm: unhide vmstat_text definition for CONFIG_SMP

[Michal Hocko]

On Wed 11-05-16 16:54:55, Arnd Bergmann wrote:
> In randconfig builds with sysfs, procfs and numa all disabled,
> but SMP enabled, we now get a link error in the newly introduced
> vmstat_refresh function:
> 
> mm/built-in.o: In function `vmstat_refresh':
> :(.text+0x15c78): undefined reference to `vmstat_text'
> 
> This modifes the already elaborate #ifdef to also cover that
> configuration.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: mmotm ("mm: /proc/sys/vm/stat_refresh to force vmstat update")

I agree with Christoph that vmstat_refresh is PROC_FS only so we should
fix it there. It is not like this would be generally reusable helper...
Why don't we just do:
---
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 57a24e919907..c759b526287b 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1370,6 +1370,7 @@ static void refresh_vm_stats(struct work_struct *work)
refresh_cpu_vm_stats(true);
 }
 
+#ifdef CONFIG_PROC_FS
 int vmstat_refresh(struct ctl_table *table, int write,
   void __user *buffer, size_t *lenp, loff_t *ppos)
 {
@@ -1422,6 +1423,7 @@ int vmstat_refresh(struct ctl_table *table, int write,
*lenp = 0;
return 0;
 }
+#endif
 
 static void vmstat_update(struct work_struct *w)
 {
-- 
Michal Hocko
SUSE Labs

Re: [PATCHSET v5] Make background writeback great again for the first time

[Jan Kara]

On Fri 13-05-16 12:29:10, Jens Axboe wrote:
> Thanks Jan, this is great and super useful! I'm revamping certain parts of
> it to deal with write back caching better, and I'll take a look at the
> regressions that you reported.
> 
> What kind of SSD is this? I'm assuming it's SATA (QD=32), and then it would
> probably be a safe assumption that it's flagging itself as having a volatile
> write back cache, would that be a correct assumption?

Yes, it is SATA with writeback cache.

> Are you using scsi-mq, or do you have an IO scheduler attached to it?

The disk was using IO scheduler, however at this point I'm not 100% sure
which scheduler (deadline or cfq) was the default one for the distro that
was installed. The machine is currently testing something else so I cannot
reinstall it and check. Maybe I can rerun some tests later in the week when
the machine gets freed with scsi-mq or deadline IO scheduler so that we
have 100% certain config.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH net-next] tuntap: introduce tx skb ring

[Jason Wang]

On 2016年05月16日 11:56, Eric Dumazet wrote:

On Mon, 2016-05-16 at 09:17 +0800, Jason Wang wrote:

We used to queue tx packets in sk_receive_queue, this is less
efficient since it requires spinlocks to synchronize between producer
and consumer.

...


struct tun_struct *detached;
+   /* reader lock */
+   spinlock_t rlock;
+   unsigned long tail;
+   struct tun_desc tx_descs[TUN_RING_SIZE];
+   /* writer lock */
+   spinlock_t wlock;
+   unsigned long head;
  };
  

Ok, we had these kind of ideas floating around for many other cases,
like qdisc, UDP or af_packet sockets...

I believe we should have a common set of helpers, not hidden in
drivers/net/tun.c but in net/core/skb_ring.c or something, with more
flexibility (like the number of slots)



Yes, this sounds good.


BTW, why are you using spin_lock_irqsave() in tun_net_xmit() and
tun_peek() ?

BH should be disabled already (in tun_next_xmit()), and we can not
transmit from hard irq.

Thanks.


Right, no need. But for tun_peek() we need spin_lock_bh() since it was 
called by vhost-net.


Thanks

Re: [PATCH net-next] tuntap: introduce tx skb ring

[Jason Wang]

On 2016年05月16日 12:23, Michael S. Tsirkin wrote:

On Mon, May 16, 2016 at 09:17:01AM +0800, Jason Wang wrote:

We used to queue tx packets in sk_receive_queue, this is less
efficient since it requires spinlocks to synchronize between producer
and consumer.

This patch tries to address this by using circular buffer which allows
lockless synchronization. This is done by switching from
sk_receive_queue to a tx skb ring with a new flag IFF_TX_RING and when
this is set:

Why do we need a new flag? Is there a userspace-visible
behaviour change?


Probably yes since tx_queue_length does not work.




- store pointer to skb in circular buffer in tun_net_xmit(), and read
   it from the circular buffer in tun_do_read().
- introduce a new proto_ops peek which could be implemented by
   specific socket which does not use sk_receive_queue.
- store skb length in circular buffer too, and implement a lockless
   peek for tuntap.
- change vhost_net to use proto_ops->peek() instead
- new spinlocks were introduced to synchronize among producers (and so
   did for consumers).

Pktgen test shows about 9% improvement on guest receiving pps:

Before: ~148pps
After : ~161pps

(I'm not sure noblocking read is still needed, so it was not included
  in this patch)

How do you mean? Of course we must support blocking and non-blocking
read - userspace uses it.


Ok, will add this.




Signed-off-by: Jason Wang 
---
---
  drivers/net/tun.c   | 157 +---
  drivers/vhost/net.c |  16 -
  include/linux/net.h |   1 +
  include/uapi/linux/if_tun.h |   1 +
  4 files changed, 165 insertions(+), 10 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 425e983..6001ece 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -71,6 +71,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 
  
@@ -130,6 +131,8 @@ struct tap_filter {

  #define MAX_TAP_FLOWS  4096
  
  #define TUN_FLOW_EXPIRE (3 * HZ)

+#define TUN_RING_SIZE 256

Can we resize this according to tx_queue_len set by user?


We can, but it needs lots of other changes, e.g being notified when 
tx_queue_len was changed by user. And if tx_queue_length is not power of 
2, we probably need modulus to calculate the capacity.





+#define TUN_RING_MASK (TUN_RING_SIZE - 1)
  
  struct tun_pcpu_stats {

u64 rx_packets;
@@ -142,6 +145,11 @@ struct tun_pcpu_stats {
u32 rx_frame_errors;
  };
  
+struct tun_desc {

+   struct sk_buff *skb;
+   int len; /* Cached skb len for peeking */
+};
+
  /* A tun_file connects an open character device to a tuntap netdevice. It
   * also contains all socket related structures (except sock_fprog and 
tap_filter)
   * to serve as one transmit queue for tuntap device. The sock_fprog and
@@ -167,6 +175,13 @@ struct tun_file {
};
struct list_head next;
struct tun_struct *detached;
+   /* reader lock */
+   spinlock_t rlock;
+   unsigned long tail;
+   struct tun_desc tx_descs[TUN_RING_SIZE];
+   /* writer lock */
+   spinlock_t wlock;
+   unsigned long head;
  };
  
  struct tun_flow_entry {

@@ -515,7 +530,27 @@ static struct tun_struct *tun_enable_queue(struct tun_file 
*tfile)
  
  static void tun_queue_purge(struct tun_file *tfile)

  {
+   unsigned long head, tail;
+   struct tun_desc *desc;
+   struct sk_buff *skb;
skb_queue_purge(&tfile->sk.sk_receive_queue);
+   spin_lock(&tfile->rlock);
+
+   head = ACCESS_ONCE(tfile->head);
+   tail = tfile->tail;
+
+   /* read tail before reading descriptor at tail */
+   smp_rmb();

I think you mean read *head* here


Right.





+
+   while (CIRC_CNT(head, tail, TUN_RING_SIZE) >= 1) {
+   desc = &tfile->tx_descs[tail];
+   skb = desc->skb;
+   kfree_skb(skb);
+   tail = (tail + 1) & TUN_RING_MASK;
+   /* read descriptor before incrementing tail. */
+   smp_store_release(&tfile->tail, tail & TUN_RING_MASK);
+   }
+   spin_unlock(&tfile->rlock);
skb_queue_purge(&tfile->sk.sk_error_queue);
  }


Barrier pairing seems messed up. Could you tag
each barrier with its pair pls?
E.g. add /* Barrier A for pairing */ Before barrier and
its pair.


Ok.

for both tun_queue_purge() and tun_do_read():

smp_rmb() is paired with smp_store_release() in tun_net_xmit().
smp_store_release() is paired with spin_unlock()/spin_lock() in 
tun_net_xmit().


   

@@ -824,6 +859,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct 
net_device *dev)
int txq = skb->queue_mapping;
struct tun_file *tfile;
u32 numqueues = 0;
+   unsigned long flags;
  
  	rcu_read_lock();

tfile = rcu_dereference(tun->tfiles[txq]);
@@ -888,8 +924,35 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
struct net_device *dev)
  
  	nf_reset(skb);
  
-	/* Enqueue packet */

-   skb_queue_tail(&tfile->sock

Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child()

[SF Markus Elfring]

>> * Change an error message.
> 
> Why?  Is dev_err needed?

I interpreted Lee's response in this way.
https://lkml.org/lkml/2016/1/11/104

Regards,
Markus

Build regressions/improvements in v4.6

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.6[1] compared to v4.5[2].

Summarized:
  - build errors: +8/-7
  - build warnings: +16195/-159

JFYI, when comparing v4.6[1] to v4.6-rc7[3], the summaries are:
  - build errors: +7/-188
  - build warnings: +994/-880

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.6.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/10344/ (all 263 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/10047/ (262 out of 263 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/10306/ (262 out of 263 configs)


*** ERRORS ***

8 error regressions:
  + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: 'cached_to_uncached' 
undeclared (first use in this function):  => 99:17
  + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: implicit declaration 
of function 'cpu_context' [-Werror=implicit-function-declaration]:  => 192:2
  + /home/kisskb/slave/src/fs/xfs/xfs_ondisk.h: error: call to 
'__compiletime_assert_79' declared with attribute error: XFS: 
sizeof(xfs_attr_shortform_t) is wrong, expected 8:  => 79:2
  + /tmp/ccSuvE7E.s: Error: pcrel too far BFD_RELOC_BFIN_10:  => 889
  + error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.eeh_check_failure' defined in .text section in 
arch/powerpc/kernel/built-in.o:  => (.text+0x1ffa6f8), (.text+0x1ffa59c), 
(.text+0x1ffaeec), (.text+0x1ffaa5c), (.text+0x1ffaca4), (.text+0x1ffa8a8), 
(.text+0x1ffb134)
  + error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_18' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff9314)
  + error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_27' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ffb284)
  + error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_savegpr0_28' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff7890)

7 error improvements:
  - error: No rule to make target include/config/auto.conf: N/A => 
  - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.udelay' defined in .text section in arch/powerpc/kernel/built-in.o: 
(.text+0x1ffb6e8), (.text+0x1ffb3e0), (.text+0x1ffb34c), (.text+0x1ffb724) => 
  - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffaecc) => 
  - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_27' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffb264) => 
  - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffae7c) => 
  - error: hns_enet.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffba68) => 
  - error: hns_enet.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ffba2c), (.text+0x1ffba70) => 


*** WARNINGS ***

16195 warning regressions:

[Deleted 16022 lines about "warning: -ffunction-sections disabled; it makes 
profiling impossible [enabled by default]" on parisc-allmodconfig]

  + /home/kisskb/slave/src/arch/arm/include/asm/irqflags.h: warning: 'flags' 
may be used uninitialized in this function [-Wuninitialized]:  => 170:2
  + /home/kisskb/slave/src/arch/arm/mach-netx/generic.c: warning: 
'netx_io_desc' defined but not used [-Wunused-variable]:  => 33:24
  + /home/kisskb/slave/src/arch/ia64/sn/kernel/io_acpi_init.c: warning: unused 
variable 'addr' [-Wunused-variable]:  => 429:16
  + /home/kisskb/slave/src/arch/ia64/sn/kernel/io_init.c: warning: 'addr' may 
be used uninitialized in this function [-Wuninitialized]:  => 189:19
  + /home/kisskb/slave/src/arch/powerpc/boot/addnote.c: warning: right shift 
count >= width of type [enabled by default]:  => 206:3, 183:3, 211:3, 188:3
  + /home/kisskb/slave/src/arch/powerpc/net/bpf_jit_comp.c: warning: the frame 
size of 4416 bytes is larger than 2048 bytes [-Wframe-larger-than=]:  => 552:1
  + /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: 
Warning: overflow in branch to __restore_all; converted into longer instruction 
sequence:  => 89
  + /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: 
Warning: overflow in branch to syscall_call; converted 

Re: [PATCH] mtd: Adding of_mtd_info_get to get mtd_info from devicetree

[Boris Brezillon]

Hi Moritz,

On Wed, 11 May 2016 10:47:39 -0700
Moritz Fischer  wrote:

> This allows for getting a struct mtd_info from a node pointer,
> allowing mtd devices to e.g. store serial numbers or MAC addresses.

Can you detail a bit what you'll do next. I guess you need to provide
this information to in-kernel users, and those users will just call
mtd_read() after retrieving the mtd_info pointer.

Here are a few questions (I'm assuming the netdev + MAC address case):
- how would you link the net/PHY device to the MTD partition storing
  the MAC address

> 
> Signed-off-by: Moritz Fischer 
> ---
>  drivers/mtd/mtdcore.c   | 21 +
>  include/linux/mtd/mtd.h |  2 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 3096251..3d0ae65 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -363,6 +363,27 @@ unsigned mtd_mmap_capabilities(struct mtd_info *mtd)
>  EXPORT_SYMBOL_GPL(mtd_mmap_capabilities);
>  #endif
>  
> +static int mtd_of_node_match(struct device *dev, const void *data)
> +{
> + return dev->of_node == data;
> +}
> +
> +struct mtd_info *of_mtd_info_get(struct device_node *node)
> +{
> + struct mtd_info *mtd;
> + struct device *d;
> + int ret = -ENODEV;
> +
> + d = class_find_device(&mtd_class, NULL, node, mtd_of_node_match);
> + if (!d)
> + return ERR_PTR(-ENODEV);
> +
> + mtd = container_of(d, struct mtd_info, dev);
> +
> + return mtd;
> +}
> +EXPORT_SYMBOL_GPL(of_mtd_info_get);
> +
>  static int mtd_reboot_notifier(struct notifier_block *n, unsigned long state,
>  void *cmd)
>  {
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 7712721..cce6cc7 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -264,6 +264,8 @@ static inline struct device_node *mtd_get_of_node(struct 
> mtd_info *mtd)
>   return mtd->dev.of_node;
>  }
>  
> +struct mtd_info *of_mtd_info_get(struct device_node *node);
> +
>  static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
>  {
>   return ops->mode == MTD_OPS_AUTO_OOB ? mtd->oobavail : mtd->oobsize;



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v4 06/18] cris: Remove unnecessary of_platform_populate with default match table

[Jesper Nilsson]

On Thu, May 12, 2016 at 08:06:03PM +0800, Kefeng Wang wrote:
> After patch "of/platform: Add common method to populate default bus",
> it is possible for arch code to remove unnecessary callers about the
> of_platform_populate with default match table.
> 
> Cc: Mikael Starvik 

Acked-by: Jesper Nilsson 

> Signed-off-by: Kefeng Wang 
> ---
>  arch/cris/kernel/setup.c | 8 
>  1 file changed, 8 deletions(-)

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

Re: [PATCH v7 10/14] usb: otg: add hcd companion support

[Roger Quadros]

On 16/05/16 05:13, Peter Chen wrote:
> On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 12/05/16 13:31, Yoshihiro Shimoda wrote:
>>> Hi,
>>>
 From: Roger Quadros
 Sent: Thursday, May 12, 2016 6:32 PM

 Hi,

 On 12/05/16 11:34, Roger Quadros wrote:
> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
>> Hi,
>>
>>> From: Alan Stern
>>> Sent: Wednesday, May 11, 2016 11:47 PM
>>>
>>> On Wed, 11 May 2016, Roger Quadros wrote:
>>>
> What I mean is if you have 2 EHCI controllers with 2 companion
> controllers, don't you need to know which companion goes with which 
> EHCI
> controller? Just like you do for the otg-controller property.
>

 That is a very good point. I'm not very sure and it seems that current 
 code won't work
 with multiple EHCI + companion instances.
>>
>> I may misunderstand this topic, but if I use the following environment, 
>> it works correctly.
>>
>> < My environment >
>> - an otg controller: Sets hcd-needs-companion.
>> - ehci0 and ohci0 and a function: They connect to the otg controller 
>> using "otg-controller" property.
>> - ehci1 and ohci1: No "otg-controller" property.
>> - ehci2 and ohci2: No "otg-controller" property.
>>
>> In this environment, all hosts works correctly.
>> Also I think if we have 2 otg controlelrs, it should be work because 
>> otg_dev instance differs.
>
> The topic is about more than one otg controllers and how to tie the right 
> ehci and ohci
> to the correct otg_dev instance especially in cases where we can't depend 
> on probe order.
>
>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
>> I'm not sure such environment actually exists.
>
> No it is not about that.
>>>
>>> Thank you for the reply. I understood it.
>>>
 Alan, does USB core even know which EHCI and OHCI are linked to the 
 same port
 or the handoff is software transparent?
>>>
>>> The core knows.  It doesn't use the information for a whole lot of
>>> things, but it does use it in a couple of places.  Search for
>>> "companion" in core/hcd-pci.c and you'll see.
>>
>> Thank you for the information. I didn't know this code.
>> If my understanding is correct, the core/hcd-pci.c code will not be used 
>> by non-PCI devices.
>
> That is correct.
>
>> In other words, nobody sets "hcd->self.hs_companion" if we use such a 
>> device.
>> So, I will try to add such a code if needed.
>
> I think OTG core would have to rely on USB core in providing the right 
> companion device,
> just like we rely on it for the primary vs shared HCD case.
>

 OK, it is not so simple.

 EHCI and companion port handoff is really meant to be software transparent.

 non-PCI devices really don't have knowledge of which OHCI instance is 
 companion to the EHCI.
 With device tree we could provide this mapping but for non-device tree 
 case we can't do
 anything.

 So my suggestion would be to keep dual role implementation limited to one 
 instance for
 EHCI + companion case for non-DT.
 For PCI case I don't see how dual role can be implemented. I don't think 
 we have any
 dual-role PCI cards.
>>>
>>> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI 
>>> bus and
>>> one high speed function controller via AXI bus.
>>> One of channel can be used as host or function.
>>>
 For DT case we could have a DT binding to tie the EHCI and companion and 
 use that
 in the OTG framework.
>>
>> After looking at the code it seems we don't need this special binding as we 
>> are already
>> linking the EHCI controller and companion controller to the single otg 
>> controller instance
>> using the otg-controller property.
>>
> 
> Then, how you know this EHCI + companion controller special case during otg 
> adds
> hcd, it needs special handling, right?

We know the special case by using the hcd_needs_companion flag.

cheers,
-roger

> 
> Peter
> 
>> So all is good as of now.
>>
>> For non DT case, it is the responsibility of platform support code to ensure 
>> that
>> it calls usb_otg_add_hcd() with the correct otg controller instance for both 
>> EHCI and
>> companion controller and things should work fine there as well.
>>
>> --
>> cheers,
>> -roger
>>
>>>
>>> R-Car Gen3 SoC (r8a7795 / arm64) will be this type.
>>> (Both USB 2.0 host/function controllers connect to AXI bus.)
>>>
 Any objections?
>>>
>>> I don't have any objections because I'm just focus on R-Car Gen3 SoC for 
>>> now.
>>> If someone needs for PCI case, I think it is possible to add such a code 
>>> somehow later.
>>>
>>> Best regards,
>>> Yoshihiro Shimoda
>>>
 cheers,
 -roger
>> --
>> To unsubscri

Re: [PATCH] mtd: Adding of_mtd_info_get to get mtd_info from devicetree

[Boris Brezillon]

On Mon, 16 May 2016 09:55:34 +0200
Boris Brezillon  wrote:

> Hi Moritz,
> 
> On Wed, 11 May 2016 10:47:39 -0700
> Moritz Fischer  wrote:
> 
> > This allows for getting a struct mtd_info from a node pointer,
> > allowing mtd devices to e.g. store serial numbers or MAC addresses.  
> 
> Can you detail a bit what you'll do next. I guess you need to provide
> this information to in-kernel users, and those users will just call
> mtd_read() after retrieving the mtd_info pointer.
> 
> Here are a few questions (I'm assuming the netdev + MAC address case):
> - how would you link the net/PHY device to the MTD partition storing
>   the MAC address

Sorry, I sent it before asking all my questions :).

- it seems quite specific to MTD devices to me. What if the MAC address
  is stored in something that is not exposed as an MTD device. I wonder
  if we shouldn't add an nvmem wrapper around MTD devices.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child()

[Julia Lawall]

On Mon, 16 May 2016, SF Markus Elfring wrote:

> >> * Change an error message.
> > 
> > Why?  Is dev_err needed?
> 
> I interpreted Lee's response in this way.
> https://lkml.org/lkml/2016/1/11/104

OK.  He didn't ask for the message to be changed though.  It's a bit 
unfortunate that it now takes up multiple lines.  And I believe it also 
prints redundant information.  Perhaps he will have some further thoughts 
on the matter.

julia

Re: [PATCH net-next] tuntap: introduce tx skb ring

[Michael S. Tsirkin]

On Mon, May 16, 2016 at 03:52:11PM +0800, Jason Wang wrote:
> 
> 
> On 2016年05月16日 12:23, Michael S. Tsirkin wrote:
> >On Mon, May 16, 2016 at 09:17:01AM +0800, Jason Wang wrote:
> >>We used to queue tx packets in sk_receive_queue, this is less
> >>efficient since it requires spinlocks to synchronize between producer
> >>and consumer.
> >>
> >>This patch tries to address this by using circular buffer which allows
> >>lockless synchronization. This is done by switching from
> >>sk_receive_queue to a tx skb ring with a new flag IFF_TX_RING and when
> >>this is set:
> >Why do we need a new flag? Is there a userspace-visible
> >behaviour change?
> 
> Probably yes since tx_queue_length does not work.

So the flag name should reflect the behaviour somehow, not
the implementation.

> >
> >>- store pointer to skb in circular buffer in tun_net_xmit(), and read
> >>   it from the circular buffer in tun_do_read().
> >>- introduce a new proto_ops peek which could be implemented by
> >>   specific socket which does not use sk_receive_queue.
> >>- store skb length in circular buffer too, and implement a lockless
> >>   peek for tuntap.
> >>- change vhost_net to use proto_ops->peek() instead
> >>- new spinlocks were introduced to synchronize among producers (and so
> >>   did for consumers).
> >>
> >>Pktgen test shows about 9% improvement on guest receiving pps:
> >>
> >>Before: ~148pps
> >>After : ~161pps
> >>
> >>(I'm not sure noblocking read is still needed, so it was not included
> >>  in this patch)
> >How do you mean? Of course we must support blocking and non-blocking
> >read - userspace uses it.
> 
> Ok, will add this.
> 
> >
> >>Signed-off-by: Jason Wang 
> >>---
> >>---
> >>  drivers/net/tun.c   | 157 
> >> +---
> >>  drivers/vhost/net.c |  16 -
> >>  include/linux/net.h |   1 +
> >>  include/uapi/linux/if_tun.h |   1 +
> >>  4 files changed, 165 insertions(+), 10 deletions(-)
> >>
> >>diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >>index 425e983..6001ece 100644
> >>--- a/drivers/net/tun.c
> >>+++ b/drivers/net/tun.c
> >>@@ -71,6 +71,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include 
> >>@@ -130,6 +131,8 @@ struct tap_filter {
> >>  #define MAX_TAP_FLOWS  4096
> >>  #define TUN_FLOW_EXPIRE (3 * HZ)
> >>+#define TUN_RING_SIZE 256
> >Can we resize this according to tx_queue_len set by user?
> 
> We can, but it needs lots of other changes, e.g being notified when
> tx_queue_len was changed by user.

Some kind of notifier?
Probably better than a new user interface.

> And if tx_queue_length is not power of 2,
> we probably need modulus to calculate the capacity.

Is that really that important for speed?
If yes, round it up to next power of two.
You can also probably wrap it with a conditional instead.

> >
> >>+#define TUN_RING_MASK (TUN_RING_SIZE - 1)
> >>  struct tun_pcpu_stats {
> >>u64 rx_packets;
> >>@@ -142,6 +145,11 @@ struct tun_pcpu_stats {
> >>u32 rx_frame_errors;
> >>  };
> >>+struct tun_desc {
> >>+   struct sk_buff *skb;
> >>+   int len; /* Cached skb len for peeking */
> >>+};
> >>+
> >>  /* A tun_file connects an open character device to a tuntap netdevice. It
> >>   * also contains all socket related structures (except sock_fprog and 
> >> tap_filter)
> >>   * to serve as one transmit queue for tuntap device. The sock_fprog and
> >>@@ -167,6 +175,13 @@ struct tun_file {
> >>};
> >>struct list_head next;
> >>struct tun_struct *detached;
> >>+   /* reader lock */
> >>+   spinlock_t rlock;
> >>+   unsigned long tail;
> >>+   struct tun_desc tx_descs[TUN_RING_SIZE];
> >>+   /* writer lock */
> >>+   spinlock_t wlock;
> >>+   unsigned long head;
> >>  };
> >>  struct tun_flow_entry {
> >>@@ -515,7 +530,27 @@ static struct tun_struct *tun_enable_queue(struct 
> >>tun_file *tfile)
> >>  static void tun_queue_purge(struct tun_file *tfile)
> >>  {
> >>+   unsigned long head, tail;
> >>+   struct tun_desc *desc;
> >>+   struct sk_buff *skb;
> >>skb_queue_purge(&tfile->sk.sk_receive_queue);
> >>+   spin_lock(&tfile->rlock);
> >>+
> >>+   head = ACCESS_ONCE(tfile->head);
> >>+   tail = tfile->tail;
> >>+
> >>+   /* read tail before reading descriptor at tail */
> >>+   smp_rmb();
> >I think you mean read *head* here
> 
> Right.
> 
> >
> >
> >>+
> >>+   while (CIRC_CNT(head, tail, TUN_RING_SIZE) >= 1) {
> >>+   desc = &tfile->tx_descs[tail];
> >>+   skb = desc->skb;
> >>+   kfree_skb(skb);
> >>+   tail = (tail + 1) & TUN_RING_MASK;
> >>+   /* read descriptor before incrementing tail. */
> >>+   smp_store_release(&tfile->tail, tail & TUN_RING_MASK);
> >>+   }
> >>+   spin_unlock(&tfile->rlock);
> >>skb_queue_purge(&tfile->sk.sk_error_queue);
> >>  }
> >>
> >Barrier pairing seems messed up. Could you tag
> >each barrier with its pair pls?
> >E.g. add /* Barrier A for pairing */ Before barrier and
> >its pair.
> 
> Ok.
> 
> fo

Re: [RFC 11/13] mm, compaction: add the ultimate direct compaction priority

[Michal Hocko]

On Mon 16-05-16 09:17:11, Vlastimil Babka wrote:
> On 05/13/2016 03:38 PM, Michal Hocko wrote:
> > On Tue 10-05-16 09:36:01, Vlastimil Babka wrote:
[...]
> > > such as hugetlbfs allocations, and reduce some corner-case OOM's for 
> > > non-costly
> > > allocations.
> > 
> > My testing has shown that even with the current implementation with
> > deferring, skip hints and cached positions had (close to) 100% success
> > rate even with close to OOM conditions.
> 
> Hmm, I thought you at one point said that ignoring skip hints was a large
> improvement, because the current resetting of them is just too fuzzy.

Not in the hugetlb test. But you are right that skip hints resulted in
really fuzzy behavior.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH V2 1/4] dt-bindings: bus: Add documentation for Tegra210 ACONNECT

[Jon Hunter]

On 14/05/16 15:22, Rob Herring wrote:
> On Tue, May 10, 2016 at 12:35:37PM +0100, Jon Hunter wrote:
>> Add binding documentation for the Tegra ACONNECT bus that is part of the
>> Audio Processing Engine (APE) on Tegra210. The ACONNECT bus is used to
>> access devices within the APE subsystem. The APE is located in a
>> separate power domain and so accesses made to the ACONNECT require the
>> power domain to be enabled as well as some platform specific clocks.
>>
>> Signed-off-by: Jon Hunter 
>> ---
>>  .../bindings/bus/nvidia,tegra210-aconnect.txt  | 45 
>> ++
>>  1 file changed, 45 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt 
>> b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
>> new file mode 100644
>> index ..81668f588eca
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
>> @@ -0,0 +1,45 @@
>> +NVIDIA Tegra ACONNECT Bus
>> +
>> +The Tegra ACONNECT bus is an AXI switch which is used to connnect various
>> +components inside the Audio Processing Engine (APE). All CPU accesses to
>> +the APE subsystem go through the ACONNECT via an APB to AXI wrapper.
>> +
>> +Required properties:
>> +- compatible: Must be "nvidia,tegra210-aconnect".
>> +- clocks: Must contain the entries for the APE clock (TEGRA210_CLK_APE),
>> +  and APE interface clock (TEGRA210_CLK_APB2APE).
>> +- clock-names: Must contain the names "ape" and "apb2ape" for the 
>> corresponding
>> +  'clocks' entries.
>> +- power-domains: Must contain a phandle that points to the audio powergate
>> +  (namely 'aud') for Tegra210.
>> +- #address-cells: The number of cells used to represent physical base 
>> addresses
>> +  in the aconnect address space. Should be 2.
>> +- #size-cells: The number of cells used to represent the size of an address
>> +  range in the aconnect address space. Should be 2.
> 
> You forgot to update these. With that,

Darn it, yes.

> Acked-by: Rob Herring 

Thanks!
Jon

Re: [PATCH v8 10/14] usb: otg: add hcd companion support

[Roger Quadros]

On 13/05/16 21:13, Rob Herring wrote:
> On Fri, May 13, 2016 at 5:03 AM, Roger Quadros  wrote:
>> From: Yoshihiro Shimoda 
>>
>> Since some host controller (e.g. EHCI) needs a companion host controller
>> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
>> core.
>>
>> Signed-off-by: Yoshihiro Shimoda 
>> Signed-off-by: Roger Quadros 
>> Acked-by: Peter Chen 
>> ---
>>  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
>>  drivers/usb/common/usb-otg.c  | 32 
>> ---
>>  include/linux/usb/otg.h   |  7 -
>>  3 files changed, 32 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
>> b/Documentation/devicetree/bindings/usb/generic.txt
>> index f6866c1..1db1c33 100644
>> --- a/Documentation/devicetree/bindings/usb/generic.txt
>> +++ b/Documentation/devicetree/bindings/usb/generic.txt
>> @@ -27,6 +27,9 @@ Optional properties:
>>   - otg-controller: phandle to otg controller. Host or gadget controllers can
>> contain this property to link it to a particular OTG
>> controller.
>> + - hcd-needs-companion: must be present if otg controller is dealing with
>> +   EHCI host controller that needs a companion OHCI host
>> +   controller.
> 
> I thought the conclusion was this is not needed?

This is still needed to differentiate between primary+shared HCD case vs
primary + primary-companion HCD case.

> 
> One thing that is not clear here is otg-controller is a host or device
> property while hcd-needs-companion is an OTG controller property.
> These lists should be separated.

Agreed. I'll fix that up.

cheers,
-roger

Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority

[Michal Hocko]

On Mon 16-05-16 09:31:44, Vlastimil Babka wrote:
> On 05/13/2016 04:15 PM, Michal Hocko wrote:
> > On Tue 10-05-16 09:36:02, Vlastimil Babka wrote:
> > > 
> > > - should_compact_retry() is only called when should_reclaim_retry() 
> > > returns
> > >false. This means that compaction priority cannot get increased as long
> > >as reclaim makes sufficient progress. Theoretically, reclaim should 
> > > stop
> > >retrying for high-order allocations as long as the high-order page 
> > > doesn't
> > >exist but due to races, this may result in spurious retries when the
> > >high-order page momentarily does exist.
> > 
> > This is intentional behavior and I would like to preserve it if it is
> > possible. For higher order pages should_reclaim_retry retries as long
> > as there are some eligible high order pages present which are just hidden
> > by the watermark check. So this is mostly to get us over watermarks to
> > start carrying about fragmentation. If we race there then nothing really
> > terrible should happen and we should eventually converge to a terminal
> > state.
> > 
> > Does this make sense to you?
> 
> Yeah it should work, my only worry was that this may get subtly wrong (as
> experience shows us) and due to e.g. slightly different watermark checks
> and/or a corner-case zone such as ZONE_DMA, should_reclaim_retry() would
> keep returning true, even if reclaim couldn't/wouldn't help anything. Then
> compaction would be needlessly kept at ineffective priority.

watermark check for ZONE_DMA should always fail because it fails even
when is completely free to the lowmem reserves. I had a subtle bug in
the original code to check highzone_idx rather than classzone_idx but
that should the fix has been posted recently:
http://lkml.kernel.org/r/1463051677-29418-2-git-send-email-mho...@kernel.org

> Also my understanding of the initial compaction priorities is to lower the
> latency if fragmentation is just light and there's enough memory. Once we
> start struggling, I don't see much point in not switching to the full
> compaction priority quickly.

That is true but why to compact when there are high order pages and they
are just hidden by the watermark check.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v7 10/14] usb: otg: add hcd companion support

[Peter Chen]

On Mon, May 16, 2016 at 11:01:27AM +0300, Roger Quadros wrote:
> On 16/05/16 05:13, Peter Chen wrote:
> > On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 12/05/16 13:31, Yoshihiro Shimoda wrote:
> >>> Hi,
> >>>
>  From: Roger Quadros
>  Sent: Thursday, May 12, 2016 6:32 PM
> 
>  Hi,
> 
>  On 12/05/16 11:34, Roger Quadros wrote:
> > On 12/05/16 07:00, Yoshihiro Shimoda wrote:
> >> Hi,
> >>
> >>> From: Alan Stern
> >>> Sent: Wednesday, May 11, 2016 11:47 PM
> >>>
> >>> On Wed, 11 May 2016, Roger Quadros wrote:
> >>>
> > What I mean is if you have 2 EHCI controllers with 2 companion
> > controllers, don't you need to know which companion goes with which 
> > EHCI
> > controller? Just like you do for the otg-controller property.
> >
> 
>  That is a very good point. I'm not very sure and it seems that 
>  current code won't work
>  with multiple EHCI + companion instances.
> >>
> >> I may misunderstand this topic, but if I use the following 
> >> environment, it works correctly.
> >>
> >> < My environment >
> >> - an otg controller: Sets hcd-needs-companion.
> >> - ehci0 and ohci0 and a function: They connect to the otg controller 
> >> using "otg-controller" property.
> >> - ehci1 and ohci1: No "otg-controller" property.
> >> - ehci2 and ohci2: No "otg-controller" property.
> >>
> >> In this environment, all hosts works correctly.
> >> Also I think if we have 2 otg controlelrs, it should be work because 
> >> otg_dev instance differs.
> >
> > The topic is about more than one otg controllers and how to tie the 
> > right ehci and ohci
> > to the correct otg_dev instance especially in cases where we can't 
> > depend on probe order.
> >
> >> Or, does this topic assume an otg controller handles 2 EHCI 
> >> controllers?
> >> I'm not sure such environment actually exists.
> >
> > No it is not about that.
> >>>
> >>> Thank you for the reply. I understood it.
> >>>
>  Alan, does USB core even know which EHCI and OHCI are linked to the 
>  same port
>  or the handoff is software transparent?
> >>>
> >>> The core knows.  It doesn't use the information for a whole lot of
> >>> things, but it does use it in a couple of places.  Search for
> >>> "companion" in core/hcd-pci.c and you'll see.
> >>
> >> Thank you for the information. I didn't know this code.
> >> If my understanding is correct, the core/hcd-pci.c code will not be 
> >> used by non-PCI devices.
> >
> > That is correct.
> >
> >> In other words, nobody sets "hcd->self.hs_companion" if we use such a 
> >> device.
> >> So, I will try to add such a code if needed.
> >
> > I think OTG core would have to rely on USB core in providing the right 
> > companion device,
> > just like we rely on it for the primary vs shared HCD case.
> >
> 
>  OK, it is not so simple.
> 
>  EHCI and companion port handoff is really meant to be software 
>  transparent.
> 
>  non-PCI devices really don't have knowledge of which OHCI instance is 
>  companion to the EHCI.
>  With device tree we could provide this mapping but for non-device tree 
>  case we can't do
>  anything.
> 
>  So my suggestion would be to keep dual role implementation limited to 
>  one instance for
>  EHCI + companion case for non-DT.
>  For PCI case I don't see how dual role can be implemented. I don't think 
>  we have any
>  dual-role PCI cards.
> >>>
> >>> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via 
> >>> PCI bus and
> >>> one high speed function controller via AXI bus.
> >>> One of channel can be used as host or function.
> >>>
>  For DT case we could have a DT binding to tie the EHCI and companion and 
>  use that
>  in the OTG framework.
> >>
> >> After looking at the code it seems we don't need this special binding as 
> >> we are already
> >> linking the EHCI controller and companion controller to the single otg 
> >> controller instance
> >> using the otg-controller property.
> >>

[...]
> > 
> > Then, how you know this EHCI + companion controller special case during otg 
> > adds
> > hcd, it needs special handling, right?
> 
> We know the special case by using the hcd_needs_companion flag.
> 

You had said "we don't need this..", ok, yes, we do need it.

-- 

Best Regards,
Peter Chen

Re: [GIT PULL] drm/arcpgu: use dedicated memory area for frame buffer

[Alexey Brodkin]

Hi Dave,

On Tue, 2016-05-10 at 09:51 +, Alexey Brodkin wrote:
> Hi Dave,
> 
> On Fri, 2016-04-29 at 11:36 +, Alexey Brodkin wrote:
> > 
> > Hi Dave,
> > 
> > Please pull this mini-series that allows ARC PGU to use
> > dedicated memory location as framebuffer backing storage.
> > 
> > v2 of that series was reviewed here
> > https://lists.freedesktop.org/archives/dri-devel/2016-April/106279.html
> > 
> > It is based on top of today's drm-next branch.
> > 
> > Best regards,
> > Alexey
> > 
> > The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:
> > 
> >   Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
> > drm-next (2016-04-29 14:57:51 +1000)
> > 
> > are available in the git repository at:
> > 
> >   https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
> > topic-arcpgu-updates
> > 
> > for you to fetch changes up to cb2ad5e5339c5122166265cea579cc6a356d46de:
> > 
> >   ARC: [axs10x] Specify reserved memory for frame buffer (2016-04-29 
> > 14:34:13 +0300)
> > 
> > 
> > Alexey Brodkin (2):
> >   drm/arcpgu: use dedicated memory area for frame buffer
> >   ARC: [axs10x] Specify reserved memory for frame buffer
> > 
> >  arch/arc/boot/dts/axc001.dtsi | 22 --
> >  arch/arc/boot/dts/axc003.dtsi | 14 ++
> >  arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
> >  arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
> >  drivers/gpu/drm/arc/arcpgu_drv.c  |  6 ++
> >  5 files changed, 55 insertions(+), 3 deletions(-)
> Could you please take a look at this pull request?

Another polite reminder.

-Alexey

[PATCH 1/2] clk: samsung: clkout: Add support for Exynos5410

[Krzysztof Kozlowski]

Add compatible for Exynos5410 so the PMU on this SoC would provide
CLKOUT.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/clk/samsung/clk-exynos-clkout.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos-clkout.c 
b/drivers/clk/samsung/clk-exynos-clkout.c
index 7cd02ff37a1f..96fab6cfb202 100644
--- a/drivers/clk/samsung/clk-exynos-clkout.c
+++ b/drivers/clk/samsung/clk-exynos-clkout.c
@@ -151,6 +151,8 @@ static void __init exynos5_clkout_init(struct device_node 
*node)
 }
 CLK_OF_DECLARE(exynos5250_clkout, "samsung,exynos5250-pmu",
exynos5_clkout_init);
+CLK_OF_DECLARE(exynos5410_clkout, "samsung,exynos5410-pmu",
+   exynos5_clkout_init);
 CLK_OF_DECLARE(exynos5420_clkout, "samsung,exynos5420-pmu",
exynos5_clkout_init);
 CLK_OF_DECLARE(exynos5433_clkout, "samsung,exynos5433-pmu",
-- 
1.9.1

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Roger Quadros]

Hi,

On 16/05/16 10:02, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>> +
>> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool 
>> connect)
>> +{
>> +struct usb_udc *udc;
>> +
>> +mutex_lock(&udc_lock);
>> +udc = usb_gadget_to_udc(gadget);
>> +if (!udc) {
>> +dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>> +__func__);
>> +mutex_unlock(&udc_lock);
>> +return -EINVAL;
>> +}
>> +
>> +if (connect) {
>> +if (!gadget->connected)
>> +usb_gadget_connect(udc->gadget);
>> +} else {
>> +if (gadget->connected) {
>> +usb_gadget_disconnect(udc->gadget);
>> +udc->driver->disconnect(udc->gadget);
>> +}
>> +}
>> +
>> +mutex_unlock(&udc_lock);
>> +
>> +return 0;
>> +}
>> +
> 
> Since this is called for vbus interrupt, why not using
> usb_udc_vbus_handler directly, and call udc->driver->disconnect
> at usb_gadget_stop.

We can't assume that this is always called for vbus interrupt so
I decided not to call usb_udc_vbus_handler.

udc->vbus is really pointless for us. We keep vbus states in our
state machine and leave udc->vbus as ture always.

Why do you want to move udc->driver->disconnect() to stop?
If USB controller disconnected from bus then the gadget driver
must be notified about the disconnect immediately. The controller
may or may not be stopped by the core.

> 
>>  return 0;
>> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device 
>> *dev,
>>  return -EOPNOTSUPP;
>>  }
>>  
>> +/* In OTG mode we don't support softconnect, but b_bus_req */
>> +if (udc->gadget->otg_dev) {
>> +dev_err(dev, "soft-connect not supported in OTG mode\n");
>> +return -EOPNOTSUPP;
>> +}
>> +
> 
> The soft-connect can be supported at dual-role mode currently, we can
> use b_bus_req entry once it is implemented later.

Soft-connect should be done via sysfs handling within the OTG core.
This can be added later. I don't want anything outside the OTG core
to handle soft-connect behaviour as it will be hard to keep things
in sync.

I can update the comment to something like this.

/* In OTG/dual-role mode, soft-connect should be handled by OTG core */

> 
>>  if (sysfs_streq(buf, "connect")) {
>>  usb_gadget_udc_start(udc);
>> -usb_gadget_connect(udc->gadget);
>> +usb_udc_connect_control(udc);
> 
> This line seems to be not related with this patch.
> 
Right. I'll remove it.

cheers,
-roger

[PATCH 2/2] ARM: dts: exynos: Enable CLKOUT on Exynos5410

[Krzysztof Kozlowski]

The CLKOUT (which control is provided by PMU) is necessary for some of
the drivers using this as a clock, e.g. usb3503 USB HUB on Odroid XU
board.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5410.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index e9564ab5b5d3..f1effd3f03c4 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -70,6 +70,9 @@
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
+   clock-names = "clkout16";
+   clocks = <&fin_pll>;
+   #clock-cells = <1>;
};
 
clock: clock-controller@1001 {
-- 
1.9.1

Re: [PATCH] tty: serial: msm: Remove duplicate handling of clocks

[Pramod Gurav]

On 11 May 2016 at 14:30, Pramod Gurav  wrote:
> msm_serial driver provides a .pm callback to the serial core to enable
> and disable clock resource in suspend/resume path. This function is
> also called before msm_startup. msm_startup also enables the clocks which
> is not needed. Hence remove the duplcate clock operation from msm_startup
> and msm_shutdown. Same is done in console setup to get rid of duplicate
> clock operation.
>
> Tested on DB410C console.
>
> Signed-off-by: Pramod Gurav 
> ---
>  drivers/tty/serial/msm_serial.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
> index dcde955..73c3217 100644
> --- a/drivers/tty/serial/msm_serial.c
> +++ b/drivers/tty/serial/msm_serial.c
> @@ -959,15 +959,6 @@ static int msm_set_baud_rate(struct uart_port *port, 
> unsigned int baud,
> return baud;
>  }
>
> -static void msm_init_clock(struct uart_port *port)
> -{
> -   struct msm_port *msm_port = UART_TO_MSM(port);
> -
> -   clk_prepare_enable(msm_port->clk);
> -   clk_prepare_enable(msm_port->pclk);
> -   msm_serial_set_mnd_regs(port);
> -}
> -
>  static int msm_startup(struct uart_port *port)
>  {
> struct msm_port *msm_port = UART_TO_MSM(port);
> @@ -982,7 +973,7 @@ static int msm_startup(struct uart_port *port)
> if (unlikely(ret))
> return ret;
>
> -   msm_init_clock(port);
> +   msm_serial_set_mnd_regs(port);

Further testing with another UART port made me realize that serial
port does not work after disabling msm_port->clk clock. The RX data
part will be affected.
Confirmed from manual that this clock should never be turned of to
avoid loss of incoming data. Sorry for the noise.

>
> if (likely(port->fifosize > 12))
> rfr_level = port->fifosize - 12;
> @@ -1021,8 +1012,6 @@ static void msm_shutdown(struct uart_port *port)
> if (msm_port->is_uartdm)
> msm_release_dma(msm_port);
>
> -   clk_disable_unprepare(msm_port->clk);
> -
> free_irq(port->irq, port);
>  }
>
> @@ -1451,7 +1440,7 @@ static int __init msm_console_setup(struct console *co, 
> char *options)
> if (unlikely(!port->membase))
> return -ENXIO;
>
> -   msm_init_clock(port);
> +   msm_serial_set_mnd_regs(port);
>
> if (options)
> uart_parse_options(options, &baud, &parity, &bits, &flow);
> --
> 1.8.2.1
>

Re: Build regressions/improvements in v4.6

[Geert Uytterhoeven]

On Mon, May 16, 2016 at 9:55 AM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v4.6[1] to v4.6-rc7[3], the summaries are:
>   - build errors: +7/-188

Nothing special to report here.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v9 2/2] gpio: move clps711x, moxart, ts4800 and gpio-ge into gpio-mmio

[Alexandre Courbot]

On Thursday, May 12, 2016 10:07:06 PM JST, Christian Lamparter wrote:

On Thursday, May 12, 2016 07:30:05 PM Alexandre Courbot wrote:

On Wednesday, May 11, 2016 6:34:35 PM JST, Christian Lamparter wrote: ...

[...]

...
Ouch, I don't like this. Also the probability that the "if (!res->name || 
...)" condition is not met is so small that I would not bother 
with it and 
do the kstrdup unconditionally. But maybe we can remove this altogether - 
see below... ...


The !res->name check is simply there because the kernel's strcmp doesn't
check for NULL... the res->name will be coming from the device tree.
Yes it should always be initialized but again: it's not within 
the functions 
control so it better be prepared for it. The "dir_reg_name" is part of the
function so we can guarantee that it's not NULL or a invalid string. 


About the leakage: I use devm_kstrdup unlike the dump strdup, it does bind
the dupped string to the device. This way the resource is not leaked even
if the module is loaded and unloaded, it stays with the device. (Until
it is destroyed).


What I wanted to point out is that it is probably ok to just duplicate the 
string at all times, since the probability that res->name will not be NULL 
*and* the string will already match what we expect is very low (and could 
only come from a device tree that is aware of this patch).


Leakage is not a concern thanks to devm, as you have pointed out.

 
Note: The strcmp is there to check if resource name was already updated

so even if the module was loaded multiple times it will dup the string
just once.


Mmm, is this how things really work? My understanding is that 
devm-allocated resources will be freed after the driver's remove function 
is called (see slides 11/12 of 
http://haifux.org/lectures/323/haifux-devres.pdf). I.e. when the module is 
unloaded, your string will be destroyed. So unless I am missing something 
you would still need to duplicate it the next time the device is probed.


So here it seems to me that to be on the safe side you either need to 
restore the previous value of res->name on device destruction, or always 
duplicate the string when probing it. But with this later solution there is 
still the risk that if you then load *another* driver to probe this device, 
which will then find a valid pointer on res->name, only to find invalid 
content when following it... So in the end I'd recommend against messing 
with resources like that - it just creates potential for invalid states.


Hopefully is my following suggestion is valid, you won't need to.



Doing a direct assignment like I did in the earlier versions would lead
to issues since the device resources are part of the the device and not
with the driver module.


...
Ok, so this is getting quite complex, with two of_device_id 
tables and two 
levels of hooks, mainly because you want to use the bgpio_pdev_probe() 
function which relies on named memory resources. ...
I think I need more here. The bgpio_pdev_probe() also sets up 
the bgpio_maps()
(there are 6 and I'm using 4 at the moment for all compat chips). 
The bgpio_pdev_probe() also deals with devm_gpiochip_add_data() 
and allocates

the memory for the gpiochip structure... as well as  and the error handling.
etc...

That's why I reused the existing code as much as possible.
(But let's get to the main issue here:)
This function is here for basic platform devices, and you are not obliged 
to rely on it for DT. Feel free to write your own function (or 
rather split 
bgpio_pdev_probe() in two code paths) if it can reduce the 
amount of black 
magic you need to do (especially the renaming of resources on-the-fly).


At the end of the day what you want is a function that calls 
bgpio_init()  ...


The main issue why this got so complicated was keeping compatibility with
the existing drivers.

If you look at "clps711x_parse_dt". You will see that it supports 5 GPIOs.
The thing that makes it really ugly is that it uses the dt alias as a way
to identify each port (A-E). The Port is then used to encode the number of
gpios the controller has and whenever it is dirin or dirout... 
I argued that this information should be put in the dts and I made patch

for it. But updating the dts was not the way to go. as Rob explained
in .

This means that unless you can make a single structure that would encode
everything these compat drivers do, (look at the call_back functions of
the other drivers, each of the compat drivers also has a little bit of
extra code associated to setup stuff like a label or have an extra ngpios
property parser, etc...). I cannot see how you could make this any better
without breaking compatibility. This was the sole reason why there are
these individual parsers. (In RFC v4? I had that parser in their original
files - I don't know if this would have worked any better, but feedback
indicated that everything should be moved to the gpio-mmio.c). 


So, what's yo

Re: [PATCH v7 10/14] usb: otg: add hcd companion support

[Roger Quadros]

On 16/05/16 11:13, Peter Chen wrote:
> On Mon, May 16, 2016 at 11:01:27AM +0300, Roger Quadros wrote:
>> On 16/05/16 05:13, Peter Chen wrote:
>>> On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
 Hi,

 On 12/05/16 13:31, Yoshihiro Shimoda wrote:
> Hi,
>
>> From: Roger Quadros
>> Sent: Thursday, May 12, 2016 6:32 PM
>>
>> Hi,
>>
>> On 12/05/16 11:34, Roger Quadros wrote:
>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
 Hi,

> From: Alan Stern
> Sent: Wednesday, May 11, 2016 11:47 PM
>
> On Wed, 11 May 2016, Roger Quadros wrote:
>
>>> What I mean is if you have 2 EHCI controllers with 2 companion
>>> controllers, don't you need to know which companion goes with which 
>>> EHCI
>>> controller? Just like you do for the otg-controller property.
>>>
>>
>> That is a very good point. I'm not very sure and it seems that 
>> current code won't work
>> with multiple EHCI + companion instances.

 I may misunderstand this topic, but if I use the following 
 environment, it works correctly.

 < My environment >
 - an otg controller: Sets hcd-needs-companion.
 - ehci0 and ohci0 and a function: They connect to the otg controller 
 using "otg-controller" property.
 - ehci1 and ohci1: No "otg-controller" property.
 - ehci2 and ohci2: No "otg-controller" property.

 In this environment, all hosts works correctly.
 Also I think if we have 2 otg controlelrs, it should be work because 
 otg_dev instance differs.
>>>
>>> The topic is about more than one otg controllers and how to tie the 
>>> right ehci and ohci
>>> to the correct otg_dev instance especially in cases where we can't 
>>> depend on probe order.
>>>
 Or, does this topic assume an otg controller handles 2 EHCI 
 controllers?
 I'm not sure such environment actually exists.
>>>
>>> No it is not about that.
>
> Thank you for the reply. I understood it.
>
>> Alan, does USB core even know which EHCI and OHCI are linked to the 
>> same port
>> or the handoff is software transparent?
>
> The core knows.  It doesn't use the information for a whole lot of
> things, but it does use it in a couple of places.  Search for
> "companion" in core/hcd-pci.c and you'll see.

 Thank you for the information. I didn't know this code.
 If my understanding is correct, the core/hcd-pci.c code will not be 
 used by non-PCI devices.
>>>
>>> That is correct.
>>>
 In other words, nobody sets "hcd->self.hs_companion" if we use such a 
 device.
 So, I will try to add such a code if needed.
>>>
>>> I think OTG core would have to rely on USB core in providing the right 
>>> companion device,
>>> just like we rely on it for the primary vs shared HCD case.
>>>
>>
>> OK, it is not so simple.
>>
>> EHCI and companion port handoff is really meant to be software 
>> transparent.
>>
>> non-PCI devices really don't have knowledge of which OHCI instance is 
>> companion to the EHCI.
>> With device tree we could provide this mapping but for non-device tree 
>> case we can't do
>> anything.
>>
>> So my suggestion would be to keep dual role implementation limited to 
>> one instance for
>> EHCI + companion case for non-DT.
>> For PCI case I don't see how dual role can be implemented. I don't think 
>> we have any
>> dual-role PCI cards.
>
> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via 
> PCI bus and
> one high speed function controller via AXI bus.
> One of channel can be used as host or function.
>
>> For DT case we could have a DT binding to tie the EHCI and companion and 
>> use that
>> in the OTG framework.

 After looking at the code it seems we don't need this special binding as 
 we are already
 linking the EHCI controller and companion controller to the single otg 
 controller instance
 using the otg-controller property.

> 
> [...]
>>>
>>> Then, how you know this EHCI + companion controller special case during otg 
>>> adds
>>> hcd, it needs special handling, right?
>>
>> We know the special case by using the hcd_needs_companion flag.
>>
> 
> You had said "we don't need this..", ok, yes, we do need it.
> 
I'm sorry for the confusion. What I meant by "we don't need this special 
binding" was that
we don't need additional binding to link the HCD and companion HCD.

cheers,
-roger

[PATCH v1 00/10] *** imx-sdma: misc fix ***

[Jiada Wang]

this patch set contains the following changes
1. fix issues in cyclic dma
2. add support to SYNC DMA termination
3. avoid system hang, when SDMA channel 0 timeouts
4. add lock to prevent race condition

Jiada Wang (10):
  dma: imx-sdma: use chn_real_count to report residue for UART
  dma: imx-sdma: don't update BD in isr routine
  dma: imx-sdma: clear BD_RROR flag before pass it to sdma script
  dma: imx-sdma: update sdma channel status for cyclic dma
  dma: imx-sdma: add flag to indicate SDMA channel state
  dma: imx-sdma: add terminate_all support
  dma: imx-sdma: Add synchronization support
  dma: imx-sdma: abort updating channel when it has been terminated
  dma: imx-sdma: disable channel 0 when it timeouts
  dma: imx-sdma: clear channel0 interrupt bit in irq routine

 drivers/dma/imx-sdma.c | 113 +++--
 1 file changed, 82 insertions(+), 31 deletions(-)

-- 
2.4.5

[PATCH 02/10] dma: imx-sdma: don't update BD in isr routine

[Jiada Wang]

commit d1a792f3b407 ("Update imx-sdma cyclic handling to report residue")
moves updating of BD to isr routine, to avoid stop
of cyclic dma, but there is chance 'new' isr comes before the 'old'
tasklet can be fired, thus cause data loss due to missing of one
tasklet. So move updating of BD back to tasklet.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1f1b64b..887e4e5 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -656,12 +656,6 @@ static void sdma_event_disable(struct sdma_channel *sdmac, 
unsigned int event)
 
 static void sdma_handle_channel_loop(struct sdma_channel *sdmac)
 {
-   if (sdmac->desc.callback)
-   sdmac->desc.callback(sdmac->desc.callback_param);
-}
-
-static void sdma_update_channel_loop(struct sdma_channel *sdmac)
-{
struct sdma_buffer_descriptor *bd;
 
/*
@@ -685,6 +679,9 @@ static void sdma_update_channel_loop(struct sdma_channel 
*sdmac)
sdmac->chn_real_count = bd->mode.count;
bd->mode.count = sdmac->chn_count;
}
+
+   if (sdmac->desc.callback)
+   sdmac->desc.callback(sdmac->desc.callback_param);
}
 }
 
@@ -740,9 +737,6 @@ static irqreturn_t sdma_int_handler(int irq, void *dev_id)
int channel = fls(stat) - 1;
struct sdma_channel *sdmac = &sdma->channel[channel];
 
-   if (sdmac->flags & IMX_DMA_SG_LOOP)
-   sdma_update_channel_loop(sdmac);
-
tasklet_schedule(&sdmac->tasklet);
 
__clear_bit(channel, &stat);
-- 
2.4.5

[PATCH 03/10] dma: imx-sdma: clear BD_RROR flag before pass it to sdma script

[Jiada Wang]

Previously in cyclic dma mode when sdma transfer fails for one buffer,
it will mask BD_RROR flag for that buffer descriptor (BD). This flag
won't be cleared unless a new cyclic dma transfer is prepared, so if
sdma script next time iterates to the same BD, even this time the
transfer is successful, but as BD_RROR flag is set, client side
will still think the transfer failed.

This patch clears BD_RROR flag before pass it to sdma script.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 887e4e5..1489de0 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -671,6 +671,7 @@ static void sdma_handle_channel_loop(struct sdma_channel 
*sdmac)
if (bd->mode.status & BD_RROR)
sdmac->status = DMA_ERROR;
 
+   bd->mode.status &= ~BD_RROR;
bd->mode.status |= BD_DONE;
sdmac->buf_tail++;
sdmac->buf_tail %= sdmac->num_bd;
-- 
2.4.5

[PATCH 07/10] dma: imx-sdma: Add synchronization support

[Jiada Wang]

Implement the new device_synchronize() callback to allow proper
synchronization when stopping a channel. Since the driver already makes
sure that no new complete callbacks are scheduled after the
device_terminate_all() has been called, all left to do in the
device_synchronize() callback is to wait for all currently running complete
callbacks to finish.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 040cbf2..0b23407 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1408,6 +1408,13 @@ static int sdma_terminate_all(struct dma_chan *chan)
return 0;
 }
 
+static void sdma_synchronize(struct dma_chan *chan)
+{
+   struct sdma_channel *sdmac = to_sdma_chan(chan);
+
+   tasklet_kill(&sdmac->tasklet);
+}
+
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V134
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V341
@@ -1827,6 +1834,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
sdma->dma_device.device_terminate_all = sdma_terminate_all;
+   sdma->dma_device.device_synchronize = sdma_synchronize;
sdma->dma_device.dev->dma_parms = &sdma->dma_parms;
dma_set_max_seg_size(sdma->dma_device.dev, 65535);
 
-- 
2.4.5

[PATCH 09/10] dma: imx-sdma: disable channel 0 when it timeouts

[Jiada Wang]

Previously when channel0 timeouts to finish its task,
sdma_run_channel0() just returns without disable channel0,
this will cause continuous interrupt later when channel0
finishs its task and set channel0 interrupt bit.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 43 ++-
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index bc867e5..8b20bf4 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -572,6 +572,27 @@ static void sdma_enable_channel(struct sdma_engine *sdma, 
int channel)
spin_unlock_irqrestore(&sdmac->lock, flags);
 }
 
+static struct sdma_channel *to_sdma_chan(struct dma_chan *chan)
+{
+   return container_of(chan, struct sdma_channel, chan);
+}
+
+static int sdma_disable_channel(struct dma_chan *chan)
+{
+   struct sdma_channel *sdmac = to_sdma_chan(chan);
+   struct sdma_engine *sdma = sdmac->sdma;
+   int channel = sdmac->channel;
+   unsigned long flags;
+
+   spin_lock_irqsave(&sdmac->lock, flags);
+   sdmac->enabled = false;
+   writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
+   sdmac->status = DMA_ERROR;
+   spin_unlock_irqrestore(&sdmac->lock, flags);
+
+   return 0;
+}
+
 /*
  * sdma_run_channel0 - run a channel and wait till it's done
  */
@@ -592,6 +613,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
/* Clear the interrupt status */
writel_relaxed(ret, sdma->regs + SDMA_H_INTR);
} else {
+   sdma_disable_channel(&sdma->channel[0].chan);
dev_err(sdma->dev, "Timeout waiting for CH0 ready\n");
}
 
@@ -916,27 +938,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
return ret;
 }
 
-static struct sdma_channel *to_sdma_chan(struct dma_chan *chan)
-{
-   return container_of(chan, struct sdma_channel, chan);
-}
-
-static int sdma_disable_channel(struct dma_chan *chan)
-{
-   struct sdma_channel *sdmac = to_sdma_chan(chan);
-   struct sdma_engine *sdma = sdmac->sdma;
-   int channel = sdmac->channel;
-   unsigned long flags;
-
-   spin_lock_irqsave(&sdmac->lock, flags);
-   sdmac->enabled = false;
-   writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
-   sdmac->status = DMA_ERROR;
-   spin_unlock_irqrestore(&sdmac->lock, flags);
-
-   return 0;
-}
-
 static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
 {
struct sdma_engine *sdma = sdmac->sdma;
-- 
2.4.5

[PATCH 10/10] dma: imx-sdma: clear channel0 interrupt bit in irq routine

[Jiada Wang]

When SDMA channel0 timeouts, even it's disabled in error path,
but sometimes we still see its interrupt bit be asserted,
which causes irq routine be triggered continuously because
no one else clears this bit.

This commit clears channel0 interrupt as well in irq routine,
so that even channel0 timeouts, it won't cause irq storm,
also adds lock to prevent irq routine to clear this bit when
sdma_run_channel0() is busy checking it.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 8b20bf4..ca1c984 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -768,12 +768,16 @@ static void sdma_tasklet(unsigned long data)
 static irqreturn_t sdma_int_handler(int irq, void *dev_id)
 {
struct sdma_engine *sdma = dev_id;
-   unsigned long stat;
+   unsigned long stat, flags;
+
+   spin_lock_irqsave(&sdma->channel_0_lock, flags);
 
stat = readl_relaxed(sdma->regs + SDMA_H_INTR);
+   writel_relaxed(stat, sdma->regs + SDMA_H_INTR);
/* not interested in channel 0 interrupts */
stat &= ~1;
-   writel_relaxed(stat, sdma->regs + SDMA_H_INTR);
+
+   spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
 
while (stat) {
int channel = fls(stat) - 1;
-- 
2.4.5

[PATCH 06/10] dma: imx-sdma: add terminate_all support

[Jiada Wang]

Implement device_terminate_all(), so that dmaengine_terminate_async()
can work.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ef5d37c..040cbf2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1401,6 +1401,13 @@ static void sdma_issue_pending(struct dma_chan *chan)
sdma_enable_channel(sdma, sdmac->channel);
 }
 
+static int sdma_terminate_all(struct dma_chan *chan)
+{
+   sdma_disable_channel(chan);
+
+   return 0;
+}
+
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V134
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V341
@@ -1819,6 +1826,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
+   sdma->dma_device.device_terminate_all = sdma_terminate_all;
sdma->dma_device.dev->dma_parms = &sdma->dma_parms;
dma_set_max_seg_size(sdma->dma_device.dev, 65535);
 
-- 
2.4.5

[PATCH 04/10] dma: imx-sdma: update sdma channel status for cyclic dma

[Jiada Wang]

Previously for cyclic dma mode, once sdma fails sdma channel status will
be set to DMA_ERROR, unless the transfer is prepared again, sdmac status
will always be kept to DMA_ERROR, even the transfer for following buffers
is successful.

This patch updates sdmac status to the status of current buffer descriptor.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1489de0..36f5e39 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -670,6 +670,8 @@ static void sdma_handle_channel_loop(struct sdma_channel 
*sdmac)
 
if (bd->mode.status & BD_RROR)
sdmac->status = DMA_ERROR;
+   else
+   sdmac->status = DMA_IN_PROGRESS;
 
bd->mode.status &= ~BD_RROR;
bd->mode.status |= BD_DONE;
-- 
2.4.5

[PATCH 05/10] dma: imx-sdma: add flag to indicate SDMA channel state

[Jiada Wang]

There is race between STOP of SDMA channel and finish of
SDMA transfer, so some times, even after sdma_disable_channel()
is called, the bit of 'terminated channel' in INTR may still get
asserted, thus cause an extra sdma tasklet be called.
Add flag 'enabled' to each sdma channel to indicate its state.
only when SDMA channel is in its enabled state, irq handler
can schedule a sdma tasklet for it.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 36f5e39..ef5d37c 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -327,6 +327,7 @@ struct sdma_channel {
unsigned intchn_real_count;
struct tasklet_struct   tasklet;
struct imx_dma_data data;
+   boolenabled;
 };
 
 #define IMX_DMA_SG_LOOPBIT(0)
@@ -562,7 +563,13 @@ static int sdma_config_ownership(struct sdma_channel 
*sdmac,
 
 static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
 {
+   struct sdma_channel *sdmac = &sdma->channel[channel];
+   unsigned long flags;
+
+   spin_lock_irqsave(&sdmac->lock, flags);
+   sdmac->enabled = true;
writel(BIT(channel), sdma->regs + SDMA_H_START);
+   spin_unlock_irqrestore(&sdmac->lock, flags);
 }
 
 /*
@@ -740,9 +747,12 @@ static irqreturn_t sdma_int_handler(int irq, void *dev_id)
int channel = fls(stat) - 1;
struct sdma_channel *sdmac = &sdma->channel[channel];
 
-   tasklet_schedule(&sdmac->tasklet);
+   spin_lock(&sdmac->lock);
+   if (sdmac->enabled)
+   tasklet_schedule(&sdmac->tasklet);
 
__clear_bit(channel, &stat);
+   spin_unlock(&sdmac->lock);
}
 
return IRQ_HANDLED;
@@ -906,9 +916,13 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
+   unsigned long flags;
 
+   spin_lock_irqsave(&sdmac->lock, flags);
+   sdmac->enabled = false;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
+   spin_unlock_irqrestore(&sdmac->lock, flags);
 
return 0;
 }
-- 
2.4.5

[PATCH 08/10] dma: imx-sdma: abort updating channel when it has been terminated

[Jiada Wang]

In case the corresponding channel has already been terminated,
then instead of go on updating channel status, driver should abort from
sdma_handle_channel_loop(), otherwise channel status will be updated
incorrecly.

This patch also adds lock to avoid race between terminate of channel,
and updaing of channel status in sdma_handle_channel_loop().

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 0b23407..bc867e5 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -664,16 +664,25 @@ static void sdma_event_disable(struct sdma_channel 
*sdmac, unsigned int event)
 static void sdma_handle_channel_loop(struct sdma_channel *sdmac)
 {
struct sdma_buffer_descriptor *bd;
+   unsigned long flags;
 
/*
 * loop mode. Iterate over descriptors, re-setup them and
 * call callback function.
 */
while (1) {
+   spin_lock_irqsave(&sdmac->lock, flags);
+   if (!sdmac->enabled) {
+   spin_unlock_irqrestore(&sdmac->lock, flags);
+   break;
+   }
+
bd = &sdmac->bd[sdmac->buf_tail];
 
-   if (bd->mode.status & BD_DONE)
+   if (bd->mode.status & BD_DONE) {
+   spin_unlock_irqrestore(&sdmac->lock, flags);
break;
+   }
 
if (bd->mode.status & BD_RROR)
sdmac->status = DMA_ERROR;
@@ -690,6 +699,7 @@ static void sdma_handle_channel_loop(struct sdma_channel 
*sdmac)
bd->mode.count = sdmac->chn_count;
}
 
+   spin_unlock_irqrestore(&sdmac->lock, flags);
if (sdmac->desc.callback)
sdmac->desc.callback(sdmac->desc.callback_param);
}
-- 
2.4.5

[PATCH 01/10] dma: imx-sdma: use chn_real_count to report residue for UART

[Jiada Wang]

For uart rx dma data may not receive fully, so the number
of data read by sdma script once isn't always equal to period_len,
thus residue returned from sdma_tx_status() isn't valid for uart rx
dma. The old way to use chn_real_count to report residue should be
used for uart rx dma.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 0f6fd42..1f1b64b 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -680,6 +680,11 @@ static void sdma_update_channel_loop(struct sdma_channel 
*sdmac)
bd->mode.status |= BD_DONE;
sdmac->buf_tail++;
sdmac->buf_tail %= sdmac->num_bd;
+   if (sdmac->peripheral_type == IMX_DMATYPE_UART) {
+   /* restore mode.count after counter readed */
+   sdmac->chn_real_count = bd->mode.count;
+   bd->mode.count = sdmac->chn_count;
+   }
}
 }
 
@@ -1285,6 +1290,9 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
goto err_out;
}
 
+   if (sdmac->peripheral_type == IMX_DMATYPE_UART)
+   sdmac->chn_count = period_len;
+
while (buf < buf_len) {
struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
int param;
@@ -1361,7 +1369,8 @@ static enum dma_status sdma_tx_status(struct dma_chan 
*chan,
struct sdma_channel *sdmac = to_sdma_chan(chan);
u32 residue;
 
-   if (sdmac->flags & IMX_DMA_SG_LOOP)
+   if ((sdmac->flags & IMX_DMA_SG_LOOP) &&
+   (sdmac->peripheral_type != IMX_DMATYPE_UART))
residue = (sdmac->num_bd - sdmac->buf_tail) * sdmac->period_len;
else
residue = sdmac->chn_count - sdmac->chn_real_count;
-- 
2.4.5

[GIT PULL] LED updates for 4.7

[Jacek Anaszewski]

Hi Linus,

Please pull LED updates for 4.7 merge cycle.

In this merge cycle we had an interaction with MTD subsystem, that
included converting drivers/mtd/nand/nand_base.c to use newly introduced
MTD (NAND/NOR) LED trigger instead of implementing it on its own.

Related MTD patches are intended to be merged through the LED tree,
before MTD tree is merged, since further MTD development is based on
those modifications.

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
for-next

for you to fetch changes up to 80d6737b27bbdf645a815c136606836b435f0268:

  leds: gpio: Support the "panic-indicator" firmware property (2016-05-06 
10:26:07 +0200)

Thanks,
Jacek Anaszewski


LEDs:
- Introduce a kernel panic LED trigger

- Introduce a MTD (NAND/NOR) trigger

- led-tca6507: silence an uninitialized variable warning

- ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

- leds-ss4200: Add depend on x86 arch

- leds-ss4200: add DMI data for FSC SCALEO Home Server

- leds-triggers: Allow to switch the trigger to "panic" on a kernel panic

- devicetree: leds: Introduce "panic-indicator" optional property

- leds-gpio: Support the "panic-indicator" firmware property

MTD:
- Uninline mtd_write_oob and move it to mtdcore.c

- Remove the "nand-disk" LED trigger

- Hook I/O activity to the MTD LED trigger


Dan Carpenter (1):
  leds: tca6507: silence an uninitialized variable warning

Ezequiel Garcia (8):
  leds: trigger: Introduce a kernel panic LED trigger
  mtd: Uninline mtd_write_oob and move it to mtdcore.c
  leds: trigger: Introduce a MTD (NAND/NOR) trigger
  mtd: nand: Remove the "nand-disk" LED trigger
  mtd: Hook I/O activity to the MTD LED trigger
  leds: triggers: Allow to switch the trigger to "panic" on a kernel panic
  devicetree: leds: Introduce "panic-indicator" optional property
  leds: gpio: Support the "panic-indicator" firmware property

Jacek Anaszewski (1):
  leds: ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

Martin Dummer (2):
  leds: ss4200: Add depend on x86 arch
  leds: ss4200: add DMI data for FSC SCALEO Home Server

 Documentation/devicetree/bindings/leds/common.txt  |3 +
 .../devicetree/bindings/leds/leds-gpio.txt |2 +
 drivers/leds/Kconfig   |5 +-
 drivers/leds/led-triggers.c|2 +-
 drivers/leds/leds-gpio.c   |4 +
 drivers/leds/leds-ss4200.c |   13 
 drivers/leds/leds-tca6507.c|2 +
 drivers/leds/leds.h|1 +
 drivers/leds/trigger/Kconfig   |   18 +
 drivers/leds/trigger/Makefile  |2 +
 drivers/leds/trigger/ledtrig-ide-disk.c|3 +-
 drivers/leds/trigger/ledtrig-mtd.c |   45 
 drivers/leds/trigger/ledtrig-panic.c   |   77 
 drivers/mtd/mtdcore.c  |   19 +
 drivers/mtd/nand/nand_base.c   |   29 +---
 include/linux/leds.h   |8 ++
 include/linux/mtd/mtd.h|   12 +--
 17 files changed, 202 insertions(+), 43 deletions(-)
 create mode 100644 drivers/leds/trigger/ledtrig-mtd.c
 create mode 100644 drivers/leds/trigger/ledtrig-panic.c

[PATCH] dwc3: gadget: Implement the suspend entry event handler

[Baolin Wang]

It had changed to be suspend event for BIT6 in DEVT register from
version 2.30a and above. Thus this patch introduces one suspend
event handler to handle the suspend event.

Signed-off-by: Baolin Wang 
---
 drivers/usb/dwc3/gadget.c |   26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8e4a1b1..9b14ecc 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2595,6 +2595,17 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
dwc3 *dwc,
dwc->link_state = next;
 }
 
+static void dwc3_gadget_suspend_interrupt(struct dwc3 *dwc,
+ unsigned int evtinfo)
+{
+   enum dwc3_link_state next = evtinfo & DWC3_LINK_STATE_MASK;
+
+   if (dwc->link_state != next && next == DWC3_LINK_STATE_U3)
+   dwc3_suspend_gadget(dwc);
+
+   dwc->link_state = next;
+}
+
 static void dwc3_gadget_hibernation_interrupt(struct dwc3 *dwc,
unsigned int evtinfo)
 {
@@ -2646,7 +2657,20 @@ static void dwc3_gadget_interrupt(struct dwc3 *dwc,
dwc3_gadget_linksts_change_interrupt(dwc, event->event_info);
break;
case DWC3_DEVICE_EVENT_EOPF:
-   dwc3_trace(trace_dwc3_gadget, "End of Periodic Frame");
+   /* It changed to be suspend event for version 2.30a and above */
+   if (dwc->revision < DWC3_REVISION_230A) {
+   dwc3_trace(trace_dwc3_gadget, "End of Periodic Frame");
+   } else {
+   dwc3_trace(trace_dwc3_gadget, "U3/L1-L2 Suspend Event");
+
+   /*
+* Ignore suspend event until the gadget enters into
+* USB_STATE_CONFIGURED state.
+*/
+   if (dwc->gadget.state >= USB_STATE_CONFIGURED)
+   dwc3_gadget_suspend_interrupt(dwc,
+   event->event_info);
+   }
break;
case DWC3_DEVICE_EVENT_SOF:
dwc3_trace(trace_dwc3_gadget, "Start of Periodic Frame");
-- 
1.7.9.5

Re: [RFC PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

[Neil Armstrong]

On 05/14/2016 05:07 PM, Kevin Hilman wrote:
> Neil Armstrong  writes:
>> +writel(readl(reg_addr) | BIT(offset), reg_addr);
> 
> The spec lists these registers as 16-bit registers, so probably readw/writew
> are more appropriate here.


Looking at the datasheet, the reset controller is an APB3 module, thus 32bit 
would be the only data width configured.

Sure, it's strange to only have 16 used bits per registers...

> 
>> +return 0;
>> +}
>> +
>> +static int meson_gxbb_reset_deassert(struct reset_controller_dev *rcdev,
>> +unsigned long id)
>> +{
>> +struct meson_gxbb_reset *data =
>> +container_of(rcdev, struct meson_gxbb_reset, rcdev);
>> +unsigned int bank = id / BITS_PER_REG;
>> +unsigned int offset = id % BITS_PER_REG;
>> +void *reg_addr = data->reg_base + (bank << 2);
>> +
>> +if (bank >= REG_COUNT)
>> +return -EINVAL;
>> +
>> +writel(readl(reg_addr) & ~BIT(offset), reg_addr);
> 
> and here.
> 
>> +return 0;
>> +}
> 
> Kevin
> 

Neil

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

[Roger Quadros]

On 13/05/16 22:36, Sergei Shtylyov wrote:
> Hello.
> 
> On 05/13/2016 12:07 PM, Roger Quadros wrote:
> 
> [...]
> 
 +}
 +EXPORT_SYMBOL(mdio_device_reset);
 +
  /**
   * mdio_probe - probe an MDIO device
   * @dev: device to probe
 @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev
  struct mdio_driver *mdiodrv = to_mdio_driver(drv);
  int err = 0;

 -if (mdiodrv->probe)
 +if (mdiodrv->probe) {
 +/* Deassert the reset signal */
 +mdio_device_reset(mdiodev, 0);
 +
  err = mdiodrv->probe(mdiodev);

 +/* Assert the reset signal */
 +mdio_device_reset(mdiodev, 1);
>>>
>>> I wonder if it's safe to do this in general. What if ->probe does
>>> something with the phy that is lost by resetting but that is relied on
>>> later?
>>
>> mdio_probe is called for non PHY devices only, right?
> 
>Yes, those also can have a reset signal.
> 
>> I'm a bit lost as to why we're de-asserting reset at multiple places. i.e.
>> mdio_probe(), phy_device_register(), phy_init_hw(), phy_probe(), 
>> of_mdiobus_register_phy().
> 
>> Isn't it simpler to just de-assert it once at the topmost level?
> 
>I wasn't after simplicity here. The intent was to save some power putting 
> the device at reset when it's not needed. Florian Fainelly (the phylib 
> maintainer) actually wanted me to go even further with that and assert reset 
> in phy_suspend() but it was too much for me.

Is using RESET for power saving a standard practice? Isn't there some register 
interface for power saving?
My concern here is that RESET does a number of things that might be undesired 
for normal operation.
e.g. PHY's will use bootstrap settings on RESET and we need to ensure that 
bootstrap pins are always in
the right setting before issuing a RESET.

What happens to the PHY link? Is it lost while PHY RESET is asserted?
Is this really desirable?


> 
>> i.e. of_mdiobus_register_device() f and of_mdiobus_register_phy()?
>>
>> Also, how about issuing a reset pulse instead of just de-asserting it.
> 
>If it's already held at reset, my assumption is that it's enough time 
> passed already.
> 
>> This would tackle the case where PHY is in invalid state with reset already
>> de-asserted.
> 
> Good question. I haven't yet met such cases though.
> 
>> Another issue is that on some boards we have one reset line tied to
>> multiple PHYs.How do we prevent multiple resets being taking place when each 
>> of
>> the PHYs are registered?
> 
>My patch just doesn't address this case -- it's about the individual 
> resets only.
> 
>> Do we just specify the reset line only for one PHY in
>> the DT or can we have the reset gpio in the mdio_bus node for such case?
> 
>I think there's mii_bus::reset() method for that case. Some Ethernet 
> drivers even use it
> (mostly instead of the code being suggested here).
> 

--
cheers,
-roger

Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

[Robert Jarzmik]

Takashi Iwai  writes:

> On Sun, 15 May 2016 23:29:27 +0200,
> Robert Jarzmik wrote:
>> 
>> Takashi Iwai  writes:
>> 
>> > On Sat, 14 May 2016 11:50:50 +0200,
>> >
>> > No, my concern is that it's creating a dummy codec object temporarily
>> > on the stack just by copying some fields and calling the ops with it.
>> > (And actually the current code may work wrongly because lack of
>> >  zero-clear of the object.)
>> Ah yes, I remember now, the on-stack generated device, indeed ugly.
>> 
>> > IMO, a cleaner way would be to define the ops passed with both
>> > controller and codec objects as arguments, and pass NULL codec here.
>> It's rather unusual to need both the device and its controller in bus
>> operations. I must admit I have no better idea so far, so I'll try that just 
>> to
>> see how it looks like, and let's see next ...
>
> Thinking of this again, I wonder now why we need to pass the codec
> object at all.  It's the read/write ops via ac97, so we just need the
> ac97_controller object and the address slot of the accessed codec?
So far it would work. The only objection I would see is if in the future the bus
operation needs a specialization which is ac97 codec dependent, such as a flag
or a mask in ac97_codec_device structure.

Even if I'd like to not have these in bus operations, the struct snd_ac97 had a
need for a 'caps', 'ext_id', ... fields for example. Yet these could be
contained in the ac97_codec_device structure and not exposed to bus operations.

Another worry is the pattern (as an example) in atmel_ac97c_write() in
sound/atmel/ac97.c, where the codec structure is used to get the controller
through a container_of() type call. Yet passing the controller to bus operations
takes care of this one.

>From a "purely API" point of view the couple (ac97_controller, ac97_slot_id) is
what will route an ac97 bus operation, be that a read/write/reset/..., the
remaining question is will it cover the cases we've not thought of ?

Cheers.

-- 
Robert

Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

On 13/05/16 13:03, Roger Quadros wrote:
> It provides APIs for the following tasks
> 
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
> 
> Provide a dual-role device (DRD) state machine.
> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
> 
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
> 
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/common/Makefile  |2 +-
>  drivers/usb/common/usb-otg.c | 1042 
> ++
>  drivers/usb/core/Kconfig |4 +-
>  include/linux/usb/gadget.h   |2 +
>  include/linux/usb/hcd.h  |1 +
>  include/linux/usb/otg-fsm.h  |7 +
>  include/linux/usb/otg.h  |  154 ++-
>  7 files changed, 1206 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c


This patch causes the following build issues when CONFIG_USB_GADGET=m, 
CONFIG_USB=m,
CONFIG_USB_COMMON=m and CONFIG_USB_OTG=y

ERROR: "usb_otg_register_gadget" [drivers/usb/gadget/udc/udc-core.ko] undefined!
ERROR: "usb_otg_unregister_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
undefined!
ERROR: "usb_otg_register_hcd" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "usb_otg_unregister_hcd" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "otg_statemachine" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1141: recipe for target 'modules' failed
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs

drivers/built-in.o: In function `drd_set_state':
usb-otg.c:(.text+0x2b4242): undefined reference to `usb_otg_state_string'
drivers/built-in.o: In function `drd_statemachine':
(.text+0x2b4b4c): undefined reference to `usb_otg_state_string'
Makefile:937: recipe for target 'vmlinux' failed

I'll fix it up with the following diff.

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..16a5b55 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS)   += renesas_usbhs/
 obj-$(CONFIG_USB_GADGET)   += gadget/
 
 obj-$(CONFIG_USB_COMMON)   += common/
+obj-$(CONFIG_USB_OTG)  += common/
 
 obj-$(CONFIG_USBIP_CORE)   += usbip/
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 77048aa..17e449e 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -56,6 +56,30 @@ static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
return hcd == hcd->primary_hcd;
 }
 
+static const char *otg_state_string(enum usb_otg_state state)
+{
+   static const char *const names[] = {
+   [OTG_STATE_A_IDLE] = "a_idle",
+   [OTG_STATE_A_WAIT_VRISE] = "a_wait_vrise",
+   [OTG_STATE_A_WAIT_BCON] = "a_wait_bcon",
+   [OTG_STATE_A_HOST] = "a_host",
+   [OTG_STATE_A_SUSPEND] = "a_suspend",
+   [OTG_STATE_A_PERIPHERAL] = "a_peripheral",
+   [OTG_STATE_A_WAIT_VFALL] = "a_wait_vfall",
+   [OTG_STATE_A_VBUS_ERR] = "a_vbus_err",
+   [OTG_STATE_B_IDLE] = "b_idle",
+   [OTG_STATE_B_SRP_INIT] = "b_srp_init",
+   [OTG_STATE_B_PERIPHERAL] = "b_peripheral",
+   [OTG_STATE_B_WAIT_ACON] = "b_wait_acon",
+   [OTG_STATE_B_HOST] = "b_host",
+   };
+
+   if (state < 0 || state >= ARRAY_SIZE(names))
+   return "UNDEFINED";
+
+   return names[state];
+}
+
 /**
  * Check if the OTG device is in our wait list and return
  * otg_wait_data, else NULL.
@@ -433,7 +457,7 @@ static void drd_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
 
fsm->state_changed = 1;
dev_dbg(otg->dev, "otg: set state: %s\n",
-   usb_otg_state_string(new_state));
+   otg_state_string(new_state));
switch (new_state) {
case OTG_STATE_B_IDLE:
drd_set_protocol(fsm, PROTO_UNDEF);
@@ -449,7 +473,7 @@ static void drd_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
break;
default:
dev_warn(otg->dev, "%s: otg: invalid state: %s\n",
-__func__, usb_otg_state_string(new_state));
+__func__, otg_state_string(new_state));
break;
}
 
@@ -507,7 +531,7 @@ int drd_statemachine(struct usb

[PATCH 1/3] ACPICA: Events: Introduce acpi_block_gpe()/acpi_unblock_gpe()/acpi_control_gpe_handling() to allow administrative GPE enabling/disabling

[Lv Zheng]

There is a facility in Linux, developers can manage GPE enabling/disabling
through /sys/firmware/acpi/interrupts/gpexx. This is mainly for debugging
purposes. Many users expect to use this facility to implement quirks to
disable specific GPEs when there is a gap in Linux causing GPE flood.
This is not working correctly because currently this facility invokes
enabling/disabling counting based GPE driver APIs:
 acpi_enable_gpe()/acpi_disable_gpe()
and the GPE drivers can still affect the count to mess up the GPE
management purposes.

This patch introduces acpi_block_gpe()/acpi_unblock_gpe() to be used in such
situation instead of acpi_enable_gpe()/acpi_disable_gpe().

The idea to implement this is to replace the GPE register EN bit with the
managed value, block EN set/clear operations but record the operation
results in blocked_enabled, so that after the managed state is removed,
restore the saved blocked_enabled back to the GPE register EN bit.

Now OSPMs should be able to use this facility to generate quirks. ACPICA
BZ 1102.

This facility can also be used by the administrator to control the GPE
handling mode during the runtime when the driver is capable of handling the
GPE in both the interrupt mode and the polling mode (for example, the Linux
EC driver). acpi_control_gpe_handling() is offered for this purpose. Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1102
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acevents.h |3 +
 drivers/acpi/acpica/aclocal.h  |1 +
 drivers/acpi/acpica/evgpe.c|   84 
 drivers/acpi/acpica/evxfgpe.c  |  142 
 drivers/acpi/acpica/hwgpe.c|   24 ++-
 include/acpi/acpixf.h  |   23 +--
 include/acpi/actypes.h |   85 +++-
 7 files changed, 336 insertions(+), 26 deletions(-)

diff --git a/drivers/acpi/acpica/acevents.h b/drivers/acpi/acpica/acevents.h
index 77af91c..3a6e4db 100644
--- a/drivers/acpi/acpica/acevents.h
+++ b/drivers/acpi/acpica/acevents.h
@@ -86,6 +86,9 @@ acpi_ev_update_gpe_enable_mask(struct acpi_gpe_event_info 
*gpe_event_info);
 acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info);
 
 acpi_status
+acpi_ev_manage_gpe(struct acpi_gpe_event_info *gpe_event_info, u8 action);
+
+acpi_status
 acpi_ev_add_gpe_reference(struct acpi_gpe_event_info *gpe_event_info);
 
 acpi_status
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 13331d7..17a6834 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -484,6 +484,7 @@ struct acpi_gpe_event_info {
u8 flags;   /* Misc info about this GPE */
u8 gpe_number;  /* This GPE */
u8 runtime_count;   /* References to a run GPE */
+   u8 blocked_enabled; /* GPE should be enabled but blocked */
 };
 
 /* Information about a GPE register pair, one per each status/enable pair in 
an array */
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index 4b4949c..f821bdd 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -130,6 +130,90 @@ acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info 
*gpe_event_info)
 
 
/***
  *
+ * FUNCTION:acpi_ev_manage_gpe
+ *
+ * PARAMETERS:  gpe_event_info  - GPE to force enabling/disabling
+ *  action  - ACPI_GPE_ENABLE, ACPI_GPE_DISABLE or
+ *ACPI_GPE_UNMANAGE
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Unconditionally enable or disable an individual GPE for the
+ *  administrative purposes during the runtime.
+ *
+ 
**/
+
+acpi_status
+acpi_ev_manage_gpe(struct acpi_gpe_event_info *gpe_event_info, u8 action)
+{
+   acpi_status status;
+   acpi_event_status event_status;
+
+   ACPI_FUNCTION_TRACE(ev_manage_gpe);
+
+   /* Perform the action */
+
+   switch (action) {
+   case ACPI_GPE_ENABLE:
+   case ACPI_GPE_DISABLE:
+
+   if (!(gpe_event_info->flags & ACPI_GPE_MANAGED_FLAG_MASK)) {
+   status =
+   acpi_hw_get_gpe_status(gpe_event_info,
+  &event_status);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+   if (event_status & ACPI_EVENT_FLAG_ENABLE_SET) {
+   gpe_event_info->blocked_enabled = TRUE;
+   } else {
+   gpe_event_info->blocked_enabled = FALSE;
+   }
+   }
+
+   /* Reset flags so that acpi_hw_low_set_gpe() can take effective 
*/
+
+   gpe_event_info->flags &= ~ACPI_GPE_MANAGE

[PATCH 2/3] ACPI / sys: Update /sys/firmware/acpi/interrupts/gpexx using new GPE forced disabling/enabling mechanism

[Lv Zheng]

Now GPE can be forced enabling/disabling through GPE management APIs, this
patch modifies /sys/firmware/acpi/interrupts/gpexx to use this new
facility.

The "block" command is implemented to invoke acpi_block_gpe() and the
"unblock" command is implemented to invoke acpi_unblock_gpe().
The "force-poll"/"force-irq"/"unforce" command is implemented to invoke
acpi_control_gpe_handling() to switch GPE handling mode (for EC driver
only).

"EN STS" is returned to display the current hardware register status, along
with "!" flag to indicate the register bit unset and "*" flag to indicate
the managed state.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/sleep.c |2 +-
 drivers/acpi/sysfs.c |   36 
 2 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 7a2e4d4..d00544c 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -555,7 +555,7 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
 
acpi_get_event_status(ACPI_EVENT_POWER_BUTTON, &pwr_btn_status);
 
-   if (pwr_btn_status & ACPI_EVENT_FLAG_SET) {
+   if (pwr_btn_status & ACPI_EVENT_FLAG_STATUS_SET) {
acpi_clear_event(ACPI_EVENT_POWER_BUTTON);
/* Flag for later */
pwr_btn_event_pending = true;
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 4b3a9e2..7f33c90 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -599,6 +599,19 @@ static ssize_t counter_show(struct kobject *kobj,
if (result)
goto end;
 
+   if (status & ACPI_EVENT_FLAG_ENABLE_SET)
+   size += sprintf(buf + size, "  EN");
+   else
+   size += sprintf(buf + size, " !EN");
+   if (status & ACPI_EVENT_FLAG_MANAGED)
+   size += sprintf(buf + size, "*");
+   else
+   size += sprintf(buf + size, " ");
+   if (status & ACPI_EVENT_FLAG_STATUS_SET)
+   size += sprintf(buf + size, " STS");
+   else
+   size += sprintf(buf + size, "!STS");
+
if (!(status & ACPI_EVENT_FLAG_HAS_HANDLER))
size += sprintf(buf + size, "   invalid");
else if (status & ACPI_EVENT_FLAG_ENABLED)
@@ -656,8 +669,23 @@ static ssize_t counter_set(struct kobject *kobj,
else if (!strcmp(buf, "enable\n") &&
 !(status & ACPI_EVENT_FLAG_ENABLED))
result = acpi_enable_gpe(handle, index);
+   else if (!strcmp(buf, "block\n"))
+   result = acpi_block_gpe(handle, index);
+   else if (!strcmp(buf, "unblock\n") &&
+(status & ACPI_EVENT_FLAG_MANAGED))
+   result = acpi_unblock_gpe(handle, index);
+   else if (!strcmp(buf, "force-poll\n"))
+   result = acpi_control_gpe_handling(handle, index,
+  TRUE, FALSE);
+   else if (!strcmp(buf, "force-irq\n"))
+   result = acpi_control_gpe_handling(handle, index,
+  FALSE, TRUE);
+   else if (!strcmp(buf, "unforce\n") &&
+(status & ACPI_EVENT_FLAG_MANAGED))
+   result = acpi_control_gpe_handling(handle, index,
+  TRUE, TRUE);
else if (!strcmp(buf, "clear\n") &&
-(status & ACPI_EVENT_FLAG_SET))
+(status & ACPI_EVENT_FLAG_STATUS_SET))
result = acpi_clear_gpe(handle, index);
else if (!kstrtoul(buf, 0, &tmp))
all_counters[index].count = tmp;
@@ -666,13 +694,13 @@ static ssize_t counter_set(struct kobject *kobj,
} else if (index < num_gpes + ACPI_NUM_FIXED_EVENTS) {
int event = index - num_gpes;
if (!strcmp(buf, "disable\n") &&
-   (status & ACPI_EVENT_FLAG_ENABLED))
+   (status & ACPI_EVENT_FLAG_ENABLE_SET))
result = acpi_disable_event(event, ACPI_NOT_ISR);
else if (!strcmp(buf, "enable\n") &&
-!(status & ACPI_EVENT_FLAG_ENABLED))
+!(status & ACPI_EVENT_FLAG_ENABLE_SET))
result = acpi_enable_event(event, ACPI_NOT_ISR);
else if (!strcmp(buf, "clear\n") &&
-(status & ACPI_EVENT_FLAG_SET))
+(status & ACPI_EVENT_FLAG_STATUS_SET))
result = acpi_clear_event(event);
else if (!kstrtoul(buf, 0, &tmp))
all_counters[index].count = tmp;
-- 
1.7.10

[PATCH 3/3] ACPI / sysfs: Provide quirk mechanism to prevent GPE flooding

[Lv Zheng]

Sometimes, the users may require a quirk to be provided from ACPI subsystem
core to prevent a GPE from flooding. Normally, if a GPE cannot be
dispatched, ACPICA core automatically prevents the GPE from firing. But
there are cases the GPE is dispatched by _Lxx/_Exx provided via AML table,
and OSPM is lacking of the knowledge to get _Lxx/_Exx correctly executed to
handle the GPE, thus the GPE flooding may still occur.

This patch provides a quirk mechanism to stop this kind of GPE flooding.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=53071
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793
Signed-off-by: Lv Zheng 
---
 drivers/acpi/internal.h |1 +
 drivers/acpi/scan.c |1 +
 drivers/acpi/sleep.c|2 ++
 drivers/acpi/sysfs.c|   56 +++
 4 files changed, 60 insertions(+)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 9bb0773..d0f1744 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -37,6 +37,7 @@ void acpi_amba_init(void);
 static inline void acpi_amba_init(void) {}
 #endif
 int acpi_sysfs_init(void);
+void acpi_gpe_apply_blocked_gpes(void);
 void acpi_container_init(void);
 void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..5ff366c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1958,6 +1958,7 @@ int __init acpi_scan_init(void)
}
}
 
+   acpi_gpe_apply_blocked_gpes();
acpi_update_all_gpes();
 
  out:
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index d00544c..daba3ba 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -414,6 +414,7 @@ static void acpi_pm_finish(void)
acpi_state);
acpi_disable_wakeup_devices(acpi_state);
acpi_leave_sleep_state(acpi_state);
+   acpi_gpe_apply_blocked_gpes();
 
/* reset firmware waking vector */
acpi_set_waking_vector(0);
@@ -774,6 +775,7 @@ static void acpi_pm_thaw(void)
 {
acpi_ec_unblock_transactions();
acpi_enable_all_runtime_gpes();
+   acpi_gpe_apply_blocked_gpes();
 }
 
 static const struct platform_hibernation_ops acpi_hibernation_ops = {
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 7f33c90..a2fb524 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -715,6 +715,62 @@ end:
return result ? result : size;
 }
 
+/*
+ * A Quirk Mechanism for GPE Flooding Prevention:
+ *
+ * Quirks may be needed to prevent GPE flooding on a specific GPE. The
+ * flooding typically cannot be detected and automatically prevented by
+ * ACPI_GPE_DISPATCH_NONE check because there is a _Lxx/_Exx prepared in
+ * the AML tables. This normally indicates a feature gap in Linux, thus
+ * instead of providing endless quirk tables, we provide a boot parameter
+ * for those who want this quirk. For example, if the users want to prevent
+ * the GPE flooding for GPE 00, they need to specify the following boot
+ * parameter:
+ *   acpi.block_gpe=0x00
+ * The blocking status can be modified by the following runtime controlling
+ * interface:
+ *   echo unblock > /sys/firmware/acpi/interrupts/gpe00
+ */
+
+/*
+ * Currently, the GPE flooding prevention only supports to block the GPEs
+ * numbered from 00 to 63.
+ */
+#define ACPI_BLOCKABLE_GPE_MAX 64
+
+static u64 acpi_blocked_gpes;
+
+static int __init acpi_gpe_set_blocked_gpes(char *val)
+{
+   u8 gpe;
+
+   if (kstrtou8(val, 0, &gpe) || gpe > ACPI_BLOCKABLE_GPE_MAX)
+   return -EINVAL;
+   acpi_blocked_gpes |= ((u64)1<

Re: Brightness control irrespective of blink state.

[Jacek Anaszewski]

Hi Tony,

On 05/13/2016 04:20 PM, Tony Makkiel wrote:



On 12/05/16 11:26, Jacek Anaszewski wrote:

On 05/11/2016 03:42 PM, Tony Makkiel wrote:



On 11/05/16 10:41, Jacek Anaszewski wrote:

On 05/10/2016 06:55 PM, Tony Makkiel wrote:



On 10/05/16 14:26, Jacek Anaszewski wrote:

On 05/10/2016 11:36 AM, Tony Makkiel wrote:



On 09/05/16 15:45, Jacek Anaszewski wrote:

Hi Tony,

On 05/09/2016 03:27 PM, Tony Makkiel wrote:

Hi Jacek,
 Thank you for getting back. I updated my kernel to 4.5 and
have
the
updated "led_set_brightness" now.

It sets
 led_cdev->flags |= LED_BLINK_BRIGHTNESS_CHANGE;
 led_cdev->blink_brightness = brightness;

 The new implementation requires hardware specific drivers to
poll
for flag change. Shouldn't the led-core driver be calling the
hardware
specific brightness_set (led_set_brightness_nosleep)
irrespective of
the
blink settings?

Unfortunately, it place additional requirement on drivers, to
implement
a polling mechanism which won't be needed otherwise. Why are the
brightness calls dependent on blink settings?


If your question is still:

"Is there a reason for rejecting brightness change requests when
either of the blink_delays are set?"

then the answer is: yes, brightness setting is deferred until
the next timer tick to avoid avoid problems in case we are called
from hard irq context. It should work fine for software blinking.



Sorry, was focused debugging 'hardware accelerated blink' on the
driver
I am working on, I missed the software blinking implementation.



Nonetheless, your question, made it obvious that we have a problem
here in case of hardware accelerated blinking, i.e. drivers that
implement blink_set op. Is this your use case?



Yes, the brightness requests from user space
(/sys/class/leds/*/brightness) does not get passed to hardware
specific
driver via the blink_set implemented, unless led_cdev->flags is
polled.


Anyway, I've noticed a discrepancy between the LED core code and
both Documentation/leds/leds-class.txt and comment over
blink_set() op
in include/linux/leds.h, which say that blinking is deactivated
upon setting the brightness again. Many drivers apply this rule.

In effect, LED_BLINK_BRIGHTNESS_CHANGE will have to be removed,
and your question will be groundless, as changing the blink
brightness should be impossible by design.


In my opinion, disabling blink, when brightness change requested
doesn't
sound like the right thing to do. There could be cases in which the
brightness of the blinking LED needs to be changed.


It could be accomplished with following sequence:

$ echo LED_FULL > brightness //set brightness
$ echo "timer" > trigger //enable blinking with
brightness=LED_FULL
$ echo 1 > brightness//stop blinking and set brightness to 1
$ echo "timer" > trigger //enable blinking with brightness=1

The only drawback here would be interfered blinking rhythm while
resetting blink brightness. Most drivers that implement blink_set
op observe what documentation says and disable blinking when
new brightness is set. Unfortunately, led_set_brightness() after
modifications doesn't take into account drivers that implement
blink_set op. It needs to be fixed, i.e. made compatible with
the docs.


Maybe we can let the
hardware driver deal with the blink request if it has implemented
brightness_set? The change below seem to work.


Subject: [PATCH] led-core: Use hardware blink when available

At present hardware implemented brightness is not called
if blink delays are set.

Signed-off-by: Tony Makkiel 
---
  drivers/leds/led-core.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 19e1e60d..02dd0f6 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -208,8 +208,10 @@ void led_set_brightness(struct led_classdev
*led_cdev,
  /*
   * In case blinking is on delay brightness setting
   * until the next timer tick.
+ * Or if brightness_set is defined, use the associated
implementation.
   */
-if (led_cdev->blink_delay_on || led_cdev->blink_delay_off) {
+if ((!led_cdev->brightness_set) &&


s/brightness_set/blink_set/ AFAICT

It wouldn't cover all cases as the fact that a driver implements
blink_set doesn't necessarily mean that hardware blinking is used
for current blinking parameters. There are drivers that resort to
using software fallback in case the LED controller device doesn't
support requested blink intervals.

I'm planning on addition of a LED_BLINKING_HW flag, that would
be set after successful execution of blink_set op. It would allow to
distinguish between hardware and software blinking modes reliably.



Did you mean something like


diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 19e1e60d..4a8b46d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -210,6 +210,13 @@ void led_set_brightness(struct led_classdev
*led_cdev,
  * until the next t

Re: [RFC 13/13] mm, compaction: fix and improve watermark handling

[Michal Hocko]

On Tue 10-05-16 09:36:03, Vlastimil Babka wrote:
> Compaction has been using watermark checks when deciding whether it was
> successful, and whether compaction is at all suitable. There are few problems
> with these checks.
> 
> - __compact_finished() uses low watermark in a check that has to pass if
>   the direct compaction is to finish and allocation should succeed. This is
>   too pessimistic, as the allocation will typically use min watermark. It
>   may happen that during compaction, we drop below the low watermark (due to
>   parallel activity), but still form the target high-order page. By checking
>   against low watermark, we might needlessly continue compaction. After this
>   patch, the check uses direct compactor's alloc_flags to determine the
>   watermark, which is effectively the min watermark.

OK, this makes some sense. It would be great if we could have at least
some clarification why the low wmark has been used previously. Probably
Mel can remember?

> - __compaction_suitable has the same issue in the check whether the allocation
>   is already supposed to succeed and we don't need to compact. Fix it the same
>   way.
>
> - __compaction_suitable() then checks the low watermark plus a (2 << order) 
> gap
>   to decide if there's enough free memory to perform compaction. This check

And this was a real head scratcher when I started looking into the
compaction recently. Why do we need to be above low watermark to even
start compaction. Compaction uses additional memory only for a short
period of time and then releases the already migrated pages.

>   uses direct compactor's alloc_flags, but that's wrong. If alloc_flags 
> doesn't
>   include ALLOC_CMA, we might fail the check, even though the freepage
>   isolation isn't restricted outside of CMA pageblocks. On the other hand,
>   alloc_flags may indicate access to memory reserves, making compaction 
> proceed
>   and then fail watermark check during freepage isolation, which doesn't pass
>   alloc_flags. The fix here is to use fixed ALLOC_CMA flags in the
>   __compaction_suitable() check.

This makes my head hurt. Whut?

> - __isolate_free_page uses low watermark check to decide if free page can be
>   isolated. It also doesn't use ALLOC_CMA, so add it for the same reasons.

Why do we check the watermark at all? What would happen if this obscure
if (!is_migrate_isolate(mt)) was gone? I remember I put some tracing
there and it never hit for me even when I was testing close to OOM
conditions. Maybe an earlier check bailed out but this code path looks
really obscure so it should either deserve a large fat comment or to
die.

> - The use of low watermark checks in __compaction_suitable() and
>   __isolate_free_page does perhaps make sense for high-order allocations where
>   more freepages increase the chance of success, and we can typically fail
>   with some order-0 fallback when the system is struggling. But for low-order
>   allocation, forming the page should not be that hard. So using low watermark
>   here might just prevent compaction from even trying, and eventually lead to
>   OOM killer even if we are above min watermarks. So after this patch, we use
>   min watermark for non-costly orders in these checks, by passing the
>   alloc_flags parameter to split_page() and __isolate_free_page().

OK, so if IIUC costly high order requests even shouldn't try when we are
below watermark (unless they are __GFP_REPEAT which would get us to a
stronger compaction mode/priority) and that would reclaim us over low
wmark and go on. Is that what you are saying? This makes some sense but
then let's have a _single_ place to check the watermak please. This
checks at few different levels is just subtle as hell and error prone
likewise.

> To sum up, after this patch, the kernel should in some situations finish
> successful direct compaction sooner, prevent compaction from starting when 
> it's
> not needed, proceed with compaction when free memory is in CMA pageblocks, and
> for non-costly orders, prevent OOM killing or excessive reclaim when free
> memory is between the min and low watermarks.

Could you please split this patch into three(?) parts. One to remove as many
wmark checks as possible, move low wmark to min for !costly high orders
and finally the cma part which I fail to understand...

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority

[Vlastimil Babka]

On 05/16/2016 10:14 AM, Michal Hocko wrote:

On Mon 16-05-16 09:31:44, Vlastimil Babka wrote:


Yeah it should work, my only worry was that this may get subtly wrong (as
experience shows us) and due to e.g. slightly different watermark checks
and/or a corner-case zone such as ZONE_DMA, should_reclaim_retry() would
keep returning true, even if reclaim couldn't/wouldn't help anything. Then
compaction would be needlessly kept at ineffective priority.


watermark check for ZONE_DMA should always fail because it fails even
when is completely free to the lowmem reserves. I had a subtle bug in
the original code to check highzone_idx rather than classzone_idx but
that should the fix has been posted recently:
http://lkml.kernel.org/r/1463051677-29418-2-git-send-email-mho...@kernel.org


Sure, but that just adds to the experience of being subtly wrong in this 
area :) But sure we can leave this part alone until proven wrong, I 
don't insist strongly.



Also my understanding of the initial compaction priorities is to lower the
latency if fragmentation is just light and there's enough memory. Once we
start struggling, I don't see much point in not switching to the full
compaction priority quickly.


That is true but why to compact when there are high order pages and they
are just hidden by the watermark check.


Compaction should skip such zone regardless of priority.

[PATCH v7 3/4] soc: mediatek: Add MT2701 power dt-bindings

[James Liao]

From: Shunli Wang 

Add power dt-bindings for MT2701.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
Acked-by: Rob Herring 
Reviewed-by: Kevin Hilman 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt| 13 +++
 include/dt-bindings/power/mt2701-power.h   | 27 ++
 2 files changed, 35 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index e8f15e3..16fe94d 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,17 +9,20 @@ domain control.
 
 The driver implements the Generic PM domain bindings described in
 power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h.
+include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
 
 Required properties:
-- compatible: Must be "mediatek,mt8173-scpsys"
+- compatible: Should be one of:
+   - "mediatek,mt2701-scpsys"
+   - "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
 - infracfg: must contain a phandle to the infracfg controller
 - clock, clock-names: clocks according to the common clock binding.
-  The clocks needed "mm", "mfg", "venc" and "venc_lt".
- These are the clocks which hardware needs to be enabled
- before enabling certain power domains.
+  These are clocks which hardware needs to be
+  enabled before enabling certain power domains.
+   Required clocks for MT2701: "mm", "mfg", "ethif"
+   Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
 
 Optional properties:
 - vdec-supply: Power supply for the vdec power domain
diff --git a/include/dt-bindings/power/mt2701-power.h 
b/include/dt-bindings/power/mt2701-power.h
new file mode 100644
index 000..64cc826
--- /dev/null
+++ b/include/dt-bindings/power/mt2701-power.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 MediaTek Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2701_POWER_H
+#define _DT_BINDINGS_POWER_MT2701_POWER_H
+
+#define MT2701_POWER_DOMAIN_CONN   0
+#define MT2701_POWER_DOMAIN_DISP   1
+#define MT2701_POWER_DOMAIN_MFG2
+#define MT2701_POWER_DOMAIN_VDEC   3
+#define MT2701_POWER_DOMAIN_ISP4
+#define MT2701_POWER_DOMAIN_BDP5
+#define MT2701_POWER_DOMAIN_ETH6
+#define MT2701_POWER_DOMAIN_HIF7
+#define MT2701_POWER_DOMAIN_IFR_MSC8
+
+#endif /* _DT_BINDINGS_POWER_MT2701_POWER_H */
-- 
1.9.1

[PATCH v7 1/4] soc: mediatek: Refine scpsys to support multiple platform

[James Liao]

Refine scpsys driver common code to support multiple SoC / platform.

Signed-off-by: James Liao 
Reviewed-by: Kevin Hilman 
---
 drivers/soc/mediatek/mtk-scpsys.c | 363 +++---
 1 file changed, 220 insertions(+), 143 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 57e781c..5870a24 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -11,17 +11,15 @@
  * GNU General Public License for more details.
  */
 #include 
-#include 
+#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
+#include 
+
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -34,6 +32,7 @@
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
+
 #define SPM_PWR_STATUS 0x060c
 #define SPM_PWR_STATUS_2ND 0x0610
 
@@ -55,12 +54,12 @@
 #define PWR_STATUS_USB BIT(25)
 
 enum clk_id {
-   MT8173_CLK_NONE,
-   MT8173_CLK_MM,
-   MT8173_CLK_MFG,
-   MT8173_CLK_VENC,
-   MT8173_CLK_VENC_LT,
-   MT8173_CLK_MAX,
+   CLK_NONE,
+   CLK_MM,
+   CLK_MFG,
+   CLK_VENC,
+   CLK_VENC_LT,
+   CLK_MAX,
 };
 
 #define MAX_CLKS   2
@@ -76,98 +75,6 @@ struct scp_domain_data {
bool active_wakeup;
 };
 
-static const struct scp_domain_data scp_domain_data[] = {
-   [MT8173_POWER_DOMAIN_VDEC] = {
-   .name = "vdec",
-   .sta_mask = PWR_STATUS_VDEC,
-   .ctl_offs = SPM_VDE_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = {MT8173_CLK_MM},
-   },
-   [MT8173_POWER_DOMAIN_VENC] = {
-   .name = "venc",
-   .sta_mask = PWR_STATUS_VENC,
-   .ctl_offs = SPM_VEN_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
-   },
-   [MT8173_POWER_DOMAIN_ISP] = {
-   .name = "isp",
-   .sta_mask = PWR_STATUS_ISP,
-   .ctl_offs = SPM_ISP_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = {MT8173_CLK_MM},
-   },
-   [MT8173_POWER_DOMAIN_MM] = {
-   .name = "mm",
-   .sta_mask = PWR_STATUS_DISP,
-   .ctl_offs = SPM_DIS_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = {MT8173_CLK_MM},
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
-   MT8173_TOP_AXI_PROT_EN_MM_M1,
-   },
-   [MT8173_POWER_DOMAIN_VENC_LT] = {
-   .name = "venc_lt",
-   .sta_mask = PWR_STATUS_VENC_LT,
-   .ctl_offs = SPM_VEN2_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
-   },
-   [MT8173_POWER_DOMAIN_AUDIO] = {
-   .name = "audio",
-   .sta_mask = PWR_STATUS_AUDIO,
-   .ctl_offs = SPM_AUDIO_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   },
-   [MT8173_POWER_DOMAIN_USB] = {
-   .name = "usb",
-   .sta_mask = PWR_STATUS_USB,
-   .ctl_offs = SPM_USB_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   .active_wakeup = true,
-   },
-   [MT8173_POWER_DOMAIN_MFG_ASYNC] = {
-   .name = "mfg_async",
-   .sta_mask = PWR_STATUS_MFG_ASYNC,
-   .ctl_offs = SPM_MFG_ASYNC_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = 0,
-   .clk_id = {MT8173_CLK_MFG},
-   },
-   [MT8173_POWER_DOMAIN_MFG_2D] = {
-   .name = "mfg_2d",
-   .sta_mask = PWR_STATUS_MFG_2D,
-   .ctl_offs = SPM_MFG_2D_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   },
-   [MT8173_POWER_DOMAIN_MFG] = {
-   .name = "mfg",
-   .sta_mask = PWR_STATUS_MFG,
-   .ctl_offs = SPM_MFG_PWR_CON,
-   .sram_pdn_bits = GENMASK(13, 8),
-   .sram_pdn_ack_bits = GENMASK(21, 16),
-   .clk_id = {MT8173_CLK_NONE},
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
-   

[PATCH v7 4/4] soc: mediatek: Add MT2701 scpsys driver

[James Liao]

From: Shunli Wang 

Add scpsys driver for MT2701.

mtk-scpsys now supports MT8173 (arm64) and MT2701 (arm). So it should
be enabled on both arm64 and arm platforms.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
Reviewed-by: Kevin Hilman 
---
 drivers/soc/mediatek/Kconfig  |   2 +-
 drivers/soc/mediatek/mtk-scpsys.c | 117 +-
 2 files changed, 116 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 0a4ea80..609bb34 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -23,7 +23,7 @@ config MTK_PMIC_WRAP
 config MTK_SCPSYS
bool "MediaTek SCPSYS Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   default ARM64 && ARCH_MEDIATEK
+   default ARCH_MEDIATEK
select REGMAP
select MTK_INFRACFG
select PM_GENERIC_DOMAINS if PM
diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 00c0adb..f4d1230 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -27,8 +28,13 @@
 #define SPM_VEN_PWR_CON0x0230
 #define SPM_ISP_PWR_CON0x0238
 #define SPM_DIS_PWR_CON0x023c
+#define SPM_CONN_PWR_CON   0x0280
 #define SPM_VEN2_PWR_CON   0x0298
-#define SPM_AUDIO_PWR_CON  0x029c
+#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173 */
+#define SPM_BDP_PWR_CON0x029c  /* MT2701 */
+#define SPM_ETH_PWR_CON0x02a0
+#define SPM_HIF_PWR_CON0x02a4
+#define SPM_IFR_MSC_PWR_CON0x02a8
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
@@ -42,10 +48,15 @@
 #define PWR_ON_2ND_BIT BIT(3)
 #define PWR_CLK_DIS_BITBIT(4)
 
+#define PWR_STATUS_CONNBIT(1)
 #define PWR_STATUS_DISPBIT(3)
 #define PWR_STATUS_MFG BIT(4)
 #define PWR_STATUS_ISP BIT(5)
 #define PWR_STATUS_VDECBIT(7)
+#define PWR_STATUS_BDP BIT(14)
+#define PWR_STATUS_ETH BIT(15)
+#define PWR_STATUS_HIF BIT(16)
+#define PWR_STATUS_IFR_MSC BIT(17)
 #define PWR_STATUS_VENC_LT BIT(20)
 #define PWR_STATUS_VENCBIT(21)
 #define PWR_STATUS_MFG_2D  BIT(22)
@@ -59,6 +70,7 @@ enum clk_id {
CLK_MFG,
CLK_VENC,
CLK_VENC_LT,
+   CLK_ETHIF,
CLK_MAX,
 };
 
@@ -321,7 +333,8 @@ static void init_clks(struct platform_device *pdev, struct 
clk *clk[CLK_MAX])
CLK_MM,
CLK_MFG,
CLK_VENC,
-   CLK_VENC_LT
+   CLK_VENC_LT,
+   CLK_ETHIF
};
 
static const char * const clk_names[] = {
@@ -329,6 +342,7 @@ static void init_clks(struct platform_device *pdev, struct 
clk *clk[CLK_MAX])
"mfg",
"venc",
"venc_lt",
+   "ethif",
};
 
int i;
@@ -459,6 +473,102 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 }
 
 /*
+ * MT2701 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt2701[] = {
+   [MT2701_POWER_DOMAIN_CONN] = {
+   .name = "conn",
+   .sta_mask = PWR_STATUS_CONN,
+   .ctl_offs = SPM_CONN_PWR_CON,
+   .bus_prot_mask = 0x0104,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_DISP] = {
+   .name = "disp",
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .clk_id = {CLK_MM},
+   .bus_prot_mask = 0x0002,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
+   .sta_mask = PWR_STATUS_MFG,
+   .ctl_offs = SPM_MFG_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MFG},
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = PWR_STATUS_ISP,
+ 

[PATCH v7 0/4] Mediatek MT2701 SCPSYS power domain support

[James Liao]

This series is based on v4.6-rc1 and adds scpsys power domain support
for Mediatek MT2701.

To share the code between MT2701 and MT8173, this patchset also refined
original mtk-scpsys.c to separate common codes and platform codes, so
that mtk-scpsys.c can support new SoCs more easily.

MT8173 and MT2701 scpsys init level are now subsys_init. Please refer to [1]
to see discussion details.

changes since v6:
- Minor changes in the dt-binding document.

changes since v5:
- Rebase to v4.6-rc1.
- Add dependent clocks for MFG, ISP, ETH and HIF power domains.
- Add "ethif" as a dependent clock in scpsys dt-binding document.

changes since v4:
- Rebase to v4.5-rc4.
- Remove mtk-scpsys.h and Merge its code into mtk-scpsys.c.
- Add names for every controlling registers and bits.
- Include dt-bindings headers at the beginning of mtk-scpsys.c.
- Sort compatible string in dt-binding documents.

changes since v3:
- Implement MT8173 and MT2701 scpsys drivers in a signle file.
- Remove naming of registers that can't be shared among SoCs.

changes since v2:
- Rebase to mbgg/linux-mediatek v4.4-next/soc [1].
- Remove MTK_SCPSYS_MT8173 and MTK_SCPSYS_MT2701.
- Modify scpsys dt-binding document to support MT2701.

changes since v1:
- Make MTK_SCPSYS in Kconfig invisible from users.
- Add comments for changing scpsys init level to subsys_init.

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

James Liao (2):
  soc: mediatek: Refine scpsys to support multiple platform
  soc: mediatek: Init MT8173 scpsys driver earlier

Shunli Wang (2):
  soc: mediatek: Add MT2701 power dt-bindings
  soc: mediatek: Add MT2701 scpsys driver

 .../devicetree/bindings/soc/mediatek/scpsys.txt|  13 +-
 drivers/soc/mediatek/Kconfig   |   2 +-
 drivers/soc/mediatek/mtk-scpsys.c  | 497 +++--
 include/dt-bindings/power/mt2701-power.h   |  27 ++
 4 files changed, 388 insertions(+), 151 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

--
1.9.1

[PATCH v7 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

[James Liao]

Some power domain comsumers may init before module_init.
So the power domain provider (scpsys) need to be initialized
earlier too.

Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
between IOMMU and multimedia HW. SMI is responsible to
enable/disable iommu and help transfer data for each multimedia
HW. Both of them have to wait until the power and clocks are
enabled.

So scpsys driver should be initialized before SMI, and SMI should
be initialized before IOMMU, and then init IOMMU consumers
(display/vdec/venc/camera etc.).

IOMMU is subsys_init by default. So we need to init scpsys driver
before subsys_init.

Signed-off-by: James Liao 
Reviewed-by: Kevin Hilman 
---
 drivers/soc/mediatek/mtk-scpsys.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 5870a24..00c0adb 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -617,4 +617,21 @@ static struct platform_driver scpsys_drv = {
.of_match_table = of_match_ptr(of_scpsys_match_tbl),
},
 };
-builtin_platform_driver(scpsys_drv);
+
+static int __init scpsys_drv_init(void)
+{
+   return platform_driver_register(&scpsys_drv);
+}
+
+/*
+ * There are some Mediatek drivers which depend on the power domain driver need
+ * to probe in earlier initcall levels. So scpsys driver also need to probe
+ * earlier.
+ *
+ * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
+ * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
+ * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
+ * IOMMU drivers are initialized during subsys_init by default, so we need to
+ * move SMI and scpsys drivers to subsys_init or earlier init levels.
+ */
+subsys_initcall(scpsys_drv_init);
-- 
1.9.1

Re: why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

[Michal Hocko]

On Fri 13-05-16 11:58:16, Xishi Qiu wrote:
> I find the count nr_file_pages is not equal to nr_inactive_file + 
> nr_active_file.
> There are 8 cpus, 2 zones in my system.

Because they count shmem pages as well and those are living on the anon
lru list (see shmem_add_to_page_cache).
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Peter Chen]

On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
> Hi,
> 
> On 16/05/16 10:02, Peter Chen wrote:
> > On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
> >> +
> >> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool 
> >> connect)
> >> +{
> >> +  struct usb_udc *udc;
> >> +
> >> +  mutex_lock(&udc_lock);
> >> +  udc = usb_gadget_to_udc(gadget);
> >> +  if (!udc) {
> >> +  dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >> +  __func__);
> >> +  mutex_unlock(&udc_lock);
> >> +  return -EINVAL;
> >> +  }
> >> +
> >> +  if (connect) {
> >> +  if (!gadget->connected)
> >> +  usb_gadget_connect(udc->gadget);
> >> +  } else {
> >> +  if (gadget->connected) {
> >> +  usb_gadget_disconnect(udc->gadget);
> >> +  udc->driver->disconnect(udc->gadget);
> >> +  }
> >> +  }
> >> +
> >> +  mutex_unlock(&udc_lock);
> >> +
> >> +  return 0;
> >> +}
> >> +
> > 
> > Since this is called for vbus interrupt, why not using
> > usb_udc_vbus_handler directly, and call udc->driver->disconnect
> > at usb_gadget_stop.
> 
> We can't assume that this is always called for vbus interrupt so
> I decided not to call usb_udc_vbus_handler.
> 
> udc->vbus is really pointless for us. We keep vbus states in our
> state machine and leave udc->vbus as ture always.
> 
> Why do you want to move udc->driver->disconnect() to stop?
> If USB controller disconnected from bus then the gadget driver
> must be notified about the disconnect immediately. The controller
> may or may not be stopped by the core.
> 

Then, would you give some comments when this API will be used?
I was assumed it is only used for drd state machine.

> > 
> >>return 0;
> >> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device 
> >> *dev,
> >>return -EOPNOTSUPP;
> >>}
> >>  
> >> +  /* In OTG mode we don't support softconnect, but b_bus_req */
> >> +  if (udc->gadget->otg_dev) {
> >> +  dev_err(dev, "soft-connect not supported in OTG mode\n");
> >> +  return -EOPNOTSUPP;
> >> +  }
> >> +
> > 
> > The soft-connect can be supported at dual-role mode currently, we can
> > use b_bus_req entry once it is implemented later.
> 
> Soft-connect should be done via sysfs handling within the OTG core.
> This can be added later. I don't want anything outside the OTG core
> to handle soft-connect behaviour as it will be hard to keep things
> in sync.
> 
> I can update the comment to something like this.
> 
> /* In OTG/dual-role mode, soft-connect should be handled by OTG core */

Ok, let's Felipe decide it.

> 
> > 
> >>if (sysfs_streq(buf, "connect")) {
> >>usb_gadget_udc_start(udc);
> >> -  usb_gadget_connect(udc->gadget);
> >> +  usb_udc_connect_control(udc);
> > 
> > This line seems to be not related with this patch.
> > 
> Right. I'll remove it.
> 
> cheers,
> -roger

-- 

Best Regards,
Peter Chen

Re: [PATCH v2] kdump: Fix gdb macros work work with newer and 64-bit kernels

[Baoquan He]

On 05/10/16 at 07:30pm, miny...@acm.org wrote:
> From: Corey Minyard 
> 
> Lots of little changes needed to be made to clean these up, remove the
> four byte pointer assumption and traverse the pid queue properly.
> Also consolidate the traceback code into a single function instead
> of having three copies of it.
> 
> Signed-off-by: Corey Minyard 

Hi Corey,

Today I tried gdbmacro.txt and found dmesg doesn't work. I tested it
on the latest 4.6.0 kernel. And I directly copy /proc/vmcore out
and use gdb to open it by below command" 

gdb vmlinux /var/crash/vmcore --"gdbmacros.txt"

All macro functions work well except of dmesg since code inside refer to
the deprecated variable like "log_end" and "logged_chars". But these
have been changed since this commit:

commit 7ff9554bb578ba02166071d2d487b7fc7d860d62
Author: Kay Sievers 
Date:   Thu May 3 02:29:13 2012 +0200

printk: convert byte-buffer to variable-length record buffer

So invoking dmesg will cause an error message printing out:

(gdb) dmesg
No symbol "log_end" in current context.

Thanks
Baoquan

> ---
> 
> Changes since v1:
> 
> Rename btthreadstruct to btthreadstack
> 
> Use sizeof(union thread_union) for the stack size instead of a hardcoded
> 4096.
> 
>  Documentation/kdump/gdbmacros.txt | 96 
> ++-
>  1 file changed, 44 insertions(+), 52 deletions(-)
> 
> diff --git a/Documentation/kdump/gdbmacros.txt 
> b/Documentation/kdump/gdbmacros.txt
> index 9b9b454..35f6a98 100644
> --- a/Documentation/kdump/gdbmacros.txt
> +++ b/Documentation/kdump/gdbmacros.txt
> @@ -15,15 +15,16 @@
>  
>  define bttnobp
>   set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
> - set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
> + set $pid_off=((size_t)&((struct task_struct *)0)->thread_group.next)
>   set $init_t=&init_task
>   set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
> + set var $stacksize = sizeof(union thread_union)
>   while ($next_t != $init_t)
>   set $next_t=(struct task_struct *)$next_t
>   printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
>   printf "===\n"
> - set var $stackp = $next_t.thread.esp
> - set var $stack_top = ($stackp & ~4095) + 4096
> + set var $stackp = $next_t.thread.sp
> + set var $stack_top = ($stackp & ~($stacksize - 1)) + $stacksize
>  
>   while ($stackp < $stack_top)
>   if (*($stackp) > _stext && *($stackp) < _sinittext)
> @@ -31,13 +32,13 @@ define bttnobp
>   end
>   set $stackp += 4
>   end
> - set $next_th=(((char *)$next_t->pids[1].pid_list.next) - 
> $pid_off)
> + set $next_th=(((char *)$next_t->thread_group.next) - $pid_off)
>   while ($next_th != $next_t)
>   set $next_th=(struct task_struct *)$next_th
>   printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
>   printf "===\n"
> - set var $stackp = $next_t.thread.esp
> - set var $stack_top = ($stackp & ~4095) + 4096
> + set var $stackp = $next_t.thread.sp
> + set var $stack_top = ($stackp & ~($stacksize - 1)) + 
> stacksize
>  
>   while ($stackp < $stack_top)
>   if (*($stackp) > _stext && *($stackp) < 
> _sinittext)
> @@ -45,7 +46,7 @@ define bttnobp
>   end
>   set $stackp += 4
>   end
> - set $next_th=(((char *)$next_th->pids[1].pid_list.next) 
> - $pid_off)
> + set $next_th=(((char *)$next_th->thread_group.next) - 
> $pid_off)
>   end
>   set $next_t=(char *)($next_t->tasks.next) - $tasks_off
>   end
> @@ -54,42 +55,44 @@ document bttnobp
>   dump all thread stack traces on a kernel compiled with 
> !CONFIG_FRAME_POINTER
>  end
>  
> +define btthreadstack
> + set var $pid_task = $arg0
> +
> + printf "\npid %d; comm %s:\n", $pid_task.pid, $pid_task.comm
> + printf "task struct: "
> + print $pid_task
> + printf "===\n"
> + set var $stackp = $pid_task.thread.sp
> + set var $stacksize = sizeof(union thread_union)
> + set var $stack_top = ($stackp & ~($stacksize - 1)) + $stacksize
> + set var $stack_bot = ($stackp & ~($stacksize - 1))
> +
> + set $stackp = *((unsigned long *) $stackp)
> + while (($stackp < $stack_top) && ($stackp > $stack_bot))
> + set var $addr = *(((unsigned long *) $stackp) + 1)
> + info symbol $addr
> + set $stackp = *((unsigned long *) $stackp)
> + end
> +end
> +document btthreadstack
> +  dump a thread stack using the given task structure pointer
> +end
> +
> +
>  defi

[PATCH] locking/rwsem: Fix comment on register clobbering

[Borislav Petkov]

On Fri, May 13, 2016 at 07:19:15PM +0200, Borislav Petkov wrote:
> The only thing that needs to be corrected then is the misleading comment
> above the 32-bit version "... Save the C-clobbered registers (%eax, %edx
> and %ecx) .." - the 64-bit version comment is correct AFAICT.

---
From: Borislav Petkov 
Date: Mon, 16 May 2016 11:29:22 +0200
Subject: [PATCH] locking/rwsem: Fix comment on register clobbering

Document explicitly that %edx can get clobbered on the slow path, on
32-bit. Something I learned the hard way. :-\

Signed-off-by: Borislav Petkov 
Cc: Ingo Molnar 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
---
 arch/x86/lib/rwsem.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S
index a37462a23546..bb49caa4dd4c 100644
--- a/arch/x86/lib/rwsem.S
+++ b/arch/x86/lib/rwsem.S
@@ -29,8 +29,10 @@
  * there is contention on the semaphore.
  *
  * %eax contains the semaphore pointer on entry. Save the C-clobbered
- * registers (%eax, %edx and %ecx) except %eax whish is either a return
- * value or just clobbered..
+ * registers (%eax, %edx and %ecx) except %eax which is either a return
+ * value or just clobbered. Same is true for %edx so make sure gcc
+ * reloads it after the slow path, by making it hold a temporary, for
+ * example; see down_write().
  */
 
 #define save_common_regs \
-- 
2.7.3

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH RFC 2/3] sched/fair: copy taskgroup shares to each cfs_rq

[Konstantin Khlebnikov]

This will be used for tweaking shares in runtime.

Signed-off-by: Konstantin Khlebnikov 
---
 kernel/sched/fair.c  |   12 +++-
 kernel/sched/sched.h |1 +
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d26b631a9a1d..5bf34532d364 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2469,21 +2469,21 @@ static long calc_cfs_shares(struct cfs_rq *cfs_rq, 
struct task_group *tg)
tg_weight = calc_tg_weight(tg, cfs_rq);
load = cfs_rq->load.weight;
 
-   shares = (tg->shares * load);
+   shares = (cfs_rq->shares * load);
if (tg_weight)
shares /= tg_weight;
 
if (shares < MIN_SHARES)
shares = MIN_SHARES;
-   if (shares > tg->shares)
-   shares = tg->shares;
+   if (shares > cfs_rq->shares)
+   shares = cfs_rq->shares;
 
return shares;
 }
 # else /* CONFIG_SMP */
 static inline long calc_cfs_shares(struct cfs_rq *cfs_rq, struct task_group 
*tg)
 {
-   return tg->shares;
+   return cfs_rq->shares;
 }
 # endif /* CONFIG_SMP */
 static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
@@ -2515,7 +2515,7 @@ static void update_cfs_shares(struct cfs_rq *cfs_rq)
if (!se || throttled_hierarchy(cfs_rq))
return;
 #ifndef CONFIG_SMP
-   if (likely(se->load.weight == tg->shares))
+   if (likely(se->load.weight == cfs_rq->shares))
return;
 #endif
shares = calc_cfs_shares(cfs_rq, tg);
@@ -8439,6 +8439,7 @@ void init_tg_cfs_entry(struct task_group *tg, struct 
cfs_rq *cfs_rq,
 
se->my_q = cfs_rq;
/* guarantee group entities always have weight */
+   cfs_rq->shares = NICE_0_LOAD;
update_load_set(&se->load, NICE_0_LOAD);
se->parent = parent;
 }
@@ -8473,6 +8474,7 @@ int sched_group_set_shares(struct task_group *tg, 
unsigned long shares)
 
/* Possible calls to update_curr() need rq clock */
update_rq_clock(rq);
+   group_cfs_rq(se)->shares = shares;
for_each_sched_entity(se)
update_cfs_shares(group_cfs_rq(se));
raw_spin_unlock_irqrestore(&rq->lock, flags);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index ec2e8d23527e..e75e755ee5e9 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -422,6 +422,7 @@ struct cfs_rq {
int on_list;
struct list_head leaf_cfs_rq_list;
struct task_group *tg;  /* group that "owns" this runqueue */
+   unsigned long shares;
 
 #ifdef CONFIG_CFS_BANDWIDTH
int runtime_enabled;

[PATCH RFC 1/3] sched/fair: call __refill_cfs_bandwidth_runtime only for finite quota

[Konstantin Khlebnikov]

Both call sites (tg_set_cfs_bandwidth and do_sched_cfs_period_timer)
already have checks for infinite quota.

Signed-off-by: Konstantin Khlebnikov 
---
 kernel/sched/core.c |5 +++--
 kernel/sched/fair.c |6 +-
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d1f7149f8704..355698188ea9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8196,10 +8196,11 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
cfs_b->period = ns_to_ktime(period);
cfs_b->quota = quota;
 
-   __refill_cfs_bandwidth_runtime(cfs_b);
/* restart the period timer (if active) to handle new period expiry */
-   if (runtime_enabled)
+   if (runtime_enabled) {
+   __refill_cfs_bandwidth_runtime(cfs_b);
start_cfs_bandwidth(cfs_b);
+   }
raw_spin_unlock_irq(&cfs_b->lock);
 
for_each_online_cpu(i) {
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e7dd0ec169be..d26b631a9a1d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3559,12 +3559,8 @@ static inline u64 sched_cfs_bandwidth_slice(void)
  */
 void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b)
 {
-   u64 now;
+   u64 now = sched_clock_cpu(smp_processor_id());
 
-   if (cfs_b->quota == RUNTIME_INF)
-   return;
-
-   now = sched_clock_cpu(smp_processor_id());
cfs_b->runtime = cfs_b->quota;
cfs_b->runtime_expires = now + ktime_to_ns(cfs_b->period);
 }

[PATCH RFC 0/3] sched/fair: cpu time reserves for cgroups

[Konstantin Khlebnikov]

This feature allows to change cpu cgroup weight for a limited time.

Cgroup interface:
cpu.cfs_reserve_us  - reserved time for each cpu.cfs_period_us
cpu.cfs_reserve_shares  - group weight during reserved time

While cfs group consumes reserved cpu time it has different weight,
thus it gets different vruntime penalty for that execution.

^ weight
|
|
reserve |
shares  ---*
|  |
|  |
|  |
shares  -  *-*
||
||
0--|-|---> time
   reserve   quota

Reserve can work as a "low limit": boost weight for "guaranteed" time,
and as a "high limit": give normal weight for a limited time and allow
utilize cpu when nobody else needs it.

Sample setup:

level   | shares  reserve shares
+
high| 1024*16 1024*16*16
normal  | 10241024*16
low | 1024/16 1024

In this way cgroups are devided into three levels.
During reserved time they are promoted to the next level.

---

Konstantin Khlebnikov (3):
  sched/fair: call __refill_cfs_bandwidth_runtime only for finite quota
  sched/fair: copy taskgroup shares to each cfs_rq
  sched/fair: pulse-weight modulation controller for cpu cgroup

 kernel/sched/core.c  |   96 +++-
 kernel/sched/fair.c  |  101 ++
 kernel/sched/sched.h |5 ++
 3 files changed, 168 insertions(+), 34 deletions(-)

[PATCH RFC 3/3] sched/fair: pulse-weight modulation controller for cpu cgroup

[Konstantin Khlebnikov]

This implements "low limit"-ish thing for cpu bandwidth controller.

Cgroup interface:
cpu.cfs_reserve_us  - reserved time for each cpu.cfs_period_us
cpu.cfs_reserve_shares  - group weight for reserved time

While cfs group consumes reserved cpu time it has different weight,
thus vruntime penalty for that execution differs too.

Distribution of reserved time is similar to distribution of cpu quota:
cfs rq pulls reserved time from shared pool which is refilled by a timer.

This feature also can work as "high limit": reserve can boost weight
from tiny to normal for limited amount of time. Such group can use
cpu even after depleting reserves if nobody else needs it.

Signed-off-by: Konstantin Khlebnikov 
---
 kernel/sched/core.c  |   91 ++
 kernel/sched/fair.c  |   85 ++-
 kernel/sched/sched.h |4 ++
 3 files changed, 157 insertions(+), 23 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 355698188ea9..4a583c6e5d4e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8150,7 +8150,8 @@ const u64 min_cfs_quota_period = 1 * NSEC_PER_MSEC; /* 
1ms */
 
 static int __cfs_schedulable(struct task_group *tg, u64 period, u64 runtime);
 
-static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
+static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period,
+   u64 quota, u64 reserve)
 {
int i, ret = 0, runtime_enabled, runtime_was_enabled;
struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth;
@@ -8184,8 +8185,9 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
if (ret)
goto out_unlock;
 
-   runtime_enabled = quota != RUNTIME_INF;
-   runtime_was_enabled = cfs_b->quota != RUNTIME_INF;
+   runtime_enabled = quota != RUNTIME_INF || reserve != 0;
+   runtime_was_enabled = cfs_b->quota != RUNTIME_INF ||
+ cfs_b->reserve != 0;
/*
 * If we need to toggle cfs_bandwidth_used, off->on must occur
 * before making related changes, and on->off must occur afterwards
@@ -8195,6 +8197,7 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
raw_spin_lock_irq(&cfs_b->lock);
cfs_b->period = ns_to_ktime(period);
cfs_b->quota = quota;
+   cfs_b->reserve = reserve;
 
/* restart the period timer (if active) to handle new period expiry */
if (runtime_enabled) {
@@ -8213,6 +8216,10 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
 
if (cfs_rq->throttled)
unthrottle_cfs_rq(cfs_rq);
+
+   if (cfs_rq->reserve_active)
+   deactivate_cfs_rq_reserve(cfs_rq);
+
raw_spin_unlock_irq(&rq->lock);
}
if (runtime_was_enabled && !runtime_enabled)
@@ -8224,17 +8231,39 @@ out_unlock:
return ret;
 }
 
+static int tg_set_cfs_reserve(struct task_group *tg, long cfs_reserve_us)
+{
+   u64 reserve, quota, period;
+
+   period = ktime_to_ns(tg->cfs_bandwidth.period);
+   quota = tg->cfs_bandwidth.quota;
+   reserve = (u64)cfs_reserve_us * NSEC_PER_USEC;
+
+   return tg_set_cfs_bandwidth(tg, period, quota, reserve);
+}
+
+static long tg_get_cfs_reserve(struct task_group *tg)
+{
+   u64 reserve_us;
+
+   reserve_us = tg->cfs_bandwidth.reserve;
+   do_div(reserve_us, NSEC_PER_USEC);
+
+   return reserve_us;
+}
+
 int tg_set_cfs_quota(struct task_group *tg, long cfs_quota_us)
 {
-   u64 quota, period;
+   u64 reserve, quota, period;
 
period = ktime_to_ns(tg->cfs_bandwidth.period);
if (cfs_quota_us < 0)
quota = RUNTIME_INF;
else
quota = (u64)cfs_quota_us * NSEC_PER_USEC;
+   reserve = tg->cfs_bandwidth.reserve;
 
-   return tg_set_cfs_bandwidth(tg, period, quota);
+   return tg_set_cfs_bandwidth(tg, period, quota, reserve);
 }
 
 long tg_get_cfs_quota(struct task_group *tg)
@@ -8252,12 +8281,13 @@ long tg_get_cfs_quota(struct task_group *tg)
 
 int tg_set_cfs_period(struct task_group *tg, long cfs_period_us)
 {
-   u64 quota, period;
+   u64 reserve, quota, period;
 
period = (u64)cfs_period_us * NSEC_PER_USEC;
quota = tg->cfs_bandwidth.quota;
+   reserve = tg->cfs_bandwidth.reserve;
 
-   return tg_set_cfs_bandwidth(tg, period, quota);
+   return tg_set_cfs_bandwidth(tg, period, quota, reserve);
 }
 
 long tg_get_cfs_period(struct task_group *tg)
@@ -8270,6 +8300,43 @@ long tg_get_cfs_period(struct task_group *tg)
return cfs_period_us;
 }
 
+static u64 cpu_cfs_reserve_read_u64(struct cgroup_subsys_state *css,
+   struct cftype *cft)
+{
+   return tg_get_cfs_reserve(css_tg(css));
+}
+
+static int cpu_cfs_reserve_write_u64(struct cgroup_subsys_state *

Re: [PATCH v2] kdump: Fix gdb macros work work with newer and 64-bit kernels

[Baoquan He]

On 05/16/16 at 05:32pm, Baoquan He wrote:
> On 05/10/16 at 07:30pm, miny...@acm.org wrote:
> > From: Corey Minyard 
> > 
> > Lots of little changes needed to be made to clean these up, remove the
> > four byte pointer assumption and traverse the pid queue properly.
> > Also consolidate the traceback code into a single function instead
> > of having three copies of it.
> > 
> > Signed-off-by: Corey Minyard 
> 
> Hi Corey,
> 
> Today I tried gdbmacro.txt and found dmesg doesn't work. I tested it
> on the latest 4.6.0 kernel. And I directly copy /proc/vmcore out
> and use gdb to open it by below command" 
> 
> gdb vmlinux /var/crash/vmcore --"gdbmacros.txt"
Here I means  --command="gdbmacros.txt"

> 
> All macro functions work well except of dmesg since code inside refer to
> the deprecated variable like "log_end" and "logged_chars". But these
> have been changed since this commit:
> 
> commit 7ff9554bb578ba02166071d2d487b7fc7d860d62
> Author: Kay Sievers 
> Date:   Thu May 3 02:29:13 2012 +0200
> 
> printk: convert byte-buffer to variable-length record buffer
> 
> So invoking dmesg will cause an error message printing out:
> 
> (gdb) dmesg
> No symbol "log_end" in current context.
> 
> Thanks
> Baoquan
> 
> > ---
> > 
> > Changes since v1:
> > 
> > Rename btthreadstruct to btthreadstack
> > 
> > Use sizeof(union thread_union) for the stack size instead of a hardcoded
> > 4096.
> > 
> >  Documentation/kdump/gdbmacros.txt | 96 
> > ++-
> >  1 file changed, 44 insertions(+), 52 deletions(-)
> > 
> > diff --git a/Documentation/kdump/gdbmacros.txt 
> > b/Documentation/kdump/gdbmacros.txt
> > index 9b9b454..35f6a98 100644
> > --- a/Documentation/kdump/gdbmacros.txt
> > +++ b/Documentation/kdump/gdbmacros.txt
> > @@ -15,15 +15,16 @@
> >  
> >  define bttnobp
> > set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
> > -   set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
> > +   set $pid_off=((size_t)&((struct task_struct *)0)->thread_group.next)
> > set $init_t=&init_task
> > set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
> > +   set var $stacksize = sizeof(union thread_union)
> > while ($next_t != $init_t)
> > set $next_t=(struct task_struct *)$next_t
> > printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
> > printf "===\n"
> > -   set var $stackp = $next_t.thread.esp
> > -   set var $stack_top = ($stackp & ~4095) + 4096
> > +   set var $stackp = $next_t.thread.sp
> > +   set var $stack_top = ($stackp & ~($stacksize - 1)) + $stacksize
> >  
> > while ($stackp < $stack_top)
> > if (*($stackp) > _stext && *($stackp) < _sinittext)
> > @@ -31,13 +32,13 @@ define bttnobp
> > end
> > set $stackp += 4
> > end
> > -   set $next_th=(((char *)$next_t->pids[1].pid_list.next) - 
> > $pid_off)
> > +   set $next_th=(((char *)$next_t->thread_group.next) - $pid_off)
> > while ($next_th != $next_t)
> > set $next_th=(struct task_struct *)$next_th
> > printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
> > printf "===\n"
> > -   set var $stackp = $next_t.thread.esp
> > -   set var $stack_top = ($stackp & ~4095) + 4096
> > +   set var $stackp = $next_t.thread.sp
> > +   set var $stack_top = ($stackp & ~($stacksize - 1)) + 
> > stacksize
> >  
> > while ($stackp < $stack_top)
> > if (*($stackp) > _stext && *($stackp) < 
> > _sinittext)
> > @@ -45,7 +46,7 @@ define bttnobp
> > end
> > set $stackp += 4
> > end
> > -   set $next_th=(((char *)$next_th->pids[1].pid_list.next) 
> > - $pid_off)
> > +   set $next_th=(((char *)$next_th->thread_group.next) - 
> > $pid_off)
> > end
> > set $next_t=(char *)($next_t->tasks.next) - $tasks_off
> > end
> > @@ -54,42 +55,44 @@ document bttnobp
> > dump all thread stack traces on a kernel compiled with 
> > !CONFIG_FRAME_POINTER
> >  end
> >  
> > +define btthreadstack
> > +   set var $pid_task = $arg0
> > +
> > +   printf "\npid %d; comm %s:\n", $pid_task.pid, $pid_task.comm
> > +   printf "task struct: "
> > +   print $pid_task
> > +   printf "===\n"
> > +   set var $stackp = $pid_task.thread.sp
> > +   set var $stacksize = sizeof(union thread_union)
> > +   set var $stack_top = ($stackp & ~($stacksize - 1)) + $stacksize
> > +   set var $stack_bot = ($stackp & ~($stacksize - 1))
> > +
> > +   set $stackp = *((unsigned long *) $stackp)
> > +   while (($stackp < $stack_top) && ($stackp > $stack_bot))
> > +   set var $addr = *(((unsigned long 

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

[Matt Fleming]

On Sun, 15 May, at 10:14:39AM, Yuyang Du wrote:
> Hi Matt,
> 
> Thanks for Ccing me.
> 
> I am indeed interested, because I recently encountered an rq clock
> issue, which is that the clock jumps about 200ms when I was
> experimenting the "flat util hierarchy" patches, which really annoyed
> me, and I had to stop to figure out what is wrong (but haven't yet
> figured out ;))
> 
> First, this patchset does not solve my problem, but never mind, by
> reviewing your patches, I have some comments:
 
Thanks for the review. One gap that this patch series doesn't address
is that some callers of update_rq_clock() do not pin rq->lock, which
makes the diagnostic checks useless in that case.

I plan on handling that next, but I wanted to get this series out as
soon as possible for review.

> On Thu, May 12, 2016 at 08:49:53PM +0100, Matt Fleming wrote:
> >  
> > -   rq->clock_skip_update = 0;
> > +   /* Clear ACT, preserve everything else */
> > +   rq->clock_update_flags ^= RQCF_ACT_SKIP;
> 
> The comment says "Clear ACT", but this is really xor, and I am not sure
> this is even what you want.
 
Urgh, you're right. I'm not sure what I was thinking when I wrote
that.

> In addition, would it be simpler to do this?
> 
> update_rq_clock()
>   if (flags & RQCF_ACT_SKIP)
>   flags <<= 1; /* effective skip is an update */
>   return;
> 
>   flags = RQCF_UPDATED;

No because if someone calls rq_clock() immediately after __schedule(),
or even immediately after we clear RQCF_ACT_SKIP in __schedule(), we
should trigger a warning since the clock has not actually been
updated.

Re: [RFC 13/13] mm, compaction: fix and improve watermark handling

[Vlastimil Babka]

On 05/16/2016 11:25 AM, Michal Hocko wrote:

On Tue 10-05-16 09:36:03, Vlastimil Babka wrote:

Compaction has been using watermark checks when deciding whether it was
successful, and whether compaction is at all suitable. There are few problems
with these checks.

- __compact_finished() uses low watermark in a check that has to pass if
   the direct compaction is to finish and allocation should succeed. This is
   too pessimistic, as the allocation will typically use min watermark. It
   may happen that during compaction, we drop below the low watermark (due to
   parallel activity), but still form the target high-order page. By checking
   against low watermark, we might needlessly continue compaction. After this
   patch, the check uses direct compactor's alloc_flags to determine the
   watermark, which is effectively the min watermark.


OK, this makes some sense. It would be great if we could have at least
some clarification why the low wmark has been used previously. Probably
Mel can remember?


- __compaction_suitable has the same issue in the check whether the allocation
   is already supposed to succeed and we don't need to compact. Fix it the same
   way.

- __compaction_suitable() then checks the low watermark plus a (2 << order) gap
   to decide if there's enough free memory to perform compaction. This check


And this was a real head scratcher when I started looking into the
compaction recently. Why do we need to be above low watermark to even
start compaction.


Hmm, above you said you're fine with low wmark (maybe after 
clarification). I don't know why it was used, can only guess.



Compaction uses additional memory only for a short
period of time and then releases the already migrated pages.


As for the 2 << order gap. I can imagine that e.g. order-5 compaction 
(32 pages) isolates 20 pages for migration and starts looking for free 
pages. It collects 19 free pages and then reaches an order-4 free page. 
Splitting that page to collect it would result in 19+16=35 pages 
isolated, thus exceed the 1 << order gap, and fail. With 2 << order gap, 
chances of this happening are reduced.



   uses direct compactor's alloc_flags, but that's wrong. If alloc_flags doesn't
   include ALLOC_CMA, we might fail the check, even though the freepage
   isolation isn't restricted outside of CMA pageblocks. On the other hand,
   alloc_flags may indicate access to memory reserves, making compaction proceed
   and then fail watermark check during freepage isolation, which doesn't pass
   alloc_flags. The fix here is to use fixed ALLOC_CMA flags in the
   __compaction_suitable() check.


This makes my head hurt. Whut?


I'll try to explain better next time.


- __isolate_free_page uses low watermark check to decide if free page can be
   isolated. It also doesn't use ALLOC_CMA, so add it for the same reasons.


Why do we check the watermark at all? What would happen if this obscure
if (!is_migrate_isolate(mt)) was gone? I remember I put some tracing
there and it never hit for me even when I was testing close to OOM
conditions. Maybe an earlier check bailed out but this code path looks
really obscure so it should either deserve a large fat comment or to
die.


The check is there so that compaction doesn't exhaust memory below 
reserves during its work, just like any other non-privileged allocation.



- The use of low watermark checks in __compaction_suitable() and
   __isolate_free_page does perhaps make sense for high-order allocations where
   more freepages increase the chance of success, and we can typically fail
   with some order-0 fallback when the system is struggling. But for low-order
   allocation, forming the page should not be that hard. So using low watermark
   here might just prevent compaction from even trying, and eventually lead to
   OOM killer even if we are above min watermarks. So after this patch, we use
   min watermark for non-costly orders in these checks, by passing the
   alloc_flags parameter to split_page() and __isolate_free_page().


OK, so if IIUC costly high order requests even shouldn't try when we are
below watermark (unless they are __GFP_REPEAT which would get us to a
stronger compaction mode/priority) and that would reclaim us over low
wmark and go on. Is that what you are saying? This makes some sense but
then let's have a _single_ place to check the watermak please. This
checks at few different levels is just subtle as hell and error prone
likewise.


What single place then? The situation might change dynamically so 
passing the initial __compaction_suitable() check doesn't guarantee that 
enough free pages are still available when it comes to isolating 
freepages. Your testing that never hit it shows that this is rare, but 
do we want to risk compaction making an OOM situation worse?



To sum up, after this patch, the kernel should in some situations finish
successful direct compaction sooner, prevent compaction from starting when it's
not needed, proceed with compa

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Roger Quadros]

On 16/05/16 12:23, Peter Chen wrote:
> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 16/05/16 10:02, Peter Chen wrote:
>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
 +
 +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool 
 connect)
 +{
 +  struct usb_udc *udc;
 +
 +  mutex_lock(&udc_lock);
 +  udc = usb_gadget_to_udc(gadget);
 +  if (!udc) {
 +  dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
 +  __func__);
 +  mutex_unlock(&udc_lock);
 +  return -EINVAL;
 +  }
 +
 +  if (connect) {
 +  if (!gadget->connected)
 +  usb_gadget_connect(udc->gadget);
 +  } else {
 +  if (gadget->connected) {
 +  usb_gadget_disconnect(udc->gadget);
 +  udc->driver->disconnect(udc->gadget);
 +  }
 +  }
 +
 +  mutex_unlock(&udc_lock);
 +
 +  return 0;
 +}
 +
>>>
>>> Since this is called for vbus interrupt, why not using
>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect
>>> at usb_gadget_stop.
>>
>> We can't assume that this is always called for vbus interrupt so
>> I decided not to call usb_udc_vbus_handler.
>>
>> udc->vbus is really pointless for us. We keep vbus states in our
>> state machine and leave udc->vbus as ture always.
>>
>> Why do you want to move udc->driver->disconnect() to stop?
>> If USB controller disconnected from bus then the gadget driver
>> must be notified about the disconnect immediately. The controller
>> may or may not be stopped by the core.
>>
> 
> Then, would you give some comments when this API will be used?
> I was assumed it is only used for drd state machine.

drd_state machine didn't even need this API in the first place :).
You guys wanted me to separate out start/stop and connect/disconnect for full 
OTG case.
Won't full OTG state machine want to use this API? If not what would it use?

cheers,
-roger

> 
>>>
return 0;
 @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device 
 *dev,
return -EOPNOTSUPP;
}
  
 +  /* In OTG mode we don't support softconnect, but b_bus_req */
 +  if (udc->gadget->otg_dev) {
 +  dev_err(dev, "soft-connect not supported in OTG mode\n");
 +  return -EOPNOTSUPP;
 +  }
 +
>>>
>>> The soft-connect can be supported at dual-role mode currently, we can
>>> use b_bus_req entry once it is implemented later.
>>
>> Soft-connect should be done via sysfs handling within the OTG core.
>> This can be added later. I don't want anything outside the OTG core
>> to handle soft-connect behaviour as it will be hard to keep things
>> in sync.
>>
>> I can update the comment to something like this.
>>
>> /* In OTG/dual-role mode, soft-connect should be handled by OTG core */
> 
> Ok, let's Felipe decide it.
> 
>>
>>>
if (sysfs_streq(buf, "connect")) {
usb_gadget_udc_start(udc);
 -  usb_gadget_connect(udc->gadget);
 +  usb_udc_connect_control(udc);
>>>
>>> This line seems to be not related with this patch.
>>>
>> Right. I'll remove it.
>>
>> cheers,
>> -roger
> 

Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority

[Michal Hocko]

On Mon 16-05-16 11:27:56, Vlastimil Babka wrote:
> On 05/16/2016 10:14 AM, Michal Hocko wrote:
> > On Mon 16-05-16 09:31:44, Vlastimil Babka wrote:
[...]
> > > Also my understanding of the initial compaction priorities is to lower the
> > > latency if fragmentation is just light and there's enough memory. Once we
> > > start struggling, I don't see much point in not switching to the full
> > > compaction priority quickly.
> > 
> > That is true but why to compact when there are high order pages and they
> > are just hidden by the watermark check.
> 
> Compaction should skip such zone regardless of priority.

The point I've tried to raise is that we shouldn't conflate the purpose
of the two. The reclaim is here primarily to get us over the watermarks
while compaction is here to form high order pages. If we get both
together the distinction is blured which, I believe, will lead to more
complicated code in the end. I might be wrong here of course but let's
try to have compaction as much wmark check free as possible.
-- 
Michal Hocko
SUSE Labs

Re: why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

[Michal Hocko]

[Sorry I haven't noticed this answer before]

On Fri 13-05-16 15:31:42, Xishi Qiu wrote:
> On 2016/5/13 15:00, Aaron Lu wrote:
> 
> Hi Aaron,
> 
> Thanks for your reply, but I find the count of nr_shmem is very small
> in my system.

which kernel version is this? I remember that we used to account thp
pages as NR_FILE_PAGE as well in the past.

I didn't get to look at your number more closely though.
-- 
Michal Hocko
SUSE Labs

[PATCH] arc: axs103_smp: Fix CPU frequency to 100MHz for dual-core

[Alexey Brodkin]

The most recent release of AXS103 [v1.1] is proven to work
at 100 MHz in dual-core mode so this change uses mentioned feature.
For that we:
 * Update axc003_idu.dtsi with mention of really-used CPU clock freq
 * Remove clock override in AXS platform code for dual-core HW

Note we're still leaving a hack for clock "downgrade" on early boot
for quad-core hardware.

Also note this change will break functionality of AXS103 v1.0 hardware.
That means all users of AXS103 __must__ upgrade their boards with the
most recent firmware.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/boot/dts/axc003_idu.dtsi | 2 +-
 arch/arc/plat-axs10x/axs10x.c | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arc/boot/dts/axc003_idu.dtsi 
b/arch/arc/boot/dts/axc003_idu.dtsi
index 8955881d..ed1674b 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -28,7 +28,7 @@
core_clk: core_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
-   clock-frequency = <9000>;
+   clock-frequency = <1>;
};
 
core_intc: archs-intc@cpu {
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 9701c93..8654870 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -410,8 +410,6 @@ static void __init axs103_early_init(void)
unsigned int num_cores = (read_aux_reg(ARC_REG_MCIP_BCR) >> 16) & 0x3F;
if (num_cores > 2)
freq = 50;
-   else if (num_cores == 2)
-   freq = 75;
 #endif
 
switch (freq) {
-- 
2.5.5

Re: [PATCHv8 resend 1/2] x86/vdso: add mremap hook to vm_special_mapping

[Dmitry Safonov]

On 05/10/2016 04:29 PM, Dmitry Safonov wrote:

Add possibility for userspace 32-bit applications to move
vdso mapping. Previously, when userspace app called
mremap for vdso, in return path it would land on previous
address of vdso page, resulting in segmentation violation.
Now it lands fine and returns to userspace with remapped vdso.
This will also fix context.vdso pointer for 64-bit, which does not
affect the user of vdso after mremap by now, but this may change.

As suggested by Andy, return EINVAL for mremap that splits vdso image.

Renamed and moved text_mapping structure declaration inside
map_vdso, as it used only there and now it complement
vvar_mapping variable.

There is still problem for remapping vdso in glibc applications:
linker relocates addresses for syscalls on vdso page, so
you need to relink with the new addresses. Or the next syscall
through glibc may fail:
  Program received signal SIGSEGV, Segmentation fault.
  #0  0xf7fd9b80 in __kernel_vsyscall ()
  #1  0xf7ec8238 in _exit () from /usr/lib32/libc.so.6

Signed-off-by: Dmitry Safonov 
Acked-by: Andy Lutomirski 
---
v8: add WARN_ON_ONCE on current->mm != new_vma->vm_mm
v7: build fix
v6: moved vdso_image_32 check and fixup code into vdso_fix_landing function
with ifdefs around
v5: as Andy suggested, add a check that new_vma->vm_mm and current->mm are
the same, also check not only in_ia32_syscall() but image == &vdso_image_32
v4: drop __maybe_unused & use image from mm->context instead vdso_image_32
v3: as Andy suggested, return EINVAL in case of splitting vdso blob on mremap;
used is_ia32_task instead of ifdefs
v2: added __maybe_unused for pt_regs in vdso_mremap


Ping?

Re: why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

[Xishi Qiu]

On 2016/5/16 17:31, Michal Hocko wrote:

> On Fri 13-05-16 11:58:16, Xishi Qiu wrote:
>> I find the count nr_file_pages is not equal to nr_inactive_file + 
>> nr_active_file.
>> There are 8 cpus, 2 zones in my system.
> 
> Because they count shmem pages as well and those are living on the anon
> lru list (see shmem_add_to_page_cache).

Hi Michal,

But the shmem seems very small.

nr_inactive_file 432444
nr_active_file 20659
nr_unevictable 2363
nr_shmem 128

nr_file_pages 462723

There is still 7129 pages difference.

root@hi3650:/ # cat /proc/vmstat 
nr_free_pages 54192
nr_inactive_anon 39830
nr_active_anon 28794
nr_inactive_file 432444
nr_active_file 20659
nr_unevictable 2363
nr_mlock 0
nr_anon_pages 65249
nr_mapped 19742
nr_file_pages 462723
nr_dirty 20
nr_writeback 0
nr_slab_reclaimable 259333
nr_slab_unreclaimable 33463
nr_page_table_pages 3456
nr_kernel_stack 892
nr_unstable 0
nr_bounce 11
nr_vmscan_write 292032
nr_vmscan_immediate_reclaim 47204474
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 128
nr_dirtied 69574
nr_written 356299
nr_anon_transparent_hugepages 0
nr_free_cma 7519
nr_swapcache 41972
nr_dirty_threshold 6982
nr_dirty_background_threshold 99297

Re: [PATCH 1/4] Staging: comedi: Fix WARNING issue in s626.c

[Ian Abbott]

On 12/05/16 07:59, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 30 --
  1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index c5e0863..43ab2e4 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -77,23 +77,30 @@ struct s626_buffer_dma {
  struct s626_private {
uint8_t ai_cmd_running; /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
+* units of the timer
+*/
uint16_t counter_int_enabs; /* counter interrupt enable mask
-* for MISC2 register */
+* for MISC2 register
+*/
uint8_t adc_items;  /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
+* program
+*/
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
+* and hold DAC data
+*/
uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
+* used to hold DAC data
+*/
uint16_t dacpol;/* image of DAC polarity register */
uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+* (board rev dependent)
+*/
  };

  /* Counter overflow/index event flag masks for RDMISC2. */
@@ -572,11 +579,14 @@ static int s626_set_dac(struct comedi_device *dev,
 * running after the packet has been sent to the target DAC.
 */
val = 0x0F00;   /* Continue clock after target DAC data
-* (write to non-existent trimdac). */
+* (write to non-existent trimdac).
+*/
val |= 0x4000;  /* Address the two main dual-DAC devices
-* (TSL's chip select enables target device). */
+* (TSL's chip select enables target device).
+*/
val |= ((uint32_t)(chan & 1) << 15);  /* Address the DAC channel
-* within the device. */
+* within the device.
+*/
val |= (uint32_t)dacdata;   /* Include DAC setpoint data. */
return s626_send_dac(dev, val);
  }



Thanks!

That's not our usual commenting style, but it will do for now.  (Our 
usual style for "end of line" comments that don't fit on the line is to 
convert them to comments on the preceding lines.)


Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

[Xishi Qiu]

On 2016/5/16 17:57, Michal Hocko wrote:

> [Sorry I haven't noticed this answer before]
> 
> On Fri 13-05-16 15:31:42, Xishi Qiu wrote:
>> On 2016/5/13 15:00, Aaron Lu wrote:
>>
>> Hi Aaron,
>>
>> Thanks for your reply, but I find the count of nr_shmem is very small
>> in my system.
> 
> which kernel version is this? I remember that we used to account thp
> pages as NR_FILE_PAGE as well in the past.
> 
> I didn't get to look at your number more closely though.

Hi Michal,

It's android kernel, v3.10
I think the thp config is off.

Thanks,
Xishi Qiu

Re: [PATCH 2/4] Staging: comedi:Fix checkpatch issue in s626.c

[Ian Abbott]

On 12/05/16 07:59, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
found by the checkpatch.pl tool

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 43ab2e4..13f302d 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -718,7 +718,7 @@ static uint16_t s626_get_mode_a(struct comedi_device *dev,
uint16_t cra;
uint16_t crb;
uint16_t setup;
-   unsigned cntsrc, clkmult, clkpol, encmode;
+   unsigned int cntsrc, clkmult, clkpol, encmode;

/* Fetch CRA and CRB register images. */
cra = s626_debi_read(dev, S626_LP_CRA(chan));
@@ -773,7 +773,7 @@ static uint16_t s626_get_mode_b(struct comedi_device *dev,
uint16_t cra;
uint16_t crb;
uint16_t setup;
-   unsigned cntsrc, clkmult, clkpol, encmode;
+   unsigned int cntsrc, clkmult, clkpol, encmode;

/* Fetch CRA and CRB register images. */
cra = s626_debi_read(dev, S626_LP_CRA(chan));
@@ -848,7 +848,7 @@ static void s626_set_mode_a(struct comedi_device *dev,
struct s626_private *devpriv = dev->private;
uint16_t cra;
uint16_t crb;
-   unsigned cntsrc, clkmult, clkpol;
+   unsigned int cntsrc, clkmult, clkpol;

/* Initialize CRA and CRB images. */
/* Preload trigger is passed through. */
@@ -926,7 +926,7 @@ static void s626_set_mode_b(struct comedi_device *dev,
struct s626_private *devpriv = dev->private;
uint16_t cra;
uint16_t crb;
-   unsigned cntsrc, clkmult, clkpol;
+   unsigned int cntsrc, clkmult, clkpol;

/* Initialize CRA and CRB images. */
/* IndexSrc is passed through. */



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

[PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

[Jaewon Kim]

There was an alignment mismatch issue for CMA and it was fixed by
commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with 
CMA setup").
However the way of the commit considers not only dma-contiguous(CMA) but also
dma-coherent which has no that requirement.

This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent.

Signed-off-by: Jaewon 
---
 drivers/of/of_reserved_mem.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index ed01c01..45b873e 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -127,7 +127,10 @@ static int __init __reserved_mem_alloc_size(unsigned long 
node,
}
 
/* Need adjust the alignment to satisfy the CMA requirement */
-   if (IS_ENABLED(CONFIG_CMA) && of_flat_dt_is_compatible(node, 
"shared-dma-pool"))
+   if (IS_ENABLED(CONFIG_CMA)
+   && of_flat_dt_is_compatible(node, "shared-dma-pool")
+   && of_get_flat_dt_prop(node, "reusable", NULL)
+   && !of_get_flat_dt_prop(node, "no-map", NULL)) {
align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, 
pageblock_order));
 
prop = of_get_flat_dt_prop(node, "alloc-ranges", &len);

ioatdma(Intel(R) I/OAT DMA Engine init failed)

[Gavin Guo]

The following error messages can be observed on the Intel Haswell-E
chipset with v3.13 kernel. After the analysis, I found there is no
difference in the logic of these error messages in the current
upstream kernel. I also searched the git log and can't find any commit
which is fix to the error(correct me if I am wrong). The following is
the detail, and I'll really appreciate if there is any comment. :)

ioatdma :00:04.0: channel error register unreachable
ioatdma :00:04.0: channel enumeration error
ioatdma :00:04.0: Intel(R) I/OAT DMA Engine init failed
ioatdma :00:04.1: channel error register unreachable
ioatdma :00:04.1: channel enumeration error
ioatdma :00:04.1: Intel(R) I/OAT DMA Engine init failed
...
ioatdma :00:04.7: channel error register unreachable
ioatdma :00:04.7: channel enumeration error
ioatdma :00:04.7: Intel(R) I/OAT DMA Engine init failed
mei_me :00:16.0: initialization failed.

There are 8 I/OAT DMA controllers on the Haswell-E chipset:
8086:2f20 ~ 8086:2f27
80:04.0 System peripheral: Intel Corporation Haswell-E DMA Channel 0 (rev 02)
80:04.1 System peripheral: Intel Corporation Haswell-E DMA Channel 1 (rev 02)
80:04.2 System peripheral: Intel Corporation Haswell-E DMA Channel 2 (rev 02)
80:04.3 System peripheral: Intel Corporation Haswell-E DMA Channel 3 (rev 02)
80:04.4 System peripheral: Intel Corporation Haswell-E DMA Channel 4 (rev 02)
80:04.5 System peripheral: Intel Corporation Haswell-E DMA Channel 5 (rev 02)
80:04.6 System peripheral: Intel Corporation Haswell-E DMA Channel 6 (rev 02)
80:04.7 System peripheral: Intel Corporation Haswell-E DMA Channel 7 (rev 02)

Analysis:
The bug happens when the driver is resetting DMA controller, this is
the sequence: The function, ioat_pci_probe, is called when the DMA
controller is detected by the PCI bus. Then,
ioat3_dma_probe -> ioat_probe -> ioat2_enumerate_channels ->
ioat3_reset_hw. The following code can be found in the ioat3_reset_hw:

drivers/dma/ioat/dma_v3.c:
chanerr = readl(chan->reg_base + IOAT_CHANERR_OFFSET);
writel(chanerr, chan->reg_base + IOAT_CHANERR_OFFSET);
...
err = pci_read_config_dword(pdev,
IOAT_PCI_CHANERR_INT_OFFSET, &chanerr);
if (err) {
dev_err(&pdev->dev,
"channel error register unreachable\n");
return err;
}

Obviously, there are something wrong in the channel error register
reset process. Then all the way back to ioat_probe(). Because the
error happens, the dma->chancnt will be set to 0:

drivers/dma/ioat/dma.c:
if (!dma->chancnt) {
dev_err(dev, "channel enumeration error\n");
goto err_setup_interrupts;
}

Finally back to ioat_pci_probe:

drivers/dma/ioat/pci.c:
err = ioat3_dma_probe(device, ioat_dca_enabled);
else
return -ENODEV;

if (err) {
dev_err(dev, "Intel(R) I/OAT DMA Engine init
failed\n");
return -ENODEV;

4.6 compilation error when making signing key

[James Morris]

I'm seeing this with the 4.6 kernel build:

CHK include/generated/compile.h
make[1]: *** No rule to make target `signing_key.pem', needed by 
`certs/signing_key.x509'.  Stop.
make: *** [certs] Error 2


-- 
James Morris

Re: [PATCH v4] platform:x86: Add PMC Driver for Intel Core SOC

[Rajneesh Bhardwaj]

On Thu, May 12, 2016 at 06:02:45PM +0300, Andy Shevchenko wrote:
> On Thu, May 12, 2016 at 4:50 PM, Rajneesh Bhardwaj
>  wrote:
> 
> Sorry for a bit late review, but I think there are still issues need
> to be addressed.
>

Thanks for the detailed review and the feedback. :)
 
> > This patch adds the Power Management Controller driver as a pci driver
> > for Intel Core SOC architecture.
> 
> SOC -> SoC
> 

Sure, will fix this throughout the code.

> >
> > This driver can utilize debugging capabilities and supported features
> > as exposed by the Power Management Controller.
> >
> > Please refer to the below specification for more details on PMC features.
> > http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html
> >
> > The current version of this driver exposes slp_s0_residency counter.
> > This counter can be used for detecting fragile SLP_S0 signal related
> > failures and take corrective actions when PCH SLP_S0 signal is not
> > asserted after kernel freeze as part of suspend to idle flow
> > (echo freeze > /sys/power/state).
> >
> > Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it
> > detects favorable conditions to enter its low power mode. As a
> > pre-requisite the SOC should be in deepest possible Package C-State
> > and devices should be in low power mode. For example, on Skylake SOC
> 
> Ditto.
> Check entire code for this.
> 

Same as above.

> > the deepest Package C-State is Package C10 or PC10. Suspend to idle
> > flow generally leads to PC10 state but PC10 state may not be sufficient
> > for realizing the platform wide power potential which SLP_S0 signal
> > assertion can provide.
> >
> > SLP_S0 signal is often connected to the Embedded Controller (EC) and the
> > Power Management IC (PMIC) for other platform power management related
> > optimizations.
> >
> > In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes
> > power gated + PLL Idle.
> >
> > As part of this driver, a mechanism to read the slp_s0 residency is exposed
> > as an api and also debugfs features are added to indicate slp_s0 signal
> 
> api -> API
> 

Sure, will take care of this change.

> > assertion residency in microseconds.
> >
> > echo freeze > /sys/power/state
> > wake the system
> > cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
> >
> > Signed-off-by: Rajneesh Bhardwaj 
> > Signed-off-by: Vishwanath Somayaji 
> 
> Two people (1).
> 
> 

Ok.

> > +INTEL PMC CORE DRIVER
> > +M:  Rajneesh Bhardwaj 
> > +M:  Vishwanath Somayaji 
> > +L:  platform-driver-...@vger.kernel.org
> > +S:  Maintained
> > +F:  drivers/platform/x86/intel_pmc_core.h
> > +F:  drivers/platform/x86/intel_pmc_core.c
> 
> So, we have arch/x86/platform/atom/pmc_atom.c
> 
> This driver looks very similar (by what functional is), so, we have to
> become clear what our layout is.
> Either we go with drivers/platform/x86 or with arch/x86/platform.
> 

IMHO, the functianality provided by this driver is platform specific and
not architecture specific.

There are few similar drivers present in this location already i.e.
intel_telemetry_core.c, intel_pmc_ipc.c etc.

We had initially put this driver along with pmc_atom.c but later we thought
that driver/platform/x86 would be a more apt place for it because of the
above mentioned reasons.

Please advise for the right location for this driver if its not placed in the
expected location.

> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -821,6 +821,18 @@ config INTEL_IPS
> >   functionality.  If in doubt, say Y here; it will only load on
> >   supported platforms.
> >
> > +config INTEL_PMC_CORE
> 
> Better to locate this in alphabetical order.
> 

Agreed, i tried to put it in alphabetical order but there are quite a few 
entries
in Kconfig that are skewed e.g. INTEL_MFLD is placed above INTEL_IPS.

Placing INTEL_PMC_CORE after INTEL_IMR would be ok?

> > +   bool "Intel PMC Core driver"
> > +   depends on X86 && PCI
> 
> > +   ---help---
> > + The Intel Platform Controller Hub for Intel Core SoCs provides 
> > access
> > + to Power Management Controller registers via a pci interface. This
> > + driver can utilize debugging capabilities and supported features 
> > as
> > + exposed by the Power Management Controller.
> > +
> > + Supported features:
> > +   - slp_s0_residency counter.
> > +
> >  config INTEL_IMR
> > bool "Intel Isolated Memory Region support"
> > default n
> > diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> > index 448443c..9b11b40 100644
> > --- a/drivers/platform/x86/Makefile
> > +++ b/drivers/platform/x86/Makefile
> > @@ -69,3 +69,4 @@ obj-$(CONFIG_INTEL_PUNIT_IPC)  += intel_punit_ipc.o
> >  obj-$(CONFIG_INTEL_TELEMETRY)  += intel_telemetry_core.o \
> >intel_telemetry_pltdrv.o \
> > 

Re: [PATCH 4/4] Staging: comedi: fix line over 80 characters issue in s626.c

[Ian Abbott]

On 12/05/16 07:59, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a  line over
80 characters issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index fb27089..fb1a190 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2510,7 +2510,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
+0);
if (ret)
return ret;
}



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: [PATCH 3/4] Staging: comedi: fix type issue in s626.c

[Ian Abbott]

On 12/05/16 07:59, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a type issues
found by the checkpatch.pl tool.

i.e Prefer kernel type 'u8' over 'uint8_t'
 Prefer kernel type 'u16' over 'uint16_t'
 Prefer kernel type 'u32' over 'uint32_t'
 Prefer kernel type 's16' over 'int16_t'
 Prefer kernel type 's32' over 'int32_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 150 +-
  1 file changed, 75 insertions(+), 75 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 13f302d..fb27089 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,7 +75,7 @@ struct s626_buffer_dma {
  };

  struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
 * units of the timer
 */
@@ -83,22 +83,22 @@ struct s626_private {
unsigned int ai_convert_timer;  /* time between conversion in
 * units of the timer
 */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
+   u16 counter_int_enabs;  /* counter interrupt enable mask
 * for MISC2 register
 */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
 * program
 */
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
 * and hold DAC data
 */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
 * used to hold DAC data
 */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
 * (board rev dependent)
 */
  };


The patch is reasonable, but messes up the alignment of those comments, 
especially the multi-line comments.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Stefano Stabellini]

On Fri, 13 May 2016, Matt Fleming wrote:
> (Including more folks, quoting entire patch)
> 
> On Thu, 12 May, at 08:19:54PM, Shannon Zhao wrote:
> > From: Shannon Zhao 
> > 
> > The EFI DT parameters for bare metal are located under /chosen node,
> > while for Xen Dom0 they are located under /hyperviosr/uefi node. These
> > parameters under /chosen and /hyperviosr/uefi are not expected to appear
> > at the same time.
> > Parse these EFI parameters and initialize EFI like the way for bare
> > metal except the runtime services because the runtime services for Xen
> > Dom0 are available through hypercalls and they are always enabled. So it
> > sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and
> > bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES
> > flag is set already.
> > 
> > CC: Matt Fleming 
> > Signed-off-by: Shannon Zhao 
> > ---
> > v2: rebase it on top of EFI and Xen next branch, add some comments to
> > explain the codes. 
> > ---
> >  arch/arm/xen/enlighten.c   | 22 +++
> >  drivers/firmware/efi/arm-runtime.c |  5 +++
> >  drivers/firmware/efi/efi.c | 81 
> > ++
> >  3 files changed, 92 insertions(+), 16 deletions(-)
>  
> This looks good to me. Thanks for all the work Shannon.
> 
> Stefan, OK, let's figure out how to deal with this.
> 
> What I've done is merge xen/linux-next into the 'efi/xen-arm' topic
> branch and applied this patch here,
> 
>   
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Yes, the merge includes some Xen patches that are not actually needed
> for any of the EFI patches, but Linus has complained about picking
> random commits of a tree to merge. At least this way this is all the
> Xen linux-next material.
> 
> If you're OK with this, and assuming no one else has any preferred
> methods, I'll send out a pull request to tip over the weekend.

I am OK with it. Thanks!


> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 13e3e9f..d4f36eb 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -15,7 +15,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -261,6 +263,19 @@ static int __init fdt_find_hyper_node(unsigned long 
> > node, const char *uname,
> > !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
> > hyper_node.version = s + strlen(hyper_node.prefix);
> >  
> > +   /*
> > +* Check if Xen supports EFI by checking whether there is the
> > +* "/hypervisor/uefi" node in DT. If so, runtime services are available
> > +* through proxy functions (e.g. in case of Xen dom0 EFI implementation
> > +* they call special hypercall which executes relevant EFI functions)
> > +* and that is why they are always enabled.
> > +*/
> > +   if (IS_ENABLED(CONFIG_XEN_EFI)) {
> > +   if ((of_get_flat_dt_subnode_by_name(node, "uefi") > 0) &&
> > +   !efi_runtime_disabled())
> > +   set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
> > +   }
> > +
> > return 0;
> >  }
> >  
> > @@ -352,6 +367,13 @@ static int __init xen_guest_init(void)
> > return -ENODEV;
> > }
> >  
> > +   /*
> > +* The fdt parsing codes have set EFI_RUNTIME_SERVICES if Xen EFI
> > +* parameters are found. Force enable runtime services.
> > +*/
> > +   if (efi_enabled(EFI_RUNTIME_SERVICES))
> > +   xen_efi_runtime_setup();
> > +
> > shared_info_page = (struct shared_info *)get_zeroed_page(GFP_KERNEL);
> >  
> > if (!shared_info_page) {
> > diff --git a/drivers/firmware/efi/arm-runtime.c 
> > b/drivers/firmware/efi/arm-runtime.c
> > index 17ccf0a..c394b81 100644
> > --- a/drivers/firmware/efi/arm-runtime.c
> > +++ b/drivers/firmware/efi/arm-runtime.c
> > @@ -107,6 +107,11 @@ static int __init arm_enable_runtime_services(void)
> > return 0;
> > }
> >  
> > +   if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > +   pr_info("EFI runtime services access via paravirt.\n");
> > +   return 0;
> > +   }
> > +
> > pr_info("Remapping and enabling EFI services.\n");
> >  
> > mapsize = efi.memmap.map_end - efi.memmap.map;
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 05509f3..1c6f9dd 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -472,12 +472,14 @@ device_initcall(efi_load_efivars);
> > FIELD_SIZEOF(struct efi_fdt_params, field) \
> > }
> >  
> > -static __initdata struct {
> > +struct params {
> > const char name[32];
> > const char propname[32];
> > int offset;
> > int size;
> > -} dt_params[] = {
> > +};
> > +
> > +static __initdata struct params fdt_params[] = {
> > UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
> > UEFI_PARAM("MemMap Address", "linux

[PATCH 5/6] Staging: comedi: Fix WARNING issue in dt2801.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the dt2801.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/dt2801.c | 84 -
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt2801.c 
b/drivers/staging/comedi/drivers/dt2801.c
index 6c7b4d2..51f2f75 100644
--- a/drivers/staging/comedi/drivers/dt2801.c
+++ b/drivers/staging/comedi/drivers/dt2801.c
@@ -3,31 +3,30 @@
  * Device Driver for DataTranslation DT2801
  *
  */
-/*
-Driver: dt2801
-Description: Data Translation DT2801 series and DT01-EZ
-Author: ds
-Status: works
-Devices: [Data Translation] DT2801 (dt2801), DT2801-A, DT2801/5716A,
-  DT2805, DT2805/5716A, DT2808, DT2818, DT2809, DT01-EZ
-
-This driver can autoprobe the type of board.
-
-Configuration options:
-  [0] - I/O port base address
-  [1] - unused
-  [2] - A/D reference 0=differential, 1=single-ended
-  [3] - A/D range
- 0 = [-10, 10]
- 1 = [0,10]
-  [4] - D/A 0 range
- 0 = [-10, 10]
- 1 = [-5,5]
- 2 = [-2.5,2.5]
- 3 = [0,10]
- 4 = [0,5]
-  [5] - D/A 1 range (same choices)
-*/
+ /* Driver: dt2801
+  * Description: Data Translation DT2801 series and DT01-EZ
+  * Author: ds
+  * Status: works
+  * Devices: [Data Translation] DT2801 (dt2801), DT2801-A, DT2801/5716A,
+  * DT2805, DT2805/5716A, DT2808, DT2818, DT2809, DT01-EZ
+
+  * This driver can autoprobe the type of board.
+
+  * Configuration options:
+  * [0] - I/O port base address
+  * [1] - unused
+  * [2] - A/D reference 0=differential, 1=single-ended
+  * [3] - A/D range
+  *  0 = [-10, 10]
+  *  1 = [0,10]
+  * [4] - D/A 0 range
+  *  0 = [-10, 10]
+  *  1 = [-5,5]
+  *  2 = [-2.5,2.5]
+  *  3 = [0,10]
+  *  4 = [0,5]
+  * [5] - D/A 1 range (same choices)
+  */
 
 #include 
 #include "../comedidev.h"
@@ -66,8 +65,8 @@ Configuration options:
 #define DT_C_READ_AD 0xe
 
 /* Command modifiers (only used with read/write), EXTTRIG can be
-   used with some other commands.
-*/
+ * used with some other commands.
+ */
 #define DT_MOD_DMA BIT(4)
 #define DT_MOD_CONTBIT(5)
 #define DT_MOD_EXTCLK  BIT(6)
@@ -136,8 +135,8 @@ struct dt2801_board {
 };
 
 /* Typeid's for the different boards of the DT2801-series
-   (taken from the test-software, that comes with the board)
-   */
+ * (taken from the test-software, that comes with the board)
+ */
 static const struct dt2801_board boardtypes[] = {
{
 .name = "dt2801",
@@ -210,14 +209,15 @@ struct dt2801_private {
 };
 
 /* These are the low-level routines:
-   writecommand: write a command to the board
-   writedata: write data byte
-   readdata: read data byte
+ * writecommand: write a command to the board
+ * writedata: write data byte
+ * readdata: read data byte
  */
 
 /* Only checks DataOutReady-flag, not the Ready-flag as it is done
-   in the examples of the manual. I don't see why this should be
-   necessary. */
+ * in the examples of the manual. I don't see why this should be
+ * necessary.
+ */
 static int dt2801_readdata(struct comedi_device *dev, int *data)
 {
int stat = 0;
@@ -517,14 +517,14 @@ static int dt2801_dio_insn_config(struct comedi_device 
*dev,
 }
 
 /*
-   options:
-   [0] - i/o base
-   [1] - unused
-   [2] - a/d 0=differential, 1=single-ended
-   [3] - a/d range 0=[-10,10], 1=[0,10]
-   [4] - dac0 range 0=[-10,10], 1=[-5,5], 2=[-2.5,2.5] 3=[0,10], 4=[0,5]
-   [5] - dac1 range 0=[-10,10], 1=[-5,5], 2=[-2.5,2.5] 3=[0,10], 4=[0,5]
-*/
+ *  options:
+ * [0] - i/o base
+ * [1] - unused
+ * [2] - a/d 0=differential, 1=single-ended
+ * [3] - a/d range 0=[-10,10], 1=[0,10]
+ * [4] - dac0 range 0=[-10,10], 1=[-5,5], 2=[-2.5,2.5] 3=[0,10], 4=[0,5]
+ * [5] - dac1 range 0=[-10,10], 1=[-5,5], 2=[-2.5,2.5] 3=[0,10], 4=[0,5]
+ */
 static int dt2801_attach(struct comedi_device *dev, struct comedi_devconfig 
*it)
 {
const struct dt2801_board *board;
-- 
1.9.1

[PATCH 6/6] Staging: comedi: Fix CHECK:Avoid CamelCase issue in daqboard2000.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the daqboard2000.c file that fixes up a
issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/daqboard2000.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index a536a15..edd91a1 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -116,12 +116,12 @@
 #define DAQBOARD2000_SUBSYSTEM_IDS40x0004  /* Daqboard/2000 - 4 Dacs */
 
 /* Initialization bits for the Serial EEPROM Control Register */
-#define DAQBOARD2000_SECRProgPinHi  0x8001767e
-#define DAQBOARD2000_SECRProgPinLo  0x8000767e
-#define DAQBOARD2000_SECRLocalBusHi 0xc000767e
-#define DAQBOARD2000_SECRLocalBusLo 0x8000767e
-#define DAQBOARD2000_SECRReloadHi   0xa000767e
-#define DAQBOARD2000_SECRReloadLo   0x8000767e
+#define DAQBOARD2000_SECRPROGPINHI  0x8001767e
+#define DAQBOARD2000_SECRPROGPINLO  0x8000767e
+#define DAQBOARD2000_SECRLOCALBUSHI 0xc000767e
+#define DAQBOARD2000_SECRLOCALBUSLO 0x8000767e
+#define DAQBOARD2000_SECRRELOADHI   0xa000767e
+#define DAQBOARD2000_SECRRELOADLO   0x8000767e
 
 /* SECR status bits */
 #define DAQBOARD2000_EEPROM_PRESENT 0x1000
-- 
1.9.1

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

[Mark Brown]

On Mon, May 16, 2016 at 12:08:31PM +1000, Stephen Rothwell wrote:
> Hi Mark,
> 
> After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:

Sorry, dropped this patch.


signature.asc
Description: PGP signature

Re: [RFC 1/3] dt-bindings: drm/mediatek: Add display binding for Mediatek SoC MT2701

[YT Shen]

Hi Yingjoe,

On Thu, 2016-05-12 at 22:59 +0800, Yingjoe Chen wrote:
> On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote:
> > From: YT Shen 
> > 
> > Add device tree binding documentation for the display subsystem in
> > Mediatek SoC MT2701
> > 
> > Signed-off-by: YT Shen 
> > ---
> >  .../bindings/display/mediatek/mediatek,disp.txt|1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > index db6e77e..53b3cc3 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > @@ -40,6 +40,7 @@ Required properties (all function blocks):
> > "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
> > "mediatek,-disp-mutex" - display mutex
> > "mediatek,-disp-od"- overdrive
> > +   "mediatek,-disp-bls"   - backlight
> >  - reg: Physical base address and length of the function block register 
> > space
> >  - interrupts: The interrupt signal from the function block (required, 
> > except for
> >merge and split function blocks).
> 
> 
> Hi,
> 
> This one is in conflict with "Support Mediatek Soc MT2701 disp pwm"
> series Weiqing sent last week, which add disp-bls support to display pwm
> driver.
> 
> Joe.C

Thanks, I will remove this part and update it in the next version.

Regards,
yt.shen

Re: [PATCH] x86/boot: Refuse to build with data relocations

[Ingo Molnar]

* H. Peter Anvin  wrote:

> On 05/12/16 15:54, Kees Cook wrote:
> >>
> >> It would be far better to warn on the *type* of relocations rather than in 
> >> which section they feel.
> > 
> > I'm open to specific changes. What's the best way to detect what you want 
> > here?
> > 
> 
> Use readelf -r and look for inappropriate relocation types (which are
> basically the same ones that we should have to muck with for the main
> kernel in relocs.c.)

I suspect initially we are good if we don't allow any relocations in 
arch/x86/boot/compressed/vmlinux:

 fomalhaut:~/linux/linux> readelf -r arch/x86/boot/compressed/vmlinux | grep -q 
 'There are no relocations in this file' ; echo $?
 0

versus a regular object file with lots of relocations:

 fomalhaut:~/linux/linux> readelf -r arch/x86/built-in.o | grep -q 'There are 
no relocations in this file' ; echo $?
 1

I.e. the relevant portion of Kees's patch would do something like:

quiet_cmd_check_data_rel = DATAREL $@
define cmd_check_data_rel
   for obj in $(filter %.o,$^); do \
   readelf -r $$obj | grep -qF 'There are no relocations in this 
file' && exit 0 || { \
   echo "error: $$obj has data relocations!" >&2; \
   exit 1; \
   } \
   done
endef

(totally untested)

Agreed?

Thanks,

Ingo

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning added missing 'int' in 'unsigned'.

[Ian Abbott]

On 15/05/16 20:45, Amit Ghadge wrote:

Signed-off-by: Amit Ghadge 
---
  drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c 
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index e9e4313..802f51e 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -643,7 +643,7 @@ static int daqp_ao_insn_write(struct comedi_device *dev,
outb(0, dev->iobase + DAQP_AUX_REG);

for (i = 0; i > insn->n; i++) {
-   unsigned val = data[i];
+   unsigned int val = data[i];
int ret;

/* D/A transfer rate is about 8ms */



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: [PATCH 5/6] Staging: comedi: Fix WARNING issue in dt2801.c

[Ian Abbott]

On 16/05/16 11:18, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the dt2801.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/dt2801.c | 84 -
  1 file changed, 42 insertions(+), 42 deletions(-)



Patch series should start at 1, not 5.  In this case, your two patches 
PATCH 5/6 and PATCH 6/6 look independent from one another, and could be 
posted as individual patches, not in a series.



diff --git a/drivers/staging/comedi/drivers/dt2801.c 
b/drivers/staging/comedi/drivers/dt2801.c
index 6c7b4d2..51f2f75 100644
--- a/drivers/staging/comedi/drivers/dt2801.c
+++ b/drivers/staging/comedi/drivers/dt2801.c
@@ -3,31 +3,30 @@
   * Device Driver for DataTranslation DT2801
   *
   */
-/*
-Driver: dt2801
-Description: Data Translation DT2801 series and DT01-EZ
-Author: ds
-Status: works
-Devices: [Data Translation] DT2801 (dt2801), DT2801-A, DT2801/5716A,
-  DT2805, DT2805/5716A, DT2808, DT2818, DT2809, DT01-EZ
-
-This driver can autoprobe the type of board.
-
-Configuration options:
-  [0] - I/O port base address
-  [1] - unused
-  [2] - A/D reference 0=differential, 1=single-ended
-  [3] - A/D range
- 0 = [-10, 10]
- 1 = [0,10]
-  [4] - D/A 0 range
- 0 = [-10, 10]
- 1 = [-5,5]
- 2 = [-2.5,2.5]
- 3 = [0,10]
- 4 = [0,5]
-  [5] - D/A 1 range (same choices)
-*/
+ /* Driver: dt2801
+  * Description: Data Translation DT2801 series and DT01-EZ
+  * Author: ds
+  * Status: works
+  * Devices: [Data Translation] DT2801 (dt2801), DT2801-A, DT2801/5716A,
+  * DT2805, DT2805/5716A, DT2808, DT2818, DT2809, DT01-EZ
+
+  * This driver can autoprobe the type of board.
+
+  * Configuration options:
+  * [0] - I/O port base address
+  * [1] - unused
+  * [2] - A/D reference 0=differential, 1=single-ended
+  * [3] - A/D range
+  *  0 = [-10, 10]
+  *  1 = [0,10]
+  * [4] - D/A 0 range
+  *  0 = [-10, 10]
+  *  1 = [-5,5]
+  *  2 = [-2.5,2.5]
+  *  3 = [0,10]
+  *  4 = [0,5]
+  * [5] - D/A 1 range (same choices)
+  */


Our usual block comment style is:

/*
 * blah blah
 * blah blah
 */

i.e. the opening '/*' is on a line by itself.  If you could fix up the 
block comments to conform to that style, that would be great!


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

[RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list 
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,
which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang 
---
 fs/f2fs/gc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);
 
if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;
 
/* if encrypted inode, let's go phase 3 */
-- 
1.9.1

[tip:efi/urgent] x86/efi: Fix 7th argument to efi_call()

[tip-bot for Alex Thorlton]

Commit-ID:  bea23c757f66d91dac8fdadd94da0cba6b0b66bc
Gitweb: http://git.kernel.org/tip/bea23c757f66d91dac8fdadd94da0cba6b0b66bc
Author: Alex Thorlton 
AuthorDate: Fri, 13 May 2016 21:34:42 +0100
Committer:  Ingo Molnar 
CommitDate: Mon, 16 May 2016 12:38:06 +0200

x86/efi: Fix 7th argument to efi_call()

The efi_call() assembly code has a slight error that prevents us from
using arguments 7 and higher, which will be passed in on the stack:

mov (%rsp), %rax
mov 8(%rax), %rax
...
mov %rax, 40(%rsp)

This code goes and grabs the return address for the current stack frame,
and puts it on the stack, next to the 5th argument for the EFI runtime
call.  Considering the fact that having the return address in that
position on the stack makes no sense, I'm guessing that the intent of
this code was actually to grab an argument off the stack frame for this
call and place it into the frame for the next one.

The small change to that offset (i.e. 8(%rax) to 16(%rax)) ensures that
we grab the 7th argument off the stack, and pass it as the 6th argument
to the EFI runtime function that we're about to call.  This change gets
our EFI runtime calls that need to pass more than 6 arguments working
again.  SGI/UV is the only platform that passes more than 6 arguments.

Signed-off-by: Alex Thorlton 
[ Updated changelog. ]
Signed-off-by: Matt Fleming 
Cc: 
Cc: Alexander Shishkin 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Dimitri Sivanich 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Mike Travis 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1463171682-13881-2-git-send-email-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
---
 arch/x86/platform/efi/efi_stub_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_stub_64.S 
b/arch/x86/platform/efi/efi_stub_64.S
index 92723ae..62938ff 100644
--- a/arch/x86/platform/efi/efi_stub_64.S
+++ b/arch/x86/platform/efi/efi_stub_64.S
@@ -43,7 +43,7 @@ ENTRY(efi_call)
FRAME_BEGIN
SAVE_XMM
mov (%rsp), %rax
-   mov 8(%rax), %rax
+   mov 16(%rax), %rax
subq $48, %rsp
mov %r9, 32(%rsp)
mov %rax, 40(%rsp)