Re: extcon: max14577: Use common error handling code in max14577_muic_set_path()

[SF Markus Elfring]

> I think that there is any benefit of this patch.
> Also, as I commented, it make the code more complicated.

We have got different software development opinions about
the shown change possibilities then.

Regards,
Markus

Re: extcon: max14577: Use common error handling code in max14577_muic_set_path()

[SF Markus Elfring]

> I think that there is any benefit of this patch.
> Also, as I commented, it make the code more complicated.

We have got different software development opinions about
the shown change possibilities then.

Regards,
Markus

Re: [PATCH 1/2] extcon: max14577: Use common error handling code in max14577_muic_set_path()

[Chanwoo Choi]

On 2017년 10월 23일 14:45, SF Markus Elfring wrote:
>> As you commented, this patch might remove the redundant error message.
>> But, it makes the code more complicated in side of readability.
> 
> Do you try to avoid duplicated code any more in other circumstances?

I usually used the goto statement on following cases:
- Return the value (error number if fail or 0 if success)
- Do free or unregister or remove operations when error happen.

I think that there is any benefit of this patch.
Also, as I commented, it make the code more complicated.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 1/2] extcon: max14577: Use common error handling code in max14577_muic_set_path()

[Chanwoo Choi]

On 2017년 10월 23일 14:45, SF Markus Elfring wrote:
>> As you commented, this patch might remove the redundant error message.
>> But, it makes the code more complicated in side of readability.
> 
> Do you try to avoid duplicated code any more in other circumstances?

I usually used the goto statement on following cases:
- Return the value (error number if fail or 0 if success)
- Do free or unregister or remove operations when error happen.

I think that there is any benefit of this patch.
Also, as I commented, it make the code more complicated.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: devfreq/exynos-bus: Use common error handling code in exynos_bus_target()

[SF Markus Elfring]

> As I already commented on your other patch related to extcon-max14577,
> this patch might remove the redundant error message.

I hope that more software improvements can be achieved in this design direction.


> But, it makes the code more complicated in side of readability. I prefer 
> existing code.

I prefer to avoid duplicated code a bit more.

Regards,
Markus

Re: devfreq/exynos-bus: Use common error handling code in exynos_bus_target()

[SF Markus Elfring]

> As I already commented on your other patch related to extcon-max14577,
> this patch might remove the redundant error message.

I hope that more software improvements can be achieved in this design direction.


> But, it makes the code more complicated in side of readability. I prefer 
> existing code.

I prefer to avoid duplicated code a bit more.

Regards,
Markus

Re: [PATCH 1/2] extcon: max14577: Use common error handling code in max14577_muic_set_path()

[SF Markus Elfring]

> As you commented, this patch might remove the redundant error message.
> But, it makes the code more complicated in side of readability.

Do you try to avoid duplicated code any more in other circumstances?

Regards,
Markus

Re: [PATCH 1/2] extcon: max14577: Use common error handling code in max14577_muic_set_path()

[SF Markus Elfring]

> As you commented, this patch might remove the redundant error message.
> But, it makes the code more complicated in side of readability.

Do you try to avoid duplicated code any more in other circumstances?

Regards,
Markus

Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration

[Kishon Vijay Abraham I]

Hi,

On Wednesday 11 October 2017 10:15 PM, Robin Murphy wrote:
> On 11/10/17 09:00, Kishon Vijay Abraham I wrote:
>> pci-epc-core.c invokes of_dma_configure in order to configure
>> the coherent_dma_mask/dma_mask of endpoint function device. This is
>> required for dma_alloc_coherent to succeed in pci function driver
>> (pci-epf-test.c). However after
>> commit 723288836628bc1c08 ("of: restrict DMA configuration"),
>> of_dma_configure doesn't configure the coherent_dma_mask/dma_mask
>> of endpoint function device (since it doesn't have dma-ranges
>> property), resulting in dma_alloc_coherent in pci endpoint function
>> driver to to fail. Fix it by making sure of_dma_configure configures
>> coherent_dma_mask/dma_mask irrespective of whether the node has
>> dma-ranges property or not.
> 
> Frankly, what the endpoint stuff is doing looks wrong anyway. As I
> understand it, the endpoint functions aren't real devices, just a
> partitioning of resources - the only piece of hardware actually doing
> DMA is the EPC itself, which should already have been configured
> appropriately as a platform device.

EPF devices use EPC devices which in turn use the actual platform device for
configuring the hardware. IMO the devices in one layer shouldn't have to
explicitly use devices in another layer other than using clearly defined API's.
Here platform_device is the bottom later, above which is epc_device and on top
is epf_device.

The idea is just by doing the initial setup in the framework, the epf driver be
able to use APIs like dma_alloc_coherent using it's own *device* rather than
the EPC's "device".
> 
> It seems to me that the EPF BAR allocations should just be using the EPC
> device directly, rather than trying to pretend the EPFs are distinct DMA
> masters.
> 
> Furthermore, now that I've looked:
> 
>>  dma_addr_t phys_addr;
> 
> please no :(
> 
> (I can easily think of more than one system with an EP-capable DWC PCIe
> block integrated behind an IOMMU)

hmm.. haven't used IOMMU but won't setting up parent-child relationship between
EPC and EPF help in the case of IOMMU?

Thanks
Kishon

Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration

[Kishon Vijay Abraham I]

Hi,

On Wednesday 11 October 2017 10:15 PM, Robin Murphy wrote:
> On 11/10/17 09:00, Kishon Vijay Abraham I wrote:
>> pci-epc-core.c invokes of_dma_configure in order to configure
>> the coherent_dma_mask/dma_mask of endpoint function device. This is
>> required for dma_alloc_coherent to succeed in pci function driver
>> (pci-epf-test.c). However after
>> commit 723288836628bc1c08 ("of: restrict DMA configuration"),
>> of_dma_configure doesn't configure the coherent_dma_mask/dma_mask
>> of endpoint function device (since it doesn't have dma-ranges
>> property), resulting in dma_alloc_coherent in pci endpoint function
>> driver to to fail. Fix it by making sure of_dma_configure configures
>> coherent_dma_mask/dma_mask irrespective of whether the node has
>> dma-ranges property or not.
> 
> Frankly, what the endpoint stuff is doing looks wrong anyway. As I
> understand it, the endpoint functions aren't real devices, just a
> partitioning of resources - the only piece of hardware actually doing
> DMA is the EPC itself, which should already have been configured
> appropriately as a platform device.

EPF devices use EPC devices which in turn use the actual platform device for
configuring the hardware. IMO the devices in one layer shouldn't have to
explicitly use devices in another layer other than using clearly defined API's.
Here platform_device is the bottom later, above which is epc_device and on top
is epf_device.

The idea is just by doing the initial setup in the framework, the epf driver be
able to use APIs like dma_alloc_coherent using it's own *device* rather than
the EPC's "device".
> 
> It seems to me that the EPF BAR allocations should just be using the EPC
> device directly, rather than trying to pretend the EPFs are distinct DMA
> masters.
> 
> Furthermore, now that I've looked:
> 
>>  dma_addr_t phys_addr;
> 
> please no :(
> 
> (I can easily think of more than one system with an EP-capable DWC PCIe
> block integrated behind an IOMMU)

hmm.. haven't used IOMMU but won't setting up parent-child relationship between
EPC and EPF help in the case of IOMMU?

Thanks
Kishon

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

[Chanwoo Choi]

Dear all,

I got the reviews from all maintainers related to this patch.
So, I make the immutable branch on extcon.git and then send
the pull request in order to prevent the possible merge conflict.

Best Regards,
Chanwoo Choi
Samsung Electronics


The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
ib-extcon-v4.15

for you to fetch changes up to 176aa36012135d172394a928a03fb03dfecd83f9:

  extcon: Split out extcon header file for consumer and provider device 
(2017-10-23 14:07:58 +0900)


Chanwoo Choi (1):
  extcon: Split out extcon header file for consumer and provider device

 drivers/extcon/extcon-adc-jack.c  |   2 +-
 drivers/extcon/extcon-arizona.c   |   2 +-
 drivers/extcon/extcon-axp288.c|   2 +-
 drivers/extcon/extcon-gpio.c  |   2 +-
 drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
 drivers/extcon/extcon-intel-int3496.c |   2 +-
 drivers/extcon/extcon-max14577.c  |   2 +-
 drivers/extcon/extcon-max3355.c   |   2 +-
 drivers/extcon/extcon-max77693.c  |   2 +-
 drivers/extcon/extcon-max77843.c  |   2 +-
 drivers/extcon/extcon-max8997.c   |   2 +-
 drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
 drivers/extcon/extcon-rt8973a.c   |   2 +-
 drivers/extcon/extcon-sm5502.c|   2 +-
 drivers/extcon/extcon-usb-gpio.c  |   2 +-
 drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
 drivers/extcon/extcon.h   |   2 +-
 drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
 drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
 drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
 drivers/power/supply/qcom_smbb.c  |   2 +-
 drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
 drivers/usb/phy/phy-tahvo.c   |   2 +-
 include/linux/extcon-provider.h   | 142 ++
 include/linux/extcon.h| 109 +---
 include/linux/mfd/palmas.h|   2 +-
 27 files changed, 172 insertions(+), 129 deletions(-)
 create mode 100644 include/linux/extcon-provider.h


On 2017년 10월 23일 14:05, Kishon Vijay Abraham I wrote:
> 
> 
> On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
>> Gently Ping.
>>
>> Dear Kishon,
>>
>> Could you please review this patch for 'drivers/phy/*'?
> 
> sorry for the delay.. here it is
> 
> Acked-by: Kishon Vijay Abraham I 
>>
>> Regards,
>> Chanwoo Choi
>>
>> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>>> Dear Kishon,
>>>
>>> Could you please review this patch?
>>> After that, I'll make the immutable brand and then send the pull request
>>> for power_supply, mfd, phy, usb and extcon framework.
>>>
>>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
 The extcon has two type of extcon devices as following.
 - 'extcon provider deivce' adds new extcon device and detect the
state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
 - 'extcon consumer device' gets the change state/properties
from extcon provider device.
 Prior to that, include/linux/extcon.h contains all exported API for
 both provider and consumer device driver. To clarify the meaning of
 header file and to remove the wrong use-case on consumer device,
 this patch separates into extcon.h and extcon-provider.h.

 [Description for include/linux/{extcon.h|extcon-provider.h}]
 - extcon.h includes the extcon API and data structure for extcon consumer
   device driver. This header file contains the following APIs:
   : Register/unregister the notifier to catch the change of extcon device
   : Get the extcon device instance
   : Get the extcon device name
   : Get the state of each external connector
   : Get the property value of each external connector
   : Get the property capability of each external connector

 - extcon-provider.h includes the extcon API and data structure for extcon
   provider device driver. This header file contains the following APIs:
   : Include 'include/linux/extcon.h'
   : Allocate the memory for extcon device instance
   : Register/unregister extcon device
   : Set the state of each external connector
   : Set the property value of each external connector
   : Set the property capability of each external connector

 Cc: Felipe Balbi 
 Cc: Kishon Vijay Abraham I 
 Cc: Greg Kroah-Hartman 
 Acked-by: Sebastian Reichel 

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

[Chanwoo Choi]

Dear all,

I got the reviews from all maintainers related to this patch.
So, I make the immutable branch on extcon.git and then send
the pull request in order to prevent the possible merge conflict.

Best Regards,
Chanwoo Choi
Samsung Electronics


The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
ib-extcon-v4.15

for you to fetch changes up to 176aa36012135d172394a928a03fb03dfecd83f9:

  extcon: Split out extcon header file for consumer and provider device 
(2017-10-23 14:07:58 +0900)


Chanwoo Choi (1):
  extcon: Split out extcon header file for consumer and provider device

 drivers/extcon/extcon-adc-jack.c  |   2 +-
 drivers/extcon/extcon-arizona.c   |   2 +-
 drivers/extcon/extcon-axp288.c|   2 +-
 drivers/extcon/extcon-gpio.c  |   2 +-
 drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
 drivers/extcon/extcon-intel-int3496.c |   2 +-
 drivers/extcon/extcon-max14577.c  |   2 +-
 drivers/extcon/extcon-max3355.c   |   2 +-
 drivers/extcon/extcon-max77693.c  |   2 +-
 drivers/extcon/extcon-max77843.c  |   2 +-
 drivers/extcon/extcon-max8997.c   |   2 +-
 drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
 drivers/extcon/extcon-rt8973a.c   |   2 +-
 drivers/extcon/extcon-sm5502.c|   2 +-
 drivers/extcon/extcon-usb-gpio.c  |   2 +-
 drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
 drivers/extcon/extcon.h   |   2 +-
 drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
 drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
 drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
 drivers/power/supply/qcom_smbb.c  |   2 +-
 drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
 drivers/usb/phy/phy-tahvo.c   |   2 +-
 include/linux/extcon-provider.h   | 142 ++
 include/linux/extcon.h| 109 +---
 include/linux/mfd/palmas.h|   2 +-
 27 files changed, 172 insertions(+), 129 deletions(-)
 create mode 100644 include/linux/extcon-provider.h


On 2017년 10월 23일 14:05, Kishon Vijay Abraham I wrote:
> 
> 
> On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
>> Gently Ping.
>>
>> Dear Kishon,
>>
>> Could you please review this patch for 'drivers/phy/*'?
> 
> sorry for the delay.. here it is
> 
> Acked-by: Kishon Vijay Abraham I 
>>
>> Regards,
>> Chanwoo Choi
>>
>> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>>> Dear Kishon,
>>>
>>> Could you please review this patch?
>>> After that, I'll make the immutable brand and then send the pull request
>>> for power_supply, mfd, phy, usb and extcon framework.
>>>
>>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
 The extcon has two type of extcon devices as following.
 - 'extcon provider deivce' adds new extcon device and detect the
state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
 - 'extcon consumer device' gets the change state/properties
from extcon provider device.
 Prior to that, include/linux/extcon.h contains all exported API for
 both provider and consumer device driver. To clarify the meaning of
 header file and to remove the wrong use-case on consumer device,
 this patch separates into extcon.h and extcon-provider.h.

 [Description for include/linux/{extcon.h|extcon-provider.h}]
 - extcon.h includes the extcon API and data structure for extcon consumer
   device driver. This header file contains the following APIs:
   : Register/unregister the notifier to catch the change of extcon device
   : Get the extcon device instance
   : Get the extcon device name
   : Get the state of each external connector
   : Get the property value of each external connector
   : Get the property capability of each external connector

 - extcon-provider.h includes the extcon API and data structure for extcon
   provider device driver. This header file contains the following APIs:
   : Include 'include/linux/extcon.h'
   : Allocate the memory for extcon device instance
   : Register/unregister extcon device
   : Set the state of each external connector
   : Set the property value of each external connector
   : Set the property capability of each external connector

 Cc: Felipe Balbi 
 Cc: Kishon Vijay Abraham I 
 Cc: Greg Kroah-Hartman 
 Acked-by: Sebastian Reichel 
 Acked-by: Chen-Yu Tsai 
 Acked-by: Charles Keepax 
 Acked-by: Lee Jones 
 

Re: [PATCH v4 1/1] pwm: mediatek: add MT2712/MT7622 support

[Zhi Mao]

Hi Thierry,

Just have a ping on this issue.

Regards,
Zhi

On Wed, 2017-09-20 at 16:48 +0800, Zhi Mao wrote:
> Hi Thierry,
> 
> Just a gentle ping on this issue.
> Would you please have a review to this patch?
> 
> Regards,
> Zhi
> 
> 
> On Tue, 2017-08-22 at 10:09 +0800, Zhi Mao wrote:
> > Add support to MT2712 and MT7622.
> > Due to register offset address of pwm7 for MT2712 is not fixed 0x40,
> > add mtk_pwm_reg_offset array for pwm register offset.
> > 
> > Signed-off-by: Zhi Mao 
> > ---
> >  drivers/pwm/pwm-mediatek.c |   51 
> > 
> >  1 file changed, 42 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> > index 1d78ab1..ccd86e7 100644
> > --- a/drivers/pwm/pwm-mediatek.c
> > +++ b/drivers/pwm/pwm-mediatek.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -40,11 +41,19 @@ enum {
> > MTK_CLK_PWM3,
> > MTK_CLK_PWM4,
> > MTK_CLK_PWM5,
> > +   MTK_CLK_PWM6,
> > +   MTK_CLK_PWM7,
> > +   MTK_CLK_PWM8,
> > MTK_CLK_MAX,
> >  };
> >  
> > -static const char * const mtk_pwm_clk_name[] = {
> > -   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"
> > +static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
> > +   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6", "pwm7",
> > +   "pwm8"
> > +};
> > +
> > +struct mtk_pwm_platform_data {
> > +   unsigned int num_pwms;
> >  };
> >  
> >  /**
> > @@ -57,6 +66,11 @@ struct mtk_pwm_chip {
> > struct pwm_chip chip;
> > void __iomem *regs;
> > struct clk *clks[MTK_CLK_MAX];
> > +   const struct mtk_pwm_platform_data *data;
> > +};
> > +
> > +static const unsigned int mtk_pwm_reg_offset[] = {
> > +   0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
> >  };
> >  
> >  static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
> > @@ -103,14 +117,14 @@ static void mtk_pwm_clk_disable(struct pwm_chip 
> > *chip, struct pwm_device *pwm)
> >  static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int 
> > num,
> > unsigned int offset)
> >  {
> > -   return readl(chip->regs + 0x10 + (num * 0x40) + offset);
> > +   return readl(chip->regs + mtk_pwm_reg_offset[num] + offset);
> >  }
> >  
> >  static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
> >   unsigned int num, unsigned int offset,
> >   u32 value)
> >  {
> > -   writel(value, chip->regs + 0x10 + (num * 0x40) + offset);
> > +   writel(value, chip->regs + mtk_pwm_reg_offset[num] + offset);
> >  }
> >  
> >  static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > @@ -194,15 +208,20 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > if (!pc)
> > return -ENOMEM;
> >  
> > +   pc->data = of_device_get_match_data(>dev);
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pc->regs = devm_ioremap_resource(>dev, res);
> > if (IS_ERR(pc->regs))
> > return PTR_ERR(pc->regs);
> >  
> > -   for (i = 0; i < MTK_CLK_MAX; i++) {
> > +   for (i = 0; i < pc->data->num_pwms + 2; i++) {
> > pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
> > -   if (IS_ERR(pc->clks[i]))
> > +   if (IS_ERR(pc->clks[i])) {
> > +   dev_err(>dev, "clock: %s fail: %ld\n",
> > +   mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
> > return PTR_ERR(pc->clks[i]);
> > +   }
> > }
> >  
> > platform_set_drvdata(pdev, pc);
> > @@ -210,7 +229,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > pc->chip.dev = >dev;
> > pc->chip.ops = _pwm_ops;
> > pc->chip.base = -1;
> > -   pc->chip.npwm = 5;
> > +   pc->chip.npwm = pc->data->num_pwms;
> >  
> > ret = pwmchip_add(>chip);
> > if (ret < 0) {
> > @@ -228,9 +247,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
> > return pwmchip_remove(>chip);
> >  }
> >  
> > +static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> > +   .num_pwms = 8,
> > +};
> > +
> > +static const struct mtk_pwm_platform_data mt7622_pwm_data = {
> > +   .num_pwms = 6,
> > +};
> > +
> > +static const struct mtk_pwm_platform_data mt7623_pwm_data = {
> > +   .num_pwms = 5,
> > +};
> > +
> >  static const struct of_device_id mtk_pwm_of_match[] = {
> > -   { .compatible = "mediatek,mt7623-pwm" },
> > -   { }
> > +   { .compatible = "mediatek,mt2712-pwm", .data = _pwm_data },
> > +   { .compatible = "mediatek,mt7622-pwm", .data = _pwm_data },
> > +   { .compatible = "mediatek,mt7623-pwm", .data = _pwm_data },
> > +   { },
> >  };
> >  MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
> >  
> 

Re: [PATCH v4 1/1] pwm: mediatek: add MT2712/MT7622 support

[Zhi Mao]

Hi Thierry,

Just have a ping on this issue.

Regards,
Zhi

On Wed, 2017-09-20 at 16:48 +0800, Zhi Mao wrote:
> Hi Thierry,
> 
> Just a gentle ping on this issue.
> Would you please have a review to this patch?
> 
> Regards,
> Zhi
> 
> 
> On Tue, 2017-08-22 at 10:09 +0800, Zhi Mao wrote:
> > Add support to MT2712 and MT7622.
> > Due to register offset address of pwm7 for MT2712 is not fixed 0x40,
> > add mtk_pwm_reg_offset array for pwm register offset.
> > 
> > Signed-off-by: Zhi Mao 
> > ---
> >  drivers/pwm/pwm-mediatek.c |   51 
> > 
> >  1 file changed, 42 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> > index 1d78ab1..ccd86e7 100644
> > --- a/drivers/pwm/pwm-mediatek.c
> > +++ b/drivers/pwm/pwm-mediatek.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -40,11 +41,19 @@ enum {
> > MTK_CLK_PWM3,
> > MTK_CLK_PWM4,
> > MTK_CLK_PWM5,
> > +   MTK_CLK_PWM6,
> > +   MTK_CLK_PWM7,
> > +   MTK_CLK_PWM8,
> > MTK_CLK_MAX,
> >  };
> >  
> > -static const char * const mtk_pwm_clk_name[] = {
> > -   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"
> > +static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
> > +   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6", "pwm7",
> > +   "pwm8"
> > +};
> > +
> > +struct mtk_pwm_platform_data {
> > +   unsigned int num_pwms;
> >  };
> >  
> >  /**
> > @@ -57,6 +66,11 @@ struct mtk_pwm_chip {
> > struct pwm_chip chip;
> > void __iomem *regs;
> > struct clk *clks[MTK_CLK_MAX];
> > +   const struct mtk_pwm_platform_data *data;
> > +};
> > +
> > +static const unsigned int mtk_pwm_reg_offset[] = {
> > +   0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
> >  };
> >  
> >  static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
> > @@ -103,14 +117,14 @@ static void mtk_pwm_clk_disable(struct pwm_chip 
> > *chip, struct pwm_device *pwm)
> >  static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int 
> > num,
> > unsigned int offset)
> >  {
> > -   return readl(chip->regs + 0x10 + (num * 0x40) + offset);
> > +   return readl(chip->regs + mtk_pwm_reg_offset[num] + offset);
> >  }
> >  
> >  static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
> >   unsigned int num, unsigned int offset,
> >   u32 value)
> >  {
> > -   writel(value, chip->regs + 0x10 + (num * 0x40) + offset);
> > +   writel(value, chip->regs + mtk_pwm_reg_offset[num] + offset);
> >  }
> >  
> >  static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > @@ -194,15 +208,20 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > if (!pc)
> > return -ENOMEM;
> >  
> > +   pc->data = of_device_get_match_data(>dev);
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pc->regs = devm_ioremap_resource(>dev, res);
> > if (IS_ERR(pc->regs))
> > return PTR_ERR(pc->regs);
> >  
> > -   for (i = 0; i < MTK_CLK_MAX; i++) {
> > +   for (i = 0; i < pc->data->num_pwms + 2; i++) {
> > pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
> > -   if (IS_ERR(pc->clks[i]))
> > +   if (IS_ERR(pc->clks[i])) {
> > +   dev_err(>dev, "clock: %s fail: %ld\n",
> > +   mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
> > return PTR_ERR(pc->clks[i]);
> > +   }
> > }
> >  
> > platform_set_drvdata(pdev, pc);
> > @@ -210,7 +229,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > pc->chip.dev = >dev;
> > pc->chip.ops = _pwm_ops;
> > pc->chip.base = -1;
> > -   pc->chip.npwm = 5;
> > +   pc->chip.npwm = pc->data->num_pwms;
> >  
> > ret = pwmchip_add(>chip);
> > if (ret < 0) {
> > @@ -228,9 +247,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
> > return pwmchip_remove(>chip);
> >  }
> >  
> > +static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> > +   .num_pwms = 8,
> > +};
> > +
> > +static const struct mtk_pwm_platform_data mt7622_pwm_data = {
> > +   .num_pwms = 6,
> > +};
> > +
> > +static const struct mtk_pwm_platform_data mt7623_pwm_data = {
> > +   .num_pwms = 5,
> > +};
> > +
> >  static const struct of_device_id mtk_pwm_of_match[] = {
> > -   { .compatible = "mediatek,mt7623-pwm" },
> > -   { }
> > +   { .compatible = "mediatek,mt2712-pwm", .data = _pwm_data },
> > +   { .compatible = "mediatek,mt7622-pwm", .data = _pwm_data },
> > +   { .compatible = "mediatek,mt7623-pwm", .data = _pwm_data },
> > +   { },
> >  };
> >  MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
> >  
> 

Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS

[Nitin Gupta]

On Sun, Oct 22, 2017 at 8:10 PM, Minchan Kim  wrote:
> On Fri, Oct 20, 2017 at 10:59:31PM +0300, Kirill A. Shutemov wrote:
>> With boot-time switching between paging mode we will have variable
>> MAX_PHYSMEM_BITS.
>>
>> Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y
>> configuration to define zsmalloc data structures.
>>
>> The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case.
>> It also suits well to handle PAE special case.
>>
>> Signed-off-by: Kirill A. Shutemov 
>> Cc: Minchan Kim 
>> Cc: Nitin Gupta 
>> Cc: Sergey Senozhatsky 
> Acked-by: Minchan Kim 
>
> Nitin:
>
> I think this patch works and it would be best for Kirill to be able to do.
> So if you have better idea to clean it up, let's make it as another patch
> regardless of this patch series.
>


I was looking into dynamically allocating size_class array to avoid that
compile error, but yes, that can be done in a future patch. So, for this patch:

Reviewed-by: Nitin Gupta 

Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS

[Nitin Gupta]

On Sun, Oct 22, 2017 at 8:10 PM, Minchan Kim  wrote:
> On Fri, Oct 20, 2017 at 10:59:31PM +0300, Kirill A. Shutemov wrote:
>> With boot-time switching between paging mode we will have variable
>> MAX_PHYSMEM_BITS.
>>
>> Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y
>> configuration to define zsmalloc data structures.
>>
>> The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case.
>> It also suits well to handle PAE special case.
>>
>> Signed-off-by: Kirill A. Shutemov 
>> Cc: Minchan Kim 
>> Cc: Nitin Gupta 
>> Cc: Sergey Senozhatsky 
> Acked-by: Minchan Kim 
>
> Nitin:
>
> I think this patch works and it would be best for Kirill to be able to do.
> So if you have better idea to clean it up, let's make it as another patch
> regardless of this patch series.
>


I was looking into dynamically allocating size_class array to avoid that
compile error, but yes, that can be done in a future patch. So, for this patch:

Reviewed-by: Nitin Gupta 

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

[Joonsoo Kim]

On Fri, Oct 20, 2017 at 10:17:00AM +0200, Michal Hocko wrote:
> On Fri 20-10-17 15:22:14, Xishi Qiu wrote:
> > On 2017/10/20 10:13, Joonsoo Kim wrote:
> > 
> > > On Thu, Oct 19, 2017 at 02:21:18PM +0200, Michal Hocko wrote:
> [...]
> > >> >From 8cbd811d741f5dd93d1b21bb3ef94482a4d0bd32 Mon Sep 17 00:00:00 2001
> > >> From: Michal Hocko 
> > >> Date: Thu, 19 Oct 2017 14:14:02 +0200
> > >> Subject: [PATCH] mm: distinguish CMA and MOVABLE isolation in
> > >>  has_unmovable_pages
> > >>
> > >> Joonsoo has noticed that "mm: drop migrate type checks from
> > >> has_unmovable_pages" would break CMA allocator because it relies on
> > >> has_unmovable_pages returning false even for CMA pageblocks which in
> > >> fact don't have to be movable:
> > >> alloc_contig_range
> > >>   start_isolate_page_range
> > >> set_migratetype_isolate
> > >>   has_unmovable_pages
> > >>
> > >> This is a result of the code sharing between CMA and memory hotplug
> > >> while each one has a different idea of what has_unmovable_pages should
> > >> return. This is unfortunate but fixing it properly would require a lot
> > >> of code duplication.
> > >>
> > >> Fix the issue by introducing the requested migrate type argument
> > >> and special case MIGRATE_CMA case where CMA page blocks are handled
> > >> properly. This will work for memory hotplug because it requires
> > >> MIGRATE_MOVABLE.
> > > 
> > > Unfortunately, alloc_contig_range() can be called with
> > > MIGRATE_MOVABLE so this patch cannot perfectly fix the problem.
> > > 
> > > I did a more thinking and found that it's strange to check if there is
> > > unmovable page in the pageblock during the set_migratetype_isolate().
> > > set_migratetype_isolate() should be just for setting the migratetype
> > > of the pageblock. Checking other things should be done by another
> > > place, for example, before calling the start_isolate_page_range() in
> > > __offline_pages().
> > > 
> > > Thanks.
> > > 
> > 
> > Hi Joonsoo,
> > 
> > How about add a flag to skip or not has_unmovable_pages() in 
> > set_migratetype_isolate()?
> > Something like the skip_hwpoisoned_pages.
> 
> I believe this is what Joonsoo was proposing actually. I cannot say I

Yes, I initially suggested this idea but change my mind. Now, I think
that problem is not in has_unmovable_pages() but in
set_migratetype_isolate(). So different solution is needed. See my other
reply to Michal.

Thanks.

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

[Joonsoo Kim]

On Fri, Oct 20, 2017 at 10:17:00AM +0200, Michal Hocko wrote:
> On Fri 20-10-17 15:22:14, Xishi Qiu wrote:
> > On 2017/10/20 10:13, Joonsoo Kim wrote:
> > 
> > > On Thu, Oct 19, 2017 at 02:21:18PM +0200, Michal Hocko wrote:
> [...]
> > >> >From 8cbd811d741f5dd93d1b21bb3ef94482a4d0bd32 Mon Sep 17 00:00:00 2001
> > >> From: Michal Hocko 
> > >> Date: Thu, 19 Oct 2017 14:14:02 +0200
> > >> Subject: [PATCH] mm: distinguish CMA and MOVABLE isolation in
> > >>  has_unmovable_pages
> > >>
> > >> Joonsoo has noticed that "mm: drop migrate type checks from
> > >> has_unmovable_pages" would break CMA allocator because it relies on
> > >> has_unmovable_pages returning false even for CMA pageblocks which in
> > >> fact don't have to be movable:
> > >> alloc_contig_range
> > >>   start_isolate_page_range
> > >> set_migratetype_isolate
> > >>   has_unmovable_pages
> > >>
> > >> This is a result of the code sharing between CMA and memory hotplug
> > >> while each one has a different idea of what has_unmovable_pages should
> > >> return. This is unfortunate but fixing it properly would require a lot
> > >> of code duplication.
> > >>
> > >> Fix the issue by introducing the requested migrate type argument
> > >> and special case MIGRATE_CMA case where CMA page blocks are handled
> > >> properly. This will work for memory hotplug because it requires
> > >> MIGRATE_MOVABLE.
> > > 
> > > Unfortunately, alloc_contig_range() can be called with
> > > MIGRATE_MOVABLE so this patch cannot perfectly fix the problem.
> > > 
> > > I did a more thinking and found that it's strange to check if there is
> > > unmovable page in the pageblock during the set_migratetype_isolate().
> > > set_migratetype_isolate() should be just for setting the migratetype
> > > of the pageblock. Checking other things should be done by another
> > > place, for example, before calling the start_isolate_page_range() in
> > > __offline_pages().
> > > 
> > > Thanks.
> > > 
> > 
> > Hi Joonsoo,
> > 
> > How about add a flag to skip or not has_unmovable_pages() in 
> > set_migratetype_isolate()?
> > Something like the skip_hwpoisoned_pages.
> 
> I believe this is what Joonsoo was proposing actually. I cannot say I

Yes, I initially suggested this idea but change my mind. Now, I think
that problem is not in has_unmovable_pages() but in
set_migratetype_isolate(). So different solution is needed. See my other
reply to Michal.

Thanks.

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

[Joonsoo Kim]

On Fri, Oct 20, 2017 at 09:02:20AM +0200, Michal Hocko wrote:
> On Fri 20-10-17 15:50:14, Joonsoo Kim wrote:
> > On Fri, Oct 20, 2017 at 07:59:22AM +0200, Michal Hocko wrote:
> > > On Fri 20-10-17 11:13:29, Joonsoo Kim wrote:
> > > > On Thu, Oct 19, 2017 at 02:21:18PM +0200, Michal Hocko wrote:
> > > > > On Thu 19-10-17 10:20:41, Michal Hocko wrote:
> > > > > > On Thu 19-10-17 16:33:56, Joonsoo Kim wrote:
> > > > > > > On Thu, Oct 19, 2017 at 09:15:03AM +0200, Michal Hocko wrote:
> > > > > > > > On Thu 19-10-17 11:51:11, Joonsoo Kim wrote:
> > > > > > [...]
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > This patch will break the CMA user. As you mentioned, CMA 
> > > > > > > > > allocation
> > > > > > > > > itself isn't migrateable. So, after a single page is 
> > > > > > > > > allocated through
> > > > > > > > > CMA allocation, has_unmovable_pages() will return true for 
> > > > > > > > > this
> > > > > > > > > pageblock. Then, futher CMA allocation request to this 
> > > > > > > > > pageblock will
> > > > > > > > > fail because it requires isolating the pageblock.
> > > > > > > > 
> > > > > > > > Hmm, does this mean that the CMA allocation path depends on
> > > > > > > > has_unmovable_pages to return false here even though the memory 
> > > > > > > > is not
> > > > > > > > movable? This sounds really strange to me and kind of abuse of 
> > > > > > > > this
> > > > > > > 
> > > > > > > Your understanding is correct. Perhaps, abuse or wrong function 
> > > > > > > name.
> > > > > > >
> > > > > > > > function. Which path is that? Can we do the migrate type test 
> > > > > > > > theres?
> > > > > > > 
> > > > > > > alloc_contig_range() -> start_isolate_page_range() ->
> > > > > > > set_migratetype_isolate() -> has_unmovable_pages()
> > > > > > 
> > > > > > I see. It seems that the CMA and memory hotplug have a very 
> > > > > > different
> > > > > > view on what should happen during isolation.
> > > > > >  
> > > > > > > We can add one argument, 'XXX' to set_migratetype_isolate() and 
> > > > > > > change
> > > > > > > it to check migrate type rather than has_unmovable_pages() if 
> > > > > > > 'XXX' is
> > > > > > > specified.
> > > > > > 
> > > > > > Can we use the migratetype argument and do the special thing for
> > > > > > MIGRATE_CMA? Like the following diff?
> > > > > 
> > > > > And with the full changelog.
> > > > > ---
> > > > > >From 8cbd811d741f5dd93d1b21bb3ef94482a4d0bd32 Mon Sep 17 00:00:00 
> > > > > >2001
> > > > > From: Michal Hocko 
> > > > > Date: Thu, 19 Oct 2017 14:14:02 +0200
> > > > > Subject: [PATCH] mm: distinguish CMA and MOVABLE isolation in
> > > > >  has_unmovable_pages
> > > > > 
> > > > > Joonsoo has noticed that "mm: drop migrate type checks from
> > > > > has_unmovable_pages" would break CMA allocator because it relies on
> > > > > has_unmovable_pages returning false even for CMA pageblocks which in
> > > > > fact don't have to be movable:
> > > > > alloc_contig_range
> > > > >   start_isolate_page_range
> > > > > set_migratetype_isolate
> > > > >   has_unmovable_pages
> > > > > 
> > > > > This is a result of the code sharing between CMA and memory hotplug
> > > > > while each one has a different idea of what has_unmovable_pages should
> > > > > return. This is unfortunate but fixing it properly would require a lot
> > > > > of code duplication.
> > > > > 
> > > > > Fix the issue by introducing the requested migrate type argument
> > > > > and special case MIGRATE_CMA case where CMA page blocks are handled
> > > > > properly. This will work for memory hotplug because it requires
> > > > > MIGRATE_MOVABLE.
> > > > 
> > > > Unfortunately, alloc_contig_range() can be called with
> > > > MIGRATE_MOVABLE so this patch cannot perfectly fix the problem.
> > > 
> > > Yes, alloc_contig_range can be called with MIGRATE_MOVABLE but my
> > > understanding is that only CMA allocator really depends on this weird
> > > semantic and that does MIGRATE_CMA unconditionally.
> > 
> > alloc_contig_range() could be called for partial pages in the
> > pageblock. With your patch, this case also fails unnecessarilly if the
> > other pages in the pageblock is pinned.
> 
> Is this really the case for GB pages? Do we really want to mess those

No, but, as I mentioned already, this API can be called with less
pages. I know that there is no user with less pages at this moment but
I cannot see any point to reduce this API's capability.

> with CMA blocks and make those blocks basically unusable because GB
> pages are rarely (if at all migrateable)?
> 
> > Until now, there is no user calling alloc_contig_range() with partial
> > pages except CMA allocator but API could support it.
> 
> I disagree. If this is a CMA thing it should stay that way. The semantic
> is quite confusing already, please let's not make it even worse.

It is already used by other component.

I'm not sure what is the confusing semantic you mentioned. I think
that set_migratetype_isolate() has 

Re: [PATCH v6 1/6] perf report: properly handle branch count in match_chain

[Namhyung Kim]

Hi Arnaldo and Milian,

On Fri, Oct 20, 2017 at 10:39:35AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 20, 2017 at 01:38:23PM +0200, Milian Wolff escreveu:
> > On Freitag, 20. Oktober 2017 12:21:35 CEST Milian Wolff wrote:
> > > On Donnerstag, 19. Oktober 2017 17:01:08 CEST Namhyung Kim wrote:
> > > > Hi Andi,
> > > > 
> > > > On Thu, Oct 19, 2017 at 06:55:19AM -0700, Andi Kleen wrote:
> > > > > On Thu, Oct 19, 2017 at 12:59:14PM +0200, Milian Wolff wrote:
> > > > > > On Donnerstag, 19. Oktober 2017 00:41:04 CEST Andi Kleen wrote:
> > > > > > > Milian Wolff  writes:
> > > > > > > > +static enum match_result match_address_dso(struct dso 
> > > > > > > > *left_dso,
> > > > > > > > u64
> > > > > > > > left_ip, + struct dso 
> > > > > > > > *right_dso, u64 right_ip)
> > > > > > > > +{
> > > > > > > > +   if (left_dso == right_dso && left_ip == right_ip)
> > > > > > > > +   return MATCH_EQ;
> > > > > > > > +   else if (left_ip < right_ip)
> > > > > > > > +   return MATCH_LT;
> > > > > > > > +   else
> > > > > > > > +   return MATCH_GT;
> > > > > > > > +}
> > > > > > > 
> > > > > > > So why does only the first case check the dso? Does it not matter
> > > > > > > for the others?
> > > > > > > 
> > > > > > > Either should be checked by none or by all.
> > > > > > 
> > > > > > I don't see why it should be checked. It is only required to prevent
> > > > > > two
> > > > > > addresses to be considered equal while they are not. So only the one
> > > > > > check is required, otherwise we return either LT or GT.
> > > > > 
> > > > > When the comparison is always in the same process (which I think
> > > > > is not the case) just checking the addresses is sufficient. If they 
> > > > > are
> > > > > not then you always need to check the DSO and only compare inside the
> > > > > same DSO.
> > > > 
> > > > As far as I know, the node->ip is a relative address (inside a DSO).
> > > > So it should compare the dso as well even in the same process.
> > > 
> > > Sorry guys, I seem to be slow at understanding your review comments.
> > > 
> > > match_address_dso should impose a sort order on two relative addresses. 
> > > The
> > > order should ensure that relative addresses in a different DSO are not
> > > considered equal. But if the DSOs are different, it doesn't matter whether
> > > we return LT or GT - or?
> > > 
> > > Put differently, how would you write this function to take care of the DSO
> > > in the other two branches? I.e. what to return if the DSOs are different -
> > > a MATCH_ERROR?
> > 
> > Thinking a bit more about this. Are you guys maybe hinting at my 
> > implementation breaking the strict ordering rules (is that the right 
> > word?). 
> > I.e. a < b && b > a iff a == b ? Potentially my implementation would break 
> > this assumption when the relative IPs are the same, but the DSO is 
> > different.
> > 
> > So is this what you want:
> > 
> > +static enum match_result match_address_dso(struct dso *left_dso, u64
> >  left_ip, + struct dso *right_dso, 
> > u64 
> > right_ip)
> >  +{
> >  +   if (left_dso == right_dso && left_ip == right_ip)
> >  +   return MATCH_EQ;
> >  +   else if (left_dso < right_dso || left_ip < right_ip)
> >  +   return MATCH_LT;
> >  +   else
> >  +   return MATCH_GT;
> >  +}

How about

if (left_dso != right_dso)
return left_dso < right_dso ? MATCH_LT : MATCH_GT;
else if (left_ip != right_ip)
return left_ip < right_ip ? MATCH_LT : MATCH_GT;
else
return MATCH_EQ;

?


> 
> Why not do all in terms of absolute addresses? Comparing relative
> addresses seems nonsensical anyway.

???

It needs to compare symbols of callchains from different address
spaces (i.e. tasks) too.  We do the same when comparing symbols of
samples - please see sort__sym_cmp().


> Perhaps something like the patch
> below, and note that cnode->ip and node->ip already already are absolute
> addresses.

Only if it couldn't find a map?

Thanks,
Namhyung


> 
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 35a920f09503..1ac3f4a5afab 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -671,8 +671,6 @@ static enum match_result match_chain(struct 
> callchain_cursor_node *node,
>  {
>   struct symbol *sym = node->sym;
>   u64 left, right;
> - struct dso *left_dso = NULL;
> - struct dso *right_dso = NULL;
>  
>   if (callchain_param.key == CCKEY_SRCLINE) {
>   enum match_result match = match_chain_strings(cnode->srcline,
> @@ -698,16 +696,14 @@ static enum match_result match_chain(struct 
> callchain_cursor_node *node,
>   return match_chain_strings(cnode->ms.sym->name,
>  node->sym->name);

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

[Joonsoo Kim]

On Fri, Oct 20, 2017 at 09:02:20AM +0200, Michal Hocko wrote:
> On Fri 20-10-17 15:50:14, Joonsoo Kim wrote:
> > On Fri, Oct 20, 2017 at 07:59:22AM +0200, Michal Hocko wrote:
> > > On Fri 20-10-17 11:13:29, Joonsoo Kim wrote:
> > > > On Thu, Oct 19, 2017 at 02:21:18PM +0200, Michal Hocko wrote:
> > > > > On Thu 19-10-17 10:20:41, Michal Hocko wrote:
> > > > > > On Thu 19-10-17 16:33:56, Joonsoo Kim wrote:
> > > > > > > On Thu, Oct 19, 2017 at 09:15:03AM +0200, Michal Hocko wrote:
> > > > > > > > On Thu 19-10-17 11:51:11, Joonsoo Kim wrote:
> > > > > > [...]
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > This patch will break the CMA user. As you mentioned, CMA 
> > > > > > > > > allocation
> > > > > > > > > itself isn't migrateable. So, after a single page is 
> > > > > > > > > allocated through
> > > > > > > > > CMA allocation, has_unmovable_pages() will return true for 
> > > > > > > > > this
> > > > > > > > > pageblock. Then, futher CMA allocation request to this 
> > > > > > > > > pageblock will
> > > > > > > > > fail because it requires isolating the pageblock.
> > > > > > > > 
> > > > > > > > Hmm, does this mean that the CMA allocation path depends on
> > > > > > > > has_unmovable_pages to return false here even though the memory 
> > > > > > > > is not
> > > > > > > > movable? This sounds really strange to me and kind of abuse of 
> > > > > > > > this
> > > > > > > 
> > > > > > > Your understanding is correct. Perhaps, abuse or wrong function 
> > > > > > > name.
> > > > > > >
> > > > > > > > function. Which path is that? Can we do the migrate type test 
> > > > > > > > theres?
> > > > > > > 
> > > > > > > alloc_contig_range() -> start_isolate_page_range() ->
> > > > > > > set_migratetype_isolate() -> has_unmovable_pages()
> > > > > > 
> > > > > > I see. It seems that the CMA and memory hotplug have a very 
> > > > > > different
> > > > > > view on what should happen during isolation.
> > > > > >  
> > > > > > > We can add one argument, 'XXX' to set_migratetype_isolate() and 
> > > > > > > change
> > > > > > > it to check migrate type rather than has_unmovable_pages() if 
> > > > > > > 'XXX' is
> > > > > > > specified.
> > > > > > 
> > > > > > Can we use the migratetype argument and do the special thing for
> > > > > > MIGRATE_CMA? Like the following diff?
> > > > > 
> > > > > And with the full changelog.
> > > > > ---
> > > > > >From 8cbd811d741f5dd93d1b21bb3ef94482a4d0bd32 Mon Sep 17 00:00:00 
> > > > > >2001
> > > > > From: Michal Hocko 
> > > > > Date: Thu, 19 Oct 2017 14:14:02 +0200
> > > > > Subject: [PATCH] mm: distinguish CMA and MOVABLE isolation in
> > > > >  has_unmovable_pages
> > > > > 
> > > > > Joonsoo has noticed that "mm: drop migrate type checks from
> > > > > has_unmovable_pages" would break CMA allocator because it relies on
> > > > > has_unmovable_pages returning false even for CMA pageblocks which in
> > > > > fact don't have to be movable:
> > > > > alloc_contig_range
> > > > >   start_isolate_page_range
> > > > > set_migratetype_isolate
> > > > >   has_unmovable_pages
> > > > > 
> > > > > This is a result of the code sharing between CMA and memory hotplug
> > > > > while each one has a different idea of what has_unmovable_pages should
> > > > > return. This is unfortunate but fixing it properly would require a lot
> > > > > of code duplication.
> > > > > 
> > > > > Fix the issue by introducing the requested migrate type argument
> > > > > and special case MIGRATE_CMA case where CMA page blocks are handled
> > > > > properly. This will work for memory hotplug because it requires
> > > > > MIGRATE_MOVABLE.
> > > > 
> > > > Unfortunately, alloc_contig_range() can be called with
> > > > MIGRATE_MOVABLE so this patch cannot perfectly fix the problem.
> > > 
> > > Yes, alloc_contig_range can be called with MIGRATE_MOVABLE but my
> > > understanding is that only CMA allocator really depends on this weird
> > > semantic and that does MIGRATE_CMA unconditionally.
> > 
> > alloc_contig_range() could be called for partial pages in the
> > pageblock. With your patch, this case also fails unnecessarilly if the
> > other pages in the pageblock is pinned.
> 
> Is this really the case for GB pages? Do we really want to mess those

No, but, as I mentioned already, this API can be called with less
pages. I know that there is no user with less pages at this moment but
I cannot see any point to reduce this API's capability.

> with CMA blocks and make those blocks basically unusable because GB
> pages are rarely (if at all migrateable)?
> 
> > Until now, there is no user calling alloc_contig_range() with partial
> > pages except CMA allocator but API could support it.
> 
> I disagree. If this is a CMA thing it should stay that way. The semantic
> is quite confusing already, please let's not make it even worse.

It is already used by other component.

I'm not sure what is the confusing semantic you mentioned. I think
that set_migratetype_isolate() has confusing semantic 

Re: [PATCH v6 1/6] perf report: properly handle branch count in match_chain

[Namhyung Kim]

Hi Arnaldo and Milian,

On Fri, Oct 20, 2017 at 10:39:35AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 20, 2017 at 01:38:23PM +0200, Milian Wolff escreveu:
> > On Freitag, 20. Oktober 2017 12:21:35 CEST Milian Wolff wrote:
> > > On Donnerstag, 19. Oktober 2017 17:01:08 CEST Namhyung Kim wrote:
> > > > Hi Andi,
> > > > 
> > > > On Thu, Oct 19, 2017 at 06:55:19AM -0700, Andi Kleen wrote:
> > > > > On Thu, Oct 19, 2017 at 12:59:14PM +0200, Milian Wolff wrote:
> > > > > > On Donnerstag, 19. Oktober 2017 00:41:04 CEST Andi Kleen wrote:
> > > > > > > Milian Wolff  writes:
> > > > > > > > +static enum match_result match_address_dso(struct dso 
> > > > > > > > *left_dso,
> > > > > > > > u64
> > > > > > > > left_ip, + struct dso 
> > > > > > > > *right_dso, u64 right_ip)
> > > > > > > > +{
> > > > > > > > +   if (left_dso == right_dso && left_ip == right_ip)
> > > > > > > > +   return MATCH_EQ;
> > > > > > > > +   else if (left_ip < right_ip)
> > > > > > > > +   return MATCH_LT;
> > > > > > > > +   else
> > > > > > > > +   return MATCH_GT;
> > > > > > > > +}
> > > > > > > 
> > > > > > > So why does only the first case check the dso? Does it not matter
> > > > > > > for the others?
> > > > > > > 
> > > > > > > Either should be checked by none or by all.
> > > > > > 
> > > > > > I don't see why it should be checked. It is only required to prevent
> > > > > > two
> > > > > > addresses to be considered equal while they are not. So only the one
> > > > > > check is required, otherwise we return either LT or GT.
> > > > > 
> > > > > When the comparison is always in the same process (which I think
> > > > > is not the case) just checking the addresses is sufficient. If they 
> > > > > are
> > > > > not then you always need to check the DSO and only compare inside the
> > > > > same DSO.
> > > > 
> > > > As far as I know, the node->ip is a relative address (inside a DSO).
> > > > So it should compare the dso as well even in the same process.
> > > 
> > > Sorry guys, I seem to be slow at understanding your review comments.
> > > 
> > > match_address_dso should impose a sort order on two relative addresses. 
> > > The
> > > order should ensure that relative addresses in a different DSO are not
> > > considered equal. But if the DSOs are different, it doesn't matter whether
> > > we return LT or GT - or?
> > > 
> > > Put differently, how would you write this function to take care of the DSO
> > > in the other two branches? I.e. what to return if the DSOs are different -
> > > a MATCH_ERROR?
> > 
> > Thinking a bit more about this. Are you guys maybe hinting at my 
> > implementation breaking the strict ordering rules (is that the right 
> > word?). 
> > I.e. a < b && b > a iff a == b ? Potentially my implementation would break 
> > this assumption when the relative IPs are the same, but the DSO is 
> > different.
> > 
> > So is this what you want:
> > 
> > +static enum match_result match_address_dso(struct dso *left_dso, u64
> >  left_ip, + struct dso *right_dso, 
> > u64 
> > right_ip)
> >  +{
> >  +   if (left_dso == right_dso && left_ip == right_ip)
> >  +   return MATCH_EQ;
> >  +   else if (left_dso < right_dso || left_ip < right_ip)
> >  +   return MATCH_LT;
> >  +   else
> >  +   return MATCH_GT;
> >  +}

How about

if (left_dso != right_dso)
return left_dso < right_dso ? MATCH_LT : MATCH_GT;
else if (left_ip != right_ip)
return left_ip < right_ip ? MATCH_LT : MATCH_GT;
else
return MATCH_EQ;

?


> 
> Why not do all in terms of absolute addresses? Comparing relative
> addresses seems nonsensical anyway.

???

It needs to compare symbols of callchains from different address
spaces (i.e. tasks) too.  We do the same when comparing symbols of
samples - please see sort__sym_cmp().


> Perhaps something like the patch
> below, and note that cnode->ip and node->ip already already are absolute
> addresses.

Only if it couldn't find a map?

Thanks,
Namhyung


> 
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 35a920f09503..1ac3f4a5afab 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -671,8 +671,6 @@ static enum match_result match_chain(struct 
> callchain_cursor_node *node,
>  {
>   struct symbol *sym = node->sym;
>   u64 left, right;
> - struct dso *left_dso = NULL;
> - struct dso *right_dso = NULL;
>  
>   if (callchain_param.key == CCKEY_SRCLINE) {
>   enum match_result match = match_chain_strings(cnode->srcline,
> @@ -698,16 +696,14 @@ static enum match_result match_chain(struct 
> callchain_cursor_node *node,
>   return match_chain_strings(cnode->ms.sym->name,
>  node->sym->name);
>  
> - 

Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

[Martin Schwidefsky]

On Fri, 20 Oct 2017 18:29:33 +0200
Christoph Hellwig  wrote:

> On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
> > Yes, however it seems these drivers / platforms have been living with
> > the lack of struct page for a long time. So they either don't use DAX,
> > or they have a constrained use case that never triggers
> > get_user_pages(). If it is the latter then they could introduce a new
> > configuration option that bypasses the pfn_t_devmap() check in
> > bdev_dax_supported() and fix up the get_user_pages() paths to fail.
> > So, I'd like to understand how these drivers have been using DAX
> > support without struct page to see if we need a workaround or we can
> > go ahead delete this support. If the usage is limited to
> > execute-in-place perhaps we can do a constrained ->direct_access() for
> > just that case.  
> 
> For axonram I doubt anyone is using it any more - it was a very for
> the IBM Cell blades, which were produceѕ in a rather limited number.
> And Cell basically seems to be dead as far as I can tell.
> 
> For S/390 Martin might be able to help out what the status of xpram
> in general and DAX support in particular is.

The goes back to the time where DAX was called XIP. The initial design
point has been *not* to have struct pages for a large read-only memory
area. There is a block device driver for z/VM that maps a DCSS segment
somewhere in memore (no struct page!) with e.g. the complete /usr
filesystem. The xpram driver is a different beast and has nothing to
do with XIP/DAX.

Now, if any there are very few users of the dcssblk driver out there.
The idea to save a few megabyte for /usr never really took of.

We have to look at our get_user_pages() implementation to see how hard
it would be to make it fail if the target address is for an area without
struct pages.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

[Martin Schwidefsky]

On Fri, 20 Oct 2017 18:29:33 +0200
Christoph Hellwig  wrote:

> On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
> > Yes, however it seems these drivers / platforms have been living with
> > the lack of struct page for a long time. So they either don't use DAX,
> > or they have a constrained use case that never triggers
> > get_user_pages(). If it is the latter then they could introduce a new
> > configuration option that bypasses the pfn_t_devmap() check in
> > bdev_dax_supported() and fix up the get_user_pages() paths to fail.
> > So, I'd like to understand how these drivers have been using DAX
> > support without struct page to see if we need a workaround or we can
> > go ahead delete this support. If the usage is limited to
> > execute-in-place perhaps we can do a constrained ->direct_access() for
> > just that case.  
> 
> For axonram I doubt anyone is using it any more - it was a very for
> the IBM Cell blades, which were produceѕ in a rather limited number.
> And Cell basically seems to be dead as far as I can tell.
> 
> For S/390 Martin might be able to help out what the status of xpram
> in general and DAX support in particular is.

The goes back to the time where DAX was called XIP. The initial design
point has been *not* to have struct pages for a large read-only memory
area. There is a block device driver for z/VM that maps a DCSS segment
somewhere in memore (no struct page!) with e.g. the complete /usr
filesystem. The xpram driver is a different beast and has nothing to
do with XIP/DAX.

Now, if any there are very few users of the dcssblk driver out there.
The idea to save a few megabyte for /usr never really took of.

We have to look at our get_user_pages() implementation to see how hard
it would be to make it fail if the target address is for an area without
struct pages.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH v5] of: dynamic: fix memory leak related to properties of __of_node_dup

[Frank Rowand]

On 10/22/17 20:19, Lixin Wang wrote:
> If a node with no properties is dynamically added, then a property is
> dynamically added to the node, then the property is dynamically removed,
> the result will be node->properties == NULL and node->deadprops != NULL.
> 
> Add a separate function to release the properties in both lists.
> 
> Signed-off-by: Lixin Wang 
> ---
>  v4 -> v5:
>  * fix the bug in v4, that the prop->next should be saved before release
>the prop.
> 
>  drivers/of/dynamic.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index 301b6db..39d69d3 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -315,6 +315,18 @@ int of_detach_node(struct device_node *np)
>  }
>  EXPORT_SYMBOL_GPL(of_detach_node);
>  
> +static void property_list_free(struct property *prop_list)
> +{
> + struct property *prop, *next;
> +
> + for (prop = prop_list; prop != NULL; prop = next) {
> + next = prop->next;
> + kfree(prop->name);
> + kfree(prop->value);
> + kfree(prop);
> + }
> +}
> +
>  /**
>   * of_node_release() - release a dynamically allocated node
>   * @kref: kref element of the node to be released
> @@ -324,7 +336,6 @@ EXPORT_SYMBOL_GPL(of_detach_node);
>  void of_node_release(struct kobject *kobj)
>  {
>   struct device_node *node = kobj_to_device_node(kobj);
> - struct property *prop = node->properties;
>  
>   /* We should never be releasing nodes that haven't been detached. */
>   if (!of_node_check_flag(node, OF_DETACHED)) {
> @@ -335,18 +346,9 @@ void of_node_release(struct kobject *kobj)
>   if (!of_node_check_flag(node, OF_DYNAMIC))
>   return;
>  
> - while (prop) {
> - struct property *next = prop->next;
> - kfree(prop->name);
> - kfree(prop->value);
> - kfree(prop);
> - prop = next;
> + property_list_free(node->properties);
> + property_list_free(node->deadprops);
>  
> - if (!prop) {
> - prop = node->deadprops;
> - node->deadprops = NULL;
> - }
> - }
>   kfree(node->full_name);
>   kfree(node->data);
>   kfree(node);
> 

Hi Lixin,
 
My bad...  Thanks for the fix.

Reviewed-by: Frank Rowand 

Re: [PATCH v5] of: dynamic: fix memory leak related to properties of __of_node_dup

[Frank Rowand]

On 10/22/17 20:19, Lixin Wang wrote:
> If a node with no properties is dynamically added, then a property is
> dynamically added to the node, then the property is dynamically removed,
> the result will be node->properties == NULL and node->deadprops != NULL.
> 
> Add a separate function to release the properties in both lists.
> 
> Signed-off-by: Lixin Wang 
> ---
>  v4 -> v5:
>  * fix the bug in v4, that the prop->next should be saved before release
>the prop.
> 
>  drivers/of/dynamic.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index 301b6db..39d69d3 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -315,6 +315,18 @@ int of_detach_node(struct device_node *np)
>  }
>  EXPORT_SYMBOL_GPL(of_detach_node);
>  
> +static void property_list_free(struct property *prop_list)
> +{
> + struct property *prop, *next;
> +
> + for (prop = prop_list; prop != NULL; prop = next) {
> + next = prop->next;
> + kfree(prop->name);
> + kfree(prop->value);
> + kfree(prop);
> + }
> +}
> +
>  /**
>   * of_node_release() - release a dynamically allocated node
>   * @kref: kref element of the node to be released
> @@ -324,7 +336,6 @@ EXPORT_SYMBOL_GPL(of_detach_node);
>  void of_node_release(struct kobject *kobj)
>  {
>   struct device_node *node = kobj_to_device_node(kobj);
> - struct property *prop = node->properties;
>  
>   /* We should never be releasing nodes that haven't been detached. */
>   if (!of_node_check_flag(node, OF_DETACHED)) {
> @@ -335,18 +346,9 @@ void of_node_release(struct kobject *kobj)
>   if (!of_node_check_flag(node, OF_DYNAMIC))
>   return;
>  
> - while (prop) {
> - struct property *next = prop->next;
> - kfree(prop->name);
> - kfree(prop->value);
> - kfree(prop);
> - prop = next;
> + property_list_free(node->properties);
> + property_list_free(node->deadprops);
>  
> - if (!prop) {
> - prop = node->deadprops;
> - node->deadprops = NULL;
> - }
> - }
>   kfree(node->full_name);
>   kfree(node->data);
>   kfree(node);
> 

Hi Lixin,
 
My bad...  Thanks for the fix.

Reviewed-by: Frank Rowand 

Re: [PATCH] PM / QoS: Fix device resume latency PM QoS

[Alex Shi]

On 10/20/2017 07:27 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The special value of 0 for device resume latency PM QoS means
> "no restriction", but there are two problems with that.
> 
> First, device resume latency PM QoS requests with 0 as the
> value are always put in front of requests with positive
> values in the priority lists used internally by the PM QoS
> framework, causing 0 to be chosen as an effective constraint
> value.  However, that 0 is then interpreted as "no restriction"
> effectively overriding the other requests with specific
> restrictions which is incorrect.
> 
> Second, the users of device resume latency PM QoS have no
> way to specify that *any* resume latency at all should be
> avoided, which is an artificial limitation in general.
> 
> To address these issues, modify device resume latency PM QoS to
> use S32_MAX as the "no constraint" value and 0 as the "no
> latency at all" one and rework its users (the cpuidle menu
> governor, the genpd QoS governor and the runtime PM framework)
> to follow these changes.
> 
> Also add a special "n/a" value to the corresponding user space I/F
> to allow user space to indicate that it cannot accept any resume
> latencies at all for the given device.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323
> Signed-off-by: Rafael J. Wysocki 
> Reported-by: Reinette Chatre 


Acked-by: Alex Shi 

Re: [PATCH] PM / QoS: Fix device resume latency PM QoS

[Alex Shi]

On 10/20/2017 07:27 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The special value of 0 for device resume latency PM QoS means
> "no restriction", but there are two problems with that.
> 
> First, device resume latency PM QoS requests with 0 as the
> value are always put in front of requests with positive
> values in the priority lists used internally by the PM QoS
> framework, causing 0 to be chosen as an effective constraint
> value.  However, that 0 is then interpreted as "no restriction"
> effectively overriding the other requests with specific
> restrictions which is incorrect.
> 
> Second, the users of device resume latency PM QoS have no
> way to specify that *any* resume latency at all should be
> avoided, which is an artificial limitation in general.
> 
> To address these issues, modify device resume latency PM QoS to
> use S32_MAX as the "no constraint" value and 0 as the "no
> latency at all" one and rework its users (the cpuidle menu
> governor, the genpd QoS governor and the runtime PM framework)
> to follow these changes.
> 
> Also add a special "n/a" value to the corresponding user space I/F
> to allow user space to indicate that it cannot accept any resume
> latencies at all for the given device.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323
> Signed-off-by: Rafael J. Wysocki 
> Reported-by: Reinette Chatre 


Acked-by: Alex Shi 

RE: [PATCH v5 3/7] PM / devfreq: Use the available min/max frequency

[MyungJoo Ham]

> The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able
> to disable OPP as a cooling device. In result, both update_devfreq()
> and {min|max}_freq_show() have to consider the 'opp->available'
> status of each OPP.
> 
> So, this patch adds the 'scaling_{min|max}_freq' to struct devfreq
> in order to indicate the available mininum and maximum frequency
> by adjusting OPP interface such as dev_pm_opp_{disable|enable}().
> The 'scaling_{min|max}_freq' are used for on both update_devfreq()
> and {min|max}_freq_show().
> 
> Signed-off-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 
(along with the 2/7, revert commit)

> ---
>  drivers/devfreq/devfreq.c | 40 
>  include/linux/devfreq.h   |  4 
>  2 files changed, 36 insertions(+), 8 deletions(-)

RE: [PATCH v5 3/7] PM / devfreq: Use the available min/max frequency

[MyungJoo Ham]

> The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able
> to disable OPP as a cooling device. In result, both update_devfreq()
> and {min|max}_freq_show() have to consider the 'opp->available'
> status of each OPP.
> 
> So, this patch adds the 'scaling_{min|max}_freq' to struct devfreq
> in order to indicate the available mininum and maximum frequency
> by adjusting OPP interface such as dev_pm_opp_{disable|enable}().
> The 'scaling_{min|max}_freq' are used for on both update_devfreq()
> and {min|max}_freq_show().
> 
> Signed-off-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 
(along with the 2/7, revert commit)

> ---
>  drivers/devfreq/devfreq.c | 40 
>  include/linux/devfreq.h   |  4 
>  2 files changed, 36 insertions(+), 8 deletions(-)

Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()

[Dave Hansen]

On 10/22/2017 07:55 PM, Jarkko Sakkinen wrote:
> On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote:
>> I've always been curious, and the changelog and thread are curiously
>> oblique on this topic: what the heck does this driver use pipes *for*?
> For communication with the process hosting the launch enclave.

But, why pipes?  Why does the kernel have to be the one setting these
up?  Why is this communication necessary in the first place?

Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()

[Dave Hansen]

On 10/22/2017 07:55 PM, Jarkko Sakkinen wrote:
> On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote:
>> I've always been curious, and the changelog and thread are curiously
>> oblique on this topic: what the heck does this driver use pipes *for*?
> For communication with the process hosting the launch enclave.

But, why pipes?  Why does the kernel have to be the one setting these
up?  Why is this communication necessary in the first place?

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

[Kishon Vijay Abraham I]

On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
> Gently Ping.
> 
> Dear Kishon,
> 
> Could you please review this patch for 'drivers/phy/*'?

sorry for the delay.. here it is

Acked-by: Kishon Vijay Abraham I 
> 
> Regards,
> Chanwoo Choi
> 
> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>> Dear Kishon,
>>
>> Could you please review this patch?
>> After that, I'll make the immutable brand and then send the pull request
>> for power_supply, mfd, phy, usb and extcon framework.
>>
>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
>>> The extcon has two type of extcon devices as following.
>>> - 'extcon provider deivce' adds new extcon device and detect the
>>>state/properties of external connector. Also, it notifies the
>>>state/properties to the extcon consumer device.
>>> - 'extcon consumer device' gets the change state/properties
>>>from extcon provider device.
>>> Prior to that, include/linux/extcon.h contains all exported API for
>>> both provider and consumer device driver. To clarify the meaning of
>>> header file and to remove the wrong use-case on consumer device,
>>> this patch separates into extcon.h and extcon-provider.h.
>>>
>>> [Description for include/linux/{extcon.h|extcon-provider.h}]
>>> - extcon.h includes the extcon API and data structure for extcon consumer
>>>   device driver. This header file contains the following APIs:
>>>   : Register/unregister the notifier to catch the change of extcon device
>>>   : Get the extcon device instance
>>>   : Get the extcon device name
>>>   : Get the state of each external connector
>>>   : Get the property value of each external connector
>>>   : Get the property capability of each external connector
>>>
>>> - extcon-provider.h includes the extcon API and data structure for extcon
>>>   provider device driver. This header file contains the following APIs:
>>>   : Include 'include/linux/extcon.h'
>>>   : Allocate the memory for extcon device instance
>>>   : Register/unregister extcon device
>>>   : Set the state of each external connector
>>>   : Set the property value of each external connector
>>>   : Set the property capability of each external connector
>>>
>>> Cc: Felipe Balbi 
>>> Cc: Kishon Vijay Abraham I 
>>> Cc: Greg Kroah-Hartman 
>>> Acked-by: Sebastian Reichel 
>>> Acked-by: Chen-Yu Tsai 
>>> Acked-by: Charles Keepax 
>>> Acked-by: Lee Jones 
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>> Changes from v1:
>>> - Don't touch drivers/usb/renesas_usbhs/common.h.
>>> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
>>> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
>>> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
>>> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
>>>
>>>  drivers/extcon/extcon-adc-jack.c  |   2 +-
>>>  drivers/extcon/extcon-arizona.c   |   2 +-
>>>  drivers/extcon/extcon-axp288.c|   2 +-
>>>  drivers/extcon/extcon-gpio.c  |   2 +-
>>>  drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
>>>  drivers/extcon/extcon-intel-int3496.c |   2 +-
>>>  drivers/extcon/extcon-max14577.c  |   2 +-
>>>  drivers/extcon/extcon-max3355.c   |   2 +-
>>>  drivers/extcon/extcon-max77693.c  |   2 +-
>>>  drivers/extcon/extcon-max77843.c  |   2 +-
>>>  drivers/extcon/extcon-max8997.c   |   2 +-
>>>  drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
>>>  drivers/extcon/extcon-rt8973a.c   |   2 +-
>>>  drivers/extcon/extcon-sm5502.c|   2 +-
>>>  drivers/extcon/extcon-usb-gpio.c  |   2 +-
>>>  drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
>>>  drivers/extcon/extcon.h   |   2 +-
>>>  drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
>>>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
>>>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
>>>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
>>>  drivers/power/supply/qcom_smbb.c  |   2 +-
>>>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
>>>  drivers/usb/phy/phy-tahvo.c   |   2 +-
>>>  include/linux/extcon-provider.h   | 142 
>>> ++
>>>  include/linux/extcon.h| 109 +---
>>>  include/linux/mfd/palmas.h|   2 +-
>>>  27 files changed, 172 insertions(+), 129 deletions(-)
>>>  create mode 100644 include/linux/extcon-provider.h
>>>
>>> diff --git a/drivers/extcon/extcon-adc-jack.c 
>>> b/drivers/extcon/extcon-adc-jack.c
>>> index 6f6537ab0a79..3877d86c746a 100644
>>> --- a/drivers/extcon/extcon-adc-jack.c
>>> +++ b/drivers/extcon/extcon-adc-jack.c
>>> 

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

[Kishon Vijay Abraham I]

On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
> Gently Ping.
> 
> Dear Kishon,
> 
> Could you please review this patch for 'drivers/phy/*'?

sorry for the delay.. here it is

Acked-by: Kishon Vijay Abraham I 
> 
> Regards,
> Chanwoo Choi
> 
> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>> Dear Kishon,
>>
>> Could you please review this patch?
>> After that, I'll make the immutable brand and then send the pull request
>> for power_supply, mfd, phy, usb and extcon framework.
>>
>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
>>> The extcon has two type of extcon devices as following.
>>> - 'extcon provider deivce' adds new extcon device and detect the
>>>state/properties of external connector. Also, it notifies the
>>>state/properties to the extcon consumer device.
>>> - 'extcon consumer device' gets the change state/properties
>>>from extcon provider device.
>>> Prior to that, include/linux/extcon.h contains all exported API for
>>> both provider and consumer device driver. To clarify the meaning of
>>> header file and to remove the wrong use-case on consumer device,
>>> this patch separates into extcon.h and extcon-provider.h.
>>>
>>> [Description for include/linux/{extcon.h|extcon-provider.h}]
>>> - extcon.h includes the extcon API and data structure for extcon consumer
>>>   device driver. This header file contains the following APIs:
>>>   : Register/unregister the notifier to catch the change of extcon device
>>>   : Get the extcon device instance
>>>   : Get the extcon device name
>>>   : Get the state of each external connector
>>>   : Get the property value of each external connector
>>>   : Get the property capability of each external connector
>>>
>>> - extcon-provider.h includes the extcon API and data structure for extcon
>>>   provider device driver. This header file contains the following APIs:
>>>   : Include 'include/linux/extcon.h'
>>>   : Allocate the memory for extcon device instance
>>>   : Register/unregister extcon device
>>>   : Set the state of each external connector
>>>   : Set the property value of each external connector
>>>   : Set the property capability of each external connector
>>>
>>> Cc: Felipe Balbi 
>>> Cc: Kishon Vijay Abraham I 
>>> Cc: Greg Kroah-Hartman 
>>> Acked-by: Sebastian Reichel 
>>> Acked-by: Chen-Yu Tsai 
>>> Acked-by: Charles Keepax 
>>> Acked-by: Lee Jones 
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>> Changes from v1:
>>> - Don't touch drivers/usb/renesas_usbhs/common.h.
>>> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
>>> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
>>> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
>>> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
>>>
>>>  drivers/extcon/extcon-adc-jack.c  |   2 +-
>>>  drivers/extcon/extcon-arizona.c   |   2 +-
>>>  drivers/extcon/extcon-axp288.c|   2 +-
>>>  drivers/extcon/extcon-gpio.c  |   2 +-
>>>  drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
>>>  drivers/extcon/extcon-intel-int3496.c |   2 +-
>>>  drivers/extcon/extcon-max14577.c  |   2 +-
>>>  drivers/extcon/extcon-max3355.c   |   2 +-
>>>  drivers/extcon/extcon-max77693.c  |   2 +-
>>>  drivers/extcon/extcon-max77843.c  |   2 +-
>>>  drivers/extcon/extcon-max8997.c   |   2 +-
>>>  drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
>>>  drivers/extcon/extcon-rt8973a.c   |   2 +-
>>>  drivers/extcon/extcon-sm5502.c|   2 +-
>>>  drivers/extcon/extcon-usb-gpio.c  |   2 +-
>>>  drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
>>>  drivers/extcon/extcon.h   |   2 +-
>>>  drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
>>>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
>>>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
>>>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
>>>  drivers/power/supply/qcom_smbb.c  |   2 +-
>>>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
>>>  drivers/usb/phy/phy-tahvo.c   |   2 +-
>>>  include/linux/extcon-provider.h   | 142 
>>> ++
>>>  include/linux/extcon.h| 109 +---
>>>  include/linux/mfd/palmas.h|   2 +-
>>>  27 files changed, 172 insertions(+), 129 deletions(-)
>>>  create mode 100644 include/linux/extcon-provider.h
>>>
>>> diff --git a/drivers/extcon/extcon-adc-jack.c 
>>> b/drivers/extcon/extcon-adc-jack.c
>>> index 6f6537ab0a79..3877d86c746a 100644
>>> --- a/drivers/extcon/extcon-adc-jack.c
>>> +++ b/drivers/extcon/extcon-adc-jack.c
>>> @@ -26,7 +26,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#include 
>>> +#include 
>>>  
>>>  /**
>>>   * struct adc_jack_data - internal data for adc_jack device driver
>>> diff --git 

[PATCH] objtool: Refactor insn search in add_dead_ends()

[Kamalesh Babulal]

Move the search for instruction dead_end into helper function
__add_dead_ends(), instead of duplicating the search for unreachable
and reachable sections in add_dead_ends().

Cc: Ingo Molnar 
Signed-off-by: Kamalesh Babulal 
---
 tools/objtool/check.c | 108 +++---
 1 file changed, 50 insertions(+), 58 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index c0e26ad1fa7e..c82966b3ad96 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -303,36 +303,23 @@ static int decode_instructions(struct objtool_file *file)
return ret;
 }
 
-/*
- * Mark "ud2" instructions and manually annotated dead ends.
- */
-static int add_dead_ends(struct objtool_file *file)
+static int __add_dead_ends(struct objtool_file *file, struct section *sec,
+  bool unreachable_sec)
 {
-   struct section *sec;
-   struct rela *rela;
+   char warn_str[12] = "unreachable";
struct instruction *insn;
+   struct rela *rela;
bool found;
 
-   /*
-* By default, "ud2" is a dead end unless otherwise annotated, because
-* GCC 7 inserts it for certain divide-by-zero cases.
-*/
-   for_each_insn(file, insn)
-   if (insn->type == INSN_BUG)
-   insn->dead_end = true;
-
-   /*
-* Check for manually annotated dead ends.
-*/
-   sec = find_section_by_name(file->elf, ".rela.discard.unreachable");
-   if (!sec)
-   goto reachable;
+   if (!unreachable_sec)
+   strcpy(warn_str, "reachable");
 
list_for_each_entry(rela, >rela_list, list) {
if (rela->sym->type != STT_SECTION) {
-   WARN("unexpected relocation symbol type in %s", 
sec->name);
+   WARN("Unexpected relocation symbol type in %s", 
sec->name);
return -1;
}
+
insn = find_insn(file, rela->sym->sec, rela->addend);
if (insn)
insn = list_prev_entry(insn, list);
@@ -346,19 +333,54 @@ static int add_dead_ends(struct objtool_file *file)
}
 
if (!found) {
-   WARN("can't find unreachable insn at %s+0x%x",
-rela->sym->sec->name, rela->addend);
+   WARN("can't find %s insn at %s+0x%x",
+   warn_str, rela->sym->sec->name,
+   rela->addend);
return -1;
}
} else {
-   WARN("can't find unreachable insn at %s+0x%x",
-rela->sym->sec->name, rela->addend);
+   WARN("can't find %s insn at %s+0x%x",
+   warn_str, rela->sym->sec->name, rela->addend);
return -1;
}
 
-   insn->dead_end = true;
+   /*
+* reachable section's insn->dead_end are false.
+*/
+   insn->dead_end = unreachable_sec;
}
 
+   return 0;
+}
+
+/*
+ * Mark "ud2" instructions and manually annotated dead ends.
+ */
+static int add_dead_ends(struct objtool_file *file)
+{
+   struct section *sec;
+   struct instruction *insn;
+   int ret;
+
+   /*
+* By default, "ud2" is a dead end unless otherwise annotated, because
+* GCC 7 inserts it for certain divide-by-zero cases.
+*/
+   for_each_insn(file, insn)
+   if (insn->type == INSN_BUG)
+   insn->dead_end = true;
+
+   /*
+* Check for manually annotated dead ends.
+*/
+   sec = find_section_by_name(file->elf, ".rela.discard.unreachable");
+   if (!sec)
+   goto reachable;
+
+   ret = __add_dead_ends(file, sec, true);
+   if (ret == -1)
+   return ret;
+
 reachable:
/*
 * These manually annotated reachable checks are needed for GCC 4.4,
@@ -370,38 +392,8 @@ static int add_dead_ends(struct objtool_file *file)
if (!sec)
return 0;
 
-   list_for_each_entry(rela, >rela_list, list) {
-   if (rela->sym->type != STT_SECTION) {
-   WARN("unexpected relocation symbol type in %s", 
sec->name);
-   return -1;
-   }
-   insn = find_insn(file, rela->sym->sec, rela->addend);
-   if (insn)
-   insn = list_prev_entry(insn, list);
-   else if (rela->addend == rela->sym->sec->len) {
-   found = false;
-   list_for_each_entry_reverse(insn, >insn_list, 
list) {
-   if (insn->sec == rela->sym->sec) {
-   

[PATCH] objtool: Refactor insn search in add_dead_ends()

[Kamalesh Babulal]

Move the search for instruction dead_end into helper function
__add_dead_ends(), instead of duplicating the search for unreachable
and reachable sections in add_dead_ends().

Cc: Ingo Molnar 
Signed-off-by: Kamalesh Babulal 
---
 tools/objtool/check.c | 108 +++---
 1 file changed, 50 insertions(+), 58 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index c0e26ad1fa7e..c82966b3ad96 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -303,36 +303,23 @@ static int decode_instructions(struct objtool_file *file)
return ret;
 }
 
-/*
- * Mark "ud2" instructions and manually annotated dead ends.
- */
-static int add_dead_ends(struct objtool_file *file)
+static int __add_dead_ends(struct objtool_file *file, struct section *sec,
+  bool unreachable_sec)
 {
-   struct section *sec;
-   struct rela *rela;
+   char warn_str[12] = "unreachable";
struct instruction *insn;
+   struct rela *rela;
bool found;
 
-   /*
-* By default, "ud2" is a dead end unless otherwise annotated, because
-* GCC 7 inserts it for certain divide-by-zero cases.
-*/
-   for_each_insn(file, insn)
-   if (insn->type == INSN_BUG)
-   insn->dead_end = true;
-
-   /*
-* Check for manually annotated dead ends.
-*/
-   sec = find_section_by_name(file->elf, ".rela.discard.unreachable");
-   if (!sec)
-   goto reachable;
+   if (!unreachable_sec)
+   strcpy(warn_str, "reachable");
 
list_for_each_entry(rela, >rela_list, list) {
if (rela->sym->type != STT_SECTION) {
-   WARN("unexpected relocation symbol type in %s", 
sec->name);
+   WARN("Unexpected relocation symbol type in %s", 
sec->name);
return -1;
}
+
insn = find_insn(file, rela->sym->sec, rela->addend);
if (insn)
insn = list_prev_entry(insn, list);
@@ -346,19 +333,54 @@ static int add_dead_ends(struct objtool_file *file)
}
 
if (!found) {
-   WARN("can't find unreachable insn at %s+0x%x",
-rela->sym->sec->name, rela->addend);
+   WARN("can't find %s insn at %s+0x%x",
+   warn_str, rela->sym->sec->name,
+   rela->addend);
return -1;
}
} else {
-   WARN("can't find unreachable insn at %s+0x%x",
-rela->sym->sec->name, rela->addend);
+   WARN("can't find %s insn at %s+0x%x",
+   warn_str, rela->sym->sec->name, rela->addend);
return -1;
}
 
-   insn->dead_end = true;
+   /*
+* reachable section's insn->dead_end are false.
+*/
+   insn->dead_end = unreachable_sec;
}
 
+   return 0;
+}
+
+/*
+ * Mark "ud2" instructions and manually annotated dead ends.
+ */
+static int add_dead_ends(struct objtool_file *file)
+{
+   struct section *sec;
+   struct instruction *insn;
+   int ret;
+
+   /*
+* By default, "ud2" is a dead end unless otherwise annotated, because
+* GCC 7 inserts it for certain divide-by-zero cases.
+*/
+   for_each_insn(file, insn)
+   if (insn->type == INSN_BUG)
+   insn->dead_end = true;
+
+   /*
+* Check for manually annotated dead ends.
+*/
+   sec = find_section_by_name(file->elf, ".rela.discard.unreachable");
+   if (!sec)
+   goto reachable;
+
+   ret = __add_dead_ends(file, sec, true);
+   if (ret == -1)
+   return ret;
+
 reachable:
/*
 * These manually annotated reachable checks are needed for GCC 4.4,
@@ -370,38 +392,8 @@ static int add_dead_ends(struct objtool_file *file)
if (!sec)
return 0;
 
-   list_for_each_entry(rela, >rela_list, list) {
-   if (rela->sym->type != STT_SECTION) {
-   WARN("unexpected relocation symbol type in %s", 
sec->name);
-   return -1;
-   }
-   insn = find_insn(file, rela->sym->sec, rela->addend);
-   if (insn)
-   insn = list_prev_entry(insn, list);
-   else if (rela->addend == rela->sym->sec->len) {
-   found = false;
-   list_for_each_entry_reverse(insn, >insn_list, 
list) {
-   if (insn->sec == rela->sym->sec) {
-   found = true;
-

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

[Amit Kucheria]

On Thu, Oct 19, 2017 at 8:54 PM, Timur Tabi  wrote:
> On 10/18/17 3:57 PM, Amit Kucheria wrote:
>>
>> Enable panic and disk activity triggers to tie to LED activity
>
>
> Could you provide some explanation as to why we want this enabled for ARM64?
> I don't have a problem with the change itself, but I think patch
> descriptions for defconfig changes should include justifications.

Indeed.

The blurb should be modified as follows:

"Most development boards and devices have one or more LEDs. It is
useful during debugging if they can be wired to show different
behaviours such as disk or cpu activity or a load-average dependent
heartbeat. Enable panic and disk activity triggers so they can be tied
to LED activity during debugging as well."

If this blurb works, I'll send out another version.

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

[Amit Kucheria]

On Thu, Oct 19, 2017 at 8:54 PM, Timur Tabi  wrote:
> On 10/18/17 3:57 PM, Amit Kucheria wrote:
>>
>> Enable panic and disk activity triggers to tie to LED activity
>
>
> Could you provide some explanation as to why we want this enabled for ARM64?
> I don't have a problem with the change itself, but I think patch
> descriptions for defconfig changes should include justifications.

Indeed.

The blurb should be modified as follows:

"Most development boards and devices have one or more LEDs. It is
useful during debugging if they can be wired to show different
behaviours such as disk or cpu activity or a load-average dependent
heartbeat. Enable panic and disk activity triggers so they can be tied
to LED activity during debugging as well."

If this blurb works, I'll send out another version.

Re: PCIe legacy interrupts blocked on Intel Apollo Lake platforms

[Daniel Drake]

Hi,

On Wed, Oct 18, 2017 at 7:54 PM, Andy Shevchenko
 wrote:
> While Rafael is looking for a solution, can you in meantime gather the
> following on the affected hardware and share it via some resource on
> Internet?
>
> 1. % acpidump -o tables.dat # tables.dat is point of interest

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/acpi%2520tables

> 2. % lspci -vv -nk # output of the command

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/pci

> 3. % dmidecode # output of the command

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/dmidecode

> 4. % grep -H 15 /sys/bus/acpi/devices/*/status # output of the command

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/grep%2520-H%252015%2520acpi%2520status

> 5. % dmesg # when kernel command line has the 'ignore_loglevel
> initcall_debug' added

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/dmesg


All above files in a zip:
https://gist.github.com/dsd/ef9b9da4c634f57de89f917c43703272/archive/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8.zip

Please let me know how we can help further!

Daniel

Re: PCIe legacy interrupts blocked on Intel Apollo Lake platforms

[Daniel Drake]

Hi,

On Wed, Oct 18, 2017 at 7:54 PM, Andy Shevchenko
 wrote:
> While Rafael is looking for a solution, can you in meantime gather the
> following on the affected hardware and share it via some resource on
> Internet?
>
> 1. % acpidump -o tables.dat # tables.dat is point of interest

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/acpi%2520tables

> 2. % lspci -vv -nk # output of the command

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/pci

> 3. % dmidecode # output of the command

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/dmidecode

> 4. % grep -H 15 /sys/bus/acpi/devices/*/status # output of the command

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/grep%2520-H%252015%2520acpi%2520status

> 5. % dmesg # when kernel command line has the 'ignore_loglevel
> initcall_debug' added

https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/dmesg


All above files in a zip:
https://gist.github.com/dsd/ef9b9da4c634f57de89f917c43703272/archive/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8.zip

Please let me know how we can help further!

Daniel

Re: n900 in next-20170901

[Joonsoo Kim]

On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim  [171019 18:53]:
> > Oops... I made a mistak. Could you test with reverting commit
> > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call
> > save_secure_ram_context() for test") in that branch?
> > Without reverting it, it doesn't call 'smc' so it always cause a
> > hang.
> 
> Oops I should have noticed that one. Here you go with commit
> c977ee280378 reverted. Still not booting.

Still very thanks to you. :)

Okay. Could you test my updated branch? In there, I also disable
atomic_pool initialization and disable to remap the CMA area in order
to completely make any operation on CMA area as no-op.

And, it enables memblock_debug to check how memblock region is
allocated.

https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901

Thanks.

Re: n900 in next-20170901

[Joonsoo Kim]

On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim  [171019 18:53]:
> > Oops... I made a mistak. Could you test with reverting commit
> > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call
> > save_secure_ram_context() for test") in that branch?
> > Without reverting it, it doesn't call 'smc' so it always cause a
> > hang.
> 
> Oops I should have noticed that one. Here you go with commit
> c977ee280378 reverted. Still not booting.

Still very thanks to you. :)

Okay. Could you test my updated branch? In there, I also disable
atomic_pool initialization and disable to remap the CMA area in order
to completely make any operation on CMA area as no-op.

And, it enables memblock_debug to check how memblock region is
allocated.

https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901

Thanks.

Re: [PATCH 4/4] arm64: dts: hisilicon: hi3660-hikey960: Allow USR4 LED to notify kernel panic

[Amit Kucheria]

On Thu, Oct 19, 2017 at 5:30 PM, Guodong Xu  wrote:
>
>
> On Thu, Oct 19, 2017 at 4:57 AM, Amit Kucheria 
> wrote:
>>
>> Blink the LED on a kernel panic.
>>
>> Signed-off-by: Amit Kucheria 
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> index fd4705c..febbcb5 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> @@ -108,6 +108,7 @@
>> label = "user_led4";
>> /* gpio_190_user_led4 */
>> gpios = < 6 0>;
>> +   panic-indicator;
>
>
> Looks good to me.

Can I take that as an Ack? How about the Hikey960 patch?

>
>
>>
>> linux,default-trigger = "cpu0";
>> };
>>
>> --
>> 2.7.4
>>
>

Re: [PATCH 4/4] arm64: dts: hisilicon: hi3660-hikey960: Allow USR4 LED to notify kernel panic

[Amit Kucheria]

On Thu, Oct 19, 2017 at 5:30 PM, Guodong Xu  wrote:
>
>
> On Thu, Oct 19, 2017 at 4:57 AM, Amit Kucheria 
> wrote:
>>
>> Blink the LED on a kernel panic.
>>
>> Signed-off-by: Amit Kucheria 
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> index fd4705c..febbcb5 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> @@ -108,6 +108,7 @@
>> label = "user_led4";
>> /* gpio_190_user_led4 */
>> gpios = < 6 0>;
>> +   panic-indicator;
>
>
> Looks good to me.

Can I take that as an Ack? How about the Hikey960 patch?

>
>
>>
>> linux,default-trigger = "cpu0";
>> };
>>
>> --
>> 2.7.4
>>
>

Re: [PATCH] net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Fri, 20 Oct 2017 19:43:11 -0500

> Use BUG_ON instead of if condition followed by BUG in do_setlink.
> 
> This issue was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Fri, 20 Oct 2017 19:43:11 -0500

> Use BUG_ON instead of if condition followed by BUG in do_setlink.
> 
> This issue was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

[PATCH v6 4/9] arm: dts: mt2712: Add clock controller device nodes

[Weiyi Lu]

Add clock controller nodes for MT2712, include topckgen, infracfg,
pericfg, mcucfg and apmixedsys. This patch also add six oscillators that
provide clocks for MT2712.

Signed-off-by: Weiyi Lu 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 115 ++
 1 file changed, 115 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 57d0396..d2ee3cd 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier: (GPL-2.0 OR MIT)
  */
 
+#include 
 #include 
 #include 
 
@@ -73,6 +74,48 @@
#clock-cells = <0>;
};
 
+   clk26m: oscillator@0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2600>;
+   clock-output-names = "clk26m";
+   };
+
+   clk32k: oscillator@1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "clk32k";
+   };
+
+   clkfpc: oscillator@2 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   clock-output-names = "clkfpc";
+   };
+
+   clkaud_ext_i_0: oscillator@3 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <650>;
+   clock-output-names = "clkaud_ext_i_0";
+   };
+
+   clkaud_ext_i_1: oscillator@4 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <196608000>;
+   clock-output-names = "clkaud_ext_i_1";
+   };
+
+   clkaud_ext_i_2: oscillator@5 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <180633600>;
+   clock-output-names = "clkaud_ext_i_2";
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
@@ -86,6 +129,24 @@
  (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>;
};
 
+   topckgen: syscon@1000 {
+   compatible = "mediatek,mt2712-topckgen", "syscon";
+   reg = <0 0x1000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   infracfg: syscon@10001000 {
+   compatible = "mediatek,mt2712-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   pericfg: syscon@10003000 {
+   compatible = "mediatek,mt2712-pericfg", "syscon";
+   reg = <0 0x10003000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
uart5: serial@1000f000 {
compatible = "mediatek,mt2712-uart",
 "mediatek,mt6577-uart";
@@ -96,6 +157,18 @@
status = "disabled";
};
 
+   apmixedsys: syscon@10209000 {
+   compatible = "mediatek,mt2712-apmixedsys", "syscon";
+   reg = <0 0x10209000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   mcucfg: syscon@1022 {
+   compatible = "mediatek,mt2712-mcucfg", "syscon";
+   reg = <0 0x1022 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
sysirq: interrupt-controller@10220a80 {
compatible = "mediatek,mt2712-sysirq",
 "mediatek,mt6577-sysirq";
@@ -167,5 +240,47 @@
clock-names = "baud", "bus";
status = "disabled";
};
+
+   mfgcfg: syscon@1300 {
+   compatible = "mediatek,mt2712-mfgcfg", "syscon";
+   reg = <0 0x1300 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   mmsys: syscon@1400 {
+   compatible = "mediatek,mt2712-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: syscon@1500 {
+   compatible = "mediatek,mt2712-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   bdpsys: syscon@1501 {
+   compatible = "mediatek,mt2712-bdpsys", "syscon";
+   reg = <0 0x1501 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: syscon@1600 {
+   compatible = "mediatek,mt2712-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: syscon@1800 {
+   compatible = "mediatek,mt2712-vencsys", "syscon";
+   reg = <0 0x1800 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   jpgdecsys: syscon@1900 {
+   

[PATCH v6 4/9] arm: dts: mt2712: Add clock controller device nodes

[Weiyi Lu]

Add clock controller nodes for MT2712, include topckgen, infracfg,
pericfg, mcucfg and apmixedsys. This patch also add six oscillators that
provide clocks for MT2712.

Signed-off-by: Weiyi Lu 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 115 ++
 1 file changed, 115 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 57d0396..d2ee3cd 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier: (GPL-2.0 OR MIT)
  */
 
+#include 
 #include 
 #include 
 
@@ -73,6 +74,48 @@
#clock-cells = <0>;
};
 
+   clk26m: oscillator@0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2600>;
+   clock-output-names = "clk26m";
+   };
+
+   clk32k: oscillator@1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "clk32k";
+   };
+
+   clkfpc: oscillator@2 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   clock-output-names = "clkfpc";
+   };
+
+   clkaud_ext_i_0: oscillator@3 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <650>;
+   clock-output-names = "clkaud_ext_i_0";
+   };
+
+   clkaud_ext_i_1: oscillator@4 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <196608000>;
+   clock-output-names = "clkaud_ext_i_1";
+   };
+
+   clkaud_ext_i_2: oscillator@5 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <180633600>;
+   clock-output-names = "clkaud_ext_i_2";
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
@@ -86,6 +129,24 @@
  (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>;
};
 
+   topckgen: syscon@1000 {
+   compatible = "mediatek,mt2712-topckgen", "syscon";
+   reg = <0 0x1000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   infracfg: syscon@10001000 {
+   compatible = "mediatek,mt2712-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   pericfg: syscon@10003000 {
+   compatible = "mediatek,mt2712-pericfg", "syscon";
+   reg = <0 0x10003000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
uart5: serial@1000f000 {
compatible = "mediatek,mt2712-uart",
 "mediatek,mt6577-uart";
@@ -96,6 +157,18 @@
status = "disabled";
};
 
+   apmixedsys: syscon@10209000 {
+   compatible = "mediatek,mt2712-apmixedsys", "syscon";
+   reg = <0 0x10209000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   mcucfg: syscon@1022 {
+   compatible = "mediatek,mt2712-mcucfg", "syscon";
+   reg = <0 0x1022 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
sysirq: interrupt-controller@10220a80 {
compatible = "mediatek,mt2712-sysirq",
 "mediatek,mt6577-sysirq";
@@ -167,5 +240,47 @@
clock-names = "baud", "bus";
status = "disabled";
};
+
+   mfgcfg: syscon@1300 {
+   compatible = "mediatek,mt2712-mfgcfg", "syscon";
+   reg = <0 0x1300 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   mmsys: syscon@1400 {
+   compatible = "mediatek,mt2712-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: syscon@1500 {
+   compatible = "mediatek,mt2712-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   bdpsys: syscon@1501 {
+   compatible = "mediatek,mt2712-bdpsys", "syscon";
+   reg = <0 0x1501 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: syscon@1600 {
+   compatible = "mediatek,mt2712-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: syscon@1800 {
+   compatible = "mediatek,mt2712-vencsys", "syscon";
+   reg = <0 0x1800 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   jpgdecsys: syscon@1900 {
+   compatible = 

[PATCH v6 7/9] soc: mediatek: add dependent clock jpgdec/audio for scpsys

[Weiyi Lu]

There are dependent clock jpgdec/audio in scpsys on MT2712,
and will exist three dependent clocks on MT2712 VDEC.

Signed-off-by: Weiyi Lu 
---
 drivers/soc/mediatek/mtk-scpsys.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index ba552de..7e7e4ec 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -84,6 +84,8 @@ enum clk_id {
CLK_ETHIF,
CLK_VDEC,
CLK_HIFSEL,
+   CLK_JPGDEC,
+   CLK_AUDIO,
CLK_MAX,
 };
 
@@ -96,10 +98,12 @@ enum clk_id {
"ethif",
"vdec",
"hif_sel",
+   "jpgdec",
+   "audio",
NULL,
 };
 
-#define MAX_CLKS   2
+#define MAX_CLKS   3
 
 struct scp_domain_data {
const char *name;
-- 
1.9.1

[PATCH v6 6/9] soc: mediatek: extend bus protection API

[Weiyi Lu]

MT2712 add "set/clear" bus control register to each control register set
instead of providing only one "enable" control register, we could avoid
the read-modify-write racing by declaring "bus_prot_reg_update" as "false"
in scp_soc_data or declaring as "true" to use the legacy update method.
By improving the mtk-infracfg bus protection implementation to
support set/clear bus protection control method by IC configuration.

Signed-off-by: Weiyi Lu 
---
 drivers/soc/mediatek/mtk-infracfg.c   | 26 ++
 drivers/soc/mediatek/mtk-scpsys.c | 28 
 include/linux/soc/mediatek/infracfg.h |  7 ---
 3 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-infracfg.c 
b/drivers/soc/mediatek/mtk-infracfg.c
index dba3055..8c310de 100644
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ b/drivers/soc/mediatek/mtk-infracfg.c
@@ -19,23 +19,33 @@
 
 #define INFRA_TOPAXI_PROTECTEN 0x0220
 #define INFRA_TOPAXI_PROTECTSTA1   0x0228
+#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
+#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
 
 /**
  * mtk_infracfg_set_bus_protection - enable bus protection
  * @regmap: The infracfg regmap
  * @mask: The mask containing the protection bits to be enabled.
+ * @reg_update: The boolean flag determines to set the protection bits
+ *  by regmap_update_bits with enable register(PROTECTEN) or
+ *  by regmap_write with set register(PROTECTEN_SET).
  *
  * This function enables the bus protection bits for disabled power
  * domains so that the system does not hang when some unit accesses the
  * bus while in power down.
  */
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask)
+int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
+   bool reg_update)
 {
unsigned long expired;
u32 val;
int ret;
 
-   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
+   if (reg_update)
+   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
+   mask);
+   else
+   regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
 
expired = jiffies + HZ;
 
@@ -59,16 +69,24 @@ int mtk_infracfg_set_bus_protection(struct regmap 
*infracfg, u32 mask)
  * mtk_infracfg_clear_bus_protection - disable bus protection
  * @regmap: The infracfg regmap
  * @mask: The mask containing the protection bits to be disabled.
+ * @reg_update: The boolean flag determines to clear the protection bits
+ *  by regmap_update_bits with enable register(PROTECTEN) or
+ *  by regmap_write with clear register(PROTECTEN_CLR).
  *
  * This function disables the bus protection bits previously enabled with
  * mtk_infracfg_set_bus_protection.
  */
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask)
+
+int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
+   bool reg_update)
 {
unsigned long expired;
int ret;
 
-   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+   if (reg_update)
+   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+   else
+   regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
 
expired = jiffies + HZ;
 
diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index e1ce8b1..ba552de 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -134,6 +134,7 @@ struct scp {
void __iomem *base;
struct regmap *infracfg;
struct scp_ctrl_reg ctrl_reg;
+   bool bus_prot_reg_update;
 };
 
 struct scp_subdomain {
@@ -147,6 +148,7 @@ struct scp_soc_data {
const struct scp_subdomain *subdomains;
int num_subdomains;
const struct scp_ctrl_reg regs;
+   bool bus_prot_reg_update;
 };
 
 static int scpsys_domain_is_on(struct scp_domain *scpd)
@@ -254,7 +256,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
 
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
-   scpd->data->bus_prot_mask);
+   scpd->data->bus_prot_mask,
+   scp->bus_prot_reg_update);
if (ret)
goto err_pwr_ack;
}
@@ -289,7 +292,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
 
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_set_bus_protection(scp->infracfg,
-   scpd->data->bus_prot_mask);
+   scpd->data->bus_prot_mask,
+   scp->bus_prot_reg_update);
if (ret)
goto out;
}
@@ -382,7 +386,8 @@ static void init_clks(struct 

[PATCH v6 8/9] soc: mediatek: add MT2712 scpsys support

[Weiyi Lu]

add scpsys driver for MT2712

Signed-off-by: Weiyi Lu 
---
 drivers/soc/mediatek/mtk-scpsys.c | 106 +++---
 1 file changed, 100 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 7e7e4ec..2a0c3a7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,7 @@
 #define SPM_DIS_PWR_CON0x023c
 #define SPM_CONN_PWR_CON   0x0280
 #define SPM_VEN2_PWR_CON   0x0298
-#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173 */
+#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173, MT2712 */
 #define SPM_BDP_PWR_CON0x029c  /* MT2701 */
 #define SPM_ETH_PWR_CON0x02a0
 #define SPM_HIF_PWR_CON0x02a4
@@ -40,12 +41,12 @@
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
+#define SPM_USB2_PWR_CON   0x02d4  /* MT2712 */
 #define SPM_ETHSYS_PWR_CON 0x02e0  /* MT7622 */
 #define SPM_HIF0_PWR_CON   0x02e4  /* MT7622 */
 #define SPM_HIF1_PWR_CON   0x02e8  /* MT7622 */
 #define SPM_WB_PWR_CON 0x02ec  /* MT7622 */
 
-
 #define SPM_PWR_STATUS 0x060c
 #define SPM_PWR_STATUS_2ND 0x0610
 
@@ -64,12 +65,13 @@
 #define PWR_STATUS_ETH BIT(15)
 #define PWR_STATUS_HIF BIT(16)
 #define PWR_STATUS_IFR_MSC BIT(17)
+#define PWR_STATUS_USB2BIT(19) /* MT2712 */
 #define PWR_STATUS_VENC_LT BIT(20)
 #define PWR_STATUS_VENCBIT(21)
-#define PWR_STATUS_MFG_2D  BIT(22)
-#define PWR_STATUS_MFG_ASYNC   BIT(23)
-#define PWR_STATUS_AUDIO   BIT(24)
-#define PWR_STATUS_USB BIT(25)
+#define PWR_STATUS_MFG_2D  BIT(22) /* MT8173 */
+#define PWR_STATUS_MFG_ASYNC   BIT(23) /* MT8173 */
+#define PWR_STATUS_AUDIO   BIT(24) /* MT8173, MT2712 */
+#define PWR_STATUS_USB BIT(25) /* MT8173, MT2712 */
 #define PWR_STATUS_ETHSYS  BIT(24) /* MT7622 */
 #define PWR_STATUS_HIF0BIT(25) /* MT7622 */
 #define PWR_STATUS_HIF1BIT(26) /* MT7622 */
@@ -602,6 +604,85 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 };
 
 /*
+ * MT2712 power domain support
+ */
+static const struct scp_domain_data scp_domain_data_mt2712[] = {
+   [MT2712_POWER_DOMAIN_MM] = {
+   .name = "mm",
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2712_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM, CLK_VDEC},
+   .active_wakeup = true,
+   },
+   [MT2712_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 = {CLK_MM, CLK_VENC, CLK_JPGDEC},
+   .active_wakeup = true,
+   },
+   [MT2712_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 = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2712_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 = {CLK_AUDIO},
+   .active_wakeup = true,
+   },
+   [MT2712_POWER_DOMAIN_USB] = {
+   .name = "usb",
+   .sta_mask = PWR_STATUS_USB,
+   .ctl_offs = SPM_USB_PWR_CON,
+   .sram_pdn_bits = GENMASK(10, 8),
+   .sram_pdn_ack_bits = GENMASK(14, 12),
+   .clk_id = {CLK_NONE},
+   .active_wakeup = true,
+   },
+   [MT2712_POWER_DOMAIN_USB2] = {
+   .name = "usb2",
+   .sta_mask = PWR_STATUS_USB2,
+   

[PATCH v6 7/9] soc: mediatek: add dependent clock jpgdec/audio for scpsys

[Weiyi Lu]

There are dependent clock jpgdec/audio in scpsys on MT2712,
and will exist three dependent clocks on MT2712 VDEC.

Signed-off-by: Weiyi Lu 
---
 drivers/soc/mediatek/mtk-scpsys.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index ba552de..7e7e4ec 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -84,6 +84,8 @@ enum clk_id {
CLK_ETHIF,
CLK_VDEC,
CLK_HIFSEL,
+   CLK_JPGDEC,
+   CLK_AUDIO,
CLK_MAX,
 };
 
@@ -96,10 +98,12 @@ enum clk_id {
"ethif",
"vdec",
"hif_sel",
+   "jpgdec",
+   "audio",
NULL,
 };
 
-#define MAX_CLKS   2
+#define MAX_CLKS   3
 
 struct scp_domain_data {
const char *name;
-- 
1.9.1

[PATCH v6 6/9] soc: mediatek: extend bus protection API

[Weiyi Lu]

MT2712 add "set/clear" bus control register to each control register set
instead of providing only one "enable" control register, we could avoid
the read-modify-write racing by declaring "bus_prot_reg_update" as "false"
in scp_soc_data or declaring as "true" to use the legacy update method.
By improving the mtk-infracfg bus protection implementation to
support set/clear bus protection control method by IC configuration.

Signed-off-by: Weiyi Lu 
---
 drivers/soc/mediatek/mtk-infracfg.c   | 26 ++
 drivers/soc/mediatek/mtk-scpsys.c | 28 
 include/linux/soc/mediatek/infracfg.h |  7 ---
 3 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-infracfg.c 
b/drivers/soc/mediatek/mtk-infracfg.c
index dba3055..8c310de 100644
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ b/drivers/soc/mediatek/mtk-infracfg.c
@@ -19,23 +19,33 @@
 
 #define INFRA_TOPAXI_PROTECTEN 0x0220
 #define INFRA_TOPAXI_PROTECTSTA1   0x0228
+#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
+#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
 
 /**
  * mtk_infracfg_set_bus_protection - enable bus protection
  * @regmap: The infracfg regmap
  * @mask: The mask containing the protection bits to be enabled.
+ * @reg_update: The boolean flag determines to set the protection bits
+ *  by regmap_update_bits with enable register(PROTECTEN) or
+ *  by regmap_write with set register(PROTECTEN_SET).
  *
  * This function enables the bus protection bits for disabled power
  * domains so that the system does not hang when some unit accesses the
  * bus while in power down.
  */
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask)
+int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
+   bool reg_update)
 {
unsigned long expired;
u32 val;
int ret;
 
-   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
+   if (reg_update)
+   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
+   mask);
+   else
+   regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
 
expired = jiffies + HZ;
 
@@ -59,16 +69,24 @@ int mtk_infracfg_set_bus_protection(struct regmap 
*infracfg, u32 mask)
  * mtk_infracfg_clear_bus_protection - disable bus protection
  * @regmap: The infracfg regmap
  * @mask: The mask containing the protection bits to be disabled.
+ * @reg_update: The boolean flag determines to clear the protection bits
+ *  by regmap_update_bits with enable register(PROTECTEN) or
+ *  by regmap_write with clear register(PROTECTEN_CLR).
  *
  * This function disables the bus protection bits previously enabled with
  * mtk_infracfg_set_bus_protection.
  */
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask)
+
+int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
+   bool reg_update)
 {
unsigned long expired;
int ret;
 
-   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+   if (reg_update)
+   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+   else
+   regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
 
expired = jiffies + HZ;
 
diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index e1ce8b1..ba552de 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -134,6 +134,7 @@ struct scp {
void __iomem *base;
struct regmap *infracfg;
struct scp_ctrl_reg ctrl_reg;
+   bool bus_prot_reg_update;
 };
 
 struct scp_subdomain {
@@ -147,6 +148,7 @@ struct scp_soc_data {
const struct scp_subdomain *subdomains;
int num_subdomains;
const struct scp_ctrl_reg regs;
+   bool bus_prot_reg_update;
 };
 
 static int scpsys_domain_is_on(struct scp_domain *scpd)
@@ -254,7 +256,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
 
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
-   scpd->data->bus_prot_mask);
+   scpd->data->bus_prot_mask,
+   scp->bus_prot_reg_update);
if (ret)
goto err_pwr_ack;
}
@@ -289,7 +292,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
 
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_set_bus_protection(scp->infracfg,
-   scpd->data->bus_prot_mask);
+   scpd->data->bus_prot_mask,
+   scp->bus_prot_reg_update);
if (ret)
goto out;
}
@@ -382,7 +386,8 @@ static void init_clks(struct platform_device *pdev, struct 

[PATCH v6 8/9] soc: mediatek: add MT2712 scpsys support

[Weiyi Lu]

add scpsys driver for MT2712

Signed-off-by: Weiyi Lu 
---
 drivers/soc/mediatek/mtk-scpsys.c | 106 +++---
 1 file changed, 100 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 7e7e4ec..2a0c3a7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,7 @@
 #define SPM_DIS_PWR_CON0x023c
 #define SPM_CONN_PWR_CON   0x0280
 #define SPM_VEN2_PWR_CON   0x0298
-#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173 */
+#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173, MT2712 */
 #define SPM_BDP_PWR_CON0x029c  /* MT2701 */
 #define SPM_ETH_PWR_CON0x02a0
 #define SPM_HIF_PWR_CON0x02a4
@@ -40,12 +41,12 @@
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
+#define SPM_USB2_PWR_CON   0x02d4  /* MT2712 */
 #define SPM_ETHSYS_PWR_CON 0x02e0  /* MT7622 */
 #define SPM_HIF0_PWR_CON   0x02e4  /* MT7622 */
 #define SPM_HIF1_PWR_CON   0x02e8  /* MT7622 */
 #define SPM_WB_PWR_CON 0x02ec  /* MT7622 */
 
-
 #define SPM_PWR_STATUS 0x060c
 #define SPM_PWR_STATUS_2ND 0x0610
 
@@ -64,12 +65,13 @@
 #define PWR_STATUS_ETH BIT(15)
 #define PWR_STATUS_HIF BIT(16)
 #define PWR_STATUS_IFR_MSC BIT(17)
+#define PWR_STATUS_USB2BIT(19) /* MT2712 */
 #define PWR_STATUS_VENC_LT BIT(20)
 #define PWR_STATUS_VENCBIT(21)
-#define PWR_STATUS_MFG_2D  BIT(22)
-#define PWR_STATUS_MFG_ASYNC   BIT(23)
-#define PWR_STATUS_AUDIO   BIT(24)
-#define PWR_STATUS_USB BIT(25)
+#define PWR_STATUS_MFG_2D  BIT(22) /* MT8173 */
+#define PWR_STATUS_MFG_ASYNC   BIT(23) /* MT8173 */
+#define PWR_STATUS_AUDIO   BIT(24) /* MT8173, MT2712 */
+#define PWR_STATUS_USB BIT(25) /* MT8173, MT2712 */
 #define PWR_STATUS_ETHSYS  BIT(24) /* MT7622 */
 #define PWR_STATUS_HIF0BIT(25) /* MT7622 */
 #define PWR_STATUS_HIF1BIT(26) /* MT7622 */
@@ -602,6 +604,85 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 };
 
 /*
+ * MT2712 power domain support
+ */
+static const struct scp_domain_data scp_domain_data_mt2712[] = {
+   [MT2712_POWER_DOMAIN_MM] = {
+   .name = "mm",
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2712_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM, CLK_VDEC},
+   .active_wakeup = true,
+   },
+   [MT2712_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 = {CLK_MM, CLK_VENC, CLK_JPGDEC},
+   .active_wakeup = true,
+   },
+   [MT2712_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 = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2712_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 = {CLK_AUDIO},
+   .active_wakeup = true,
+   },
+   [MT2712_POWER_DOMAIN_USB] = {
+   .name = "usb",
+   .sta_mask = PWR_STATUS_USB,
+   .ctl_offs = SPM_USB_PWR_CON,
+   .sram_pdn_bits = GENMASK(10, 8),
+   .sram_pdn_ack_bits = GENMASK(14, 12),
+   .clk_id = {CLK_NONE},
+   .active_wakeup = true,
+   },
+   [MT2712_POWER_DOMAIN_USB2] = {
+   .name = "usb2",
+   .sta_mask = PWR_STATUS_USB2,
+   .ctl_offs = 

[PATCH v6 3/9] clk: mediatek: Add MT2712 clock support

[Weiyi Lu]

Add MT2712 clock support, include topckgen, apmixedsys,
infracfg, pericfg, mcucfg and subsystem clocks.

Signed-off-by: Weiyi Lu 
---
 drivers/clk/mediatek/Kconfig |   50 ++
 drivers/clk/mediatek/Makefile|8 +
 drivers/clk/mediatek/clk-mt2712-bdp.c|  102 +++
 drivers/clk/mediatek/clk-mt2712-img.c|   80 ++
 drivers/clk/mediatek/clk-mt2712-jpgdec.c |   76 ++
 drivers/clk/mediatek/clk-mt2712-mfg.c|   75 ++
 drivers/clk/mediatek/clk-mt2712-mm.c |  170 
 drivers/clk/mediatek/clk-mt2712-vdec.c   |   94 ++
 drivers/clk/mediatek/clk-mt2712-venc.c   |   77 ++
 drivers/clk/mediatek/clk-mt2712.c| 1435 ++
 drivers/clk/mediatek/clk-mtk.h   |2 +
 drivers/clk/mediatek/clk-pll.c   |   13 +-
 12 files changed, 2180 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2712-bdp.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-jpgdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 28739a9..300dbb5 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,56 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT2712
+   bool "Clock driver for Mediatek MT2712"
+   depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK && ARM64
+   ---help---
+ This driver supports Mediatek MT2712 basic clocks.
+
+config COMMON_CLK_MT2712_BDPSYS
+   bool "Clock driver for Mediatek MT2712 bdpsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 bdpsys clocks.
+
+config COMMON_CLK_MT2712_IMGSYS
+   bool "Clock driver for Mediatek MT2712 imgsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 imgsys clocks.
+
+config COMMON_CLK_MT2712_JPGDECSYS
+   bool "Clock driver for Mediatek MT2712 jpgdecsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 jpgdecsys clocks.
+
+config COMMON_CLK_MT2712_MFGCFG
+   bool "Clock driver for Mediatek MT2712 mfgcfg"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 mfgcfg clocks.
+
+config COMMON_CLK_MT2712_MMSYS
+   bool "Clock driver for Mediatek MT2712 mmsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 mmsys clocks.
+
+config COMMON_CLK_MT2712_VDECSYS
+   bool "Clock driver for Mediatek MT2712 vdecsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 vdecsys clocks.
+
+config COMMON_CLK_MT2712_VENCSYS
+   bool "Clock driver for Mediatek MT2712 vencsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 vencsys clocks.
+
 config COMMON_CLK_MT6797
bool "Clock driver for Mediatek MT6797"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 2a755b5..a4e5c47 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -12,5 +12,13 @@ obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
 obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o
 obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o
 obj-$(CONFIG_COMMON_CLK_MT2701_VDECSYS) += clk-mt2701-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT2712) += clk-mt2712.o
+obj-$(CONFIG_COMMON_CLK_MT2712_BDPSYS) += clk-mt2712-bdp.o
+obj-$(CONFIG_COMMON_CLK_MT2712_IMGSYS) += clk-mt2712-img.o
+obj-$(CONFIG_COMMON_CLK_MT2712_JPGDECSYS) += clk-mt2712-jpgdec.o
+obj-$(CONFIG_COMMON_CLK_MT2712_MFGCFG) += clk-mt2712-mfg.o
+obj-$(CONFIG_COMMON_CLK_MT2712_MMSYS) += clk-mt2712-mm.o
+obj-$(CONFIG_COMMON_CLK_MT2712_VDECSYS) += clk-mt2712-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT2712_VENCSYS) += clk-mt2712-venc.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-mt2712-bdp.c 
b/drivers/clk/mediatek/clk-mt2712-bdp.c
new file mode 100644
index 000..5fe4728
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2712-bdp.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Weiyi Lu 
+ *
+ * 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 

[PATCH v6 3/9] clk: mediatek: Add MT2712 clock support

[Weiyi Lu]

Add MT2712 clock support, include topckgen, apmixedsys,
infracfg, pericfg, mcucfg and subsystem clocks.

Signed-off-by: Weiyi Lu 
---
 drivers/clk/mediatek/Kconfig |   50 ++
 drivers/clk/mediatek/Makefile|8 +
 drivers/clk/mediatek/clk-mt2712-bdp.c|  102 +++
 drivers/clk/mediatek/clk-mt2712-img.c|   80 ++
 drivers/clk/mediatek/clk-mt2712-jpgdec.c |   76 ++
 drivers/clk/mediatek/clk-mt2712-mfg.c|   75 ++
 drivers/clk/mediatek/clk-mt2712-mm.c |  170 
 drivers/clk/mediatek/clk-mt2712-vdec.c   |   94 ++
 drivers/clk/mediatek/clk-mt2712-venc.c   |   77 ++
 drivers/clk/mediatek/clk-mt2712.c| 1435 ++
 drivers/clk/mediatek/clk-mtk.h   |2 +
 drivers/clk/mediatek/clk-pll.c   |   13 +-
 12 files changed, 2180 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2712-bdp.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-jpgdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 28739a9..300dbb5 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,56 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT2712
+   bool "Clock driver for Mediatek MT2712"
+   depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK && ARM64
+   ---help---
+ This driver supports Mediatek MT2712 basic clocks.
+
+config COMMON_CLK_MT2712_BDPSYS
+   bool "Clock driver for Mediatek MT2712 bdpsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 bdpsys clocks.
+
+config COMMON_CLK_MT2712_IMGSYS
+   bool "Clock driver for Mediatek MT2712 imgsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 imgsys clocks.
+
+config COMMON_CLK_MT2712_JPGDECSYS
+   bool "Clock driver for Mediatek MT2712 jpgdecsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 jpgdecsys clocks.
+
+config COMMON_CLK_MT2712_MFGCFG
+   bool "Clock driver for Mediatek MT2712 mfgcfg"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 mfgcfg clocks.
+
+config COMMON_CLK_MT2712_MMSYS
+   bool "Clock driver for Mediatek MT2712 mmsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 mmsys clocks.
+
+config COMMON_CLK_MT2712_VDECSYS
+   bool "Clock driver for Mediatek MT2712 vdecsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 vdecsys clocks.
+
+config COMMON_CLK_MT2712_VENCSYS
+   bool "Clock driver for Mediatek MT2712 vencsys"
+   depends on COMMON_CLK_MT2712
+   ---help---
+ This driver supports Mediatek MT2712 vencsys clocks.
+
 config COMMON_CLK_MT6797
bool "Clock driver for Mediatek MT6797"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 2a755b5..a4e5c47 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -12,5 +12,13 @@ obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
 obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o
 obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o
 obj-$(CONFIG_COMMON_CLK_MT2701_VDECSYS) += clk-mt2701-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT2712) += clk-mt2712.o
+obj-$(CONFIG_COMMON_CLK_MT2712_BDPSYS) += clk-mt2712-bdp.o
+obj-$(CONFIG_COMMON_CLK_MT2712_IMGSYS) += clk-mt2712-img.o
+obj-$(CONFIG_COMMON_CLK_MT2712_JPGDECSYS) += clk-mt2712-jpgdec.o
+obj-$(CONFIG_COMMON_CLK_MT2712_MFGCFG) += clk-mt2712-mfg.o
+obj-$(CONFIG_COMMON_CLK_MT2712_MMSYS) += clk-mt2712-mm.o
+obj-$(CONFIG_COMMON_CLK_MT2712_VDECSYS) += clk-mt2712-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT2712_VENCSYS) += clk-mt2712-venc.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-mt2712-bdp.c 
b/drivers/clk/mediatek/clk-mt2712-bdp.c
new file mode 100644
index 000..5fe4728
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2712-bdp.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Weiyi Lu 
+ *
+ * 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 

[PATCH v6 2/9] clk: mediatek: Add dt-bindings for MT2712 clocks

[Weiyi Lu]

Add MT2712 clock dt-bindings, include topckgen, apmixedsys,
infracfg, pericfg, mcucfg and subsystem clocks.

Signed-off-by: Weiyi Lu 
---
 include/dt-bindings/clock/mt2712-clk.h | 427 +
 1 file changed, 427 insertions(+)
 create mode 100644 include/dt-bindings/clock/mt2712-clk.h

diff --git a/include/dt-bindings/clock/mt2712-clk.h 
b/include/dt-bindings/clock/mt2712-clk.h
new file mode 100644
index 000..48a8e79
--- /dev/null
+++ b/include/dt-bindings/clock/mt2712-clk.h
@@ -0,0 +1,427 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Weiyi Lu 
+ *
+ * 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_CLK_MT2712_H
+#define _DT_BINDINGS_CLK_MT2712_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_MAINPLL0
+#define CLK_APMIXED_UNIVPLL1
+#define CLK_APMIXED_VCODECPLL  2
+#define CLK_APMIXED_VENCPLL3
+#define CLK_APMIXED_APLL1  4
+#define CLK_APMIXED_APLL2  5
+#define CLK_APMIXED_LVDSPLL6
+#define CLK_APMIXED_LVDSPLL2   7
+#define CLK_APMIXED_MSDCPLL8
+#define CLK_APMIXED_MSDCPLL2   9
+#define CLK_APMIXED_TVDPLL 10
+#define CLK_APMIXED_MMPLL  11
+#define CLK_APMIXED_ARMCA35PLL 12
+#define CLK_APMIXED_ARMCA72PLL 13
+#define CLK_APMIXED_ETHERPLL   14
+#define CLK_APMIXED_NR_CLK 15
+
+/* TOPCKGEN */
+
+#define CLK_TOP_ARMCA35PLL 0
+#define CLK_TOP_ARMCA35PLL_600M1
+#define CLK_TOP_ARMCA35PLL_400M2
+#define CLK_TOP_ARMCA72PLL 3
+#define CLK_TOP_SYSPLL 4
+#define CLK_TOP_SYSPLL_D2  5
+#define CLK_TOP_SYSPLL1_D2 6
+#define CLK_TOP_SYSPLL1_D4 7
+#define CLK_TOP_SYSPLL1_D8 8
+#define CLK_TOP_SYSPLL1_D169
+#define CLK_TOP_SYSPLL_D3  10
+#define CLK_TOP_SYSPLL2_D2 11
+#define CLK_TOP_SYSPLL2_D4 12
+#define CLK_TOP_SYSPLL_D5  13
+#define CLK_TOP_SYSPLL3_D2 14
+#define CLK_TOP_SYSPLL3_D4 15
+#define CLK_TOP_SYSPLL_D7  16
+#define CLK_TOP_SYSPLL4_D2 17
+#define CLK_TOP_SYSPLL4_D4 18
+#define CLK_TOP_UNIVPLL19
+#define CLK_TOP_UNIVPLL_D7 20
+#define CLK_TOP_UNIVPLL_D2621
+#define CLK_TOP_UNIVPLL_D5222
+#define CLK_TOP_UNIVPLL_D104   23
+#define CLK_TOP_UNIVPLL_D208   24
+#define CLK_TOP_UNIVPLL_D2 25
+#define CLK_TOP_UNIVPLL1_D226
+#define CLK_TOP_UNIVPLL1_D427
+#define CLK_TOP_UNIVPLL1_D828
+#define CLK_TOP_UNIVPLL_D3 29
+#define CLK_TOP_UNIVPLL2_D230
+#define CLK_TOP_UNIVPLL2_D431
+#define CLK_TOP_UNIVPLL2_D832
+#define CLK_TOP_UNIVPLL_D5 33
+#define CLK_TOP_UNIVPLL3_D234
+#define CLK_TOP_UNIVPLL3_D435
+#define CLK_TOP_UNIVPLL3_D836
+#define CLK_TOP_F_MP0_PLL1 37
+#define CLK_TOP_F_MP0_PLL2 38
+#define CLK_TOP_F_BIG_PLL1 39
+#define CLK_TOP_F_BIG_PLL2 40
+#define CLK_TOP_F_BUS_PLL1 41
+#define CLK_TOP_F_BUS_PLL2 42
+#define CLK_TOP_APLL1  43
+#define CLK_TOP_APLL1_D2   44
+#define CLK_TOP_APLL1_D4   45
+#define CLK_TOP_APLL1_D8   46
+#define CLK_TOP_APLL1_D16  47
+#define CLK_TOP_APLL2  48
+#define CLK_TOP_APLL2_D2   49
+#define CLK_TOP_APLL2_D4   50
+#define CLK_TOP_APLL2_D8   51
+#define CLK_TOP_APLL2_D16  52
+#define CLK_TOP_LVDSPLL53
+#define CLK_TOP_LVDSPLL_D2 54
+#define CLK_TOP_LVDSPLL_D4 55
+#define CLK_TOP_LVDSPLL_D8 56
+#define CLK_TOP_LVDSPLL2   57
+#define CLK_TOP_LVDSPLL2_D258
+#define CLK_TOP_LVDSPLL2_D459
+#define CLK_TOP_LVDSPLL2_D860
+#define CLK_TOP_ETHERPLL_125M  61
+#define CLK_TOP_ETHERPLL_50M   62
+#define CLK_TOP_CVBS   63
+#define CLK_TOP_CVBS_D264
+#define CLK_TOP_SYS_26M65
+#define CLK_TOP_MMPLL  66
+#define CLK_TOP_MMPLL_D2   67
+#define CLK_TOP_VENCPLL68
+#define CLK_TOP_VENCPLL_D2 69
+#define CLK_TOP_VCODECPLL  70
+#define 

[PATCH v6 2/9] clk: mediatek: Add dt-bindings for MT2712 clocks

[Weiyi Lu]

Add MT2712 clock dt-bindings, include topckgen, apmixedsys,
infracfg, pericfg, mcucfg and subsystem clocks.

Signed-off-by: Weiyi Lu 
---
 include/dt-bindings/clock/mt2712-clk.h | 427 +
 1 file changed, 427 insertions(+)
 create mode 100644 include/dt-bindings/clock/mt2712-clk.h

diff --git a/include/dt-bindings/clock/mt2712-clk.h 
b/include/dt-bindings/clock/mt2712-clk.h
new file mode 100644
index 000..48a8e79
--- /dev/null
+++ b/include/dt-bindings/clock/mt2712-clk.h
@@ -0,0 +1,427 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Weiyi Lu 
+ *
+ * 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_CLK_MT2712_H
+#define _DT_BINDINGS_CLK_MT2712_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_MAINPLL0
+#define CLK_APMIXED_UNIVPLL1
+#define CLK_APMIXED_VCODECPLL  2
+#define CLK_APMIXED_VENCPLL3
+#define CLK_APMIXED_APLL1  4
+#define CLK_APMIXED_APLL2  5
+#define CLK_APMIXED_LVDSPLL6
+#define CLK_APMIXED_LVDSPLL2   7
+#define CLK_APMIXED_MSDCPLL8
+#define CLK_APMIXED_MSDCPLL2   9
+#define CLK_APMIXED_TVDPLL 10
+#define CLK_APMIXED_MMPLL  11
+#define CLK_APMIXED_ARMCA35PLL 12
+#define CLK_APMIXED_ARMCA72PLL 13
+#define CLK_APMIXED_ETHERPLL   14
+#define CLK_APMIXED_NR_CLK 15
+
+/* TOPCKGEN */
+
+#define CLK_TOP_ARMCA35PLL 0
+#define CLK_TOP_ARMCA35PLL_600M1
+#define CLK_TOP_ARMCA35PLL_400M2
+#define CLK_TOP_ARMCA72PLL 3
+#define CLK_TOP_SYSPLL 4
+#define CLK_TOP_SYSPLL_D2  5
+#define CLK_TOP_SYSPLL1_D2 6
+#define CLK_TOP_SYSPLL1_D4 7
+#define CLK_TOP_SYSPLL1_D8 8
+#define CLK_TOP_SYSPLL1_D169
+#define CLK_TOP_SYSPLL_D3  10
+#define CLK_TOP_SYSPLL2_D2 11
+#define CLK_TOP_SYSPLL2_D4 12
+#define CLK_TOP_SYSPLL_D5  13
+#define CLK_TOP_SYSPLL3_D2 14
+#define CLK_TOP_SYSPLL3_D4 15
+#define CLK_TOP_SYSPLL_D7  16
+#define CLK_TOP_SYSPLL4_D2 17
+#define CLK_TOP_SYSPLL4_D4 18
+#define CLK_TOP_UNIVPLL19
+#define CLK_TOP_UNIVPLL_D7 20
+#define CLK_TOP_UNIVPLL_D2621
+#define CLK_TOP_UNIVPLL_D5222
+#define CLK_TOP_UNIVPLL_D104   23
+#define CLK_TOP_UNIVPLL_D208   24
+#define CLK_TOP_UNIVPLL_D2 25
+#define CLK_TOP_UNIVPLL1_D226
+#define CLK_TOP_UNIVPLL1_D427
+#define CLK_TOP_UNIVPLL1_D828
+#define CLK_TOP_UNIVPLL_D3 29
+#define CLK_TOP_UNIVPLL2_D230
+#define CLK_TOP_UNIVPLL2_D431
+#define CLK_TOP_UNIVPLL2_D832
+#define CLK_TOP_UNIVPLL_D5 33
+#define CLK_TOP_UNIVPLL3_D234
+#define CLK_TOP_UNIVPLL3_D435
+#define CLK_TOP_UNIVPLL3_D836
+#define CLK_TOP_F_MP0_PLL1 37
+#define CLK_TOP_F_MP0_PLL2 38
+#define CLK_TOP_F_BIG_PLL1 39
+#define CLK_TOP_F_BIG_PLL2 40
+#define CLK_TOP_F_BUS_PLL1 41
+#define CLK_TOP_F_BUS_PLL2 42
+#define CLK_TOP_APLL1  43
+#define CLK_TOP_APLL1_D2   44
+#define CLK_TOP_APLL1_D4   45
+#define CLK_TOP_APLL1_D8   46
+#define CLK_TOP_APLL1_D16  47
+#define CLK_TOP_APLL2  48
+#define CLK_TOP_APLL2_D2   49
+#define CLK_TOP_APLL2_D4   50
+#define CLK_TOP_APLL2_D8   51
+#define CLK_TOP_APLL2_D16  52
+#define CLK_TOP_LVDSPLL53
+#define CLK_TOP_LVDSPLL_D2 54
+#define CLK_TOP_LVDSPLL_D4 55
+#define CLK_TOP_LVDSPLL_D8 56
+#define CLK_TOP_LVDSPLL2   57
+#define CLK_TOP_LVDSPLL2_D258
+#define CLK_TOP_LVDSPLL2_D459
+#define CLK_TOP_LVDSPLL2_D860
+#define CLK_TOP_ETHERPLL_125M  61
+#define CLK_TOP_ETHERPLL_50M   62
+#define CLK_TOP_CVBS   63
+#define CLK_TOP_CVBS_D264
+#define CLK_TOP_SYS_26M65
+#define CLK_TOP_MMPLL  66
+#define CLK_TOP_MMPLL_D2   67
+#define CLK_TOP_VENCPLL68
+#define CLK_TOP_VENCPLL_D2 69
+#define CLK_TOP_VCODECPLL  70
+#define CLK_TOP_VCODECPLL_D2   71
+#define 

[PATCH v6 5/9] dt-bindings: soc: add MT2712 power dt-bindings

[Weiyi Lu]

Add power dt-bindings for MT2712.

Acked-by: Rob Herring 
Signed-off-by: Weiyi Lu 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt|  3 +++
 include/dt-bindings/power/mt2712-power.h   | 26 ++
 2 files changed, 29 insertions(+)
 create mode 100644 include/dt-bindings/power/mt2712-power.h

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 40056f7..76bf45b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -12,11 +12,13 @@ power/power_domain.txt. It provides the power domains 
defined in
 - include/dt-bindings/power/mt8173-power.h
 - include/dt-bindings/power/mt6797-power.h
 - include/dt-bindings/power/mt2701-power.h
+- include/dt-bindings/power/mt2712-power.h
 - include/dt-bindings/power/mt7622-power.h
 
 Required properties:
 - compatible: Should be one of:
- "mediatek,mt2701-scpsys"
+   - "mediatek,mt2712-scpsys"
- "mediatek,mt6797-scpsys"
- "mediatek,mt7622-scpsys"
- "mediatek,mt8173-scpsys"
@@ -27,6 +29,7 @@ Required properties:
   These are clocks which hardware needs to be
   enabled before enabling certain power domains.
Required clocks for MT2701: "mm", "mfg", "ethif"
+   Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", 
"vdec"
Required clocks for MT6797: "mm", "mfg", "vdec"
Required clocks for MT7622: "hif_sel"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
diff --git a/include/dt-bindings/power/mt2712-power.h 
b/include/dt-bindings/power/mt2712-power.h
new file mode 100644
index 000..92b46d7
--- /dev/null
+++ b/include/dt-bindings/power/mt2712-power.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2017 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 http://www.gnu.org/licenses/gpl-2.0.html for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2712_POWER_H
+#define _DT_BINDINGS_POWER_MT2712_POWER_H
+
+#define MT2712_POWER_DOMAIN_MM 0
+#define MT2712_POWER_DOMAIN_VDEC   1
+#define MT2712_POWER_DOMAIN_VENC   2
+#define MT2712_POWER_DOMAIN_ISP3
+#define MT2712_POWER_DOMAIN_AUDIO  4
+#define MT2712_POWER_DOMAIN_USB5
+#define MT2712_POWER_DOMAIN_USB2   6
+#define MT2712_POWER_DOMAIN_MFG7
+
+#endif /* _DT_BINDINGS_POWER_MT2712_POWER_H */
-- 
1.9.1

[PATCH v6 5/9] dt-bindings: soc: add MT2712 power dt-bindings

[Weiyi Lu]

Add power dt-bindings for MT2712.

Acked-by: Rob Herring 
Signed-off-by: Weiyi Lu 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt|  3 +++
 include/dt-bindings/power/mt2712-power.h   | 26 ++
 2 files changed, 29 insertions(+)
 create mode 100644 include/dt-bindings/power/mt2712-power.h

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 40056f7..76bf45b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -12,11 +12,13 @@ power/power_domain.txt. It provides the power domains 
defined in
 - include/dt-bindings/power/mt8173-power.h
 - include/dt-bindings/power/mt6797-power.h
 - include/dt-bindings/power/mt2701-power.h
+- include/dt-bindings/power/mt2712-power.h
 - include/dt-bindings/power/mt7622-power.h
 
 Required properties:
 - compatible: Should be one of:
- "mediatek,mt2701-scpsys"
+   - "mediatek,mt2712-scpsys"
- "mediatek,mt6797-scpsys"
- "mediatek,mt7622-scpsys"
- "mediatek,mt8173-scpsys"
@@ -27,6 +29,7 @@ Required properties:
   These are clocks which hardware needs to be
   enabled before enabling certain power domains.
Required clocks for MT2701: "mm", "mfg", "ethif"
+   Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", 
"vdec"
Required clocks for MT6797: "mm", "mfg", "vdec"
Required clocks for MT7622: "hif_sel"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
diff --git a/include/dt-bindings/power/mt2712-power.h 
b/include/dt-bindings/power/mt2712-power.h
new file mode 100644
index 000..92b46d7
--- /dev/null
+++ b/include/dt-bindings/power/mt2712-power.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2017 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 http://www.gnu.org/licenses/gpl-2.0.html for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2712_POWER_H
+#define _DT_BINDINGS_POWER_MT2712_POWER_H
+
+#define MT2712_POWER_DOMAIN_MM 0
+#define MT2712_POWER_DOMAIN_VDEC   1
+#define MT2712_POWER_DOMAIN_VENC   2
+#define MT2712_POWER_DOMAIN_ISP3
+#define MT2712_POWER_DOMAIN_AUDIO  4
+#define MT2712_POWER_DOMAIN_USB5
+#define MT2712_POWER_DOMAIN_USB2   6
+#define MT2712_POWER_DOMAIN_MFG7
+
+#endif /* _DT_BINDINGS_POWER_MT2712_POWER_H */
-- 
1.9.1

[PATCH v6 9/9] arm: dts: Add power controller device node of MT2712

[Weiyi Lu]

add power controller node for MT2712

Signed-off-by: Weiyi Lu 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index d2ee3cd..fa87f92 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "mediatek,mt2712";
@@ -147,6 +148,21 @@
#clock-cells = <1>;
};
 
+   scpsys: scpsys@10006000 {
+   compatible = "mediatek,mt2712-scpsys", "syscon";
+   #power-domain-cells = <1>;
+   reg = <0 0x10006000 0 0x1000>;
+   clocks = < CLK_TOP_MM_SEL>,
+< CLK_TOP_MFG_SEL>,
+< CLK_TOP_VENC_SEL>,
+< CLK_TOP_JPGDEC_SEL>,
+< CLK_TOP_A1SYS_HP_SEL>,
+< CLK_TOP_VDEC_SEL>;
+   clock-names = "mm", "mfg", "venc",
+   "jpgdec", "audio", "vdec";
+   infracfg = <>;
+   };
+
uart5: serial@1000f000 {
compatible = "mediatek,mt2712-uart",
 "mediatek,mt6577-uart";
-- 
1.9.1

[PATCH v6 1/9] dt-bindings: ARM: Mediatek: Document bindings for MT2712

[Weiyi Lu]

This patch adds the binding documentation for apmixedsys, bdpsys,
imgsys, imgsys, infracfg, mcucfg, mfgcfg, mmsys, pericfg, topckgen,
vdecsys and vencsys for Mediatek MT2712.

Acked-by: Rob Herring 
Signed-off-by: Weiyi Lu 
---
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  1 +
 .../bindings/arm/mediatek/mediatek,bdpsys.txt  |  1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |  1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|  1 +
 .../bindings/arm/mediatek/mediatek,jpgdecsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,mcucfg.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mfgcfg.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  1 +
 .../bindings/arm/mediatek/mediatek,pericfg.txt |  1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|  1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |  1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |  1 +
 12 files changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt

diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index cd977db..19fc116 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
+   - "mediatek,mt2712-apmixedsys", "syscon"
- "mediatek,mt6797-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8173-apmixedsys"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
index 4137196..4010e37 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be:
- "mediatek,mt2701-bdpsys", "syscon"
+   - "mediatek,mt2712-bdpsys", "syscon"
 - #clock-cells: Must be 1
 
 The bdpsys controller uses the common clk binding from
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index 047b11a..868bd51 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
+   - "mediatek,mt2712-imgsys", "syscon"
- "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
 - #clock-cells: Must be 1
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index 58d58e2..a3430cd 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -8,6 +8,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
+   - "mediatek,mt2712-infracfg", "syscon"
- "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
new file mode 100644
index 000..2df799c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek jpgdecsys controller
+
+
+The Mediatek jpgdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt2712-jpgdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The jpgdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+jpgdecsys: syscon@1900 {
+   compatible = "mediatek,mt2712-jpgdecsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
new file mode 100644
index 000..b8fb03f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
@@ -0,0 

[PATCH v6 0/9] Mediatek MT2712 clock and scpsys support

[Weiyi Lu]

This series is based on v4.14-rc1 and composed of
clock control (PATCH 1-4) and scpsys control (PATCH 5-9)

changes since v5:
- Refine bus protection with proper variable name
  and better implementation for the if statement.

changes since v4:
- Refine scpsys and infracfg for bus protection by passing 
  a boolean flag to determine the register update method

changes since v3:
- Rebase to v4.14-rc1.

changes since v2:
- ensure the clocks used by clocksource driver are registered
  before clocksource init() by using CLK_OF_DECLARE()
- correct the frequency of clk32k/clkrtc_ext/clkrtc_int

changes since v1:
- Rebase to v4.13-next-soc.
- Refine scpsys and infracfg for bus protection.

Weiyi Lu (9):
  dt-bindings: ARM: Mediatek: Document bindings for MT2712
  clk: mediatek: Add dt-bindings for MT2712 clocks
  clk: mediatek: Add MT2712 clock support
  arm: dts: mt2712: Add clock controller device nodes
  dt-bindings: soc: add MT2712 power dt-bindings
  soc: mediatek: extend bus protection API
  soc: mediatek: add dependent clock jpgdec/audio for scpsys
  soc: mediatek: add MT2712 scpsys support
  arm: dts: Add power controller device node of MT2712

 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,bdpsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
 .../bindings/arm/mediatek/mediatek,jpgdecsys.txt   |   22 +
 .../bindings/arm/mediatek/mediatek,mcucfg.txt  |   22 +
 .../bindings/arm/mediatek/mediatek,mfgcfg.txt  |   22 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
 .../bindings/arm/mediatek/mediatek,pericfg.txt |1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |1 +
 .../devicetree/bindings/soc/mediatek/scpsys.txt|3 +
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi  |  131 ++
 drivers/clk/mediatek/Kconfig   |   50 +
 drivers/clk/mediatek/Makefile  |8 +
 drivers/clk/mediatek/clk-mt2712-bdp.c  |  102 ++
 drivers/clk/mediatek/clk-mt2712-img.c  |   80 ++
 drivers/clk/mediatek/clk-mt2712-jpgdec.c   |   76 ++
 drivers/clk/mediatek/clk-mt2712-mfg.c  |   75 +
 drivers/clk/mediatek/clk-mt2712-mm.c   |  170 +++
 drivers/clk/mediatek/clk-mt2712-vdec.c |   94 ++
 drivers/clk/mediatek/clk-mt2712-venc.c |   77 ++
 drivers/clk/mediatek/clk-mt2712.c  | 1435 
 drivers/clk/mediatek/clk-mtk.h |2 +
 drivers/clk/mediatek/clk-pll.c |   13 +-
 drivers/soc/mediatek/mtk-infracfg.c|   26 +-
 drivers/soc/mediatek/mtk-scpsys.c  |  140 +-
 include/dt-bindings/clock/mt2712-clk.h |  427 ++
 include/dt-bindings/power/mt2712-power.h   |   26 +
 include/linux/soc/mediatek/infracfg.h  |7 +-
 31 files changed, 2993 insertions(+), 24 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt
 create mode 100644 drivers/clk/mediatek/clk-mt2712-bdp.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-jpgdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712.c
 create mode 100644 include/dt-bindings/clock/mt2712-clk.h
 create mode 100644 include/dt-bindings/power/mt2712-power.h

[PATCH v6 9/9] arm: dts: Add power controller device node of MT2712

[Weiyi Lu]

add power controller node for MT2712

Signed-off-by: Weiyi Lu 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index d2ee3cd..fa87f92 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "mediatek,mt2712";
@@ -147,6 +148,21 @@
#clock-cells = <1>;
};
 
+   scpsys: scpsys@10006000 {
+   compatible = "mediatek,mt2712-scpsys", "syscon";
+   #power-domain-cells = <1>;
+   reg = <0 0x10006000 0 0x1000>;
+   clocks = < CLK_TOP_MM_SEL>,
+< CLK_TOP_MFG_SEL>,
+< CLK_TOP_VENC_SEL>,
+< CLK_TOP_JPGDEC_SEL>,
+< CLK_TOP_A1SYS_HP_SEL>,
+< CLK_TOP_VDEC_SEL>;
+   clock-names = "mm", "mfg", "venc",
+   "jpgdec", "audio", "vdec";
+   infracfg = <>;
+   };
+
uart5: serial@1000f000 {
compatible = "mediatek,mt2712-uart",
 "mediatek,mt6577-uart";
-- 
1.9.1

[PATCH v6 1/9] dt-bindings: ARM: Mediatek: Document bindings for MT2712

[Weiyi Lu]

This patch adds the binding documentation for apmixedsys, bdpsys,
imgsys, imgsys, infracfg, mcucfg, mfgcfg, mmsys, pericfg, topckgen,
vdecsys and vencsys for Mediatek MT2712.

Acked-by: Rob Herring 
Signed-off-by: Weiyi Lu 
---
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  1 +
 .../bindings/arm/mediatek/mediatek,bdpsys.txt  |  1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |  1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|  1 +
 .../bindings/arm/mediatek/mediatek,jpgdecsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,mcucfg.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mfgcfg.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  1 +
 .../bindings/arm/mediatek/mediatek,pericfg.txt |  1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|  1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |  1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |  1 +
 12 files changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt

diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index cd977db..19fc116 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
+   - "mediatek,mt2712-apmixedsys", "syscon"
- "mediatek,mt6797-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8173-apmixedsys"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
index 4137196..4010e37 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be:
- "mediatek,mt2701-bdpsys", "syscon"
+   - "mediatek,mt2712-bdpsys", "syscon"
 - #clock-cells: Must be 1
 
 The bdpsys controller uses the common clk binding from
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index 047b11a..868bd51 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
+   - "mediatek,mt2712-imgsys", "syscon"
- "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
 - #clock-cells: Must be 1
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index 58d58e2..a3430cd 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -8,6 +8,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
+   - "mediatek,mt2712-infracfg", "syscon"
- "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
new file mode 100644
index 000..2df799c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek jpgdecsys controller
+
+
+The Mediatek jpgdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt2712-jpgdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The jpgdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+jpgdecsys: syscon@1900 {
+   compatible = "mediatek,mt2712-jpgdecsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
new file mode 100644
index 000..b8fb03f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
@@ -0,0 +1,22 @@
+Mediatek mcucfg controller

[PATCH v6 0/9] Mediatek MT2712 clock and scpsys support

[Weiyi Lu]

This series is based on v4.14-rc1 and composed of
clock control (PATCH 1-4) and scpsys control (PATCH 5-9)

changes since v5:
- Refine bus protection with proper variable name
  and better implementation for the if statement.

changes since v4:
- Refine scpsys and infracfg for bus protection by passing 
  a boolean flag to determine the register update method

changes since v3:
- Rebase to v4.14-rc1.

changes since v2:
- ensure the clocks used by clocksource driver are registered
  before clocksource init() by using CLK_OF_DECLARE()
- correct the frequency of clk32k/clkrtc_ext/clkrtc_int

changes since v1:
- Rebase to v4.13-next-soc.
- Refine scpsys and infracfg for bus protection.

Weiyi Lu (9):
  dt-bindings: ARM: Mediatek: Document bindings for MT2712
  clk: mediatek: Add dt-bindings for MT2712 clocks
  clk: mediatek: Add MT2712 clock support
  arm: dts: mt2712: Add clock controller device nodes
  dt-bindings: soc: add MT2712 power dt-bindings
  soc: mediatek: extend bus protection API
  soc: mediatek: add dependent clock jpgdec/audio for scpsys
  soc: mediatek: add MT2712 scpsys support
  arm: dts: Add power controller device node of MT2712

 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,bdpsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
 .../bindings/arm/mediatek/mediatek,jpgdecsys.txt   |   22 +
 .../bindings/arm/mediatek/mediatek,mcucfg.txt  |   22 +
 .../bindings/arm/mediatek/mediatek,mfgcfg.txt  |   22 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
 .../bindings/arm/mediatek/mediatek,pericfg.txt |1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |1 +
 .../devicetree/bindings/soc/mediatek/scpsys.txt|3 +
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi  |  131 ++
 drivers/clk/mediatek/Kconfig   |   50 +
 drivers/clk/mediatek/Makefile  |8 +
 drivers/clk/mediatek/clk-mt2712-bdp.c  |  102 ++
 drivers/clk/mediatek/clk-mt2712-img.c  |   80 ++
 drivers/clk/mediatek/clk-mt2712-jpgdec.c   |   76 ++
 drivers/clk/mediatek/clk-mt2712-mfg.c  |   75 +
 drivers/clk/mediatek/clk-mt2712-mm.c   |  170 +++
 drivers/clk/mediatek/clk-mt2712-vdec.c |   94 ++
 drivers/clk/mediatek/clk-mt2712-venc.c |   77 ++
 drivers/clk/mediatek/clk-mt2712.c  | 1435 
 drivers/clk/mediatek/clk-mtk.h |2 +
 drivers/clk/mediatek/clk-pll.c |   13 +-
 drivers/soc/mediatek/mtk-infracfg.c|   26 +-
 drivers/soc/mediatek/mtk-scpsys.c  |  140 +-
 include/dt-bindings/clock/mt2712-clk.h |  427 ++
 include/dt-bindings/power/mt2712-power.h   |   26 +
 include/linux/soc/mediatek/infracfg.h  |7 +-
 31 files changed, 2993 insertions(+), 24 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt
 create mode 100644 drivers/clk/mediatek/clk-mt2712-bdp.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-jpgdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt2712.c
 create mode 100644 include/dt-bindings/clock/mt2712-clk.h
 create mode 100644 include/dt-bindings/power/mt2712-power.h

Re: [PATCH] printk: fix typo in printk_safe.c

[Sergey Senozhatsky]

On (10/22/17 22:30), Baoquan He wrote:
> Signed-off-by: Baoquan He 

Reviewed-by: Sergey Senozhatsky 

-ss

> ---
>  kernel/printk/printk_safe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> index 3cdaeaef9ce1..89558b85f45c 100644
> --- a/kernel/printk/printk_safe.c
> +++ b/kernel/printk/printk_safe.c
> @@ -75,7 +75,7 @@ static void queue_flush_work(struct printk_safe_seq_buf *s)
>   * have dedicated buffers, because otherwise printk-safe preempted by
>   * NMI-printk would have overwritten the NMI messages.
>   *
> - * The messages are fushed from irq work (or from panic()), possibly,
> + * The messages are flushed from irq work (or from panic()), possibly,
>   * from other CPU, concurrently with printk_safe_log_store(). Should this
>   * happen, printk_safe_log_store() will notice the buffer->len mismatch
>   * and repeat the write.
> -- 
> 2.5.5
> 

Re: [PATCH] printk: fix typo in printk_safe.c

[Sergey Senozhatsky]

On (10/22/17 22:30), Baoquan He wrote:
> Signed-off-by: Baoquan He 

Reviewed-by: Sergey Senozhatsky 

-ss

> ---
>  kernel/printk/printk_safe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> index 3cdaeaef9ce1..89558b85f45c 100644
> --- a/kernel/printk/printk_safe.c
> +++ b/kernel/printk/printk_safe.c
> @@ -75,7 +75,7 @@ static void queue_flush_work(struct printk_safe_seq_buf *s)
>   * have dedicated buffers, because otherwise printk-safe preempted by
>   * NMI-printk would have overwritten the NMI messages.
>   *
> - * The messages are fushed from irq work (or from panic()), possibly,
> + * The messages are flushed from irq work (or from panic()), possibly,
>   * from other CPU, concurrently with printk_safe_log_store(). Should this
>   * happen, printk_safe_log_store() will notice the buffer->len mismatch
>   * and repeat the write.
> -- 
> 2.5.5
> 

PROBLEM: Kernel 4.13.8 hangs on boot (no output, log entries) on Surface Book

[Benjamin Braun]

Hi lkml,

Linux 4.13.8 hangs on boot very early, so no output or log entries and
just a blank screen after bootloader, on Surface Book.

https://bugzilla.kernel.org/show_bug.cgi?id=197359

A parallel bug report on Ubuntu suggests the problem starts at 4.13.0
and persists to 4.14.0.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1724657

Thanks,
-Ben

PROBLEM: Kernel 4.13.8 hangs on boot (no output, log entries) on Surface Book

[Benjamin Braun]

Hi lkml,

Linux 4.13.8 hangs on boot very early, so no output or log entries and
just a blank screen after bootloader, on Surface Book.

https://bugzilla.kernel.org/show_bug.cgi?id=197359

A parallel bug report on Ubuntu suggests the problem starts at 4.13.0
and persists to 4.14.0.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1724657

Thanks,
-Ben

[PATCH v2] ARM: Remove .pad section when CONFIG_EFI_STUB enabled

[Jeffy Chen]

Currently we are using the .pad section to ensure the zImage file size
aligned to 8 bytes.

But that is not needed when CONFIG_EFI_STUB enabled, as it would
followed by a 512 bytes aligned .data section.

Signed-off-by: Jeffy Chen 
---

Changes in v2:
Remove .pad section when CONFIG_EFI_STUB enabled as Russell King 
 suggested.

 arch/arm/boot/compressed/vmlinux.lds.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..394b2bf5d28a 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
   .got : { *(.got) }
   _got_end = .;
 
-  /* ensure the zImage file size is always a multiple of 64 bits */
-  /* (without a dummy byte, ld just ignores the empty section) */
-  .pad : { BYTE(0); . = ALIGN(8); }
-
 #ifdef CONFIG_EFI_STUB
   .data : ALIGN(4096) {
 __pecoff_data_start = .;
@@ -91,6 +87,10 @@ SECTIONS
 . = ALIGN(512);
   }
   __pecoff_data_rawsize = . - ADDR(.data);
+#else
+  /* ensure the zImage file size is always a multiple of 64 bits */
+  /* (without a dummy byte, ld just ignores the empty section) */
+  .pad : { BYTE(0); . = ALIGN(8); }
 #endif
 
   _edata = .;
-- 
2.11.0

[PATCH v2] ARM: Remove .pad section when CONFIG_EFI_STUB enabled

[Jeffy Chen]

Currently we are using the .pad section to ensure the zImage file size
aligned to 8 bytes.

But that is not needed when CONFIG_EFI_STUB enabled, as it would
followed by a 512 bytes aligned .data section.

Signed-off-by: Jeffy Chen 
---

Changes in v2:
Remove .pad section when CONFIG_EFI_STUB enabled as Russell King 
 suggested.

 arch/arm/boot/compressed/vmlinux.lds.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..394b2bf5d28a 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
   .got : { *(.got) }
   _got_end = .;
 
-  /* ensure the zImage file size is always a multiple of 64 bits */
-  /* (without a dummy byte, ld just ignores the empty section) */
-  .pad : { BYTE(0); . = ALIGN(8); }
-
 #ifdef CONFIG_EFI_STUB
   .data : ALIGN(4096) {
 __pecoff_data_start = .;
@@ -91,6 +87,10 @@ SECTIONS
 . = ALIGN(512);
   }
   __pecoff_data_rawsize = . - ADDR(.data);
+#else
+  /* ensure the zImage file size is always a multiple of 64 bits */
+  /* (without a dummy byte, ld just ignores the empty section) */
+  .pad : { BYTE(0); . = ALIGN(8); }
 #endif
 
   _edata = .;
-- 
2.11.0

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

[jeffy]

Hi Ard,

On 10/22/2017 09:01 PM, Ard Biesheuvel wrote:

On 22 October 2017 at 13:47, Russell King - ARM Linux
 wrote:

On Sun, Oct 22, 2017 at 12:01:13PM +0100, Ard Biesheuvel wrote:

On 18 October 2017 at 06:01, Jeffy Chen  wrote:

The zImage file size should be aligned.

Fixes: e4bae4d0b5f3 ("arm/efi: Split zImage code and data into separate PE/COFF 
sections")
Signed-off-by: Jeffy Chen 
---

  arch/arm/boot/compressed/vmlinux.lds.S | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..1636fa259577 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
.got : { *(.got) }
_got_end = .;

-  /* ensure the zImage file size is always a multiple of 64 bits */
-  /* (without a dummy byte, ld just ignores the empty section) */
-  .pad : { BYTE(0); . = ALIGN(8); }
-
  #ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
  __pecoff_data_start = .;
@@ -93,6 +89,10 @@ SECTIONS
__pecoff_data_rawsize = . - ADDR(.data);
  #endif

+  /* ensure the zImage file size is always a multiple of 64 bits */
+  /* (without a dummy byte, ld just ignores the empty section) */
+  .pad : { BYTE(0); . = ALIGN(8); }
+
_edata = .;

_magic_sig = ZIMAGE_MAGIC(0x016f2818);
--
2.11.0



This is not the right fix. If CONFIG_EFI_STUB is enabled, the zImage
filesize should be rounded up to 512 bytes not 8 bytes. The '. =
ALIGN(512);' in the .data section appears to ensure that, but for some
reason, that appears not to be working.


Actually, the existing .pad section is totally and utterly bogus when
EFI is enabled:

   . = ALIGN(4);
   _etext = .;

   .got.plt  : { *(.got.plt) }
   _got_start = .;
   .got  : { *(.got) }
   _got_end = .;

The .got.plt and .got are always word-based.  This is then followed by
.pad, which does nothing but pad out to a multiple of 64 bit:

   /* ensure the zImage file size is always a multiple of 64 bits */
   /* (without a dummy byte, ld just ignores the empty section) */
   .pad  : { BYTE(0); . = ALIGN(8); }

So this may add zero or 4 bytes of padding.

This is then followed by the EFI data:

   .data : ALIGN(4096) {
   ...
 . = ALIGN(512);
   }

which is aligned to 4K but aligns the end of itself to 512.

So, we have the end of .got aligned to 4, followed by .pad that tries to
align to 8, followed by an optional .data section.  This is pointless.

A sane patch would be to choose between the EFI .data section and the
.pad section.  So, it should be:

#ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
...
  . = ALIGN(512);
}
#else
.pad : { BYTE(0); . = ALIGN(8); }
#endif



Agreed, the .pad section has no point for EFI_STUB=y. However, it
seems this symptom is caused by the same issues I am trying to address
here

https://marc.info/?l=linux-arm-kernel=150488477807353

which is that we have __ksymtab_xxx sections that we should discard,
because the linker will otherwise emit them /after/ .data or .pad.
This is caused by the use of lib/sort.c in the EFI stub, which
contains an EXPORT_SYMBOL().


hmm, right, didn't notice the data is already aligned...
so it's indeed caused by the ksym:

  [ 9] .data PROGBITS006ce000 6d6000 000200 00  WA 
 0   0 4096
  [10] ___ksymtab+sort   PROGBITS006ce200 6d6200 08 00  WA 
 0   0  4
  [11] .bss  NOBITS  006ce208 6d6208 1c 00  WA 
 0   0  4



and both of your old([PATCH] ARM: compressed: discard ksym/kcrctab input 
section) and new([PATCH] efi/libstub: arm: omit sorting of the UEFI 
memory map) patches fix the issue i meet, thanks:)




Would you perhaps prefer that I clone sort.c into its own .c file
specifically for the EFI stub? (under drivers/firmware/efi/libstub)
That should get rid of these spurious sections and thus the
misalignments and/or movements that are causing all of these issues.

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

[jeffy]

Hi Ard,

On 10/22/2017 09:01 PM, Ard Biesheuvel wrote:

On 22 October 2017 at 13:47, Russell King - ARM Linux
 wrote:

On Sun, Oct 22, 2017 at 12:01:13PM +0100, Ard Biesheuvel wrote:

On 18 October 2017 at 06:01, Jeffy Chen  wrote:

The zImage file size should be aligned.

Fixes: e4bae4d0b5f3 ("arm/efi: Split zImage code and data into separate PE/COFF 
sections")
Signed-off-by: Jeffy Chen 
---

  arch/arm/boot/compressed/vmlinux.lds.S | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..1636fa259577 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
.got : { *(.got) }
_got_end = .;

-  /* ensure the zImage file size is always a multiple of 64 bits */
-  /* (without a dummy byte, ld just ignores the empty section) */
-  .pad : { BYTE(0); . = ALIGN(8); }
-
  #ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
  __pecoff_data_start = .;
@@ -93,6 +89,10 @@ SECTIONS
__pecoff_data_rawsize = . - ADDR(.data);
  #endif

+  /* ensure the zImage file size is always a multiple of 64 bits */
+  /* (without a dummy byte, ld just ignores the empty section) */
+  .pad : { BYTE(0); . = ALIGN(8); }
+
_edata = .;

_magic_sig = ZIMAGE_MAGIC(0x016f2818);
--
2.11.0



This is not the right fix. If CONFIG_EFI_STUB is enabled, the zImage
filesize should be rounded up to 512 bytes not 8 bytes. The '. =
ALIGN(512);' in the .data section appears to ensure that, but for some
reason, that appears not to be working.


Actually, the existing .pad section is totally and utterly bogus when
EFI is enabled:

   . = ALIGN(4);
   _etext = .;

   .got.plt  : { *(.got.plt) }
   _got_start = .;
   .got  : { *(.got) }
   _got_end = .;

The .got.plt and .got are always word-based.  This is then followed by
.pad, which does nothing but pad out to a multiple of 64 bit:

   /* ensure the zImage file size is always a multiple of 64 bits */
   /* (without a dummy byte, ld just ignores the empty section) */
   .pad  : { BYTE(0); . = ALIGN(8); }

So this may add zero or 4 bytes of padding.

This is then followed by the EFI data:

   .data : ALIGN(4096) {
   ...
 . = ALIGN(512);
   }

which is aligned to 4K but aligns the end of itself to 512.

So, we have the end of .got aligned to 4, followed by .pad that tries to
align to 8, followed by an optional .data section.  This is pointless.

A sane patch would be to choose between the EFI .data section and the
.pad section.  So, it should be:

#ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
...
  . = ALIGN(512);
}
#else
.pad : { BYTE(0); . = ALIGN(8); }
#endif



Agreed, the .pad section has no point for EFI_STUB=y. However, it
seems this symptom is caused by the same issues I am trying to address
here

https://marc.info/?l=linux-arm-kernel=150488477807353

which is that we have __ksymtab_xxx sections that we should discard,
because the linker will otherwise emit them /after/ .data or .pad.
This is caused by the use of lib/sort.c in the EFI stub, which
contains an EXPORT_SYMBOL().


hmm, right, didn't notice the data is already aligned...
so it's indeed caused by the ksym:

  [ 9] .data PROGBITS006ce000 6d6000 000200 00  WA 
 0   0 4096
  [10] ___ksymtab+sort   PROGBITS006ce200 6d6200 08 00  WA 
 0   0  4
  [11] .bss  NOBITS  006ce208 6d6208 1c 00  WA 
 0   0  4



and both of your old([PATCH] ARM: compressed: discard ksym/kcrctab input 
section) and new([PATCH] efi/libstub: arm: omit sorting of the UEFI 
memory map) patches fix the issue i meet, thanks:)




Would you perhaps prefer that I clone sort.c into its own .c file
specifically for the EFI stub? (under drivers/firmware/efi/libstub)
That should get rid of these spurious sections and thus the
misalignments and/or movements that are causing all of these issues.

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

[santosh.shilim...@oracle.com]

On 10/10/17 12:19 AM, Mark Brown wrote:

Hi Santosh,

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

   DTC arch/arm/boot/dts/keystone-k2g-evm.dtb
Error: /home/broonie/tmpfs/next/arch/arm/boot/dts/keystone-k2g-evm.dts:150.1-15 
syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:316: recipe for target 
'arch/arm/boot/dts/keystone-k2g-evm.dtb' failed
make[2]: *** [arch/arm/boot/dts/keystone-k2g-evm.dtb] Error 1

Caused by commit

a6f244505915f ("ARM: dts: keystone-k2g-evm: Add I2C EEPROM DT entry")

I've used the keystone tree from yesterday.


I fixed this next day but forgot to reply to you Mark.

Regards,
Santosh

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

[santosh.shilim...@oracle.com]

On 10/10/17 12:19 AM, Mark Brown wrote:

Hi Santosh,

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

   DTC arch/arm/boot/dts/keystone-k2g-evm.dtb
Error: /home/broonie/tmpfs/next/arch/arm/boot/dts/keystone-k2g-evm.dts:150.1-15 
syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:316: recipe for target 
'arch/arm/boot/dts/keystone-k2g-evm.dtb' failed
make[2]: *** [arch/arm/boot/dts/keystone-k2g-evm.dtb] Error 1

Caused by commit

a6f244505915f ("ARM: dts: keystone-k2g-evm: Add I2C EEPROM DT entry")

I've used the keystone tree from yesterday.


I fixed this next day but forgot to reply to you Mark.

Regards,
Santosh

Re: [PATCH] mm/swap: Use page flags to determine LRU list in __activate_page()

[Anshuman Khandual]

On 10/19/2017 09:03 PM, Michal Hocko wrote:
> On Thu 19-10-17 20:26:57, Anshuman Khandual wrote:
>> Its already assumed that the PageActive flag is clear on the input
>> page, hence page_lru(page) will pick the base LRU for the page. In
>> the same way page_lru(page) will pick active base LRU, once the
>> flag PageActive is set on the page. This change of LRU list should
>> happen implicitly through the page flags instead of being hard
>> coded.
> 
> The patch description tells what but it doesn't explain _why_? Does the
> resulting code is better, more optimized or is this a pure readability
> thing?

Not really. Not only it removes couple of lines of code but it also
makes it look more logical from function flow point of view as well.

> 
> All I can see is that page_lru is more complex and a large part of it
> can be optimized away which has been done manually here. I suspect the
> compiler can deduce the same thing.

Why not ? I mean, that is the essence of the function page_lru() which
should get us the exact LRU list the page should be on and hence we
should not hand craft these manually.

Re: [PATCH] mm/swap: Use page flags to determine LRU list in __activate_page()

[Anshuman Khandual]

On 10/19/2017 09:03 PM, Michal Hocko wrote:
> On Thu 19-10-17 20:26:57, Anshuman Khandual wrote:
>> Its already assumed that the PageActive flag is clear on the input
>> page, hence page_lru(page) will pick the base LRU for the page. In
>> the same way page_lru(page) will pick active base LRU, once the
>> flag PageActive is set on the page. This change of LRU list should
>> happen implicitly through the page flags instead of being hard
>> coded.
> 
> The patch description tells what but it doesn't explain _why_? Does the
> resulting code is better, more optimized or is this a pure readability
> thing?

Not really. Not only it removes couple of lines of code but it also
makes it look more logical from function flow point of view as well.

> 
> All I can see is that page_lru is more complex and a large part of it
> can be optimized away which has been done manually here. I suspect the
> compiler can deduce the same thing.

Why not ? I mean, that is the essence of the function page_lru() which
should get us the exact LRU list the page should be on and hence we
should not hand craft these manually.

[PATCH v5] of: dynamic: fix memory leak related to properties of __of_node_dup

[Lixin Wang]

If a node with no properties is dynamically added, then a property is
dynamically added to the node, then the property is dynamically removed,
the result will be node->properties == NULL and node->deadprops != NULL.

Add a separate function to release the properties in both lists.

Signed-off-by: Lixin Wang 
---
 v4 -> v5:
 * fix the bug in v4, that the prop->next should be saved before release
   the prop.

 drivers/of/dynamic.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..39d69d3 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -315,6 +315,18 @@ int of_detach_node(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_detach_node);
 
+static void property_list_free(struct property *prop_list)
+{
+   struct property *prop, *next;
+
+   for (prop = prop_list; prop != NULL; prop = next) {
+   next = prop->next;
+   kfree(prop->name);
+   kfree(prop->value);
+   kfree(prop);
+   }
+}
+
 /**
  * of_node_release() - release a dynamically allocated node
  * @kref: kref element of the node to be released
@@ -324,7 +336,6 @@ EXPORT_SYMBOL_GPL(of_detach_node);
 void of_node_release(struct kobject *kobj)
 {
struct device_node *node = kobj_to_device_node(kobj);
-   struct property *prop = node->properties;
 
/* We should never be releasing nodes that haven't been detached. */
if (!of_node_check_flag(node, OF_DETACHED)) {
@@ -335,18 +346,9 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
 
-   while (prop) {
-   struct property *next = prop->next;
-   kfree(prop->name);
-   kfree(prop->value);
-   kfree(prop);
-   prop = next;
+   property_list_free(node->properties);
+   property_list_free(node->deadprops);
 
-   if (!prop) {
-   prop = node->deadprops;
-   node->deadprops = NULL;
-   }
-   }
kfree(node->full_name);
kfree(node->data);
kfree(node);
-- 
2.6.2

[PATCH v5] of: dynamic: fix memory leak related to properties of __of_node_dup

[Lixin Wang]

If a node with no properties is dynamically added, then a property is
dynamically added to the node, then the property is dynamically removed,
the result will be node->properties == NULL and node->deadprops != NULL.

Add a separate function to release the properties in both lists.

Signed-off-by: Lixin Wang 
---
 v4 -> v5:
 * fix the bug in v4, that the prop->next should be saved before release
   the prop.

 drivers/of/dynamic.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..39d69d3 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -315,6 +315,18 @@ int of_detach_node(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_detach_node);
 
+static void property_list_free(struct property *prop_list)
+{
+   struct property *prop, *next;
+
+   for (prop = prop_list; prop != NULL; prop = next) {
+   next = prop->next;
+   kfree(prop->name);
+   kfree(prop->value);
+   kfree(prop);
+   }
+}
+
 /**
  * of_node_release() - release a dynamically allocated node
  * @kref: kref element of the node to be released
@@ -324,7 +336,6 @@ EXPORT_SYMBOL_GPL(of_detach_node);
 void of_node_release(struct kobject *kobj)
 {
struct device_node *node = kobj_to_device_node(kobj);
-   struct property *prop = node->properties;
 
/* We should never be releasing nodes that haven't been detached. */
if (!of_node_check_flag(node, OF_DETACHED)) {
@@ -335,18 +346,9 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
 
-   while (prop) {
-   struct property *next = prop->next;
-   kfree(prop->name);
-   kfree(prop->value);
-   kfree(prop);
-   prop = next;
+   property_list_free(node->properties);
+   property_list_free(node->deadprops);
 
-   if (!prop) {
-   prop = node->deadprops;
-   node->deadprops = NULL;
-   }
-   }
kfree(node->full_name);
kfree(node->data);
kfree(node);
-- 
2.6.2

Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS

[Minchan Kim]

On Fri, Oct 20, 2017 at 10:59:31PM +0300, Kirill A. Shutemov wrote:
> With boot-time switching between paging mode we will have variable
> MAX_PHYSMEM_BITS.
> 
> Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y
> configuration to define zsmalloc data structures.
> 
> The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case.
> It also suits well to handle PAE special case.
> 
> Signed-off-by: Kirill A. Shutemov 
> Cc: Minchan Kim 
> Cc: Nitin Gupta 
> Cc: Sergey Senozhatsky 
Acked-by: Minchan Kim 

Nitin:

I think this patch works and it would be best for Kirill to be able to do.
So if you have better idea to clean it up, let's make it as another patch
regardless of this patch series.

Thanks.

Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS

[Minchan Kim]

On Fri, Oct 20, 2017 at 10:59:31PM +0300, Kirill A. Shutemov wrote:
> With boot-time switching between paging mode we will have variable
> MAX_PHYSMEM_BITS.
> 
> Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y
> configuration to define zsmalloc data structures.
> 
> The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case.
> It also suits well to handle PAE special case.
> 
> Signed-off-by: Kirill A. Shutemov 
> Cc: Minchan Kim 
> Cc: Nitin Gupta 
> Cc: Sergey Senozhatsky 
Acked-by: Minchan Kim 

Nitin:

I think this patch works and it would be best for Kirill to be able to do.
So if you have better idea to clean it up, let's make it as another patch
regardless of this patch series.

Thanks.

Re: [RFC] mm/swap: Rename pagevec_lru_move_fn() as pagevec_lruvec_move_fn()

[Anshuman Khandual]

On 10/19/2017 08:59 PM, Michal Hocko wrote:
> On Thu 19-10-17 14:03:14, Anshuman Khandual wrote:
>> The function pagevec_lru_move_fn() actually moves pages from various
>> per cpu pagevecs into per node lruvecs with a custom function which
>> knows how to handle individual pages present in any given pagevec.
>> Because it does movement between pagevecs and lruvecs as whole not
>> to an individual list element, the name should reflect it.
> I find the original name quite understandable (and shorter). I do not
> think this is worth changing. It is just a code churn without a good
> reason.
> 

Sure, I understand.

Re: [RFC] mm/swap: Rename pagevec_lru_move_fn() as pagevec_lruvec_move_fn()

[Anshuman Khandual]

On 10/19/2017 08:59 PM, Michal Hocko wrote:
> On Thu 19-10-17 14:03:14, Anshuman Khandual wrote:
>> The function pagevec_lru_move_fn() actually moves pages from various
>> per cpu pagevecs into per node lruvecs with a custom function which
>> knows how to handle individual pages present in any given pagevec.
>> Because it does movement between pagevecs and lruvecs as whole not
>> to an individual list element, the name should reflect it.
> I find the original name quite understandable (and shorter). I do not
> think this is worth changing. It is just a code churn without a good
> reason.
> 

Sure, I understand.

Re: [PATCH V3] selftests/vm: Add tests validating mremap mirror functionality

[Anshuman Khandual]

On 10/20/2017 04:54 AM, Mike Kravetz wrote:
> On 10/17/2017 10:55 PM, Anshuman Khandual wrote:
>> This adds two tests to validate mirror functionality with mremap()
>> system call on shared and private anon mappings. After the commit
>> dba58d3b8c5 ("mm/mremap: fail map duplication attempts for private
>> mappings"), any attempt to mirror private anon mapping will fail.
>>
>> Suggested-by: Mike Kravetz 
>> Signed-off-by: Anshuman Khandual 
> The tests themselves look fine.  However, they are pretty simple and
> could very easily be combined into one 'mremap_mirror.c' file.  I
> would prefer that they be combined, but it is not a deal breaker.
> 
> Reviewed-by: Mike Kravetz 
> 

Hello Andrew/Shuah,

Is this okay or should I resend this patch with both tests folded
into one test case file ?

- Anshuman

Re: [PATCH V3] selftests/vm: Add tests validating mremap mirror functionality

[Anshuman Khandual]

On 10/20/2017 04:54 AM, Mike Kravetz wrote:
> On 10/17/2017 10:55 PM, Anshuman Khandual wrote:
>> This adds two tests to validate mirror functionality with mremap()
>> system call on shared and private anon mappings. After the commit
>> dba58d3b8c5 ("mm/mremap: fail map duplication attempts for private
>> mappings"), any attempt to mirror private anon mapping will fail.
>>
>> Suggested-by: Mike Kravetz 
>> Signed-off-by: Anshuman Khandual 
> The tests themselves look fine.  However, they are pretty simple and
> could very easily be combined into one 'mremap_mirror.c' file.  I
> would prefer that they be combined, but it is not a deal breaker.
> 
> Reviewed-by: Mike Kravetz 
> 

Hello Andrew/Shuah,

Is this okay or should I resend this patch with both tests folded
into one test case file ?

- Anshuman

Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API

[Michael Turquette]

Hi all,

On Fri, Oct 20, 2017 at 3:34 PM, Bjorn Andersson
 wrote:
> On Fri 20 Oct 07:43 PDT 2017, Georgi Djakov wrote:
>
>> Hi,
>>
>> On 09/08/2017 08:18 PM, Georgi Djakov wrote:
>> > This patch introduce a new API to get requirements and configure the
>> > interconnect buses across the entire chipset to fit with the current 
>> > demand.
>> >
>> > The API is using a consumer/provider-based model, where the providers are
>> > the interconnect buses and the consumers could be various drivers.
>> > The consumers request interconnect resources (path) between endpoints and
>> > set the desired constraints on this data flow path. The providers receive
>> > requests from consumers and aggregate these requests for all master-slave
>> > pairs on that path. Then the providers configure each participating in the
>> > topology node according to the requested data flow path, physical links and
>> > constraints. The topology could be complicated and multi-tiered and is SoC
>> > specific.
>> >
>> > Signed-off-by: Georgi Djakov 
>> > ---
>> >  Documentation/interconnect/interconnect.rst |  93 +++
>> >  drivers/Kconfig |   2 +
>> >  drivers/Makefile|   1 +
>> >  drivers/interconnect/Kconfig|  10 +
>> >  drivers/interconnect/Makefile   |   1 +
>> >  drivers/interconnect/interconnect.c | 382 
>> > 
>> >  include/linux/interconnect-consumer.h   |  73 ++
>> >  include/linux/interconnect-provider.h   | 119 +
>> >  8 files changed, 681 insertions(+)
>> >  create mode 100644 Documentation/interconnect/interconnect.rst
>> >  create mode 100644 drivers/interconnect/Kconfig
>> >  create mode 100644 drivers/interconnect/Makefile
>> >  create mode 100644 drivers/interconnect/interconnect.c
>> >  create mode 100644 include/linux/interconnect-consumer.h
>> >  create mode 100644 include/linux/interconnect-provider.h
>>
>> Any comments on this patch?
>>
>
> Sorry, I still haven't found the time to do a proper review of this yet.

Same.

>
>> I am planning to change the prefix that is used for naming for example
>> the functions from "interconnect_" to something shorter like icbus_.
>>
>
> This isn't implementing a bus; if you feel that just ic_ is too short I
> would suggest naming things inter_. (But keep the full name in the file
> names)

Not trying to bikeshed too much, but how about icc_ for "interconnect
controller"? No idea if that is a hash collision with other in-kernel
apis.

Just "ic_" looks to me like "integrated circuit".

Regards,
Mike

>
> Regards,
> Bjorn

Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API

[Michael Turquette]

Hi all,

On Fri, Oct 20, 2017 at 3:34 PM, Bjorn Andersson
 wrote:
> On Fri 20 Oct 07:43 PDT 2017, Georgi Djakov wrote:
>
>> Hi,
>>
>> On 09/08/2017 08:18 PM, Georgi Djakov wrote:
>> > This patch introduce a new API to get requirements and configure the
>> > interconnect buses across the entire chipset to fit with the current 
>> > demand.
>> >
>> > The API is using a consumer/provider-based model, where the providers are
>> > the interconnect buses and the consumers could be various drivers.
>> > The consumers request interconnect resources (path) between endpoints and
>> > set the desired constraints on this data flow path. The providers receive
>> > requests from consumers and aggregate these requests for all master-slave
>> > pairs on that path. Then the providers configure each participating in the
>> > topology node according to the requested data flow path, physical links and
>> > constraints. The topology could be complicated and multi-tiered and is SoC
>> > specific.
>> >
>> > Signed-off-by: Georgi Djakov 
>> > ---
>> >  Documentation/interconnect/interconnect.rst |  93 +++
>> >  drivers/Kconfig |   2 +
>> >  drivers/Makefile|   1 +
>> >  drivers/interconnect/Kconfig|  10 +
>> >  drivers/interconnect/Makefile   |   1 +
>> >  drivers/interconnect/interconnect.c | 382 
>> > 
>> >  include/linux/interconnect-consumer.h   |  73 ++
>> >  include/linux/interconnect-provider.h   | 119 +
>> >  8 files changed, 681 insertions(+)
>> >  create mode 100644 Documentation/interconnect/interconnect.rst
>> >  create mode 100644 drivers/interconnect/Kconfig
>> >  create mode 100644 drivers/interconnect/Makefile
>> >  create mode 100644 drivers/interconnect/interconnect.c
>> >  create mode 100644 include/linux/interconnect-consumer.h
>> >  create mode 100644 include/linux/interconnect-provider.h
>>
>> Any comments on this patch?
>>
>
> Sorry, I still haven't found the time to do a proper review of this yet.

Same.

>
>> I am planning to change the prefix that is used for naming for example
>> the functions from "interconnect_" to something shorter like icbus_.
>>
>
> This isn't implementing a bus; if you feel that just ic_ is too short I
> would suggest naming things inter_. (But keep the full name in the file
> names)

Not trying to bikeshed too much, but how about icc_ for "interconnect
controller"? No idea if that is a hash collision with other in-kernel
apis.

Just "ic_" looks to me like "integrated circuit".

Regards,
Mike

>
> Regards,
> Bjorn

Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

[Jarkko Sakkinen]

On Fri, Oct 20, 2017 at 02:42:54PM +, alexander.stef...@infineon.com wrote:
> > The TPM burstcount status indicates the number of bytes that can
> > be sent to the TPM without causing bus wait states.  Effectively,
> > it is the number of empty bytes in the command FIFO.
> > 
> > This patch optimizes the tpm_tis_send_data() function by checking
> > the burstcount only once. And if the burstcount is valid, it writes
> > all the bytes at once, permitting wait state.
> > 
> > After this change, performance on a TPM 1.2 with an 8 byte
> > burstcount for 1000 extends improved from ~41sec to ~14sec.
> > 
> > Suggested-by: Ken Goldman  in
> > conjunction with the TPM Device Driver work group.
> > Signed-off-by: Nayna Jain 
> > Acked-by: Mimi Zohar 
> > ---
> >  drivers/char/tpm/tpm_tis_core.c | 42 +++--
> > 
> >  1 file changed, 15 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > b/drivers/char/tpm/tpm_tis_core.c
> > index b33126a35694..993328ae988c 100644
> > --- a/drivers/char/tpm/tpm_tis_core.c
> > +++ b/drivers/char/tpm/tpm_tis_core.c
> > @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> >  {
> > struct tpm_tis_data *priv = dev_get_drvdata(>dev);
> > int rc, status, burstcnt;
> > -   size_t count = 0;
> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
> > 
> > status = tpm_tis_status(chip);
> > @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> > }
> > }
> > 
> > -   while (count < len - 1) {
> > -   burstcnt = get_burstcount(chip);
> > -   if (burstcnt < 0) {
> > -   dev_err(>dev, "Unable to read burstcount\n");
> > -   rc = burstcnt;
> > -   goto out_err;
> > -   }
> > -   burstcnt = min_t(int, burstcnt, len - count - 1);
> > -   rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv-
> > >locality),
> > -burstcnt, buf + count);
> > -   if (rc < 0)
> > -   goto out_err;
> > -
> > -   count += burstcnt;
> > -
> > -   if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip-
> > >timeout_c,
> > -   >int_queue, false) < 0) {
> > -   rc = -ETIME;
> > -   goto out_err;
> > -   }
> > -   status = tpm_tis_status(chip);
> > -   if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
> > -   rc = -EIO;
> > -   goto out_err;
> > -   }
> > +   /*
> > +* Get the initial burstcount to ensure TPM is ready to
> > +* accept data.
> > +*/
> > +   burstcnt = get_burstcount(chip);
> > +   if (burstcnt < 0) {
> > +   dev_err(>dev, "Unable to read burstcount\n");
> > +   rc = burstcnt;
> > +   goto out_err;
> > }
> > 
> > +   rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality),
> > +   len - 1, buf);
> > +   if (rc < 0)
> > +   goto out_err;
> > +
> > /* write last byte */
> > -   rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality),
> > buf[count]);
> > +   rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len-
> > 1]);
> > if (rc < 0)
> > goto out_err;
> > 
> > --
> > 2.13.3
> 
> This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying
> to send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests seem to take an unusual amount of time. More analysis probably
> has to wait until November, since I am going to be in Prague next
> week.
> 
> Alexander

For the time being I'll drop this patch from the next branch and keep it
in the master branch.

/Jarkko

Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

[Jarkko Sakkinen]

On Fri, Oct 20, 2017 at 02:42:54PM +, alexander.stef...@infineon.com wrote:
> > The TPM burstcount status indicates the number of bytes that can
> > be sent to the TPM without causing bus wait states.  Effectively,
> > it is the number of empty bytes in the command FIFO.
> > 
> > This patch optimizes the tpm_tis_send_data() function by checking
> > the burstcount only once. And if the burstcount is valid, it writes
> > all the bytes at once, permitting wait state.
> > 
> > After this change, performance on a TPM 1.2 with an 8 byte
> > burstcount for 1000 extends improved from ~41sec to ~14sec.
> > 
> > Suggested-by: Ken Goldman  in
> > conjunction with the TPM Device Driver work group.
> > Signed-off-by: Nayna Jain 
> > Acked-by: Mimi Zohar 
> > ---
> >  drivers/char/tpm/tpm_tis_core.c | 42 +++--
> > 
> >  1 file changed, 15 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > b/drivers/char/tpm/tpm_tis_core.c
> > index b33126a35694..993328ae988c 100644
> > --- a/drivers/char/tpm/tpm_tis_core.c
> > +++ b/drivers/char/tpm/tpm_tis_core.c
> > @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> >  {
> > struct tpm_tis_data *priv = dev_get_drvdata(>dev);
> > int rc, status, burstcnt;
> > -   size_t count = 0;
> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
> > 
> > status = tpm_tis_status(chip);
> > @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> > }
> > }
> > 
> > -   while (count < len - 1) {
> > -   burstcnt = get_burstcount(chip);
> > -   if (burstcnt < 0) {
> > -   dev_err(>dev, "Unable to read burstcount\n");
> > -   rc = burstcnt;
> > -   goto out_err;
> > -   }
> > -   burstcnt = min_t(int, burstcnt, len - count - 1);
> > -   rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv-
> > >locality),
> > -burstcnt, buf + count);
> > -   if (rc < 0)
> > -   goto out_err;
> > -
> > -   count += burstcnt;
> > -
> > -   if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip-
> > >timeout_c,
> > -   >int_queue, false) < 0) {
> > -   rc = -ETIME;
> > -   goto out_err;
> > -   }
> > -   status = tpm_tis_status(chip);
> > -   if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
> > -   rc = -EIO;
> > -   goto out_err;
> > -   }
> > +   /*
> > +* Get the initial burstcount to ensure TPM is ready to
> > +* accept data.
> > +*/
> > +   burstcnt = get_burstcount(chip);
> > +   if (burstcnt < 0) {
> > +   dev_err(>dev, "Unable to read burstcount\n");
> > +   rc = burstcnt;
> > +   goto out_err;
> > }
> > 
> > +   rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality),
> > +   len - 1, buf);
> > +   if (rc < 0)
> > +   goto out_err;
> > +
> > /* write last byte */
> > -   rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality),
> > buf[count]);
> > +   rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len-
> > 1]);
> > if (rc < 0)
> > goto out_err;
> > 
> > --
> > 2.13.3
> 
> This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying
> to send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests seem to take an unusual amount of time. More analysis probably
> has to wait until November, since I am going to be in Prague next
> week.
> 
> Alexander

For the time being I'll drop this patch from the next branch and keep it
in the master branch.

/Jarkko

Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()

[Jarkko Sakkinen]

On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote:
> I've always been curious, and the changelog and thread are curiously
> oblique on this topic: what the heck does this driver use pipes *for*?

For communication with the process hosting the launch enclave.

/Jarkko

Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()

[Jarkko Sakkinen]

On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote:
> I've always been curious, and the changelog and thread are curiously
> oblique on this topic: what the heck does this driver use pipes *for*?

For communication with the process hosting the launch enclave.

/Jarkko

[tip:WIP.timers 28/37] htmldocs: include/linux/hrtimer.h:118: warning: No description found for parameter 'is_soft'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers
head:   0f0f9ec319ea27dba44d16c643805821005f4955
commit: 7f6f735b72fb372668f6526167a7f6ae4b39ab87 [28/37] hrtimer: Implement 
support for softirq based hrtimers
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   kernel/trace/blktrace.c:824: warning: No description found for parameter 
'cgid'
>> include/linux/hrtimer.h:118: warning: No description found for parameter 
>> 'is_soft'
   include/linux/sync_file.h:51: warning: No description found for parameter 
'flags'
   drivers/gpio/gpiolib.c:593: warning: No description found for parameter '16'
   drivers/gpio/gpiolib.c:593: warning: Excess struct/union/enum/typedef member 
'events' description in 'lineevent_state'
   include/linux/usb/gadget.h:232: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:232: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:414: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:414: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:414: warning: No description found for parameter 
'quirk_zlp_not_supp'
   fs/inode.c:1680: warning: No description found for parameter 'rcu'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_transaction'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_next_transaction'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_list'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_vfs_inode'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_flags'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_rsv_handle'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_reserved'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_type'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_line_no'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_start_jiffies'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_requested_credits'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'saved_alloc_context'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_chkpt_bhs'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_devname'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_average_commit_time'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_min_batch_time'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_max_batch_time'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_commit_callback'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_failed_commit'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_chksum_driver'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_csum_seed'
   fs/jbd2/transaction.c:511: warning: No description found for parameter 'type'
   fs/jbd2/transaction.c:511: warning: No description found for parameter 
'line_no'
   fs/jbd2/transaction.c:641: warning: No description found for parameter 
'gfp_mask'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_mode_config.h:771: warning: No description found for 
parameter 'modifiers_property'
   include/drm/drm_mode_config.h:771: warning: Excess struct/union/enum/typedef 
member 'modifiers' description in 'drm_mode_config'
   include/drm/drm_plane.h:544: warning: No description found for parameter 
'modifiers'
   include/drm/drm_plane.h:544: warning: No description found for parameter 
'modifier_count'
   drivers/gpu/host1x/bus.c:50: warning: No description found for parameter 
'driver'
   include/linux/rcupdate.h:571: ERROR: Unexpected indentation.
   include/linux/rcupdate.h:575: ERROR: Unexpected indentation.
   

[tip:WIP.timers 28/37] htmldocs: include/linux/hrtimer.h:118: warning: No description found for parameter 'is_soft'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers
head:   0f0f9ec319ea27dba44d16c643805821005f4955
commit: 7f6f735b72fb372668f6526167a7f6ae4b39ab87 [28/37] hrtimer: Implement 
support for softirq based hrtimers
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   kernel/trace/blktrace.c:824: warning: No description found for parameter 
'cgid'
>> include/linux/hrtimer.h:118: warning: No description found for parameter 
>> 'is_soft'
   include/linux/sync_file.h:51: warning: No description found for parameter 
'flags'
   drivers/gpio/gpiolib.c:593: warning: No description found for parameter '16'
   drivers/gpio/gpiolib.c:593: warning: Excess struct/union/enum/typedef member 
'events' description in 'lineevent_state'
   include/linux/usb/gadget.h:232: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:232: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:414: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:414: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:414: warning: No description found for parameter 
'quirk_zlp_not_supp'
   fs/inode.c:1680: warning: No description found for parameter 'rcu'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_transaction'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_next_transaction'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_list'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_vfs_inode'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_flags'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_rsv_handle'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_reserved'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_type'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_line_no'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_start_jiffies'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_requested_credits'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'saved_alloc_context'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_chkpt_bhs'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_devname'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_average_commit_time'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_min_batch_time'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_max_batch_time'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_commit_callback'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_failed_commit'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_chksum_driver'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_csum_seed'
   fs/jbd2/transaction.c:511: warning: No description found for parameter 'type'
   fs/jbd2/transaction.c:511: warning: No description found for parameter 
'line_no'
   fs/jbd2/transaction.c:641: warning: No description found for parameter 
'gfp_mask'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:594: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_mode_config.h:771: warning: No description found for 
parameter 'modifiers_property'
   include/drm/drm_mode_config.h:771: warning: Excess struct/union/enum/typedef 
member 'modifiers' description in 'drm_mode_config'
   include/drm/drm_plane.h:544: warning: No description found for parameter 
'modifiers'
   include/drm/drm_plane.h:544: warning: No description found for parameter 
'modifier_count'
   drivers/gpu/host1x/bus.c:50: warning: No description found for parameter 
'driver'
   include/linux/rcupdate.h:571: ERROR: Unexpected indentation.
   include/linux/rcupdate.h:575: ERROR: Unexpected indentation.
   

Only for Business Expertise

[Eugen Hagler]

My sincere apology if this email will cause any inconvenience. I have a
proposal which I think might be of interest to you, I have a client who
is searching for Good Business Owners that have got lucrative
projects/business ideas he can invest his funds on. My client has great
interest to invest in worthy creative start ups that has good
potentials. He is not concerned about the type of project or the
location of the investment rather his interest is that the Project
should be one that will be able to yield a high return on investment.
The investment range should be within the range of US$ One million-US$
Two Hundred million. His plan is to invest in a long term (maybe a
period of 10 - 15 years) and after that, will withdraw his original
capital and at the end of every financial year both of you will be
sharing the interest generated on any percentage you both agree on.
send me your Tel. Number or send mailto: i...@ibreach.org

Regards
Mr Eugen Hagler

Only for Business Expertise

[Eugen Hagler]

My sincere apology if this email will cause any inconvenience. I have a
proposal which I think might be of interest to you, I have a client who
is searching for Good Business Owners that have got lucrative
projects/business ideas he can invest his funds on. My client has great
interest to invest in worthy creative start ups that has good
potentials. He is not concerned about the type of project or the
location of the investment rather his interest is that the Project
should be one that will be able to yield a high return on investment.
The investment range should be within the range of US$ One million-US$
Two Hundred million. His plan is to invest in a long term (maybe a
period of 10 - 15 years) and after that, will withdraw his original
capital and at the end of every financial year both of you will be
sharing the interest generated on any percentage you both agree on.
send me your Tel. Number or send mailto: i...@ibreach.org

Regards
Mr Eugen Hagler

Re: [PATCH v6 01/12] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

[Chaotian Jing]

Hi Rob & Ulf,

Gentle ping...
Any other comments about this series of patch ?
On Mon, 2017-10-16 at 09:46 +0800, Chaotian Jing wrote:
> Change the comptiable for support of multi-platform
> Make compatible explicit, as MMC host of mt8173 has difference with
> mt8135(mt8173 supports hs400 and hs400_tune),so that need separate
> mt8173/mt8135 compatible name.
> Add description for reg
> Add description for source_cg
> Add description for mediatek,latch-ck
> Note that source_cg and mediatek,latch-ck are optional for some projects,
> eg, MT2701 do not have source_cg, and MT2712 do not need
> mediatek,latch-ck
> 
> Signed-off-by: Chaotian Jing 
> ---
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 4182ea3..72d2a73 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -7,10 +7,18 @@ This file documents differences between the core properties 
> in mmc.txt
>  and the properties used by the msdc driver.
>  
>  Required properties:
> -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> +- compatible: value should be either of the following.
> + "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> + "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> + "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> + "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> +- reg: physical base address of the controller and length
>  - interrupts: Should contain MSDC interrupt number
> -- clocks: MSDC source clock, HCLK
> -- clock-names: "source", "hclk"
> +- clocks: Should contain phandle for the clock feeding the MMC controller
> +- clock-names: Should contain the following:
> + "source" - source clock (required)
> + "hclk" - HCLK which used for host (required)
> + "source_cg" - independent source clock gate (required for MT2712)
>  - pinctrl-names: should be "default", "state_uhs"
>  - pinctrl-0: should contain default/high speed pin ctrl
>  - pinctrl-1: should contain uhs mode pin ctrl
> @@ -30,6 +38,10 @@ Optional properties:
>  - mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample 
> selection
>  If present,HS400 command responses are 
> sampled on rising edges.
>  If not present,HS400 command responses 
> are sampled on falling edges.
> +- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct 
> latch-ck to avoid data crc
> +  error caused by stop clock(fifo full)
> +  Valid range = [0:0x7]. if not present, default value is 0.
> +  applied to compatible "mediatek,mt2701-mmc".
>  
>  Examples:
>  mmc0: mmc@1123 {

Re: [PATCH v6 01/12] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

[Chaotian Jing]

Hi Rob & Ulf,

Gentle ping...
Any other comments about this series of patch ?
On Mon, 2017-10-16 at 09:46 +0800, Chaotian Jing wrote:
> Change the comptiable for support of multi-platform
> Make compatible explicit, as MMC host of mt8173 has difference with
> mt8135(mt8173 supports hs400 and hs400_tune),so that need separate
> mt8173/mt8135 compatible name.
> Add description for reg
> Add description for source_cg
> Add description for mediatek,latch-ck
> Note that source_cg and mediatek,latch-ck are optional for some projects,
> eg, MT2701 do not have source_cg, and MT2712 do not need
> mediatek,latch-ck
> 
> Signed-off-by: Chaotian Jing 
> ---
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 4182ea3..72d2a73 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -7,10 +7,18 @@ This file documents differences between the core properties 
> in mmc.txt
>  and the properties used by the msdc driver.
>  
>  Required properties:
> -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> +- compatible: value should be either of the following.
> + "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> + "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> + "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> + "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> +- reg: physical base address of the controller and length
>  - interrupts: Should contain MSDC interrupt number
> -- clocks: MSDC source clock, HCLK
> -- clock-names: "source", "hclk"
> +- clocks: Should contain phandle for the clock feeding the MMC controller
> +- clock-names: Should contain the following:
> + "source" - source clock (required)
> + "hclk" - HCLK which used for host (required)
> + "source_cg" - independent source clock gate (required for MT2712)
>  - pinctrl-names: should be "default", "state_uhs"
>  - pinctrl-0: should contain default/high speed pin ctrl
>  - pinctrl-1: should contain uhs mode pin ctrl
> @@ -30,6 +38,10 @@ Optional properties:
>  - mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample 
> selection
>  If present,HS400 command responses are 
> sampled on rising edges.
>  If not present,HS400 command responses 
> are sampled on falling edges.
> +- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct 
> latch-ck to avoid data crc
> +  error caused by stop clock(fifo full)
> +  Valid range = [0:0x7]. if not present, default value is 0.
> +  applied to compatible "mediatek,mt2701-mmc".
>  
>  Examples:
>  mmc0: mmc@1123 {

Re: [15/23] drm/sun4i: Add LVDS support

[Jonathan Liu]

Hi Maxime,

On 17 October 2017 at 20:06, Maxime Ripard
 wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
>  drivers/gpu/drm/sun4i/sun4i_lvds.h |  18 +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  25 -
>  5 files changed, 419 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index cfba2c07519c..6fee15d016ef 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -10,6 +10,7 @@ sun4i-drm-hdmi-y  += sun4i_hdmi_tmds_clk.o
>
>  sun4i-tcon-y   += sun4i_tcon.o
>  sun4i-tcon-y   += sun4i_rgb.o
> +sun4i-tcon-y   += sun4i_lvds.o
>  sun4i-tcon-y   += sun4i_dotclock.o
>  sun4i-tcon-y   += sun4i_crtc.o
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> new file mode 100644
> index ..635a3f505ecb
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sun4i_crtc.h"
> +#include "sun4i_tcon.h"
> +#include "sun4i_lvds.h"
> +
> +struct sun4i_lvds {
> +   struct drm_connectorconnector;
> +   struct drm_encoder  encoder;
> +
> +   struct sun4i_tcon   *tcon;
> +};
> +
> +static inline struct sun4i_lvds *
> +drm_connector_to_sun4i_lvds(struct drm_connector *connector)
> +{
> +   return container_of(connector, struct sun4i_lvds,
> +   connector);
> +}
> +
> +static inline struct sun4i_lvds *
> +drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
> +{
> +   return container_of(encoder, struct sun4i_lvds,
> +   encoder);
> +}
> +
> +static int sun4i_lvds_get_modes(struct drm_connector *connector)
> +{
> +   struct sun4i_lvds *lvds =
> +   drm_connector_to_sun4i_lvds(connector);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   return drm_panel_get_modes(tcon->panel);
> +}
> +
> +static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> +   .get_modes  = sun4i_lvds_get_modes,
> +};
> +
> +static void
> +sun4i_lvds_connector_destroy(struct drm_connector *connector)
> +{
> +   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   drm_panel_detach(tcon->panel);
> +   drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
> +   .fill_modes = drm_helper_probe_single_connector_modes,
> +   .destroy= sun4i_lvds_connector_destroy,
> +   .reset  = drm_atomic_helper_connector_reset,
> +   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
> +   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
> +
> +   if (!IS_ERR(tcon->panel)) {
> +   drm_panel_prepare(tcon->panel);
> +   drm_panel_enable(tcon->panel);
> +   }
> +}
> +
> +static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
> +{
> +   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   DRM_DEBUG_DRIVER("Disabling LVDS output\n");
> +
> +   if (!IS_ERR(tcon->panel)) {
> +   drm_panel_disable(tcon->panel);
> +   drm_panel_unprepare(tcon->panel);
> +   }
> +}
> +
> +static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
> +   .disable= sun4i_lvds_encoder_disable,
> +   .enable = sun4i_lvds_encoder_enable,
> +};
> +
> +static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
> +   .destroy= 

Re: [15/23] drm/sun4i: Add LVDS support

[Jonathan Liu]

Hi Maxime,

On 17 October 2017 at 20:06, Maxime Ripard
 wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
>  drivers/gpu/drm/sun4i/sun4i_lvds.h |  18 +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  25 -
>  5 files changed, 419 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index cfba2c07519c..6fee15d016ef 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -10,6 +10,7 @@ sun4i-drm-hdmi-y  += sun4i_hdmi_tmds_clk.o
>
>  sun4i-tcon-y   += sun4i_tcon.o
>  sun4i-tcon-y   += sun4i_rgb.o
> +sun4i-tcon-y   += sun4i_lvds.o
>  sun4i-tcon-y   += sun4i_dotclock.o
>  sun4i-tcon-y   += sun4i_crtc.o
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> new file mode 100644
> index ..635a3f505ecb
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sun4i_crtc.h"
> +#include "sun4i_tcon.h"
> +#include "sun4i_lvds.h"
> +
> +struct sun4i_lvds {
> +   struct drm_connectorconnector;
> +   struct drm_encoder  encoder;
> +
> +   struct sun4i_tcon   *tcon;
> +};
> +
> +static inline struct sun4i_lvds *
> +drm_connector_to_sun4i_lvds(struct drm_connector *connector)
> +{
> +   return container_of(connector, struct sun4i_lvds,
> +   connector);
> +}
> +
> +static inline struct sun4i_lvds *
> +drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
> +{
> +   return container_of(encoder, struct sun4i_lvds,
> +   encoder);
> +}
> +
> +static int sun4i_lvds_get_modes(struct drm_connector *connector)
> +{
> +   struct sun4i_lvds *lvds =
> +   drm_connector_to_sun4i_lvds(connector);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   return drm_panel_get_modes(tcon->panel);
> +}
> +
> +static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> +   .get_modes  = sun4i_lvds_get_modes,
> +};
> +
> +static void
> +sun4i_lvds_connector_destroy(struct drm_connector *connector)
> +{
> +   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   drm_panel_detach(tcon->panel);
> +   drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
> +   .fill_modes = drm_helper_probe_single_connector_modes,
> +   .destroy= sun4i_lvds_connector_destroy,
> +   .reset  = drm_atomic_helper_connector_reset,
> +   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
> +   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
> +
> +   if (!IS_ERR(tcon->panel)) {
> +   drm_panel_prepare(tcon->panel);
> +   drm_panel_enable(tcon->panel);
> +   }
> +}
> +
> +static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
> +{
> +   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> +   struct sun4i_tcon *tcon = lvds->tcon;
> +
> +   DRM_DEBUG_DRIVER("Disabling LVDS output\n");
> +
> +   if (!IS_ERR(tcon->panel)) {
> +   drm_panel_disable(tcon->panel);
> +   drm_panel_unprepare(tcon->panel);
> +   }
> +}
> +
> +static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
> +   .disable= sun4i_lvds_encoder_disable,
> +   .enable = sun4i_lvds_encoder_enable,
> +};
> +
> +static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
> +   .destroy= drm_encoder_cleanup,
> +};
> +
> +int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
> +{
>