Re: [PATCH v4 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1028a-pcie"

[Lorenzo Pieralisi]

On Fri, Aug 23, 2019 at 04:26:41PM +0800, Xiaowei Bao wrote:
> Add the PCIe compatible string for LS1028A
> 
> Signed-off-by: Xiaowei Bao 
> Signed-off-by: Hou Zhiqiang 
> Reviewed-by: Rob Herring 
> ---
> v2:
>  - No change.
> v3:
>  - No change.
> v4:
>  - No change.
> 
>  Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
> b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index e20ceaa..99a386e 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -21,6 +21,7 @@ Required properties:
>  "fsl,ls1046a-pcie"
>  "fsl,ls1043a-pcie"
>  "fsl,ls1012a-pcie"
> +"fsl,ls1028a-pcie"
>EP mode:
>   "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
>  - reg: base addresses and lengths of the PCIe controller register blocks.

This series does not apply to v5.3-rc1, what is it based on ?

Lorenzo

Re: [PATCH -next] rtc: pcf2127: Fix build error without CONFIG_WATCHDOG_CORE

[Alexandre Belloni]

On 23/08/2019 20:45:53+0800, YueHaibing wrote:
> If WATCHDOG_CORE is not set, build fails:
> 
> drivers/rtc/rtc-pcf2127.o: In function `pcf2127_probe.isra.6':
> drivers/rtc/rtc-pcf2127.c:478: undefined reference to 
> `devm_watchdog_register_device'
> 
> Add WATCHDOG_CORE Kconfig dependency to fix this.
> 
> Reported-by: Hulk Robot 
> Fixes: bbc597561ce1 ("rtc: pcf2127: add watchdog feature support")
> Signed-off-by: YueHaibing 
> ---
>  drivers/rtc/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 25af63d..9dce7dc 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -886,6 +886,8 @@ config RTC_DRV_DS3232_HWMON
>  config RTC_DRV_PCF2127
>   tristate "NXP PCF2127"
>   depends on RTC_I2C_AND_SPI
> + depends on WATCHDOG

Definitively not, I fixed it that way:
+   select WATCHDOG_CORE if WATCHDOG


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [RESEND, PATCH v13 10/12] soc: mediatek: cmdq: add polling function

[Matthias Brugger]

On 20/08/2019 10:49, Bibby Hsieh wrote:
> add polling function in cmdq helper functions
> 
> Signed-off-by: Bibby Hsieh 
> Reviewed-by: CK Hu 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   | 28 
>  include/linux/mailbox/mtk-cmdq-mailbox.h |  1 +
>  include/linux/soc/mediatek/mtk-cmdq.h| 15 +
>  3 files changed, 44 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index e3d5b0be8e79..c53f8476c68d 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -221,6 +221,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_clear_event);
>  
> +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> +   u16 offset, u32 value, u32 mask)
> +{
> + struct cmdq_instruction *inst;
> +
> + if (mask != 0x) {

Is this necessary? Can't we just always set the mask, even if it's 0x?

Regarding interfaces, depending on how often you expect the mask being ~0 we
might think of adding a cmdq_pkt_poll_mask call.
What I want to say, if in the end most of the callers will use the mask with
0x, then we should add a call cmdq_pkt_poll_mask which actually allows
to set the mask and let cmdq_pkt_poll set the mask in it's function body.
As I already said, this depends on how often you think a caller will use/not-use
the mask.
Does this make sense?

> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_MASK;
> + inst->value = ~mask;
> + offset = offset | 0x1;
> + }
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_POLL;
> + inst->value = value;
> + inst->offset = offset;
> + inst->subsys = subsys;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(cmdq_pkt_poll);
> +
>  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
>   struct cmdq_instruction *inst;
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index c8adedefaf42..9e3502945bc1 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -46,6 +46,7 @@
>  enum cmdq_code {
>   CMDQ_CODE_MASK = 0x02,
>   CMDQ_CODE_WRITE = 0x04,
> + CMDQ_CODE_POLL = 0x08,
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 9618debb9ceb..a345870a6d10 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
>   */
>  int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>  
> +/**
> + * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> + *execute an instruction that wait for a specified hardware
> + *register to check for the value. All GCE hardware
> + *threads will be blocked by this instruction.
> + * @pkt: the CMDQ packet
> + * @subsys:  the CMDQ sub system code
> + * @offset:  register offset from CMDQ sub system
> + * @value:   the specified target register value
> + * @mask:the specified target register mask
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> +   u16 offset, u32 value, u32 mask);
>  /**
>   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>   *  packet and call back at the end of done packet
> 

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

[Peter Zijlstra]

On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
> I'm assuming the lockdep one will land, so not going to resend that.

I was assuming you'd wake the might_lock_nested() along with the i915
user through the i915/drm tree. If want me to take some or all of that,
lemme know.

Re: [PATCH] ethernet: Delete unnecessary checks before the macro call “dev_kfree_skb”

[Christophe JAILLET]

Hi,

in this patch, there is one piece that looked better before. (see below)

Removing the 'if (skb)' is fine, but concatening everything in one 
statement just to save 2 variables and a few LOC is of no use, IMHO, and 
the code is less readable.


just my 2c.


CJ


diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c

index d3a0b614dbfa..8b19ddcdafaa 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2515,19 +2515,14 @@ static int bcmgenet_dma_teardown(struct 
bcmgenet_priv *priv)

 static void bcmgenet_fini_dma(struct bcmgenet_priv *priv)
 {
 struct netdev_queue *txq;
-    struct sk_buff *skb;
-    struct enet_cb *cb;
 int i;

 bcmgenet_fini_rx_napi(priv);
 bcmgenet_fini_tx_napi(priv);

-    for (i = 0; i < priv->num_tx_bds; i++) {
-    cb = priv->tx_cbs + i;
-    skb = bcmgenet_free_tx_cb(>pdev->dev, cb);
-    if (skb)
-    dev_kfree_skb(skb);
-    }
+    for (i = 0; i < priv->num_tx_bds; i++)
+ dev_kfree_skb(bcmgenet_free_tx_cb(>pdev->dev,
+  priv->tx_cbs + i));

 for (i = 0; i < priv->hw_params->tx_queues; i++) {
 txq = netdev_get_tx_queue(priv->dev, priv->tx_rings[i].queue);

Re: [PATCH v2] Ext4 documentation fixes.

[Theodore Y. Ts'o]

On Fri, Aug 23, 2019 at 04:56:42AM +, Ayush Ranjan wrote:
> Hey Ted!
> Thanks for reviewing! The comment in 
> fs/ext4/ext4.h:ext4_group_desc:bg_checksum
> says that the crc16 checksum formula should be crc16(sb_uuid+group+desc). I
> think group over here denotes group number.
> 
> Briefly looking through fs/ext4/super.c:ext4_group_desc_csum() suggests that:
> - For the new metadata_csum algorithm, only the group number and the block
> descriptor are included in the checksum. So the formula should be
> crc32c(group+desc) & 0xFFF (this looks like a bug as this should also include 
> sb
> UUID?)
> - For the old crc16 algorithm, the sb UUID, group number and the block
> descriptor are included in the checksum. So the formula should be
> crc16(sb\_uuid+group+desc). (should remain unchanged)

Thanks for the research and explanation.  I think I'm going to change
that to be:

crc{16,32c}(sb_uuid + group_num + bg_desc)

That should make it clearer what is meant.

 - Ted








> 
> Ayush Ranjan
> University of Illinois - Urbana Champaign | May 2020
> Bachelors of Science in Computer Science and Mathematics
> Business Minor | Gies College of Business
> 
> 
> On Fri, Aug 23, 2019 at 8:48 AM Theodore Y. Ts'o  wrote:
> >
> > On Thu, Aug 15, 2019 at 09:11:51AM -0700, Ayush Ranjan wrote:
> > > This commit aims to fix the following issues in ext4 documentation:
> > > - Flexible block group docs said that the aim was to group block
> > >   metadata together instead of block group metadata.
> > > - The documentation consistly uses "location" instead of "block number".
> > >   It is easy to confuse location to be an absolute offset on disk. Added
> > >   a line to clarify all location values are in terms of block numbers.
> > > - Dirent2 docs said that the rec_len field is shortened instead of the
> > >   name_len field.
> > > - Typo in bg_checksum description.
> > > - Inode size is 160 bytes now, and hence i_extra_isize is now 32.
> > > - Cluster size formula was incorrect, it did not include the +10 to
> > >   s_log_cluster_size value.
> > > - Typo: there were two s_wtime_hi in the superblock struct.
> > > - Superblock struct was outdated, added the new fields which were part
> > >   of s_reserved earlier.
> > > - Multiple mount protection seems to be implemented in fs/ext4/mmp.c.
> > >
> > > Signed-off-by: Ayush Ranjan 
> >
> > Fixed with one minor typo fix:
> >
> > > diff --git a/Documentation/filesystems/ext4/group_descr.rst
> > > b/Documentation/filesystems/ext4/group_descr.rst
> > > index 0f783ed88..feb5c613d 100644
> > > --- a/Documentation/filesystems/ext4/group_descr.rst
> > > +++ b/Documentation/filesystems/ext4/group_descr.rst
> > > @@ -100,7 +100,7 @@ The block group descriptor is laid out in ``struct
> > > ext4_group_desc``.
> > >       - \_\_le16
> > >       - bg\_checksum
> > >       - Group descriptor checksum; crc16(sb\_uuid+group+desc) if the
> > > -       RO\_COMPAT\_GDT\_CSUM feature is set, or
> crc32c(sb\_uuid+group\_desc) &
> > > +       RO\_COMPAT\_GDT\_CSUM feature is set, or 
> > > crc32c(sb\_uuid+group+desc)
> &
> > >         0x if the RO\_COMPAT\_METADATA\_CSUM feature is set.
> >
> > The correct checksum should be "crc16(sb\_uuid+group\_desc)" or
> > "crc32c(sb\_uuid+group\_desc)".  That is, it's previous line which
> > needed modification.
> >
> >                                         - Ted

Re: [PATCH v1 3/3] watchdog/aspeed: add support for dual boot

[Guenter Roeck]

On Fri, Aug 23, 2019 at 12:35:28PM +0300, Ivan Mikhaylov wrote:
> Set WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION into WDT_CLEAR_TIMEOUT_STATUS
> to clear out boot code source and re-enable access to the primary SPI flash
> chip while booted via wdt2 from the alternate chip.
> 
> AST2400 datasheet says:
> "In the 2nd flash booting mode, all the address mapping to CS0# would be
> re-directed to CS1#. And CS0# is not accessable under this mode. To access
> CS0#, firmware should clear the 2nd boot mode register in the WDT2 status
> register WDT30.bit[1]."
> 
> Signed-off-by: Ivan Mikhaylov 
> ---
>  drivers/watchdog/aspeed_wdt.c | 44 ++-
>  1 file changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index cc71861e033a..62bf95cb741f 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -53,6 +53,8 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
>  #define   WDT_CTRL_ENABLEBIT(0)
>  #define WDT_TIMEOUT_STATUS   0x10
>  #define   WDT_TIMEOUT_STATUS_BOOT_SECONDARY  BIT(1)
> +#define WDT_CLEAR_TIMEOUT_STATUS 0x14
> +#define   WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION  BIT(0)
>  
>  /*
>   * WDT_RESET_WIDTH controls the characteristics of the external pulse (if
> @@ -165,6 +167,42 @@ static int aspeed_wdt_restart(struct watchdog_device 
> *wdd,
>   return 0;
>  }
>  
> +/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
> +static ssize_t access_cs0_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> +

Unnecessary empty line.

> + uint32_t status = readl(wdt->base + WDT_TIMEOUT_STATUS);
> +
> + return sprintf(buf, "%u\n",
> + !(status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY));
> +}
> +
> +static ssize_t access_cs0_store(struct device *dev,
> +   struct device_attribute *attr,
> +   const char *buf, size_t size)
> +{
> + struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> + unsigned long val = 0;

Unnecessary initialization.

> +
> + if (kstrtoul(buf, 10, ))
> + return -EINVAL;
> +
> + if (val)
> + writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
> + wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(access_cs0);
> +
> +static struct attribute *bswitch_attrs[] = {
> + _attr_access_cs0.attr,

The attribute needs to be documented.

> + NULL
> +};
> +ATTRIBUTE_GROUPS(bswitch);
> +
>  static const struct watchdog_ops aspeed_wdt_ops = {
>   .start  = aspeed_wdt_start,
>   .stop   = aspeed_wdt_stop,
> @@ -306,8 +344,12 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
>   }
>  
>   status = readl(wdt->base + WDT_TIMEOUT_STATUS);
> - if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
> + if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
>   wdt->wdd.bootstatus = WDIOF_CARDRESET;
> + wdt->wdd.groups = bswitch_groups;
> + }

So the attribute would only exist if the boot was from the secondary
flash, and it would exist even if it wasn't needed (ie on ast2500 /
ast2600) ? Well, if that is what you want, who am I to argue, but
you'll have to document it accordingly. When you do so, please also
document what happens on ast2500 / ast2600 when the attribute exists
and is written.

> +
> + dev_set_drvdata(dev, wdt);
>  
>   return devm_watchdog_register_device(dev, >wdd);
>  }
> -- 
> 2.20.1
> 
> 

Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function

[Matthias Brugger]

On 20/08/2019 10:49, Bibby Hsieh wrote:
> GCE cannot know the register base address, this function
> can help cmdq client to get the cmdq_client_reg structure.
> 
> Signed-off-by: Bibby Hsieh 
> Reviewed-by: CK Hu 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++
>  include/linux/soc/mediatek/mtk-cmdq.h  | 21 +++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index c53f8476c68d..80f75a1075b4 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -27,6 +27,35 @@ struct cmdq_instruction {
>   u8 op;
>  };
>  
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx)
> +{

Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
properties we have and allocating these using a pointer to cmdq_client_reg in
cmdq_client?
We will have to free the pointer then in cmdq_mbox_destroy.

Regards,
Matthias

> + struct of_phandle_args spec;
> + int err;
> +
> + if (!client_reg)
> + return -ENOENT;
> +
> + err = of_parse_phandle_with_fixed_args(dev->of_node,
> +"mediatek,gce-client-reg",
> +3, idx, );
> + if (err < 0) {
> + dev_err(dev,
> + "error %d can't parse gce-client-reg property (%d)",
> + err, idx);
> +
> + return err;
> + }
> +
> + client_reg->subsys = (u8)spec.args[0];
> + client_reg->offset = (u16)spec.args[1];
> + client_reg->size = (u16)spec.args[2];
> + of_node_put(spec.np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> +
>  static void cmdq_client_timeout(struct timer_list *t)
>  {
>   struct cmdq_client *client = from_timer(client, t, timer);
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a345870a6d10..02ddd60b212f 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -15,6 +15,12 @@
>  
>  struct cmdq_pkt;
>  
> +struct cmdq_client_reg {
> + u8 subsys;
> + u16 offset;
> + u16 size;
> +};
> +
>  struct cmdq_client {
>   spinlock_t lock;
>   u32 pkt_cnt;
> @@ -24,6 +30,21 @@ struct cmdq_client {
>   u32 timeout_ms; /* in unit of microsecond */
>  };
>  
> +/**
> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> + *  node of CMDQ client
> + * @dev: device of CMDQ mailbox client
> + * @client_reg: CMDQ client reg pointer
> + * @idx: the index of desired reg
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Help CMDQ client parsing the cmdq client reg
> + * from the device node of CMDQ client.
> + */
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx);
> +
>  /**
>   * cmdq_mbox_create() - create CMDQ mailbox client and channel
>   * @dev: device of CMDQ mailbox client
> 

[PATCH] powerpc/mm/radix: remove useless kernel messages

[Qian Cai]

Booting a POWER9 PowerNV system generates a few messages below with
"ptrval" due to the pointers printed without a specifier
extension (i.e unadorned %p) are hashed to prevent leaking information
about the kernel memory layout.

radix-mmu: Initializing Radix MMU
radix-mmu: Partition table (ptrval)
radix-mmu: Mapped 0x-0x4000 with 1.00 GiB
pages (exec)
radix-mmu: Mapped 0x4000-0x0020 with 1.00 GiB
pages
radix-mmu: Mapped 0x2000-0x2020 with 1.00 GiB
pages
radix-mmu: Process table (ptrval) and radix root for kernel:
(ptrval)

Signed-off-by: Qian Cai 
---
 arch/powerpc/mm/book3s64/radix_pgtable.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c 
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index b4ca9e95e678..b6692ee9411d 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -386,7 +386,6 @@ static void __init radix_init_pgtable(void)
 * physical address here.
 */
register_process_table(__pa(process_tb), 0, PRTB_SIZE_SHIFT - 12);
-   pr_info("Process table %p and radix root for kernel: %p\n", process_tb, 
init_mm.pgd);
asm volatile("ptesync" : : : "memory");
asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
 "r" (TLBIEL_INVAL_SET_LPID), "r" (0));
@@ -420,7 +419,6 @@ static void __init radix_init_partition_table(void)
mmu_partition_table_set_entry(0, dw0, 0);
 
pr_info("Initializing Radix MMU\n");
-   pr_info("Partition table %p\n", partition_tb);
 }
 
 void __init radix_init_native(void)
-- 
1.8.3.1

Re: [Resubmit] Read battery voltage from Logitech Gaming mice

[Pedro Vanzella]

Hi Benjamin,

On 8/23/19 4:25 AM, Benjamin Tissoires wrote:

Hi Pedro,

On Thu, Aug 22, 2019 at 10:19 PM Pedro Vanzella  wrote:


Resumitting this after having rebased it against the latest changes.


thanks for resubmitting. Sorry I wasn't able to provide feedback on
the last revision



No worries, I know how these things are.



The gaming line of Logitech devices doesn't use the old hidpp20
feature for battery level reporting. Instead, they report the
current voltage of the battery, in millivolts.

This patch set handles this case by adding a quirk to the
devices we know to have this new feature, in both wired
and wireless mode.


So the quirk is in the end a bad idea after all. I had some chats with
Filipe that made me realize this.


I actually resubmitted by Filipe's request, since the patches weren't 
applying cleanly anymore. The idea was to apply these patches and in the 
future refactor the code to use the feature discovery routines.



Re-reading our previous exchanges also made me understood why I wasn't
happy with the initial submission: for every request the code was
checking both features 0x1000 and 0x1001 when we can remember this
once and for all during hidpp_initialize_battery().


Yeah I wasn't too happy about this either, but since there was nothing 
prohibiting some device to have both features enabled, I thought this 
wasn't too horrible.




So I think we should remove the useless quirk in the end (bad idea
from me, I concede), and instead during hidpp_initialize_battery() set
the correct HIDPP_CAPABILITY_*.
Not entirely sure if we should try to call 0x1000, or 0x1001 or if we
should rely on the 0x0001 feature to know which feature is available,
but this should be implementation detail.


I like the idea of calling 0x0001 once on device boot much better. I 
think we could easily just fetch the location for the features we know 
about and want to deal with once only. This also makes sure we support 
every single device that supports this feature, so that is a huge plus.


In fact, I think we should _not_ call 0x0001 on battery init, but only 
call battery init _after_ we called 0x0001 and discovered either 0x1000 
or 0x1001 (or the solar battery feature, or any other one that might 
crop up in the feature).






This version of the patch set is better split, as well as adding the
quirk to make sure we don't needlessly probe every device connected.


It is for sure easy to review, but doesn't make much sense in the end.
I think we should squash all the patches together as you are just
adding one feature in the driver, and it is a little bit disturbing to
first add the quirk that has no use, then set up the structs when they
are not used, and so on, so forth.


You're right. My first instinct was to send a single patch. As much as I 
tested this, I always feel like breaking the patch up post-facto will 
break a git bisect in the future and everyone will hate me :P


So we (you, me and Filipe) should probably come up with an action plan 
here. The way I see it there are two issues here: one is adding this 
feature, and the other is refactoring to use feature discovery for all 
features. There are advantages and disadvantages to doing one or another 
first and we might want to discuss that.


By merging this first (probably after I resubmit it as a single squashed 
patch) we get to test it a bit better and have a usable feature sooner. 
Plenty of people have been requesting this and there is plenty of stuff 
that can be built on top of it, but only once this is actually merged I 
think.


On the other hand, by first refactoring the rest of the code to use 
0x0001 we avoid some rework on this patch. It should be minor, as most 
functions here do all the heavy lifting after the initial feature 
discovery, and are thus mostly independent from how that is done.


I'm happy either way, so just let me know what you guys decide.

If you guys (or anyone else reading this on the public list, really) has 
any input - naming things being notoriosly hard, I'm actually happy with 
nitpicking - I'd appreciate it. On that note, come to think of it, I'm 
not 100% sure reporting the voltage in milivolts is the standard way. I 
looked through the docs, but found no solid guideline. It was either 
that or a float, so I think I made the right call here, but still.


- Pedro



Cheers,
Benjamin

Re: [PATCH v3 10/10] arm64: Retrieve stolen time as paravirtualized guest

[Steven Price]

On 23/08/2019 12:45, Zenghui Yu wrote:
> Hi Steven,
> 
> On 2019/8/21 23:36, Steven Price wrote:
>> Enable paravirtualization features when running under a hypervisor
>> supporting the PV_TIME_ST hypercall.
>>
>> For each (v)CPU, we ask the hypervisor for the location of a shared
>> page which the hypervisor will use to report stolen time to us. We set
>> pv_time_ops to the stolen time function which simply reads the stolen
>> value from the shared page for a VCPU. We guarantee single-copy
>> atomicity using READ_ONCE which means we can also read the stolen
>> time for another VCPU than the currently running one while it is
>> potentially being updated by the hypervisor.
>>
>> Signed-off-by: Steven Price 
>> ---
>>   arch/arm64/include/asm/paravirt.h |   9 +-
>>   arch/arm64/kernel/paravirt.c  | 148 ++
>>   arch/arm64/kernel/time.c  |   3 +
>>   include/linux/cpuhotplug.h    |   1 +
>>   4 files changed, 160 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/paravirt.h
>> b/arch/arm64/include/asm/paravirt.h
>> index 799d9dd6f7cc..125c26c42902 100644
>> --- a/arch/arm64/include/asm/paravirt.h
>> +++ b/arch/arm64/include/asm/paravirt.h
>> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
>>   {
>>   return pv_ops.time.steal_clock(cpu);
>>   }
>> -#endif
>> +
>> +int __init kvm_guest_init(void);
>> +
>> +#else
>> +
>> +#define kvm_guest_init()
>> +
>> +#endif // CONFIG_PARAVIRT
>>     #endif
>> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
>> index 4cfed91fe256..ea8dbbbd3293 100644
>> --- a/arch/arm64/kernel/paravirt.c
>> +++ b/arch/arm64/kernel/paravirt.c
>> @@ -6,13 +6,161 @@
>>    * Author: Stefano Stabellini 
>>    */
>>   +#define pr_fmt(fmt) "kvmarm-pv: " fmt
>> +
>> +#include 
>> +#include 
>>   #include 
>> +#include 
>>   #include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>   #include 
>> +
>>   #include 
>> +#include 
>> +#include 
>>     struct static_key paravirt_steal_enabled;
>>   struct static_key paravirt_steal_rq_enabled;
>>     struct paravirt_patch_template pv_ops;
>>   EXPORT_SYMBOL_GPL(pv_ops);
>> +
>> +struct kvmarm_stolen_time_region {
>> +    struct pvclock_vcpu_stolen_time *kaddr;
>> +};
>> +
>> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region,
>> stolen_time_region);
>> +
>> +static bool steal_acc = true;
>> +static int __init parse_no_stealacc(char *arg)
>> +{
>> +    steal_acc = false;
>> +    return 0;
>> +}
>> +
>> +early_param("no-steal-acc", parse_no_stealacc);
>> +
>> +/* return stolen time in ns by asking the hypervisor */
>> +static u64 kvm_steal_clock(int cpu)
>> +{
>> +    struct kvmarm_stolen_time_region *reg;
>> +
>> +    reg = per_cpu_ptr(_time_region, cpu);
>> +    if (!reg->kaddr) {
>> +    pr_warn_once("stolen time enabled but not configured for cpu
>> %d\n",
>> + cpu);
>> +    return 0;
>> +    }
>> +
>> +    return le64_to_cpu(READ_ONCE(reg->kaddr->stolen_time));
>> +}
>> +
>> +static int disable_stolen_time_current_cpu(void)
>> +{
>> +    struct kvmarm_stolen_time_region *reg;
>> +
>> +    reg = this_cpu_ptr(_time_region);
>> +    if (!reg->kaddr)
>> +    return 0;
>> +
>> +    memunmap(reg->kaddr);
>> +    memset(reg, 0, sizeof(*reg));
>> +
>> +    return 0;
>> +}
>> +
>> +static int stolen_time_dying_cpu(unsigned int cpu)
>> +{
>> +    return disable_stolen_time_current_cpu();
>> +}
>> +
>> +static int init_stolen_time_cpu(unsigned int cpu)
>> +{
>> +    struct kvmarm_stolen_time_region *reg;
>> +    struct arm_smccc_res res;
>> +
>> +    reg = this_cpu_ptr(_time_region);
>> +
>> +    arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_TIME_ST, );
>> +
>> +    if ((long)res.a0 < 0)
>> +    return -EINVAL;
>> +
>> +    reg->kaddr = memremap(res.a0,
>> +  sizeof(struct pvclock_vcpu_stolen_time),
>> +  MEMREMAP_WB);
> 
> cpuhp callbacks can be invoked in atomic context (see:
> secondary_start_kernel ->
> notify_cpu_starting ->
> invoke callbacks),
> but memremap might sleep...
> 
> Try to run a DEBUG_ATOMIC_SLEEP enabled PV guest, I guess we will be
> greeted by the Sleep-in-Atomic-Context BUG.  We need an alternative
> here?

Actually I had run DEBUG_ATOMIC_SLEEP and not seen any issue. But I
think that's because of the way I've configured the region in my kvmtool
changes. I'm hitting the path where the memory region is in the linear
map of the kernel and so no actual remapping is needed and hence
memremap doesn't sleep (the shared structure is in a reserved region of
RAM).

But even changing the memory layout of the guest so the call goes into
ioremap_page_range() (which contains a might_sleep()) I'm not seeing any
problems.

Am I missing something? I have to admit I don't entirely follow the
early start up - perhaps it's a simple as DEBUG_ATOMIC_SLEEP doesn't
work this early in boot?

>> +
>> +    if (!reg->kaddr) {
>> +    pr_warn("Failed to map stolen time data 

Re: [PATCH] rdma/siw: Use proper enumerated type in map_cqe_status

[Jason Gunthorpe]

On Thu, Jul 11, 2019 at 10:30:30AM -0700, Nathan Chancellor wrote:
> On Thu, Jul 11, 2019 at 02:18:08PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jul 11, 2019 at 10:16:44AM -0700, Nick Desaulniers wrote:
> > > On Thu, Jul 11, 2019 at 6:39 AM Jason Gunthorpe  wrote:
> > > >
> > > > On Thu, Jul 11, 2019 at 01:14:34AM -0700, Nathan Chancellor wrote:
> > > > > Maybe time to start plumbing Clang into your test flow until it can 
> > > > > get
> > > > > intergrated with more CI setups? :) It can catch some pretty dodgy
> > > > > behavior that GCC doesn't:
> > > >
> > > > I keep asking how to use clang to build the kernel and last I was told
> > > > it still wasn't ready..
> > > >
> > > > Is it ready now? Is there some flow that will compile with clang
> > > > warning free, on any arch? (at least the portion of the kernel I check)
> > > 
> > > $ make CC=clang ...
> > > 
> > > Let us know if you find something we haven't already.
> > > https://clangbuiltlinux.github.io/
> > > https://github.com/ClangBuiltLinux/linux/issues
> > 
> > What clang version?
> > 
> > Jason
> 
> You'll need clang-9 for x86 because of the asm-goto requirement (or a
> selective set of reverts for clang-8) but everything else should be
> good with clang-8:

The latest clang-9 packages from apt.llvm.org do seem to build the
kernel, I get one puzzling warning under RDMA:

drivers/infiniband/hw/hfi1/platform.o: warning: objtool: tune_serdes()+0x1f4: 
can't find jump dest instruction at .text+0x118a

And a BPF one:

kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0xd: sibling call from 
callable instruction with modified stack frame

Jason

Re: [1/3] rtc/fsl: support flextimer for lx2160a

[Alexandre Belloni]

On 23/08/2019 17:57:38+0800, Biwen Li wrote:
> The patch supports flextimer for lx2160a
> 
> Signed-off-by: Biwen Li 
> ---
>  drivers/rtc/rtc-fsl-ftm-alarm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
> index 4f7259c2d6a3..2b81525f6db8 100644
> --- a/drivers/rtc/rtc-fsl-ftm-alarm.c
> +++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
> @@ -313,6 +313,7 @@ static const struct of_device_id ftm_rtc_match[] = {
>   { .compatible = "fsl,ls1088a-ftm-alarm", },
>   { .compatible = "fsl,ls208xa-ftm-alarm", },
>   { .compatible = "fsl,ls1028a-ftm-alarm", },
> + { .compatible = "fsl,lx2160a-ftm-alarm", },
>   { },
>  };

I've squashed it with 3/3 and in the patch adding the driver. I also
added proper documentation.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH][rtc-next] rtc: fsl: fix spelling mistake: "memery" -> "memory"

[Alexandre Belloni]

On 23/08/2019 11:18:23+0100, Colin King wrote:
> From: Colin Ian King 
> 
> There is a spelling mistake in a dev_err error message. Fix it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/rtc/rtc-fsl-ftm-alarm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

I squashed that in the original patch, thanks!

> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
> index 4f7259c2d6a3..4bb98310cc3f 100644
> --- a/drivers/rtc/rtc-fsl-ftm-alarm.c
> +++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
> @@ -255,7 +255,7 @@ static int ftm_rtc_probe(struct platform_device *pdev)
>  
>   rtc = devm_kzalloc(>dev, sizeof(*rtc), GFP_KERNEL);
>   if (unlikely(!rtc)) {
> - dev_err(>dev, "cannot alloc memery for rtc\n");
> + dev_err(>dev, "cannot alloc memory for rtc\n");
>   return -ENOMEM;
>   }
>  
> -- 
> 2.20.1
> 

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler

[Christophe Leroy]

Le 23/08/2019 à 00:56, Andrew Morton a écrit :

On Tue, 20 Aug 2019 09:47:55 -0700 Kees Cook  wrote:


Reply-To: 20190819234111.9019-8-keesc...@chromium.org


Really?


That seems correct, that's the "[PATCH 7/7] bug: Move WARN_ON() "cut 
here" into exception handler" from the series at 
https://lkml.org/lkml/2019/8/19/1155






Subject: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler


It's strange to receive a standalone [7/7] patch.


Iaw the Reply_To, I understand it as an update of the 7th patch of the 
series.





Date:   Tue, 20 Aug 2019 09:47:55 -0700
Sender: linux-kernel-ow...@vger.kernel.org

The original clean up of "cut here" missed the WARN_ON() case (that
does not have a printk message), which was fixed recently by adding
an explicit printk of "cut here". This had the downside of adding a
printk() to every WARN_ON() caller, which reduces the utility of using
an instruction exception to streamline the resulting code. By making
this a new BUGFLAG, all of these can be removed and "cut here" can be
handled by the exception handler.

This was very pronounced on PowerPC, but the effect can be seen on
x86 as well. The resulting text size of a defconfig build shows some
small savings from this patch:

textdata bss dec hex filename
196911675134320 1646664 26472151193eed7 vmlinux.before
196763625134260 1663048 26473670193f4c6 vmlinux.after

This change also opens the door for creating something like BUG_MSG(),
where a custom printk() before issuing BUG(), without confusing the "cut
here" line.


I can't get this to apply to anything, so I guess that [1/7]-[6/7]
mattered ;)


On my side it applies cleanly on top of patch 1-6 of the series.

Christophe





Reported-by: Christophe Leroy 
Fixes: Fixes: 6b15f678fb7d ("include/asm-generic/bug.h: fix "cut here" for WARN_ON 
for __WARN_TAINT architectures")


I'm seeing double.


Signed-off-by: Kees Cook 

Re: [PATCH 4.4 00/78] 4.4.190-stable review

[Guenter Roeck]

On 8/22/19 10:18 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.190 release.
There are 78 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat 24 Aug 2019 05:18:13 PM UTC.
Anything received after that time might be too late.



Build results:
total: 170 pass: 170 fail: 0
Qemu test results:
total: 324 pass: 324 fail: 0

Guenter

Re: comments style: Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

[Andrea Parri]

> I am not suggesting to remove all comments. Some human readable
> explanation is important as long as the code is developed by humans.
> 
> I think that I'll have to accept also the extra comments if you are
> really going to use them to check the consistency by a tool. Or
> if they are really used for review by some people.

Glad to hear this.  Thank you, Petr.


> Do all this manuals, tools, people use any common syntax, please?
> Would it be usable in our case as well?
> 
> I would like to avoid reinventing the wheel. Also I do not want
> to create a dialect for few people that other potentially interested
> parties will not understand.

Right; I think that terms such as "(barrier) matching", "reads-from"
and "overwrites" are commonly used to refer to litmus tests.  (The
various primitives/instructions are of course specific to the given
context: the language, the memory model, etc. )

IOW, I'd say that that wheel _and a common denominator here can be
represented by the notion of "litmus test".  I'm not suggesting to
reinvent this wheel of course; my point was more along the lines of
"let's use the wheel, it'll be helpful..."  ;-)

  Andrea

Re: [PATCH 4.9 000/103] 4.9.190-stable review

[Guenter Roeck]

On Thu, Aug 22, 2019 at 10:17:48AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.190 release.
> There are 103 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat 24 Aug 2019 05:15:44 PM UTC.
> Anything received after that time might be too late.
> 

Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 356 pass: 356 fail: 0

Guenter

Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a

[Andrew Murray]

On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> Add PCIe EP mode support for ls1088a and ls2088a, there are some
> difference between LS1 and LS2 platform, so refactor the code of
> the EP driver.
> 
> Signed-off-by: Xiaowei Bao 
> ---
> v2:
>  - New mechanism for layerscape EP driver.

Was there a v1 of this patch?

> 
>  drivers/pci/controller/dwc/pci-layerscape-ep.c | 76 
> --
>  1 file changed, 58 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c 
> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index 7ca5fe8..2a66f07 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -20,27 +20,29 @@
>  
>  #define PCIE_DBI2_OFFSET 0x1000  /* DBI2 base address*/
>  
> -struct ls_pcie_ep {
> - struct dw_pcie  *pci;
> - struct pci_epc_features *ls_epc;
> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> +
> +struct ls_pcie_ep_drvdata {
> + u32 func_offset;
> + const struct dw_pcie_ep_ops *ops;
> + const struct dw_pcie_ops*dw_pcie_ops;
>  };
>  
> -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> +struct ls_pcie_ep {
> + struct dw_pcie  *pci;
> + struct pci_epc_features *ls_epc;
> + const struct ls_pcie_ep_drvdata *drvdata;
> +};
>  
>  static int ls_pcie_establish_link(struct dw_pcie *pci)
>  {
>   return 0;
>  }
>  
> -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
>   .start_link = ls_pcie_establish_link,
>  };
>  
> -static const struct of_device_id ls_pcie_ep_of_match[] = {
> - { .compatible = "fsl,ls-pcie-ep",},
> - { },
> -};
> -
>  static const struct pci_epc_features*
>  ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
>  {
> @@ -82,10 +84,44 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 
> func_no,
>   }
>  }
>  
> -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> + u8 func_no)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> + u8 header_type;
> +
> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> +
> + if (header_type & (1 << 7))
> + return pcie->drvdata->func_offset * func_no;
> + else
> + return 0;

It looks like there isn't a PCI define for multi function, the nearest I
could find was PCI_HEADER_TYPE_MULTIDEVICE in hotplug/ibmphp.h. A comment
above the test might be helpful to explain the test.

As the ls_pcie_ep_drvdata structures are static, the unset .func_offset
will be initialised to 0, so you could just drop the test above.

However something to the effect of the following may help spot
misconfiguration:

WARN_ON(func_no && !pcie->drvdata->func_offset);
return pcie->drvdata->func_offset * func_no;

The WARN is probably quite useful as if you are attempting to use
non-zero functions and func_offset isn't set - then things may appear to work
normally but actually will break horribly.

Thanks,

Andrew Murray

> +}
> +
> +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
>   .ep_init = ls_pcie_ep_init,
>   .raise_irq = ls_pcie_ep_raise_irq,
>   .get_features = ls_pcie_ep_get_features,
> + .func_conf_select = ls_pcie_ep_func_conf_select,
> +};
> +
> +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> + .ops = _pcie_ep_ops,
> + .dw_pcie_ops = _ls_pcie_ep_ops,
> +};
> +
> +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> + .func_offset = 0x2,
> + .ops = _pcie_ep_ops,
> + .dw_pcie_ops = _ls_pcie_ep_ops,
> +};
> +
> +static const struct of_device_id ls_pcie_ep_of_match[] = {
> + { .compatible = "fsl,ls1046a-pcie-ep", .data = _ep_drvdata },
> + { .compatible = "fsl,ls1088a-pcie-ep", .data = _ep_drvdata },
> + { .compatible = "fsl,ls2088a-pcie-ep", .data = _ep_drvdata },
> + { },
>  };
>  
>  static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> @@ -98,7 +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
>   int ret;
>  
>   ep = >ep;
> - ep->ops = _ep_ops;
> + ep->ops = pcie->drvdata->ops;
>  
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
>   if (!res)
> @@ -137,14 +173,11 @@ static int __init ls_pcie_ep_probe(struct 
> platform_device *pdev)
>   if (!ls_epc)
>   return -ENOMEM;
>  
> - dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> - if (IS_ERR(pci->dbi_base))
> - return PTR_ERR(pci->dbi_base);
> + pcie->drvdata = of_device_get_match_data(dev);
>  
> - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
>

Re: [PATCH v2 0/2] Simplify mtty driver and mdev core

[Alex Williamson]

On Fri, 23 Aug 2019 08:14:39 +
Parav Pandit  wrote:

> Hi Alex,
> 
> 
> > -Original Message-
> > From: Jiri Pirko 
> > Sent: Friday, August 23, 2019 1:42 PM
> > To: Parav Pandit 
> > Cc: Alex Williamson ; Jiri Pirko
> > ; David S . Miller ; Kirti
> > Wankhede ; Cornelia Huck ;
> > k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia ;
> > net...@vger.kernel.org
> > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > 
> > Thu, Aug 22, 2019 at 03:33:30PM CEST, pa...@mellanox.com wrote:  
> > >
> > >  
> > >> -Original Message-
> > >> From: Jiri Pirko 
> > >> Sent: Thursday, August 22, 2019 5:50 PM
> > >> To: Parav Pandit 
> > >> Cc: Alex Williamson ; Jiri Pirko
> > >> ; David S . Miller ; Kirti
> > >> Wankhede ; Cornelia Huck  
> > ;  
> > >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > >> ; net...@vger.kernel.org
> > >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > >>
> > >> Thu, Aug 22, 2019 at 12:04:02PM CEST, pa...@mellanox.com wrote:  
> > >> >
> > >> >  
> > >> >> -Original Message-
> > >> >> From: Jiri Pirko 
> > >> >> Sent: Thursday, August 22, 2019 3:28 PM
> > >> >> To: Parav Pandit 
> > >> >> Cc: Alex Williamson ; Jiri Pirko
> > >> >> ; David S . Miller ; Kirti
> > >> >> Wankhede ; Cornelia Huck  
> > >> ;  
> > >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > >> >> ; net...@vger.kernel.org
> > >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > >> >>
> > >> >> Thu, Aug 22, 2019 at 11:42:13AM CEST, pa...@mellanox.com wrote:  
> > >> >> >
> > >> >> >  
> > >> >> >> -Original Message-
> > >> >> >> From: Jiri Pirko 
> > >> >> >> Sent: Thursday, August 22, 2019 2:59 PM
> > >> >> >> To: Parav Pandit 
> > >> >> >> Cc: Alex Williamson ; Jiri Pirko
> > >> >> >> ; David S . Miller ;
> > >> >> >> Kirti Wankhede ; Cornelia Huck  
> > >> >> ;  
> > >> >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > >> >> >> ; net...@vger.kernel.org
> > >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > >> >> >>
> > >> >> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, pa...@mellanox.com wrote:  
> > >> >> >> >
> > >> >> >> >  
> > >> >> >> >> -Original Message-
> > >> >> >> >> From: Alex Williamson 
> > >> >> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
> > >> >> >> >> To: Parav Pandit 
> > >> >> >> >> Cc: Jiri Pirko ; David S . Miller
> > >> >> >> >> ; Kirti Wankhede
> > >> >> >> >> ; Cornelia Huck ;
> > >> >> >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > >> >> >> >> ; net...@vger.kernel.org
> > >> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev
> > >> >> >> >> core
> > >> >> >> >>  
> > >> >> >> >> > > > > Just an example of the alias, not proposing how it's 
> > >> >> >> >> > > > > set.
> > >> >> >> >> > > > > In fact, proposing that the user does not set it,
> > >> >> >> >> > > > > mdev-core provides one  
> > >> >> >> >> > > automatically.  
> > >> >> >> >> > > > >  
> > >> >> >> >> > > > > > > Since there seems to be some prefix overhead, as
> > >> >> >> >> > > > > > > I ask about above in how many characters we
> > >> >> >> >> > > > > > > actually have to work with in IFNAMESZ, maybe we
> > >> >> >> >> > > > > > > start with
> > >> >> >> >> > > > > > > 8 characters (matching your "index" namespace)
> > >> >> >> >> > > > > > > and expand as necessary for  
> > >> >> >> disambiguation.  
> > >> >> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's
> > >> >> >> >> > > > > > > start with  
> > >> 12.  
> > >> >> >> >> > > > > > > Thanks,
> > >> >> >> >> > > > > > >  
> > >> >> >> >> > > > > > If user is going to choose the alias, why does it
> > >> >> >> >> > > > > > have to be limited to  
> > >> >> >> >> sha1?  
> > >> >> >> >> > > > > > Or you just told it as an example?
> > >> >> >> >> > > > > >
> > >> >> >> >> > > > > > It can be an alpha-numeric string.  
> > >> >> >> >> > > > >
> > >> >> >> >> > > > > No, I'm proposing a different solution where
> > >> >> >> >> > > > > mdev-core creates an alias based on an abbreviated
> > >> >> >> >> > > > > sha1.  The user does not provide the  
> > >> >> >> >> alias.  
> > >> >> >> >> > > > >  
> > >> >> >> >> > > > > > Instead of mdev imposing number of characters on
> > >> >> >> >> > > > > > the alias, it should be best  
> > >> >> >> >> > > > > left to the user.  
> > >> >> >> >> > > > > > Because in future if netdev improves on the naming
> > >> >> >> >> > > > > > scheme, mdev will be  
> > >> >> >> >> > > > > limiting it, which is not right.  
> > >> >> >> >> > > > > > So not restricting alias size seems right to me.
> > >> >> >> >> > > > > > User configuring mdev for networking devices in a
> > >> >> >> >> > > > > > given kernel knows what  
> > >> >> >> >> > > > > user is doing.  
> > >> >> >> >> > > > > > So user can choose alias name size as it finds 
> > >> >> >> >> > > > > > suitable.  
> > >> >> >> >> > > > >
> > >> >> >> >> > > > > 

Re: [PATCH 4.14 00/71] 4.14.140-stable review

[Guenter Roeck]

On 8/22/19 10:18 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.14.140 release.
There are 71 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat 24 Aug 2019 05:15:46 PM UTC.
Anything received after that time might be too late.



Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 372 pass: 372 fail: 0

Guenter

Re: [PATCH 4.19 00/85] 4.19.68-stable review

[Guenter Roeck]

On 8/22/19 10:18 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.68 release.
There are 85 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat 24 Aug 2019 05:15:49 PM UTC.
Anything received after that time might be too late.



Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 390 pass: 390 fail: 0

Guenter

Re: [Resubmit] Read battery voltage from Logitech Gaming mice

[Filipe Laíns]

On Fri, 2019-08-23 at 10:22 -0400, Pedro Vanzella wrote:
> I actually resubmitted by Filipe's request, since the patches weren't 
> applying cleanly anymore. The idea was to apply these patches and in the 
> future refactor the code to use the feature discovery routines.

Yes, I want to refactor everything so I though there was no point in us
changing the patch set again. I did not review the first revision of
the patch set so if that works for you (Benjamin) we can just merge
that.

> So we (you, me and Filipe) should probably come up with an action plan 
> here. The way I see it there are two issues here: one is adding this 
> feature, and the other is refactoring to use feature discovery for all 
> features. There are advantages and disadvantages to doing one or another 
> first and we might want to discuss that.
> 
> By merging this first (probably after I resubmit it as a single squashed 
> patch) we get to test it a bit better and have a usable feature sooner. 
> Plenty of people have been requesting this and there is plenty of stuff 
> that can be built on top of it, but only once this is actually merged I 
> think.
> 
> On the other hand, by first refactoring the rest of the code to use 
> 0x0001 we avoid some rework on this patch. It should be minor, as most 
> functions here do all the heavy lifting after the initial feature 
> discovery, and are thus mostly independent from how that is done.
> 
> I'm happy either way, so just let me know what you guys decide.

I am also fine either way so I think we should just re-send the first
revision of your patch set as Benjamin requested.

Thank you,
Filipe Laíns


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 5.2 000/135] 5.2.10-stable review

[Guenter Roeck]

On 8/22/19 10:05 AM, Sasha Levin wrote:


This is the start of the stable review cycle for the 5.2.10 release.
There are 135 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat 24 Aug 2019 05:07:10 PM UTC.
Anything received after that time might be too late.



Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 390 pass: 390 fail: 0

Guenter

Re: [PATCH 4/6] x86: remove set_memory_x and set_memory_nx

[Peter Zijlstra]

On Tue, Aug 13, 2019 at 11:01:44AM +0200, Christoph Hellwig wrote:
> These wrappers don't provide a real benefit over just using
> set_memory_x and set_memory_nx.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/x86/include/asm/set_memory.h  |  2 --
>  arch/x86/kernel/machine_kexec_32.c |  4 ++--
>  arch/x86/mm/init_32.c  |  2 +-
>  arch/x86/mm/pageattr.c | 16 
>  4 files changed, 3 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/x86/include/asm/set_memory.h 
> b/arch/x86/include/asm/set_memory.h
> index 899ec9ae7cff..fd549c3ebb17 100644
> --- a/arch/x86/include/asm/set_memory.h
> +++ b/arch/x86/include/asm/set_memory.h
> @@ -75,8 +75,6 @@ int set_pages_array_wb(struct page **pages, int 
> addrinarray);
>  
>  int set_pages_uc(struct page *page, int numpages);
>  int set_pages_wb(struct page *page, int numpages);
> -int set_pages_x(struct page *page, int numpages);
> -int set_pages_nx(struct page *page, int numpages);
>  int set_pages_ro(struct page *page, int numpages);
>  int set_pages_rw(struct page *page, int numpages);

$Subject and patch content don't match up.

Other than that,

Acked-by: Peter Zijlstra (Intel) 

for all x86 patches.

Re: [PATCH] tty/serial: atmel: remove unneeded atmel_get_lines_status function

[Uwe Kleine-König]

On Fri, Aug 23, 2019 at 03:41:09PM +0200, Richard Genoud wrote:
> Since commit ce59e48fdbad ("serial: mctrl_gpio: implement interrupt
> handling"), the GPIOs interrupts are handled by mctrl_gpio_irq_handle().

Well no, since ce59e48fdbad the mctrl_gpio helper can do all that
interrupt stuff. You want to reference
18dfef9c7f87b75bbb0fb66a634f7c13a45b9f8d here.

> So, atmel_get_lines_status() can be completely killed and replaced by :
> atmel_uart_readl(port, ATMEL_US_CSR);
> 
> Signed-off-by: Richard Genoud 

Suggested-by: Uwe Kleine-König 
Acked-by: Uwe Kleine-König 

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

WARNING in sk_msg_check_to_free

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:fed07ef3 Merge tag 'mlx5-updates-2019-08-21' of git://git...
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=150102bc60
kernel config:  https://syzkaller.appspot.com/x/.config?x=e34a4fe936eac597
dashboard link: https://syzkaller.appspot.com/bug?extid=ea3c54a7b2364123d818
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ea3c54a7b2364123d...@syzkaller.appspotmail.com

[ cut here ]
WARNING: CPU: 0 PID: 14478 at include/linux/skmsg.h:129  
sk_msg_check_to_free.isra.0.part.0+0x15/0x19 include/linux/skmsg.h:129

Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 14478 Comm: syz-executor.0 Not tainted 5.3.0-rc5+ #143
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 panic+0x2dc/0x755 kernel/panic.c:219
 __warn.cold+0x20/0x4c kernel/panic.c:576
 report_bug+0x263/0x2b0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:179 [inline]
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:sk_msg_check_to_free.isra.0.part.0+0x15/0x19  
include/linux/skmsg.h:129
Code: 77 ff ff ff e8 4e de 03 fc eb 96 4c 89 f7 e8 e4 dd 03 fc eb c3 55 48  
89 e5 e8 f9 b4 c9 fb 48 c7 c7 80 3a 48 88 e8 c1 55 b3 fb <0f> 0b 5d c3 e8  
e4 b4 c9 fb e8 dd ff ff ff 48 8b 45 d0 0f b6 00 41

RSP: 0018:88806381fb98 EFLAGS: 00010286
RAX: 0024 RBX: 0001 RCX: 
RDX:  RSI: 815c2456 RDI: ed100c703f65
RBP: 88806381fb98 R08: 0024 R09: ed1015d060d1
R10: ed1015d060d0 R11: 8880ae830687 R12: 000d
R13: 8880986c1550 R14: 0001 R15: 0007
 sk_msg_check_to_free include/linux/skmsg.h:129 [inline]
 __sk_msg_free.cold+0xa/0x2e net/core/skmsg.c:190
 sk_msg_free+0x44/0x60 net/core/skmsg.c:207
 tls_sw_release_resources_tx+0x268/0x6b0 net/tls/tls_sw.c:2092
 tls_sk_proto_cleanup net/tls/tls_main.c:275 [inline]
 tls_sk_proto_close+0x6a7/0x990 net/tls/tls_main.c:305
 inet_release+0xed/0x200 net/ipv4/af_inet.c:427
 inet6_release+0x53/0x80 net/ipv6/af_inet6.c:470
 __sock_release+0xce/0x280 net/socket.c:590
 sock_close+0x1e/0x30 net/socket.c:1268
 __fput+0x2ff/0x890 fs/file_table.c:280
 fput+0x16/0x20 fs/file_table.c:313
 task_work_run+0x145/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
 do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x413511
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48  
83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48  
89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01

RSP: 002b:7ffdca8135c0 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0004 RCX: 00413511
RDX: 001b3192 RSI:  RDI: 0003
RBP: 0001 R08: 25038832 R09: 25038836
R10: 7ffdca8136a0 R11: 0293 R12: 0075bf20
R13: 0009f412 R14: 00760b20 R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [Resubmit] Read battery voltage from Logitech Gaming mice

[Benjamin Tissoires]

On Fri, Aug 23, 2019 at 4:22 PM Pedro Vanzella  wrote:
>
> Hi Benjamin,
>
> On 8/23/19 4:25 AM, Benjamin Tissoires wrote:
> > Hi Pedro,
> >
> > On Thu, Aug 22, 2019 at 10:19 PM Pedro Vanzella  
> > wrote:
> >>
> >> Resumitting this after having rebased it against the latest changes.
> >
> > thanks for resubmitting. Sorry I wasn't able to provide feedback on
> > the last revision
> >
>
> No worries, I know how these things are.
>
> >>
> >> The gaming line of Logitech devices doesn't use the old hidpp20
> >> feature for battery level reporting. Instead, they report the
> >> current voltage of the battery, in millivolts.
> >>
> >> This patch set handles this case by adding a quirk to the
> >> devices we know to have this new feature, in both wired
> >> and wireless mode.
> >
> > So the quirk is in the end a bad idea after all. I had some chats with
> > Filipe that made me realize this.
>
> I actually resubmitted by Filipe's request, since the patches weren't
> applying cleanly anymore. The idea was to apply these patches and in the
> future refactor the code to use the feature discovery routines.
>
> > Re-reading our previous exchanges also made me understood why I wasn't
> > happy with the initial submission: for every request the code was
> > checking both features 0x1000 and 0x1001 when we can remember this
> > once and for all during hidpp_initialize_battery().
>
> Yeah I wasn't too happy about this either, but since there was nothing
> prohibiting some device to have both features enabled, I thought this
> wasn't too horrible.

I honestly don't think we will find one device that has both features
enabled. It doesn't make sense as the "new" feature allows for fine
tuning in the software, which would be moot if you also enable the
percentage.

>
> >
> > So I think we should remove the useless quirk in the end (bad idea
> > from me, I concede), and instead during hidpp_initialize_battery() set
> > the correct HIDPP_CAPABILITY_*.
> > Not entirely sure if we should try to call 0x1000, or 0x1001 or if we
> > should rely on the 0x0001 feature to know which feature is available,
> > but this should be implementation detail.
>
> I like the idea of calling 0x0001 once on device boot much better. I
> think we could easily just fetch the location for the features we know
> about and want to deal with once only. This also makes sure we support
> every single device that supports this feature, so that is a huge plus.
>
> In fact, I think we should _not_ call 0x0001 on battery init, but only
> call battery init _after_ we called 0x0001 and discovered either 0x1000
> or 0x1001 (or the solar battery feature, or any other one that might
> crop up in the feature).

ack for that

>
> >
> >>
> >> This version of the patch set is better split, as well as adding the
> >> quirk to make sure we don't needlessly probe every device connected.
> >
> > It is for sure easy to review, but doesn't make much sense in the end.
> > I think we should squash all the patches together as you are just
> > adding one feature in the driver, and it is a little bit disturbing to
> > first add the quirk that has no use, then set up the structs when they
> > are not used, and so on, so forth.
>
> You're right. My first instinct was to send a single patch. As much as I
> tested this, I always feel like breaking the patch up post-facto will
> break a git bisect in the future and everyone will hate me :P

as long as the patches are compiling and are not breaking, git bisect
will not be a problem. However, we might end up with the last one,
which is not very explicit in what it does as it just enables the
features implemented previously.

>
> So we (you, me and Filipe) should probably come up with an action plan
> here. The way I see it there are two issues here: one is adding this
> feature, and the other is refactoring to use feature discovery for all
> features. There are advantages and disadvantages to doing one or another
> first and we might want to discuss that.
>
> By merging this first (probably after I resubmit it as a single squashed
> patch) we get to test it a bit better and have a usable feature sooner.
> Plenty of people have been requesting this and there is plenty of stuff
> that can be built on top of it, but only once this is actually merged I
> think.
>
> On the other hand, by first refactoring the rest of the code to use
> 0x0001 we avoid some rework on this patch. It should be minor, as most
> functions here do all the heavy lifting after the initial feature
> discovery, and are thus mostly independent from how that is done.
>
> I'm happy either way, so just let me know what you guys decide.

I think we should merge your v3 squashed series with a slight
autodetection during battery init, like the method you used in the v1.
This would remove the quirk, but keep the straightforward commands
when addressing battery data.

Relying on 0x0001 should be done separately and can come in in a later
patch IMO (unless you plan to work on it, 

Re: [PATCH net-next v4 0/2] r8152: save EEE

[Andrew Lunn]

On Fri, Aug 23, 2019 at 03:33:39PM +0800, Hayes Wang wrote:
> v4:
> For patch #2, remove redundant calling of "ocp_reg_write(tp, OCP_EEE_ADV, 0)".
> 
> v3:
> For patch #2, fix the mistake caused by copying and pasting.
> 
> v2:
> Adjust patch #1. The EEE has been disabled in the beginning of
> r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if
> it is necessary to enable EEE.

Hi Hayes

That was 3 revisions of the patches in less than 30 minutes. Slow
down, take your time, review your work yourself before posting it,
etc.

Aim for no more than one revision, posted to the list, per day.

Andrew

Re: [RESEND PATCH 01/13] KVM: x86: Relocate MMIO exit stats counting

[Sean Christopherson]

On Fri, Aug 23, 2019 at 11:15:18AM +0200, Vitaly Kuznetsov wrote:
> Sean Christopherson  writes:
> 
> > Move the stat.mmio_exits update into x86_emulate_instruction().  This is
> > both a bug fix, e.g. the current update flows will incorrectly increment
> > mmio_exits on emulation failure, and a preparatory change to set the
> > stage for eliminating EMULATE_DONE and company.
> >
> > Signed-off-by: Sean Christopherson 
> 
> Reviewed-by: Vitaly Kuznetsov 
> 
> This, however, makes me wonder why this is handled in x86-specific code
> in the first place, can we just count KVM_EXIT_MMIO exits when handling
> KVM_RUN?

struct kvm_vcpu_stat is arch specific.  At a glance, everyone is counting
similar things, but often in slightly different ways.  E.g. PowerPC and
ARM count MMIO exits, but PowerPC counts all exits, ARM has separate
counters for in-kernel vs. userspace, and x86 counts only userspace.

KASAN: use-after-free Read in rxrpc_release_call

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:fed07ef3 Merge tag 'mlx5-updates-2019-08-21' of git://git...
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1256e22e60
kernel config:  https://syzkaller.appspot.com/x/.config?x=e34a4fe936eac597
dashboard link: https://syzkaller.appspot.com/bug?extid=eed305768ece6682bb7f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+eed305768ece6682b...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in rxrpc_release_call+0xb2d/0xb60  
net/rxrpc/call_object.c:481

Read of size 8 at addr 888062ffeb50 by task syz-executor.5/4764

CPU: 1 PID: 4764 Comm: syz-executor.5 Not tainted 5.3.0-rc5+ #143
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
 __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
 kasan_report+0x12/0x17 mm/kasan/common.c:612
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
 rxrpc_release_call+0xb2d/0xb60 net/rxrpc/call_object.c:481
 rxrpc_release_calls_on_socket+0x6e7/0x1320 net/rxrpc/call_object.c:517
 rxrpc_release_sock net/rxrpc/af_rxrpc.c:898 [inline]
 rxrpc_release+0x40c/0x840 net/rxrpc/af_rxrpc.c:930
 __sock_release+0xce/0x280 net/socket.c:590
 sock_close+0x1e/0x30 net/socket.c:1268
 __fput+0x2ff/0x890 fs/file_table.c:280
 fput+0x16/0x20 fs/file_table.c:313
 task_work_run+0x145/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
 do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fe5ddebec78 EFLAGS: 0246 ORIG_RAX: 0003
RAX:  RBX: 0001 RCX: 00459829
RDX:  RSI:  RDI: 0003
RBP: 0075bf20 R08:  R09: 
R10:  R11: 0246 R12: 7fe5ddebf6d4
R13: 004f8f72 R14: 004d1a70 R15: 

Allocated by task 4766:
 save_stack+0x23/0x90 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_kmalloc mm/kasan/common.c:487 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
 kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:748 [inline]
 rxrpc_alloc_connection+0x86/0x5f0 net/rxrpc/conn_object.c:41
 rxrpc_alloc_client_connection net/rxrpc/conn_client.c:176 [inline]
 rxrpc_get_client_conn net/rxrpc/conn_client.c:339 [inline]
 rxrpc_connect_call+0x648/0x4c00 net/rxrpc/conn_client.c:697
 rxrpc_new_client_call+0x978/0x19d0 net/rxrpc/call_object.c:289
 rxrpc_new_client_call_for_sendmsg net/rxrpc/sendmsg.c:594 [inline]
 rxrpc_do_sendmsg+0xff5/0x1d53 net/rxrpc/sendmsg.c:651
 rxrpc_sendmsg+0x4d6/0x5f0 net/rxrpc/af_rxrpc.c:585
 sock_sendmsg_nosec net/socket.c:637 [inline]
 sock_sendmsg+0xd7/0x130 net/socket.c:657
 ___sys_sendmsg+0x3e2/0x920 net/socket.c:2311
 __sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413
 __do_sys_sendmmsg net/socket.c:2442 [inline]
 __se_sys_sendmmsg net/socket.c:2439 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2439
 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 16:
 save_stack+0x23/0x90 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
 kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
 __cache_free mm/slab.c:3425 [inline]
 kfree+0x10a/0x2c0 mm/slab.c:3756
 rxrpc_destroy_connection+0x1f2/0x2d0 net/rxrpc/conn_object.c:372
 __rcu_reclaim kernel/rcu/rcu.h:222 [inline]
 rcu_do_batch kernel/rcu/tree.c:2114 [inline]
 rcu_core+0x67f/0x1580 kernel/rcu/tree.c:2314
 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2323
 __do_softirq+0x262/0x98c kernel/softirq.c:292

The buggy address belongs to the object at 888062ffe900
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 592 bytes inside of
 1024-byte region [888062ffe900, 888062ffed00)
The buggy address belongs to the page:
page:ea00018bff80 refcount:1 mapcount:0 mapping:8880aa400c40  

Re: [PATCH] drm/komeda: Add missing of_node_get() call

[Ayan Halder]

On Fri, Aug 23, 2019 at 01:43:49PM +, Ayan Halder wrote:
> On Tue, Aug 20, 2019 at 03:16:58PM +, Mihail Atanassov wrote:
> > komeda_pipeline_destroy has the matching of_node_put().
> > 
> > Fixes: 29e56aec911dd ("drm/komeda: Add DT parsing")
> > Signed-off-by: Mihail Atanassov 
> > ---
> >  drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index 0142ee991957..ca64a129c594 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -130,7 +130,7 @@ static int komeda_parse_pipe_dt(struct komeda_dev 
> > *mdev, struct device_node *np)
> > of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
> >  
> > pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
> > -   pipe->of_node = np;
> > +   pipe->of_node = of_node_get(np);
> >  
> 
> Good catch.
> Reviewed-by: Ayan Kumar Halder 
> > return 0;
> >  }
> > --

Pushed to drm-misc-fixes - 51a44a28eefd0d4c1addeb23fc5a599ff1787dfd

Apologies, I accidently pushed the gerrit change-id in the commit
message. Surprisingly, "checkpatch.pl --strict" did not catch the issue.
> > 2.22.0
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Matthias Brugger]

On 23/08/2019 14:00, Frank Wunderlich wrote:
>> Gesendet: Freitag, 23. August 2019 um 12:04 Uhr
>> Von: "Mark Brown" 
> 
>> Can you run a git bisect to try to identify the commit that
>> caused things to fail?
> 
> i have not figured out, how to rebase linux-next on my current (working) 
> codebase :) (failes on file untouched by me at Patch 3/7000+)
> 
>> Look to see if there is a device driver bound to that device, or
>> check if the parent regulator is visible in /sys/class/regulators.
>> You'll also see a mesage printed out for each regulator as it
>> instantiates in the boot logs, you can check there too.
> 
> in working version i only get this message in dmesg which
> looks like a device-binding:
> 
> mt6323-regulator mt6323-regulator: Chip ID = 0x2023
> 
> this is my regulator: mt6323_vpa_reg
> 
> defined in arch/arm/boot/dts/mt6323.dtsi
> 
>  {
>   pmic: mt6323 {
> mt6323regulator: mt6323regulator{
>   compatible = "mediatek,mt6323-regulator";
>   mt6323_vpa_reg: buck_vpa{
>   regulator-name = "vpa";
>   regulator-min-microvolt = < 50>;
>   regulator-max-microvolt = <365>;
>   };
> };
>   };
> };
> 
> parent regulator is then
> mt6323regulator: mt6323regulator
> 
> which is the one i see i dmesg.
> 
> in working version i see the regulator in sys-fs
> 
> cat /sys/class/regulator/regulator.*/name | grep vpa
> vpa
> 
> ---
> 
> so, now to the non-working regulator:
> 
> dmesg do not have such entry ;(
> 
> regulators-list in /sys/class only containing the dummy and some fixed 
> regulators
> 
> cat /sys/class/regulator/regulator.*/name
> regulator-dummy
> fixed-1.8V
> fixed-3.3V
> fixed-5V
> 
> in arch/arm/boot/dts/mt*.dts and Makefile there is no change between
> working and non-working version.
> in drivers/regulators only the 2 files where i had reverted the
> changes manually without success.
> 
> where can be the cause for no more binding main-regulator?
> 
> are these strange messages related to this problem?
> 
> mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0
> 
> another strange line is this:
> 
> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
> 
> so the pwrap above regulator is affected too
> 
> and here are many changes in 2 files...
> 
> git diff --name-only non-working..working -- drivers/mfd/mt6397-*
> drivers/mfd/mt6397-core.c
> drivers/mfd/mt6397-irq.c
> 
> which brings me to this 2 commits:
> 
> a4872e80ce7d mfd: mt6397: Extract IRQ related code from core driver
> 708cb5cc3fde mfd: mt6397: Rename macros to something more readable

These are commit IDs from linux-next. At least file from 20190822 should
pinpoint you to the correct commits.

@frank: please don't use commit IDs from linux-next as the history get's
rewritten every day and the IDs can change. Better search the tree to which they
got applied and use the commit IDs from there (stating, of course, which tree
you are looking at).

Looking at commit
a4872e80ce7d ("mfd: mt6397: Extract IRQ related code from core driver")

you can see that it doesn't just move the code but also adds new logic in
mt6397_irq_init(). :(

It seems your chip_id is not supported yet. So you will have to find out which
one it is and add it to the switch.

Hope that helped.
Matthias

> 
> after reverting those 2 regulators are working again.
> Adding both Signed-off-People to CC to keep them informed that a fix is needed
> 
>> Please fix your mail client to word wrap within paragraphs at something
>> substantially less than 80 columns.  Doing this makes your messages much
>> easier to read and reply to.
> 
> i currently write in webmailer, where i cannot set this setting,
> i try to add manual linebreak in long lines, ok?
> 
> regards Frank
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

Re: [RESEND PATCH 07/13] KVM: x86: Add explicit flag for forced emulation on #UD

[Sean Christopherson]

On Fri, Aug 23, 2019 at 04:47:14PM +0300, Liran Alon wrote:
> 
> 
> > On 23 Aug 2019, at 4:07, Sean Christopherson 
> >  wrote:
> > 
> > Add an explicit emulation type for forced #UD emulation and use it to
> > detect that KVM should unconditionally inject a #UD instead of falling
> > into its standard emulation failure handling.
> > 
> > Signed-off-by: Sean Christopherson 
> 
> The name "forced emulation on #UD" is not clear to me.
> 
> If I understand correctly, EMULTYPE_TRAP_UD is currently used to indicate
> that in case the x86 emulator fails to decode instruction, the caller would
> like the x86 emulator to fail early such that it can handle this condition
> properly.  Thus, I would rename it EMULTYPE_TRAP_DECODE_FAILURE.

EMULTYPE_TRAP_UD is used when KVM intercepts a #UD from hardware.  KVM
only emulates select instructions in this case in order to minmize the
emulator attack surface, e.g.:

if (unlikely(ctxt->ud) && likely(!(ctxt->d & EmulateOnUD)))
return EMULATION_FAILED;

To enable testing of the emulator, KVM recognizes a special "opcode" that
triggers full emulation on #UD, e.g. ctxt->ud is false when the #UD was
triggered with the magic prefix.  The prefix is only recognized when the
module param force_emulation_prefix is toggled on, hence the name
EMULTYPE_TRAP_UD_FORCED.

> But this new flag seems to do the same. So I’m left confused.  I’m probably
> missing something trivial here.

Re: [Resubmit] Read battery voltage from Logitech Gaming mice

[Filipe Laíns]

On Fri, 2019-08-23 at 16:32 +0200, Benjamin Tissoires wrote:
> The problem I have with quirks, and that I explained to Filipe on IRC
> is that this is kernel ABI. Even if there is a very low chance we have
> someone using this, re-using the same drv_data bit in the future might
> break someone's device.

But we can reserve those bits. I don't expect there to be a ton of
devices that need to be quirked, so using the remaining bits should be
perfectly fine. Do you agree?


signature.asc
Description: This is a digitally signed message part

Re: [PATCH -next v2] sched/fair: fix -Wunused-but-set-variable warnings

[Dave Chiluk]

On Wed, Aug 21, 2019 at 12:36 PM  wrote:
>
> Qian Cai  writes:
>
> > The linux-next commit "sched/fair: Fix low cpu usage with high
> > throttling by removing expiration of cpu-local slices" [1] introduced a
> > few compilation warnings,
> >
> > kernel/sched/fair.c: In function '__refill_cfs_bandwidth_runtime':
> > kernel/sched/fair.c:4365:6: warning: variable 'now' set but not used
> > [-Wunused-but-set-variable]
> > kernel/sched/fair.c: In function 'start_cfs_bandwidth':
> > kernel/sched/fair.c:4992:6: warning: variable 'overrun' set but not used
> > [-Wunused-but-set-variable]
> >
> > Also, __refill_cfs_bandwidth_runtime() does no longer update the
> > expiration time, so fix the comments accordingly.
> >
> > [1] 
> > https://lore.kernel.org/lkml/1558121424-2914-1-git-send-email-chiluk+li...@indeed.com/
> >
> > Signed-off-by: Qian Cai 
>
> Reviewed-by: Ben Segall 
>
> > ---
> >
> > v2: Keep hrtimer_forward_now() in start_cfs_bandwidth() per Ben.
> >
> >  kernel/sched/fair.c | 19 ++-
> >  1 file changed, 6 insertions(+), 13 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 84959d3285d1..06782491691f 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -4354,21 +4354,16 @@ static inline u64 sched_cfs_bandwidth_slice(void)
> >  }
> >
> >  /*
> > - * Replenish runtime according to assigned quota and update expiration 
> > time.
> > - * We use sched_clock_cpu directly instead of rq->clock to avoid adding
> > - * additional synchronization around rq->lock.
> > + * Replenish runtime according to assigned quota. We use sched_clock_cpu
> > + * directly instead of rq->clock to avoid adding additional synchronization
> > + * around rq->lock.
> >   *
> >   * requires cfs_b->lock
> >   */
> >  void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b)
> >  {
> > - u64 now;
> > -
> > - if (cfs_b->quota == RUNTIME_INF)
> > - return;
> > -
> > - now = sched_clock_cpu(smp_processor_id());
> > - cfs_b->runtime = cfs_b->quota;
> > + if (cfs_b->quota != RUNTIME_INF)
> > + cfs_b->runtime = cfs_b->quota;
> >  }
> >
> >  static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
> > @@ -4989,15 +4984,13 @@ static void init_cfs_rq_runtime(struct cfs_rq 
> > *cfs_rq)
> >
> >  void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
> >  {
> > - u64 overrun;
> > -
> >   lockdep_assert_held(_b->lock);
> >
> >   if (cfs_b->period_active)
> >   return;
> >
> >   cfs_b->period_active = 1;
> > - overrun = hrtimer_forward_now(_b->period_timer, cfs_b->period);
> > + hrtimer_forward_now(_b->period_timer, cfs_b->period);
> >   hrtimer_start_expires(_b->period_timer, HRTIMER_MODE_ABS_PINNED);
> >  }

Looks good.
Reviewed-by: Dave Chiluk 

Sorry for the slow response, I was on vacation.

@Ben do you think it would be useful to still capture overrun, and
WARN on any overruns?  We wouldn't expect overruns, but their
existence would indicate an over-loaded node or too short of a
cfs_period.  Additionally, it would be interesting to see if we could
capture the offset between when the bandwidth was refilled, and when
the timer was supposed to fire.  I've always done all my calculations
assuming that the timer fires and is handled exceedingly close to the
time it was supposed to fire.  Although, if the node is running that
overloaded you probably have many more problems than worrying about
timer warnings.

Re: [PATCH v2 1/3] kprobes/x86: use instruction_pointer and instruction_pointer_set

[Masami Hiramatsu]

Hi Jisheng,

On Wed, 21 Aug 2019 02:09:10 +
Jisheng Zhang  wrote:

> > > In v2, actually, the arm64 version's kprobe_ftrace_handler() is the same
> > > as x86's, the only difference is comment, e.g
> > >
> > > /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> > >
> > > while in arm64
> > >
> > > /* Kprobe handler expects regs->pc = ip + 1 as breakpoint hit */  
> > 
> > As Peter pointed, on arm64, is that really 1 or 4 bytes?
> > This part is heavily depends on the processor software-breakpoint
> > implementation.
> 
> Per my understanding, the "+1" here means "+ one kprobe_opcode_t".

No, that is the size of INT3. It just emulates the software trap on x86.

Thank you,
-- 
Masami Hiramatsu 

RE: [PATCH v2 0/2] Simplify mtty driver and mdev core

[Parav Pandit]

> -Original Message-
> From: Alex Williamson 
> Sent: Friday, August 23, 2019 7:58 PM
> To: Parav Pandit 
> Cc: Jiri Pirko ; Jiri Pirko ; David S . 
> Miller
> ; Kirti Wankhede ; Cornelia
> Huck ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; cjia ; net...@vger.kernel.org
> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> 
> On Fri, 23 Aug 2019 08:14:39 +
> Parav Pandit  wrote:
> 
> > Hi Alex,
> >
> >
> > > -Original Message-
> > > From: Jiri Pirko 
> > > Sent: Friday, August 23, 2019 1:42 PM
> > > To: Parav Pandit 
> > > Cc: Alex Williamson ; Jiri Pirko
> > > ; David S . Miller ; Kirti
> > > Wankhede ; Cornelia Huck
> ;
> > > k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > > ; net...@vger.kernel.org
> > > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > >
> > > Thu, Aug 22, 2019 at 03:33:30PM CEST, pa...@mellanox.com wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Jiri Pirko 
> > > >> Sent: Thursday, August 22, 2019 5:50 PM
> > > >> To: Parav Pandit 
> > > >> Cc: Alex Williamson ; Jiri Pirko
> > > >> ; David S . Miller ;
> > > >> Kirti Wankhede ; Cornelia Huck
> > > ;
> > > >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > > >> ; net...@vger.kernel.org
> > > >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > > >>
> > > >> Thu, Aug 22, 2019 at 12:04:02PM CEST, pa...@mellanox.com wrote:
> > > >> >
> > > >> >
> > > >> >> -Original Message-
> > > >> >> From: Jiri Pirko 
> > > >> >> Sent: Thursday, August 22, 2019 3:28 PM
> > > >> >> To: Parav Pandit 
> > > >> >> Cc: Alex Williamson ; Jiri Pirko
> > > >> >> ; David S . Miller ;
> > > >> >> Kirti Wankhede ; Cornelia Huck
> > > >> ;
> > > >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > > >> >> ; net...@vger.kernel.org
> > > >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> > > >> >>
> > > >> >> Thu, Aug 22, 2019 at 11:42:13AM CEST, pa...@mellanox.com wrote:
> > > >> >> >
> > > >> >> >
> > > >> >> >> -Original Message-
> > > >> >> >> From: Jiri Pirko 
> > > >> >> >> Sent: Thursday, August 22, 2019 2:59 PM
> > > >> >> >> To: Parav Pandit 
> > > >> >> >> Cc: Alex Williamson ; Jiri
> > > >> >> >> Pirko ; David S . Miller
> > > >> >> >> ; Kirti Wankhede
> > > >> >> >> ; Cornelia Huck
> > > >> >> ;
> > > >> >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> > > >> >> >> ; net...@vger.kernel.org
> > > >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev
> > > >> >> >> core
> > > >> >> >>
> > > >> >> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, pa...@mellanox.com
> wrote:
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >> >> -Original Message-
> > > >> >> >> >> From: Alex Williamson 
> > > >> >> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
> > > >> >> >> >> To: Parav Pandit 
> > > >> >> >> >> Cc: Jiri Pirko ; David S . Miller
> > > >> >> >> >> ; Kirti Wankhede
> > > >> >> >> >> ; Cornelia Huck
> > > >> >> >> >> ; k...@vger.kernel.org;
> > > >> >> >> >> linux-kernel@vger.kernel.org; cjia ;
> > > >> >> >> >> net...@vger.kernel.org
> > > >> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and
> > > >> >> >> >> mdev core
> > > >> >> >> >>
> > > >> >> >> >> > > > > Just an example of the alias, not proposing how it's 
> > > >> >> >> >> > > > > set.
> > > >> >> >> >> > > > > In fact, proposing that the user does not set
> > > >> >> >> >> > > > > it, mdev-core provides one
> > > >> >> >> >> > > automatically.
> > > >> >> >> >> > > > >
> > > >> >> >> >> > > > > > > Since there seems to be some prefix
> > > >> >> >> >> > > > > > > overhead, as I ask about above in how many
> > > >> >> >> >> > > > > > > characters we actually have to work with in
> > > >> >> >> >> > > > > > > IFNAMESZ, maybe we start with
> > > >> >> >> >> > > > > > > 8 characters (matching your "index"
> > > >> >> >> >> > > > > > > namespace) and expand as necessary for
> > > >> >> >> disambiguation.
> > > >> >> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ,
> > > >> >> >> >> > > > > > > let's start with
> > > >> 12.
> > > >> >> >> >> > > > > > > Thanks,
> > > >> >> >> >> > > > > > >
> > > >> >> >> >> > > > > > If user is going to choose the alias, why does
> > > >> >> >> >> > > > > > it have to be limited to
> > > >> >> >> >> sha1?
> > > >> >> >> >> > > > > > Or you just told it as an example?
> > > >> >> >> >> > > > > >
> > > >> >> >> >> > > > > > It can be an alpha-numeric string.
> > > >> >> >> >> > > > >
> > > >> >> >> >> > > > > No, I'm proposing a different solution where
> > > >> >> >> >> > > > > mdev-core creates an alias based on an
> > > >> >> >> >> > > > > abbreviated sha1.  The user does not provide the
> > > >> >> >> >> alias.
> > > >> >> >> >> > > > >
> > > >> >> >> >> > > > > > Instead of mdev imposing number of characters
> > > >> >> >> >> > > > > > on the alias, it should be best
> > > >> >> >> >> > > > > left to the user.
> > > >> >> >> >> > > > > 

Re: [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver

[Matthias Brugger]

On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> In order to support different types of irq design, we decide to add
> separate irq drivers for different design and keep mt6397 mfd core
> simple and reusable to all generations of PMICs so far.
> 
> Acked-for-mfd-by: Lee Jones 
> Signed-off-by: Hsin-Hsiung Wang 
> ---
>  drivers/mfd/Makefile|   3 +-
>  drivers/mfd/mt6397-core.c   | 146 
>  drivers/mfd/mt6397-irq.c| 181 
> 
>  include/linux/mfd/mt6397/core.h |   9 ++
>  4 files changed, 192 insertions(+), 147 deletions(-)
>  create mode 100644 drivers/mfd/mt6397-irq.c
> 
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index f026ada..9a96325 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -241,7 +241,8 @@ obj-$(CONFIG_INTEL_SOC_PMIC)  += intel-soc-pmic.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)   += intel_soc_pmic_chtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +mt6397-objs  := mt6397-core.o mt6397-irq.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397.o
>  
>  obj-$(CONFIG_MFD_ALTERA_A10SR)   += altera-a10sr.o
>  obj-$(CONFIG_MFD_ALTERA_SYSMGR) += altera-sysmgr.o
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index c070862..93c8881 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -18,10 +18,6 @@
>  #define MT6397_RTC_BASE  0xe000
>  #define MT6397_RTC_SIZE  0x3e
>  
> -#define MT6323_CHIP_ID   0x23
> -#define MT6391_CHIP_ID   0x91
> -#define MT6397_CHIP_ID   0x97
> -
>  static const struct resource mt6397_rtc_resources[] = {
>   {
>   .start = MT6397_RTC_BASE,
> @@ -86,148 +82,6 @@
>   }
>  };
>  
> -static void mt6397_irq_lock(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> -
> - mutex_lock(>irqlock);
> -}
> -
> -static void mt6397_irq_sync_unlock(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> -
> - regmap_write(mt6397->regmap, mt6397->int_con[0],
> -  mt6397->irq_masks_cur[0]);
> - regmap_write(mt6397->regmap, mt6397->int_con[1],
> -  mt6397->irq_masks_cur[1]);
> -
> - mutex_unlock(>irqlock);
> -}
> -
> -static void mt6397_irq_disable(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> - int shift = data->hwirq & 0xf;
> - int reg = data->hwirq >> 4;
> -
> - mt6397->irq_masks_cur[reg] &= ~BIT(shift);
> -}
> -
> -static void mt6397_irq_enable(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> - int shift = data->hwirq & 0xf;
> - int reg = data->hwirq >> 4;
> -
> - mt6397->irq_masks_cur[reg] |= BIT(shift);
> -}
> -
> -#ifdef CONFIG_PM_SLEEP
> -static int mt6397_irq_set_wake(struct irq_data *irq_data, unsigned int on)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(irq_data);
> - int shift = irq_data->hwirq & 0xf;
> - int reg = irq_data->hwirq >> 4;
> -
> - if (on)
> - mt6397->wake_mask[reg] |= BIT(shift);
> - else
> - mt6397->wake_mask[reg] &= ~BIT(shift);
> -
> - return 0;
> -}
> -#else
> -#define mt6397_irq_set_wake NULL
> -#endif
> -
> -static struct irq_chip mt6397_irq_chip = {
> - .name = "mt6397-irq",
> - .irq_bus_lock = mt6397_irq_lock,
> - .irq_bus_sync_unlock = mt6397_irq_sync_unlock,
> - .irq_enable = mt6397_irq_enable,
> - .irq_disable = mt6397_irq_disable,
> - .irq_set_wake = mt6397_irq_set_wake,
> -};
> -
> -static void mt6397_irq_handle_reg(struct mt6397_chip *mt6397, int reg,
> - int irqbase)
> -{
> - unsigned int status;
> - int i, irq, ret;
> -
> - ret = regmap_read(mt6397->regmap, reg, );
> - if (ret) {
> - dev_err(mt6397->dev, "Failed to read irq status: %d\n", ret);
> - return;
> - }
> -
> - for (i = 0; i < 16; i++) {
> - if (status & BIT(i)) {
> - irq = irq_find_mapping(mt6397->irq_domain, irqbase + i);
> - if (irq)
> - handle_nested_irq(irq);
> - }
> - }
> -
> - regmap_write(mt6397->regmap, reg, status);
> -}
> -
> -static irqreturn_t mt6397_irq_thread(int irq, void *data)
> -{
> - struct mt6397_chip *mt6397 = data;
> -
> - mt6397_irq_handle_reg(mt6397, mt6397->int_status[0], 0);
> - mt6397_irq_handle_reg(mt6397, mt6397->int_status[1], 16);
> -
> - return IRQ_HANDLED;
> -}
> -
> -static int mt6397_irq_domain_map(struct irq_domain *d, unsigned int irq,
> - irq_hw_number_t hw)
> -{
> - struct mt6397_chip 

[RFC 2/9] dt-bindings: arm: samsung: Document missing S5Pv210 boards bindings

[Krzysztof Kozlowski]

Add missing documentation of Samsung S5Pv210 SoC based boards bindings.

Signed-off-by: Krzysztof Kozlowski 
---
 .../bindings/arm/samsung/samsung-boards.yaml   | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index e963fd70c436..f8da3b5fb374 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -14,6 +14,16 @@ properties:
 const: '/'
   compatible:
 oneOf:
+  - description: S5PV210 based boards
+items:
+  - enum:
+  - aesop,torbreck  # aESOP Torbreck based on 
S5PV210
+  - samsung,aquila  # Samsung Aquila based on 
S5PC110
+  - samsung,goni# Samsung Goni based on S5PC110
+  - yic,smdkc110# YIC System SMDKC110 based on 
S5PC110
+  - yic,smdkv210# YIC System SMDKV210 based on 
S5PV210
+  - const: samsung,s5pv210
+
   - description: S5PV210 based Aries boards
 items:
   - enum:
-- 
2.17.1

[RFC 1/9] dt-bindings: arm: samsung: Convert Samsung board/soc bindings to json-schema

[Krzysztof Kozlowski]

Convert Samsung S5P and Exynos SoC bindings to DT schema format using
json-schema.  This is purely conversion of already documented bindings
so it does not cover all of DTS in the Linux kernel (few S5P/Exynos and
all S3C are missing).

Signed-off-by: Krzysztof Kozlowski 

---

If the schema looks sensible, I will continue on converting other
SoC and driver bindings and later adding missing schemas (S3C
SoCs).
---
 .../bindings/arm/samsung/samsung-boards.txt   |  83 
 .../bindings/arm/samsung/samsung-boards.yaml  | 188 ++
 2 files changed, 188 insertions(+), 83 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
deleted file mode 100644
index 56021bf2a916..
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-* Samsung's Exynos and S5P SoC based boards
-
-Required root node properties:
-- compatible = should be one or more of the following.
-   - "samsung,aries"   - for S5PV210-based Samsung Aries board.
-   - "samsung,fascinate4g" - for S5PV210-based Samsung Galaxy S Fascinate 
4G (SGH-T959P) board.
-   - "samsung,galaxys" - for S5PV210-based Samsung Galaxy S (i9000)  
board.
-   - "samsung,artik5"  - for Exynos3250-based Samsung ARTIK5 module.
-   - "samsung,artik5-eval" - for Exynos3250-based Samsung ARTIK5 eval 
board.
-   - "samsung,monk"- for Exynos3250-based Samsung Simband board.
-   - "samsung,rinato"  - for Exynos3250-based Samsung Gear2 board.
-   - "samsung,smdkv310"- for Exynos4210-based Samsung SMDKV310 eval 
board.
-   - "samsung,trats"   - for Exynos4210-based Tizen Reference board.
-   - "samsung,universal_c210" - for Exynos4210-based Samsung board.
-   - "samsung,i9300"  - for Exynos4412-based Samsung GT-I9300 
board.
-   - "samsung,i9305"  - for Exynos4412-based Samsung GT-I9305 
board.
-   - "samsung,midas"   - for Exynos4412-based Samsung Midas board.
-   - "samsung,smdk4412",   - for Exynos4412-based Samsung SMDK4412 eval 
board.
-   - "samsung,n710x"  - for Exynos4412-based Samsung 
GT-N7100/GT-N7105 board.
-   - "samsung,trats2"  - for Exynos4412-based Tizen Reference board.
-   - "samsung,smdk5250"- for Exynos5250-based Samsung SMDK5250 eval 
board.
-   - "samsung,xyref5260"   - for Exynos5260-based Samsung board.
-   - "samsung,smdk5410"- for Exynos5410-based Samsung SMDK5410 eval 
board.
-   - "samsung,smdk5420"- for Exynos5420-based Samsung SMDK5420 eval 
board.
-   - "samsung,tm2" - for Exynos5433-based Samsung TM2 board.
-   - "samsung,tm2e"- for Exynos5433-based Samsung TM2E board.
-
-* Other companies Exynos SoC based
-  * FriendlyARM
-   - "friendlyarm,tiny4412"  - for Exynos4412-based FriendlyARM
-   TINY4412 board.
-  * TOPEET
-   - "topeet,itop4412-elite" - for Exynos4412-based TOPEET
-Elite base board.
-
-  * Google
-   - "google,pi"   - for Exynos5800-based Google Peach Pi
- Rev 10+ board,
- also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14",
-   "google,pi-rev13", "google,pi-rev12", "google,pi-rev11",
-   "google,pi-rev10", "google,peach".
-
-   - "google,pit"  - for Exynos5420-based Google Peach Pit
- Rev 6+ (Exynos5420),
- also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14",
-   "google,pit-rev13", "google,pit-rev12", "google,pit-rev11",
-   "google,pit-rev10", "google,pit-rev9", "google,pit-rev8",
-   "google,pit-rev7", "google,pit-rev6", "google,peach".
-
-   - "google,snow-rev4"- for Exynos5250-based Google Snow board,
- also: "google,snow"
-   - "google,snow-rev5"- for Exynos5250-based Google Snow
- Rev 5+ board.
-   - "google,spring"   - for Exynos5250-based Google Spring board.
-
-  * Hardkernel
-   - "hardkernel,odroid-u3"  - for Exynos4412-based Hardkernel Odroid U3.
-   - "hardkernel,odroid-x"   - for Exynos4412-based Hardkernel Odroid X.
-   - "hardkernel,odroid-x2"  - for Exynos4412-based Hardkernel Odroid X2.
-   - "hardkernel,odroid-xu"  - for Exynos5410-based Hardkernel Odroid XU.
-   - "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
-   - "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
-Odroid XU3 Lite board.
-   - "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4.
-  

[RFC 6/9] dt-bindings: arm: samsung: Convert Exynos System Registers bindings to json-schema

[Krzysztof Kozlowski]

Convert Samsung Exynos System Registers (SYSREG) bindings to DT schema
format using json-schema.

Signed-off-by: Krzysztof Kozlowski 

---

Example somehow fails:
Documentation/devicetree/bindings/arm/samsung/pmu.example.dt.yaml:
system-controller@1004: compatible:0: 'samsung,exynos5250-pmu' is
not one of ['samsung,exynos4-sysreg', 'samsung,exynos5-sysreg']

It seems that PMU schema is applied to sysreq nodes (and vice-versa).
---
 .../bindings/arm/samsung/sysreg.txt   | 19 ---
 .../bindings/arm/samsung/sysreg.yaml  | 33 +++
 2 files changed, 33 insertions(+), 19 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.txt
 create mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.yaml

diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt 
b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
deleted file mode 100644
index 4fced6e9d5e4..
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
-
-Properties:
- - compatible : should contain two values. First value must be one from 
following list:
-   - "samsung,exynos4-sysreg" - for Exynos4 based SoCs,
-   - "samsung,exynos5-sysreg" - for Exynos5 based SoCs.
-   second value must be always "syscon".
- - reg : offset and length of the register set.
-
-Example:
-   syscon@1001 {
-   compatible = "samsung,exynos4-sysreg", "syscon";
-   reg = <0x1001 0x400>;
-   };
-
-   syscon@1005 {
-   compatible = "samsung,exynos5-sysreg", "syscon";
-   reg = <0x1005 0x5000>;
-   };
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml 
b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
new file mode 100644
index ..a3d44646e441
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/samsung/sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5P/Exynos SoC series System Registers (SYSREG)
+
+maintainers:
+  - Krzysztof Kozlowski 
+
+properties:
+  compatible:
+items:
+  - enum:
+  - samsung,exynos4-sysreg
+  - samsung,exynos5-sysreg
+  - const: syscon
+
+  reg:
+maxItems: 1
+
+examples:
+  - |
+syscon@1001 {
+  compatible = "samsung,exynos4-sysreg", "syscon";
+  reg = <0x1001 0x400>;
+};
+
+syscon@1005 {
+  compatible = "samsung,exynos5-sysreg", "syscon";
+  reg = <0x1005 0x5000>;
+};
-- 
2.17.1

[RFC 7/9] dt-bindings: rtc: s3c: Convert S3C/Exynos RTC bindings to json-schema

[Krzysztof Kozlowski]

Convert Samsung S3C/Exynos Real Time Clock bindings to DT schema format
using json-schema.

Signed-off-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/rtc/s3c-rtc.txt   | 31 --
 .../devicetree/bindings/rtc/s3c-rtc.yaml  | 95 +++
 2 files changed, 95 insertions(+), 31 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.txt
 create mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml

diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt 
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
deleted file mode 100644
index fdde63a5419c..
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* Samsung's S3C Real Time Clock controller
-
-Required properties:
-- compatible: should be one of the following.
-* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
-* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
-* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
-* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
-* "samsung,exynos3250-rtc" - (deprecated) for controllers compatible with
- exynos3250 rtc (use "samsung,s3c6410-rtc").
-- reg: physical base address of the controller and length of memory mapped
-  region.
-- interrupts: Two interrupt numbers to the cpu should be specified. First
-  interrupt number is the rtc alarm interrupt and second interrupt number
-  is the rtc tick interrupt. The number of cells representing a interrupt
-  depends on the parent interrupt controller.
-- clocks: Must contain a list of phandle and clock specifier for the rtc
-  clock and in the case of a s3c6410 compatible controller, also
-  a source clock.
-- clock-names: Must contain "rtc" and for a s3c6410 compatible controller,
-   a "rtc_src" sorted in the same order as the clocks property.
-
-Example:
-
-   rtc@1007 {
-   compatible = "samsung,s3c6410-rtc";
-   reg = <0x1007 0x100>;
-   interrupts = <44 0 45 0>;
-   clocks = < CLK_RTC>, <_osc S2MPS11_CLK_AP>;
-   clock-names = "rtc", "rtc_src";
-   };
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
new file mode 100644
index ..44b021812a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/s3c-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S3C, S5P and Exynos Real Time Clock controller
+
+maintainers:
+  - Krzysztof Kozlowski 
+
+# Select also deprecated compatibles (for finding deprecate usage)
+select:
+  properties:
+compatible:
+  items:
+- enum:
+- samsung,s3c2410-rtc
+- samsung,s3c2416-rtc
+- samsung,s3c2443-rtc
+- samsung,s3c6410-rtc
+# Deprecated, use samsung,s3c6410-rtc
+- samsung,exynos3250-rtc
+  required:
+- compatible
+
+properties:
+  compatible:
+items:
+  - enum:
+  - samsung,s3c2410-rtc
+  - samsung,s3c2416-rtc
+  - samsung,s3c2443-rtc
+  - samsung,s3c6410-rtc
+  reg:
+maxItems: 1
+
+  clocks:
+description:
+  Must contain a list of phandle and clock specifier for the rtc
+  clock and in the case of a s3c6410 compatible controller, also
+  a source clock.
+minItems: 1
+maxItems: 2
+
+  clock-names:
+description:
+  Must contain "rtc" and for a s3c6410 compatible controller,
+  a "rtc_src" sorted in the same order as the clocks property.
+oneOf:
+  - items:
+  - const: rtc
+  - items:
+  # TODO: This can be in any order matching clocks, how to express it?
+  - const: rtc
+  - const: rtc_src
+
+  interrupts:
+description:
+  Two interrupt numbers to the cpu should be specified. First
+  interrupt number is the rtc alarm interrupt and second interrupt number
+  is the rtc tick interrupt. The number of cells representing a interrupt
+  depends on the parent interrupt controller.
+minItems: 2
+maxItems: 2
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - samsung,s3c6410-rtc
+  - samsung,exynos3250-rtc
+
+then:
+  properties:
+clocks:
+  minItems: 2
+  maxItems: 2
+clock-names:
+  items:
+  - const: rtc
+  - const: rtc_src
+
+examples:
+  - |
+rtc@1007 {
+  compatible = "samsung,s3c6410-rtc";
+  reg = <0x1007 0x100>;
+  interrupts = <0 44 4>, <0 45 4>;
+  clocks = < 0>, // CLK_RTC
+   <_osc 0>; // S2MPS11_CLK_AP
+  clock-names = "rtc", "rtc_src";
+ 

[RFC 4/9] dt-bindings: arm: samsung: Convert Exynos Chipid bindings to json-schema

[Krzysztof Kozlowski]

Convert Samsung Exynos Chipid bindings to DT schema format using
json-schema.

Signed-off-by: Krzysztof Kozlowski 
---
 .../bindings/arm/samsung/exynos-chipid.txt| 12 --
 .../bindings/arm/samsung/exynos-chipid.yaml   | 24 +++
 2 files changed, 24 insertions(+), 12 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
deleted file mode 100644
index 85c5dfd4a720..
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-SAMSUNG Exynos SoCs Chipid driver.
-
-Required properties:
-- compatible : Should at least contain "samsung,exynos4210-chipid".
-
-- reg: offset and length of the register set
-
-Example:
-   chipid@1000 {
-   compatible = "samsung,exynos4210-chipid";
-   reg = <0x1000 0x100>;
-   };
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml 
b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml
new file mode 100644
index ..d22d5376a11e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/samsung/exynos-chipid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series Chipid driver
+
+maintainers:
+  - Krzysztof Kozlowski 
+
+properties:
+  compatible:
+items:
+  - const: samsung,exynos4210-chipid
+  reg:
+maxItems: 1
+
+examples:
+  - |
+chipid@1000 {
+  compatible = "samsung,exynos4210-chipid";
+  reg = <0x1000 0x100>;
+};
-- 
2.17.1

[RFC 3/9] dt-bindings: arm: samsung: Document missing Exynos7 boards bindings

[Krzysztof Kozlowski]

Add missing documentation of ARMv8 Samsung Exynos7 SoC based boards
bindings.

Signed-off-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/arm/samsung/samsung-boards.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index f8da3b5fb374..c640191c5d73 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -174,6 +174,12 @@ properties:
   - samsung,tm2e# Samsung TM2E
   - const: samsung,exynos5433
 
+  - description: Exynos7 based boards
+items:
+  - enum:
+  - samsung,exynos7-espresso# Samsung Exynos7 Espresso
+  - const: samsung,exynos7
+
   firmware:
 type: object
 description:
-- 
2.17.1

[RFC 5/9] dt-bindings: arm: samsung: Convert Exynos PMU bindings to json-schema

[Krzysztof Kozlowski]

Convert Samsung Exynos Power Management Unit (PMU) bindings to DT schema
format using json-schema.

Signed-off-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/arm/samsung/pmu.txt   | 72 --
 .../devicetree/bindings/arm/samsung/pmu.yaml  | 93 +++
 2 files changed, 93 insertions(+), 72 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.yaml

diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
deleted file mode 100644
index 433bfd7593ac..
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-SAMSUNG Exynos SoC series PMU Registers
-
-Properties:
- - compatible : should contain two values. First value must be one from 
following list:
-  - "samsung,exynos3250-pmu" - for Exynos3250 SoC,
-  - "samsung,exynos4210-pmu" - for Exynos4210 SoC,
-  - "samsung,exynos4412-pmu" - for Exynos4412 SoC,
-  - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
-  - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
-  - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
-  - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
-  - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
-  - "samsung,exynos7-pmu" - for Exynos7 SoC.
-   second value must be always "syscon".
-
- - reg : offset and length of the register set.
-
- - #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
-   The single specifier cell is used as index to list of clocks
-   provided by PMU, which is currently:
-   0 : SoC clock output (CLKOUT pin)
-
- - clock-names : list of clock names for particular CLKOUT mux inputs in
-   following format:
-   "clkoutN", where N is a decimal number corresponding to
-   CLKOUT mux control bits value for given input, e.g.
-   "clkout0", "clkout7", "clkout15".
-
- - clocks : list of phandles and specifiers to all input clocks listed in
-   clock-names property.
-
-Optional properties:
-
-Some PMUs are capable of behaving as an interrupt controller (mostly
-to wake up a suspended PMU). In which case, they can have the
-following properties:
-
-- interrupt-controller: indicate that said PMU is an interrupt controller
-
-- #interrupt-cells: must be identical to the that of the parent interrupt
-  controller.
-
-
-Optional nodes:
-
-- nodes defining the restart and poweroff syscon children
-
-
-Example :
-pmu_system_controller: system-controller@1004 {
-   compatible = "samsung,exynos5250-pmu", "syscon";
-   reg = <0x1004 0x5000>;
-   interrupt-controller;
-   #interrupt-cells = <3>;
-   interrupt-parent = <>;
-   #clock-cells = <1>;
-   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
-   "clkout4", "clkout8", "clkout9";
-   clocks = < CLK_OUT_DMC>, < CLK_OUT_TOP>,
-   < CLK_OUT_LEFTBUS>, < CLK_OUT_RIGHTBUS>,
-   < CLK_OUT_CPU>, < CLK_XXTI>,
-   < CLK_XUSBXTI>;
-};
-
-Example of clock consumer :
-
-usb3503: usb3503@8 {
-   /* ... */
-   clock-names = "refclk";
-   clocks = <_system_controller 0>;
-   /* ... */
-};
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml 
b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
new file mode 100644
index ..818c6f3488ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series Power Management Unit (PMU)
+
+maintainers:
+  - Krzysztof Kozlowski 
+
+properties:
+  compatible:
+items:
+  - enum:
+  - samsung,exynos3250-pmu
+  - samsung,exynos4210-pmu
+  - samsung,exynos4412-pmu
+  - samsung,exynos5250-pmu
+  - samsung,exynos5260-pmu
+  - samsung,exynos5410-pmu
+  - samsung,exynos5420-pmu
+  - samsung,exynos5433-pmu
+  - samsung,exynos7-pmu
+  - const: syscon
+
+  reg:
+maxItems: 1
+
+  '#clock-cells':
+const: 1
+
+  clock-names:
+description:
+  list of clock names for particular CLKOUT mux inputs
+# TODO: what is the maximum number of elements (mux inputs)?
+minItems: 1
+maxItems: 32
+items:
+  - enum:
+  - clkout0
+  - clkout1
+  - clkout2
+  - clkout3
+  - clkout4
+  - clkout5
+  - clkout6
+  - clkout7
+  - clkout8
+  - clkout9
+  - clkout10
+  - 

[RFC 8/9] dt-bindings: iio: adc: exynos: Convert Exynos ADC bindings to json-schema

[Krzysztof Kozlowski]

Convert Samsung Exynos Analog to Digital Converter bindings to DT schema
format using json-schema.

Signed-off-by: Krzysztof Kozlowski 
---
 .../bindings/iio/adc/samsung,exynos-adc.txt   | 107 
 .../bindings/iio/adc/samsung,exynos-adc.yaml  | 159 ++
 2 files changed, 159 insertions(+), 107 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
 create mode 100644 
Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml

diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
deleted file mode 100644
index e1fe02f3e3e9..
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-Samsung Exynos Analog to Digital Converter bindings
-
-The devicetree bindings are for the new ADC driver written for
-Exynos4 and upward SoCs from Samsung.
-
-New driver handles the following
-1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
-   and future SoCs from Samsung
-2. Add ADC driver under iio/adc framework
-3. Also adds the Documentation for device tree bindings
-
-Required properties:
-- compatible:  Must be "samsung,exynos-adc-v1"
-   for Exynos5250 controllers.
-   Must be "samsung,exynos-adc-v2" for
-   future controllers.
-   Must be "samsung,exynos3250-adc" for
-   controllers compatible with ADC of Exynos3250.
-   Must be "samsung,exynos4212-adc" for
-   controllers compatible with ADC of Exynos4212 
and Exynos4412.
-   Must be "samsung,exynos7-adc" for
-   the ADC in Exynos7 and compatibles
-   Must be "samsung,s3c2410-adc" for
-   the ADC in s3c2410 and compatibles
-   Must be "samsung,s3c2416-adc" for
-   the ADC in s3c2416 and compatibles
-   Must be "samsung,s3c2440-adc" for
-   the ADC in s3c2440 and compatibles
-   Must be "samsung,s3c2443-adc" for
-   the ADC in s3c2443 and compatibles
-   Must be "samsung,s3c6410-adc" for
-   the ADC in s3c6410 and compatibles
-   Must be "samsung,s5pv210-adc" for
-   the ADC in s5pv210 and compatibles
-- reg: List of ADC register address range
-   - The base address and range of ADC register
-   - The base address and range of ADC_PHY register (every
- SoC except for s3c24xx/s3c64xx ADC)
-- interrupts:  Contains the interrupt information for the timer. The
-   format is being dependent on which interrupt controller
-   the Samsung device uses.
-- #io-channel-cells = <1>; As ADC has multiple outputs
-- clocks   From common clock bindings: handles to clocks specified
-   in "clock-names" property, in the same order.
-- clock-names  From common clock bindings: list of clock input names
-   used by ADC block:
-   - "adc" : ADC bus clock
-   - "sclk" : ADC special clock (only for Exynos3250 and
-  compatible ADC block)
-- vdd-supply   VDD input supply.
-
-- samsung,syscon-phandle Contains the PMU system controller node
-   (To access the ADC_PHY register on 
Exynos5250/5420/5800/3250)
-Optional properties:
-- has-touchscreen: If present, indicates that a touchscreen is
-   connected an usable.
-
-Note: child nodes can be added for auto probing from device tree.
-
-Example: adding device info in dtsi file
-
-adc: adc@12d1 {
-   compatible = "samsung,exynos-adc-v1";
-   reg = <0x12D1 0x100>;
-   interrupts = <0 106 0>;
-   #io-channel-cells = <1>;
-   io-channel-ranges;
-
-   clocks = < 303>;
-   clock-names = "adc";
-
-   vdd-supply = <_reg>;
-   samsung,syscon-phandle = <_system_controller>;
-};
-
-Example: adding device info in dtsi file for Exynos3250 with additional sclk
-
-adc: adc@126c {
-   compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
-   reg = <0x126C 0x100>;
-   interrupts = <0 137 0>;
-   #io-channel-cells = <1>;
-   io-channel-ranges;
-
-   clocks = < CLK_TSADC>, < CLK_SCLK_TSADC>;
-   clock-names = "adc", "sclk";
-
-   vdd-supply = <_reg>;
-   samsung,syscon-phandle = <_system_controller>;
-};
-
-Example: Adding child nodes in dts file
-
-adc@12d1 {
-
-   /* NTC thermistor is a hwmon device */
-   ncp15wb473@0 {

[RFC 9/9] ARM: dts: exynos: Remove not accurate secondary ADC compatible

[Krzysztof Kozlowski]

The Exynos3250 ADC has its own compatible because of differences from
other Exynos SoCs.  Therefore it is not entirely compatible with
samsung,exynos-adc-v2.  Remove the samsung,exynos-adc-v2.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 5659c4a10729..784818490376 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -450,8 +450,7 @@
};
 
adc: adc@126c {
-   compatible = "samsung,exynos3250-adc",
-"samsung,exynos-adc-v2";
+   compatible = "samsung,exynos3250-adc";
reg = <0x126C 0x100>;
interrupts = ;
clock-names = "adc", "sclk";
-- 
2.17.1

Re: [PATCH] staging: vt6656: Use common error handling code in vnt_alloc_bufs()

[Quentin Deslandes]

On Fri, Aug 23, 2019 at 03:30:11PM +0200, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 23 Aug 2019 15:15:41 +0200
> 
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/staging/vt6656/main_usb.c | 46 +--
>  1 file changed, 19 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/vt6656/main_usb.c 
> b/drivers/staging/vt6656/main_usb.c
> index 856ba97aec4f..d9f14da37bbc 100644
> --- a/drivers/staging/vt6656/main_usb.c
> +++ b/drivers/staging/vt6656/main_usb.c
> @@ -443,10 +443,8 @@ static int vnt_alloc_bufs(struct vnt_private *priv)
> 
>   for (ii = 0; ii < priv->num_tx_context; ii++) {
>   tx_context = kmalloc(sizeof(*tx_context), GFP_KERNEL);
> - if (!tx_context) {
> - ret = -ENOMEM;
> - goto free_tx;
> - }
> + if (!tx_context)
> + goto e_nomem_tx;
> 
>   priv->tx_context[ii] = tx_context;
>   tx_context->priv = priv;
> @@ -454,20 +452,16 @@ static int vnt_alloc_bufs(struct vnt_private *priv)
> 
>   /* allocate URBs */
>   tx_context->urb = usb_alloc_urb(0, GFP_KERNEL);
> - if (!tx_context->urb) {
> - ret = -ENOMEM;
> - goto free_tx;
> - }
> + if (!tx_context->urb)
> + goto e_nomem_tx;
> 
>   tx_context->in_use = false;
>   }
> 
>   for (ii = 0; ii < priv->num_rcb; ii++) {
>   priv->rcb[ii] = kzalloc(sizeof(*priv->rcb[ii]), GFP_KERNEL);
> - if (!priv->rcb[ii]) {
> - ret = -ENOMEM;
> - goto free_rx_tx;
> - }
> + if (!priv->rcb[ii])
> + goto e_nomem_rx;
> 
>   rcb = priv->rcb[ii];
> 
> @@ -475,16 +469,12 @@ static int vnt_alloc_bufs(struct vnt_private *priv)
> 
>   /* allocate URBs */
>   rcb->urb = usb_alloc_urb(0, GFP_KERNEL);
> - if (!rcb->urb) {
> - ret = -ENOMEM;
> - goto free_rx_tx;
> - }
> + if (!rcb->urb)
> + goto e_nomem_rx;
> 
>   rcb->skb = dev_alloc_skb(priv->rx_buf_sz);
> - if (!rcb->skb) {
> - ret = -ENOMEM;
> - goto free_rx_tx;
> - }
> + if (!rcb->skb)
> + goto e_nomem_rx;
> 
>   rcb->in_use = false;
> 
> @@ -495,21 +485,23 @@ static int vnt_alloc_bufs(struct vnt_private *priv)
>   }
> 
>   priv->interrupt_urb = usb_alloc_urb(0, GFP_KERNEL);
> - if (!priv->interrupt_urb) {
> - ret = -ENOMEM;
> - goto free_rx_tx;
> - }
> + if (!priv->interrupt_urb)
> + goto e_nomem_rx;
> 
>   priv->int_buf.data_buf = kmalloc(MAX_INTERRUPT_SIZE, GFP_KERNEL);
> - if (!priv->int_buf.data_buf) {
> - ret = -ENOMEM;
> + if (!priv->int_buf.data_buf)
>   goto free_rx_tx_urb;
> - }
> 
>   return 0;
> 
> +e_nomem_tx:
> + ret = -ENOMEM;
> + goto free_tx;
> +
>  free_rx_tx_urb:
>   usb_free_urb(priv->interrupt_urb);
> +e_nomem_rx:
> + ret = -ENOMEM;
>  free_rx_tx:
>   vnt_free_rx_bufs(priv);
>  free_tx:
> --
> 2.23.0
> 

Your patch remove redundant code, which is fine. However, and IMHO, the
code you changed was simple enough to be understand quickly. I think replacing
it with a crossed goto (even if it remove redundant code) might not be the best
option.

A solution might be to move the second loop to the top of the function so
you should be able to replace the end of the cleanup calls with:

enomem:
ret = -ENOMEM;
free_rx:
vnt_free_rx_bufs(priv);
return ret;

This way, only a failed call to vnt_submit_rx_urb() should jump to
free_rx, another failed call should jump to enomem or previously defined
label, so we can correctly forward errors. With such solution it might
be worth adding a comment to describe that all error should be ENOMEM
except for vnt_submit_rx_urb(). Does that looks good to you?

Regards,
Quentin

Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver

[Matthias Brugger]

On 23/08/2019 14:13, Frank Wunderlich wrote:
> Hi,
> 
> this commit breaks mt6323 pmic on BananaPi-R2
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4872e80ce7d2a1844328176dbf279d0a2b89bdb
> 
> resulting in this message in dmesg:
> 
> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
> and multiple
> mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0
> 
> see discussion here:
> http://lists.infradead.org/pipermail/linux-mediatek/2019-August/022505.html
> 
> after reverting this one the errors are gone, please provide a fix

are you sure that you provide the correct chip_id here? I saw 0x2023 (if I
remember correctly), while this switch checks for 0x23, 0x91 and 0x97, so I'm
not sure if the problem really lies here. I didn't dig into the code to find out
how the chip_id is created.

Regards,
Matthias

> 
> regards Frank
> 
> 
>> Gesendet: Freitag, 23. August 2019 um 05:45 Uhr
>> Von: "Hsin-Hsiung Wang" 
>> Betreff: [PATCH v5 02/10] mfd: mt6397: extract irq related code from core 
>> driver
>>
>> In order to support different types of irq design, we decide to add
>> separate irq drivers for different design and keep mt6397 mfd core
>> simple and reusable to all generations of PMICs so far.
>>
>> Acked-for-mfd-by: Lee Jones 
>> Signed-off-by: Hsin-Hsiung Wang 
>> ---
>>  drivers/mfd/Makefile|   3 +-
>>  drivers/mfd/mt6397-core.c   | 146 
>>  drivers/mfd/mt6397-irq.c| 181 
>> 
>>  include/linux/mfd/mt6397/core.h |   9 ++
>>  4 files changed, 192 insertions(+), 147 deletions(-)
>>  create mode 100644 drivers/mfd/mt6397-irq.c
> 

Re: [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node

[Maxime Ripard]

Hi,

On Tue, Aug 20, 2019 at 08:17:49AM -0500, Samuel Holland wrote:
> On 8/20/19 3:15 AM, Maxime Ripard wrote:
> > On Mon, Aug 19, 2019 at 10:23:06PM -0500, Samuel Holland wrote:
> >> The A80 SoC contains a message box that can be used to send messages and
> >> interrupts back and forth between the ARM application CPUs and the ARISC
> >> coprocessor. Add a device tree node for it.
> >>
> >> Signed-off-by: Samuel Holland 
> >
> > I think you mentionned that crust has been tested only on the A64 and
> > the H3/H5, did you test the mailbox on those other SoCs as well?
>
> No, I only have A64/H3/H5, and recently H6, hardware to test. I've looked
> through the manuals to verify that the registers are all the same, but I 
> haven't
> run the driver on earlier SoCs.

I'd rather not merge them until they've been properly tested. We've
had some surprises with the documentation in the past :/

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler

[Christophe Leroy]

In-Reply-To: 20190819234111.9019-8-keesc...@chromium.org

Le 20/08/2019 à 18:47, Kees Cook a écrit :

The original clean up of "cut here" missed the WARN_ON() case (that
does not have a printk message), which was fixed recently by adding
an explicit printk of "cut here". This had the downside of adding a
printk() to every WARN_ON() caller, which reduces the utility of using
an instruction exception to streamline the resulting code. By making
this a new BUGFLAG, all of these can be removed and "cut here" can be
handled by the exception handler.

This was very pronounced on PowerPC, but the effect can be seen on
x86 as well. The resulting text size of a defconfig build shows some
small savings from this patch:

textdata bss dec hex filename
196911675134320 1646664 26472151193eed7 vmlinux.before
196763625134260 1663048 26473670193f4c6 vmlinux.after

This change also opens the door for creating something like BUG_MSG(),
where a custom printk() before issuing BUG(), without confusing the "cut
here" line.

Reported-by: Christophe Leroy 
Fixes: Fixes: 6b15f678fb7d ("include/asm-generic/bug.h: fix "cut here" for WARN_ON 
for __WARN_TAINT architectures")
Signed-off-by: Kees Cook 


Tested-by: Christophe Leroy 


---
v2:
  - rename BUGFLAG_PRINTK to BUGFLAG_NO_CUT_HERE (peterz, christophe)
---
  include/asm-generic/bug.h |  8 +++-
  lib/bug.c | 11 +--
  2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 588dd59a5b72..a21e83f8a274 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -10,6 +10,7 @@
  #define BUGFLAG_WARNING   (1 << 0)
  #define BUGFLAG_ONCE  (1 << 1)
  #define BUGFLAG_DONE  (1 << 2)
+#define BUGFLAG_NO_CUT_HERE(1 << 3)  /* CUT_HERE already sent */
  #define BUGFLAG_TAINT(taint)  ((taint) << 8)
  #define BUG_GET_TAINT(bug)((bug)->flags >> 8)
  #endif
@@ -86,13 +87,10 @@ void warn_slowpath_fmt(const char *file, const int line, 
unsigned taint,
warn_slowpath_fmt(__FILE__, __LINE__, taint, arg)
  #else
  extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
-#define __WARN() do {  \
-   printk(KERN_WARNING CUT_HERE);  \
-   __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN));\
-   } while (0)
+#define __WARN()   __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN))
  #define __WARN_printf(taint, arg...) do { \
__warn_printk(arg); \
-   __WARN_FLAGS(BUGFLAG_TAINT(taint)); \
+   __WARN_FLAGS(BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\
} while (0)
  #define WARN_ON_ONCE(condition) ({\
int __ret_warn_on = !!(condition);  \
diff --git a/lib/bug.c b/lib/bug.c
index 1077366f496b..8c98af0bf585 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -181,6 +181,15 @@ enum bug_trap_type report_bug(unsigned long bugaddr, 
struct pt_regs *regs)
}
}
  
+	/*

+* BUG() and WARN_ON() families don't print a custom debug message
+* before triggering the exception handler, so we must add the
+* "cut here" line now. WARN() issues its own "cut here" before the
+* extra debugging message it writes before triggering the handler.
+*/
+   if ((bug->flags & BUGFLAG_NO_CUT_HERE) == 0)
+   printk(KERN_DEFAULT CUT_HERE);
+
if (warning) {
/* this is a WARN_ON rather than BUG/BUG_ON */
__warn(file, line, (void *)bugaddr, BUG_GET_TAINT(bug), regs,
@@ -188,8 +197,6 @@ enum bug_trap_type report_bug(unsigned long bugaddr, struct 
pt_regs *regs)
return BUG_TRAP_TYPE_WARN;
}
  
-	printk(KERN_DEFAULT CUT_HERE);

-
if (file)
pr_crit("kernel BUG at %s:%u!\n", file, line);
else

Re: [PATCH v5] arm64: implement KPROBES_ON_FTRACE

[Masami Hiramatsu]

Hi Jisheng,

On Thu, 22 Aug 2019 11:25:00 +
Jisheng Zhang  wrote:

> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
> 
> Tested on berlin arm64 platform.
> 
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
> 
> before the patch:
> 
> /sys/kernel/debug # cat kprobes/list
> ff801009fe28  k  _do_fork+0x0[DISABLED]
> 
> after the patch:
> 
> /sys/kernel/debug # cat kprobes/list
> ff801009ff54  k  _do_fork+0x4[DISABLED][FTRACE]
> 
> Signed-off-by: Jisheng Zhang 

Looks good to me.

Acked-by: Masami Hiramatsu 

Thank you,

> ---
> 
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
> 
> Applied after arm64 FTRACE_WITH_REGS:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/674404.html
> 
> Changes since v4:
>   - correct reg->pc: probed on foo, then pre_handler see foo+0x4, while
> post_handler see foo+0x8
> 
> Changes since v3:
>   - move kprobe_lookup_name() and arch_kprobe_on_func_entry to ftrace.c since
> we only want to choose the ftrace entry for KPROBES_ON_FTRACE.
>   - only choose ftrace entry if (addr && !offset)
> 
> Changes since v2:
>   - remove patch1, make it a single cleanup patch
>   - remove "This patch" in the change log
>   - implement arm64's kprobe_lookup_name() and arch_kprobe_on_func_entry 
> instead
> of patching the common kprobes code
> 
> Changes since v1:
>   - make the kprobes/x86: use instruction_pointer and instruction_pointer_set
> as patch1
>   - add Masami's ACK to patch1
>   - add some description about KPROBES_ON_FTRACE and why we need it on
> arm64
>   - correct the log before the patch
>   - remove the consolidation patch, make it as TODO
>   - only adjust kprobe's addr when KPROBE_FLAG_FTRACE is set
>   - if KPROBES_ON_FTRACE, ftrace_call_adjust() the kprobe's addr before
> calling ftrace_location()
>   - update the kprobes-on-ftrace/arch-support.txt in doc
> 
>  .../debug/kprobes-on-ftrace/arch-support.txt  |  2 +-
>  arch/arm64/Kconfig|  1 +
>  arch/arm64/kernel/probes/Makefile |  1 +
>  arch/arm64/kernel/probes/ftrace.c | 83 +++
>  4 files changed, 86 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/kernel/probes/ftrace.c
> 
> diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt 
> b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> index 68f266944d5f..e8358a38981c 100644
> --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> @@ -9,7 +9,7 @@
>  |   alpha: | TODO |
>  | arc: | TODO |
>  | arm: | TODO |
> -|   arm64: | TODO |
> +|   arm64: |  ok  |
>  | c6x: | TODO |
>  |csky: | TODO |
>  |   h8300: | TODO |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 663392d1eae2..928700f15e23 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -167,6 +167,7 @@ config ARM64
>   select HAVE_STACKPROTECTOR
>   select HAVE_SYSCALL_TRACEPOINTS
>   select HAVE_KPROBES
> + select HAVE_KPROBES_ON_FTRACE
>   select HAVE_KRETPROBES
>   select HAVE_GENERIC_VDSO
>   select IOMMU_DMA if IOMMU_SUPPORT
> diff --git a/arch/arm64/kernel/probes/Makefile 
> b/arch/arm64/kernel/probes/Makefile
> index 8e4be92e25b1..4020cfc66564 100644
> --- a/arch/arm64/kernel/probes/Makefile
> +++ b/arch/arm64/kernel/probes/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o  
> \
>  simulate-insn.o
>  obj-$(CONFIG_UPROBES)+= uprobes.o decode-insn.o  \
>  simulate-insn.o
> +obj-$(CONFIG_KPROBES_ON_FTRACE)  += ftrace.o
> diff --git a/arch/arm64/kernel/probes/ftrace.c 
> b/arch/arm64/kernel/probes/ftrace.c
> new file mode 100644
> index ..9f80905f02fa
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/ftrace.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Dynamic Ftrace based Kprobes Optimization
> + *
> + * Copyright (C) Hitachi Ltd., 2012
> + * Copyright (C) 2019 Jisheng Zhang 
> + * Synaptics Incorporated
> + */
> +
> +#include 
> +
> +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> +void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> +struct ftrace_ops *ops, struct pt_regs *regs)
> +{
> + struct kprobe *p;
> + struct kprobe_ctlblk *kcb;
> +
> + /* Preempt is disabled by ftrace */
> + p = get_kprobe((kprobe_opcode_t 

Re: [PATCH 1/2] f2fs: introduce {page,io}_is_mergeable() for readability

[Jaegeuk Kim]

On 08/23, Chao Yu wrote:
> On 2019/7/12 16:55, Chao Yu wrote:
> > Wrap merge condition into function for readability, no logic change.
> > 
> > Signed-off-by: Chao Yu 
> > ---
> > v2: remove bio validation check in page_is_mergeable().
> >  fs/f2fs/data.c | 40 +---
> >  1 file changed, 33 insertions(+), 7 deletions(-)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 6a8db4abdf5f..f1e401f9fc13 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -482,6 +482,33 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
> > return 0;
> >  }
> >  
> > +static bool page_is_mergeable(struct f2fs_sb_info *sbi, struct bio *bio,
> > +   block_t last_blkaddr, block_t cur_blkaddr)
> > +{
> > +   if (last_blkaddr != cur_blkaddr)
> 
> if (last_blkaddr + 1 != cur_blkaddr)
> 
> Merge condition is wrong here.
> 
> > +   return false;
> > +   return __same_bdev(sbi, cur_blkaddr, bio);
> > +}
> > +
> > +static bool io_type_is_mergeable(struct f2fs_bio_info *io,
> > +   struct f2fs_io_info *fio)
> > +{
> > +   if (io->fio.op != fio->op)
> > +   return false;
> > +   return io->fio.op_flags == fio->op_flags;
> > +}
> > +
> > +static bool io_is_mergeable(struct f2fs_sb_info *sbi, struct bio *bio,
> > +   struct f2fs_bio_info *io,
> > +   struct f2fs_io_info *fio,
> > +   block_t last_blkaddr,
> > +   block_t cur_blkaddr)
> > +{
> > +   if (!page_is_mergeable(sbi, bio, last_blkaddr, cur_blkaddr))
> > +   return false;
> > +   return io_type_is_mergeable(io, fio);
> > +}
> > +
> >  int f2fs_merge_page_bio(struct f2fs_io_info *fio)
> >  {
> > struct bio *bio = *fio->bio;
> > @@ -495,8 +522,8 @@ int f2fs_merge_page_bio(struct f2fs_io_info *fio)
> > trace_f2fs_submit_page_bio(page, fio);
> > f2fs_trace_ios(fio, 0);
> >  
> > -   if (bio && (*fio->last_block + 1 != fio->new_blkaddr ||
> > -   !__same_bdev(fio->sbi, fio->new_blkaddr, bio))) {
> > +   if (bio && !page_is_mergeable(fio->sbi, bio, *fio->last_block,
> > +   fio->new_blkaddr)) {
> > __submit_bio(fio->sbi, bio, fio->type);
> > bio = NULL;
> > }
> > @@ -569,9 +596,8 @@ void f2fs_submit_page_write(struct f2fs_io_info *fio)
> >  
> > inc_page_count(sbi, WB_DATA_TYPE(bio_page));
> >  
> > -   if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
> > -   (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags) ||
> > -   !__same_bdev(sbi, fio->new_blkaddr, io->bio)))
> > +   if (io->bio && !io_is_mergeable(sbi, io->bio, io, fio,
> > +   io->last_block_in_bio, fio->new_blkaddr))
> > __submit_merged_bio(io);
> >  alloc_new:
> > if (io->bio == NULL) {
> > @@ -1643,8 +1669,8 @@ static int f2fs_read_single_page(struct inode *inode, 
> > struct page *page,
> >  * This page will go to BIO.  Do we need to send this
> >  * BIO off first?
> >  */
> > -   if (bio && (*last_block_in_bio != block_nr - 1 ||
> > -   !__same_bdev(F2FS_I_SB(inode), block_nr, bio))) {
> > +   if (bio && !page_is_mergeable(F2FS_I_SB(inode), bio,
> > +   *last_block_in_bio, block_nr - 1)) {
> 
> *last_block_in_bio, block_nr)
> 
> Sorry, anyway, let me send v2.

Fixed, thanks,

> 
> >  submit_and_realloc:
> > __submit_bio(F2FS_I_SB(inode), bio, DATA);
> > bio = NULL;
> > 

Re: [PATCH v1 3/3] watchdog/aspeed: add support for dual boot

[Ivan Mikhaylov]

On Fri, 2019-08-23 at 07:19 -0700, Guenter Roeck wrote:
> >  
> > +/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
> > +static ssize_t access_cs0_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> > +
> 
> Unnecessary empty line.
> 

Ok, will cut.

> > +static ssize_t access_cs0_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > +   struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> > +   unsigned long val = 0;
> 
> Unnecessary initialization.

So, you're saying 'unsigned long val;' is enough? Will do then.

> 
> So the attribute would only exist if the boot was from the secondary
> flash, and it would exist even if it wasn't needed (ie on ast2500 /
> ast2600)?
Yes, only at secondary flash it will be available.
Also, found out that is for 2600 aspeed completely changed the process of
switch. For 2500 it just swaps chipselects back to make it accordingly as at
first side, on idea it may be helpful.

May be some approach like this will suffice?
if ((of_device_is_compatible(np, "aspeed,ast2400-wdt") or
(of_device_is_compatible(np, "aspeed,ast2500-wdt"))
wdt->wdd.groups = bswitch_groups;


>  Well, if that is what you want, who am I to argue, but
> you'll have to document it accordingly. When you do so, please also
> document what happens on ast2500 / ast2600 when the attribute exists
> and is written.
> 

Ok, I'll put it in Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
for next patch set.

Re: [PATCH v6 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Fri, 2019-08-23 at 01:16 -0400, Pankaj Gupta wrote:
> > On Thu, 2019-08-22 at 06:43 -0400, Pankaj Gupta wrote:
> > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > that a guest page is no longer in use and can have the data associated
> > > > with it dropped. To do this I have implemented functionality that allows
> > > > for what I am referring to as unused page reporting
> > > > 
> > > > The functionality for this is fairly simple. When enabled it will
> > > > allocate
> > > > statistics to track the number of reported pages in a given free area.
> > > > When the number of free pages exceeds this value plus a high water 
> > > > value,
> > > > currently 32, it will begin performing page reporting which consists of
> > > > pulling pages off of free list and placing them into a scatter list. The
> > > > scatterlist is then given to the page reporting device and it will
> > > > perform
> > > > the required action to make the pages "reported", in the case of
> > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > and as such they are forced out of the guest. After this they are placed
> > > > back on the free list, and an additional bit is added if they are not
> > > > merged indicating that they are a reported buddy page instead of a
> > > > standard buddy page. The cycle then repeats with additional non-reported
> > > > pages being pulled until the free areas all consist of reported pages.
> > > > 
> > > > I am leaving a number of things hard-coded such as limiting the lowest
> > > > order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
> > > > determine what the limit is on how many pages it wants to allocate to
> > > > process the hints. The upper limit for this is based on the size of the
> > > > queue used to store the scattergather list.
> > > > 
> > > > My primary testing has just been to verify the memory is being freed
> > > > after
> > > > allocation by running memhog 40g on a 40g guest and watching the total
> > > > free memory via /proc/meminfo on the host. With this I have verified 
> > > > most
> > > > of the memory is freed after each iteration.
> > > 
> > > I tried to go through the entire patch series. I can see you reported a
> > > -3.27 drop from the baseline. If its because of re-faulting the page after
> > > host has freed them? Can we avoid freeing all the pages from the guest
> > > free_area
> > > and keep some pages(maybe some mixed order), so that next allocation is
> > > done from
> > > the guest itself than faulting to host. This will work with real workload
> > > where
> > > allocation and deallocation happen at regular intervals.
> > > 
> > > This can be further optimized based on other factors like host memory
> > > pressure etc.
> > > 
> > > Thanks,
> > > Pankaj
> > 
> > When I originally started implementing and testing this code I was seeing
> > less than a 1% regression. I didn't feel like that was really an accurate
> > result since it wasn't putting much stress on the changed code so I have
> > modified my tests and kernel so that I have memory shuffting and THP
> > enabled. In addition I have gone out of my way to lock things down to a
> > single NUMA node on my host system as the code I had would sometimes
> > perform better than baseline when running the test due to the fact that
> > memory was being freed back to the hose and then reallocated which
> > actually allowed for better NUMA locality.
> > 
> > The general idea was I wanted to know what the worst case penalty would be
> > for running this code, and it turns out most of that is just the cost of
> > faulting back in the pages. By enabling memory shuffling I am forcing the
> > memory to churn as pages are added to both the head and tail of the
> > free_list. The test itself was modified so that it didn't allocate order 0
> > pages and instead was allocating transparent huge pages so the effects
> > were as visible as possible. Without that the page faulting overhead would
> > mostly fall into the noise of having to allocate the memory as order 0
> > pages, that is what I had essentially seen earlier when I was running the
> > stock page_fault1 test.
> 
> Right. I think the reason is this test is allocating THP's in guest, host side
> you are still using order 0 pages, I assume?

No, on host side they should be huge pages as well. Most of the cost for
the fault is the page zeroing I believe since we are having to zero a 2MB
page twice, once in the host and once in the guest.

Basically if I disable THP in the guest the results are roughly half what
they are with THP enabled, and the difference between the patchset and
baseline drops to less than 1%.

> > This code does no hinting on anything smaller than either MAX_ORDER - 1 or
> > HUGETLB_PAGE_ORDER pages, and it only starts when there are at least 32 of
> > them available to hint on. This results in us not starting to perform the
> > hinting until there is 64MB to 128MB of 

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Jason Gunthorpe]

On Fri, Aug 23, 2019 at 12:22:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/mlx5/mlx5_ib.h
> 
> between commit:
> 
>   0e6613b41edd ("IB/mlx5: Consolidate use_umr checks into single function")
> 
> from the rdma-fixes tree and commit:
> 
>   3e1f000ff746 ("IB/mlx5: Support per device q counters in switchdev mode")
> 
> from the rdma tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks OK to me, thanks

Jason

[tip: timers/core] clocksource/drivers/hyperv: Allocate Hyper-V TSC page statically

[tip-bot2 for Tianyu Lan]

The following commit has been merged into the timers/core branch of tip:

Commit-ID: adb87ff4f96c9700718e09c97a804124d5cd61ff
Gitweb:
https://git.kernel.org/tip/adb87ff4f96c9700718e09c97a804124d5cd61ff
Author:Tianyu Lan 
AuthorDate:Wed, 14 Aug 2019 20:32:15 +08:00
Committer: Thomas Gleixner 
CommitterDate: Fri, 23 Aug 2019 16:59:53 +02:00

clocksource/drivers/hyperv: Allocate Hyper-V TSC page statically

Prepare to add Hyper-V sched clock callback and move Hyper-V Reference TSC
initialization much earlier in the boot process.  Earlier initialization is
needed so that it happens while the timestamp value is still 0 and no
discontinuity in the timestamp will occur when pv_ops.time.sched_clock
calculates its offset.

The earlier initialization requires that the Hyper-V TSC page be allocated
statically instead of with vmalloc(), so fixup the references to the TSC
page and the method of getting its physical address.

Signed-off-by: Tianyu Lan 
Signed-off-by: Thomas Gleixner 
Acked-by: Daniel Lezcano 
Link: https://lkml.kernel.org/r/20190814123216.32245-2-tianyu@microsoft.com
---
 arch/x86/entry/vdso/vma.c  |  2 +-
 drivers/clocksource/hyperv_timer.c | 12 
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 349a61d..f593774 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -122,7 +122,7 @@ static vm_fault_t vvar_fault(const struct 
vm_special_mapping *sm,
 
if (tsc_pg && vclock_was_used(VCLOCK_HVCLOCK))
return vmf_insert_pfn(vma, vmf->address,
-   vmalloc_to_pfn(tsc_pg));
+   virt_to_phys(tsc_pg) >> PAGE_SHIFT);
}
 
return VM_FAULT_SIGBUS;
diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index ba2c79e..432aa33 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -214,17 +214,17 @@ EXPORT_SYMBOL_GPL(hyperv_cs);
 
 #ifdef CONFIG_HYPERV_TSCPAGE
 
-static struct ms_hyperv_tsc_page *tsc_pg;
+static struct ms_hyperv_tsc_page tsc_pg __aligned(PAGE_SIZE);
 
 struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
 {
-   return tsc_pg;
+   return _pg;
 }
 EXPORT_SYMBOL_GPL(hv_get_tsc_page);
 
 static u64 notrace read_hv_sched_clock_tsc(void)
 {
-   u64 current_tick = hv_read_tsc_page(tsc_pg);
+   u64 current_tick = hv_read_tsc_page(_pg);
 
if (current_tick == U64_MAX)
hv_get_time_ref_count(current_tick);
@@ -280,12 +280,8 @@ static bool __init hv_init_tsc_clocksource(void)
if (!(ms_hyperv.features & HV_MSR_REFERENCE_TSC_AVAILABLE))
return false;
 
-   tsc_pg = vmalloc(PAGE_SIZE);
-   if (!tsc_pg)
-   return false;
-
hyperv_cs = _cs_tsc;
-   phys_addr = page_to_phys(vmalloc_to_page(tsc_pg));
+   phys_addr = virt_to_phys(_pg);
 
/*
 * The Hyper-V TLFS specifies to preserve the value of reserved

[tip: timers/core] clocksource/drivers/hyperv: Add Hyper-V specific sched clock function

[tip-bot2 for Tianyu Lan]

The following commit has been merged into the timers/core branch of tip:

Commit-ID: bd00cd52d5be655a2f217e2ed74b91a71cb2b14f
Gitweb:
https://git.kernel.org/tip/bd00cd52d5be655a2f217e2ed74b91a71cb2b14f
Author:Tianyu Lan 
AuthorDate:Wed, 14 Aug 2019 20:32:16 +08:00
Committer: Thomas Gleixner 
CommitterDate: Fri, 23 Aug 2019 16:59:54 +02:00

clocksource/drivers/hyperv: Add Hyper-V specific sched clock function

Hyper-V guests use the default native_sched_clock() in
pv_ops.time.sched_clock on x86. But native_sched_clock() directly uses the
raw TSC value, which can be discontinuous in a Hyper-V VM.

Add the generic hv_setup_sched_clock() to set the sched clock function
appropriately. On x86, this sets pv_ops.time.sched_clock to read the
Hyper-V reference TSC value that is scaled and adjusted to be continuous.

Also move the Hyper-V reference TSC initialization much earlier in the boot
process so no discontinuity is observed when pv_ops.time.sched_clock
calculates its offset.

[ tglx: Folded build fix ]

Signed-off-by: Tianyu Lan 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Michael Kelley 
Link: https://lkml.kernel.org/r/20190814123216.32245-3-tianyu@microsoft.com
---
 arch/x86/hyperv/hv_init.c  |  2 --
 arch/x86/kernel/cpu/mshyperv.c |  8 
 drivers/clocksource/hyperv_timer.c | 22 --
 include/asm-generic/mshyperv.h |  1 +
 4 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 0d25868..866dfb3 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -301,8 +301,6 @@ void __init hyperv_init(void)
 
x86_init.pci.arch_init = hv_pci_init;
 
-   /* Register Hyper-V specific clocksource */
-   hv_init_clocksource();
return;
 
 remove_cpuhp_state:
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 062f772..53afd33 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -338,9 +339,16 @@ static void __init ms_hyperv_init_platform(void)
x2apic_phys = 1;
 # endif
 
+   /* Register Hyper-V specific clocksource */
+   hv_init_clocksource();
 #endif
 }
 
+void hv_setup_sched_clock(void *sched_clock)
+{
+   pv_ops.time.sched_clock = sched_clock;
+}
+
 const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
.name   = "Microsoft Hyper-V",
.detect = ms_hyperv_platform,
diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index 432aa33..c322ab4 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -22,6 +22,7 @@
 #include 
 
 static struct clock_event_device __percpu *hv_clock_event;
+static u64 hv_sched_clock_offset __ro_after_init;
 
 /*
  * If false, we're using the old mechanism for stimer0 interrupts
@@ -222,7 +223,7 @@ struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
 }
 EXPORT_SYMBOL_GPL(hv_get_tsc_page);
 
-static u64 notrace read_hv_sched_clock_tsc(void)
+static u64 notrace read_hv_clock_tsc(struct clocksource *arg)
 {
u64 current_tick = hv_read_tsc_page(_pg);
 
@@ -232,9 +233,9 @@ static u64 notrace read_hv_sched_clock_tsc(void)
return current_tick;
 }
 
-static u64 read_hv_clock_tsc(struct clocksource *arg)
+static u64 read_hv_sched_clock_tsc(void)
 {
-   return read_hv_sched_clock_tsc();
+   return read_hv_clock_tsc(NULL) - hv_sched_clock_offset;
 }
 
 static struct clocksource hyperv_cs_tsc = {
@@ -246,7 +247,7 @@ static struct clocksource hyperv_cs_tsc = {
 };
 #endif
 
-static u64 notrace read_hv_sched_clock_msr(void)
+static u64 notrace read_hv_clock_msr(struct clocksource *arg)
 {
u64 current_tick;
/*
@@ -258,9 +259,9 @@ static u64 notrace read_hv_sched_clock_msr(void)
return current_tick;
 }
 
-static u64 read_hv_clock_msr(struct clocksource *arg)
+static u64 read_hv_sched_clock_msr(void)
 {
-   return read_hv_sched_clock_msr();
+   return read_hv_clock_msr(NULL) - hv_sched_clock_offset;
 }
 
 static struct clocksource hyperv_cs_msr = {
@@ -298,8 +299,9 @@ static bool __init hv_init_tsc_clocksource(void)
hv_set_clocksource_vdso(hyperv_cs_tsc);
clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
 
-   /* sched_clock_register is needed on ARM64 but is a no-op on x86 */
-   sched_clock_register(read_hv_sched_clock_tsc, 64, HV_CLOCK_HZ);
+   hv_sched_clock_offset = hyperv_cs->read(hyperv_cs);
+   hv_setup_sched_clock(read_hv_sched_clock_tsc);
+
return true;
 }
 #else
@@ -329,7 +331,7 @@ void __init hv_init_clocksource(void)
hyperv_cs = _cs_msr;
clocksource_register_hz(_cs_msr, NSEC_PER_SEC/100);
 
-   /* sched_clock_register is needed on ARM64 but is a no-op on x86 */
-  

[tip: timers/core] clocksource/drivers/hyperv: Enable TSC page clocksource on 32bit

[tip-bot2 for Vitaly Kuznetsov]

The following commit has been merged into the timers/core branch of tip:

Commit-ID: 3e2d94535adb2df15f3907e4b4c7cd8a5a4c2b5a
Gitweb:
https://git.kernel.org/tip/3e2d94535adb2df15f3907e4b4c7cd8a5a4c2b5a
Author:Vitaly Kuznetsov 
AuthorDate:Thu, 22 Aug 2019 10:36:30 +02:00
Committer: Thomas Gleixner 
CommitterDate: Fri, 23 Aug 2019 16:59:54 +02:00

clocksource/drivers/hyperv: Enable TSC page clocksource on 32bit

There is no particular reason to not enable TSC page clocksource on
32-bit. mul_u64_u64_shr() is available and despite the increased
computational complexity (compared to 64bit) TSC page is still a huge win
compared to MSR-based clocksource.

In-kernel reads:
  MSR based clocksource: 3361 cycles
  TSC page clocksource: 49 cycles

Reads from userspace (utilizing vDSO in case of TSC page):
  MSR based clocksource: 5664 cycles
  TSC page clocksource: 131 cycles

Enabling TSC page on 32bits allows to get rid of CONFIG_HYPERV_TSCPAGE as
it is now not any different from CONFIG_HYPERV_TIMER.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Michael Kelley 
Link: https://lkml.kernel.org/r/20190822083630.17059-1-vkuzn...@redhat.com

---
 arch/x86/include/asm/vdso/gettimeofday.h |  6 +++---
 drivers/clocksource/hyperv_timer.c   | 11 ---
 drivers/hv/Kconfig   |  3 ---
 include/clocksource/hyperv_timer.h   |  8 +++-
 4 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/vdso/gettimeofday.h 
b/arch/x86/include/asm/vdso/gettimeofday.h
index ae91429..bcbf901 100644
--- a/arch/x86/include/asm/vdso/gettimeofday.h
+++ b/arch/x86/include/asm/vdso/gettimeofday.h
@@ -51,7 +51,7 @@ extern struct pvclock_vsyscall_time_info pvclock_page
__attribute__((visibility("hidden")));
 #endif
 
-#ifdef CONFIG_HYPERV_TSCPAGE
+#ifdef CONFIG_HYPERV_TIMER
 extern struct ms_hyperv_tsc_page hvclock_page
__attribute__((visibility("hidden")));
 #endif
@@ -192,7 +192,7 @@ static u64 vread_pvclock(void)
 }
 #endif
 
-#ifdef CONFIG_HYPERV_TSCPAGE
+#ifdef CONFIG_HYPERV_TIMER
 static u64 vread_hvclock(void)
 {
return hv_read_tsc_page(_page);
@@ -215,7 +215,7 @@ static inline u64 __arch_get_hw_counter(s32 clock_mode)
return vread_pvclock();
}
 #endif
-#ifdef CONFIG_HYPERV_TSCPAGE
+#ifdef CONFIG_HYPERV_TIMER
if (clock_mode == VCLOCK_HVCLOCK) {
barrier();
return vread_hvclock();
diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index c322ab4..2317d4e 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -213,8 +213,6 @@ EXPORT_SYMBOL_GPL(hv_stimer_global_cleanup);
 struct clocksource *hyperv_cs;
 EXPORT_SYMBOL_GPL(hyperv_cs);
 
-#ifdef CONFIG_HYPERV_TSCPAGE
-
 static struct ms_hyperv_tsc_page tsc_pg __aligned(PAGE_SIZE);
 
 struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
@@ -245,7 +243,6 @@ static struct clocksource hyperv_cs_tsc = {
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
-#endif
 
 static u64 notrace read_hv_clock_msr(struct clocksource *arg)
 {
@@ -272,7 +269,6 @@ static struct clocksource hyperv_cs_msr = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-#ifdef CONFIG_HYPERV_TSCPAGE
 static bool __init hv_init_tsc_clocksource(void)
 {
u64 tsc_msr;
@@ -304,13 +300,6 @@ static bool __init hv_init_tsc_clocksource(void)
 
return true;
 }
-#else
-static bool __init hv_init_tsc_clocksource(void)
-{
-   return false;
-}
-#endif
-
 
 void __init hv_init_clocksource(void)
 {
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 9a59957..79e5356 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -14,9 +14,6 @@ config HYPERV
 config HYPERV_TIMER
def_bool HYPERV
 
-config HYPERV_TSCPAGE
-   def_bool HYPERV && X86_64
-
 config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
depends on HYPERV && CONNECTOR && NLS
diff --git a/include/clocksource/hyperv_timer.h 
b/include/clocksource/hyperv_timer.h
index a821deb..422f5e5 100644
--- a/include/clocksource/hyperv_timer.h
+++ b/include/clocksource/hyperv_timer.h
@@ -28,12 +28,10 @@ extern void hv_stimer_cleanup(unsigned int cpu);
 extern void hv_stimer_global_cleanup(void);
 extern void hv_stimer0_isr(void);
 
-#if IS_ENABLED(CONFIG_HYPERV)
+#ifdef CONFIG_HYPERV_TIMER
 extern struct clocksource *hyperv_cs;
 extern void hv_init_clocksource(void);
-#endif /* CONFIG_HYPERV */
 
-#ifdef CONFIG_HYPERV_TSCPAGE
 extern struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
 
 static inline notrace u64
@@ -91,7 +89,7 @@ hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
return hv_read_tsc_page_tsc(tsc_pg, _tsc);
 }
 
-#else /* CONFIG_HYPERV_TSC_PAGE */
+#else /* CONFIG_HYPERV_TIMER */
 static inline struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
 {
return NULL;
@@ -102,6 +100,6 @@ 

Re: [PATCH v2 0/2] Simplify mtty driver and mdev core

[Jiri Pirko]

Fri, Aug 23, 2019 at 04:53:06PM CEST, pa...@mellanox.com wrote:
>
>
>> -Original Message-
>> From: Alex Williamson 
>> Sent: Friday, August 23, 2019 7:58 PM
>> To: Parav Pandit 
>> Cc: Jiri Pirko ; Jiri Pirko ; David S . 
>> Miller
>> ; Kirti Wankhede ; Cornelia
>> Huck ; k...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; cjia ; net...@vger.kernel.org
>> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> 
>> On Fri, 23 Aug 2019 08:14:39 +
>> Parav Pandit  wrote:
>> 
>> > Hi Alex,
>> >
>> >
>> > > -Original Message-
>> > > From: Jiri Pirko 
>> > > Sent: Friday, August 23, 2019 1:42 PM
>> > > To: Parav Pandit 
>> > > Cc: Alex Williamson ; Jiri Pirko
>> > > ; David S . Miller ; Kirti
>> > > Wankhede ; Cornelia Huck
>> ;
>> > > k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> > > ; net...@vger.kernel.org
>> > > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> > >
>> > > Thu, Aug 22, 2019 at 03:33:30PM CEST, pa...@mellanox.com wrote:
>> > > >
>> > > >
>> > > >> -Original Message-
>> > > >> From: Jiri Pirko 
>> > > >> Sent: Thursday, August 22, 2019 5:50 PM
>> > > >> To: Parav Pandit 
>> > > >> Cc: Alex Williamson ; Jiri Pirko
>> > > >> ; David S . Miller ;
>> > > >> Kirti Wankhede ; Cornelia Huck
>> > > ;
>> > > >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> > > >> ; net...@vger.kernel.org
>> > > >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> > > >>
>> > > >> Thu, Aug 22, 2019 at 12:04:02PM CEST, pa...@mellanox.com wrote:
>> > > >> >
>> > > >> >
>> > > >> >> -Original Message-
>> > > >> >> From: Jiri Pirko 
>> > > >> >> Sent: Thursday, August 22, 2019 3:28 PM
>> > > >> >> To: Parav Pandit 
>> > > >> >> Cc: Alex Williamson ; Jiri Pirko
>> > > >> >> ; David S . Miller ;
>> > > >> >> Kirti Wankhede ; Cornelia Huck
>> > > >> ;
>> > > >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> > > >> >> ; net...@vger.kernel.org
>> > > >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> > > >> >>
>> > > >> >> Thu, Aug 22, 2019 at 11:42:13AM CEST, pa...@mellanox.com wrote:
>> > > >> >> >
>> > > >> >> >
>> > > >> >> >> -Original Message-
>> > > >> >> >> From: Jiri Pirko 
>> > > >> >> >> Sent: Thursday, August 22, 2019 2:59 PM
>> > > >> >> >> To: Parav Pandit 
>> > > >> >> >> Cc: Alex Williamson ; Jiri
>> > > >> >> >> Pirko ; David S . Miller
>> > > >> >> >> ; Kirti Wankhede
>> > > >> >> >> ; Cornelia Huck
>> > > >> >> ;
>> > > >> >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> > > >> >> >> ; net...@vger.kernel.org
>> > > >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev
>> > > >> >> >> core
>> > > >> >> >>
>> > > >> >> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, pa...@mellanox.com
>> wrote:
>> > > >> >> >> >
>> > > >> >> >> >
>> > > >> >> >> >> -Original Message-
>> > > >> >> >> >> From: Alex Williamson 
>> > > >> >> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
>> > > >> >> >> >> To: Parav Pandit 
>> > > >> >> >> >> Cc: Jiri Pirko ; David S . Miller
>> > > >> >> >> >> ; Kirti Wankhede
>> > > >> >> >> >> ; Cornelia Huck
>> > > >> >> >> >> ; k...@vger.kernel.org;
>> > > >> >> >> >> linux-kernel@vger.kernel.org; cjia ;
>> > > >> >> >> >> net...@vger.kernel.org
>> > > >> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and
>> > > >> >> >> >> mdev core
>> > > >> >> >> >>
>> > > >> >> >> >> > > > > Just an example of the alias, not proposing how it's 
>> > > >> >> >> >> > > > > set.
>> > > >> >> >> >> > > > > In fact, proposing that the user does not set
>> > > >> >> >> >> > > > > it, mdev-core provides one
>> > > >> >> >> >> > > automatically.
>> > > >> >> >> >> > > > >
>> > > >> >> >> >> > > > > > > Since there seems to be some prefix
>> > > >> >> >> >> > > > > > > overhead, as I ask about above in how many
>> > > >> >> >> >> > > > > > > characters we actually have to work with in
>> > > >> >> >> >> > > > > > > IFNAMESZ, maybe we start with
>> > > >> >> >> >> > > > > > > 8 characters (matching your "index"
>> > > >> >> >> >> > > > > > > namespace) and expand as necessary for
>> > > >> >> >> disambiguation.
>> > > >> >> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ,
>> > > >> >> >> >> > > > > > > let's start with
>> > > >> 12.
>> > > >> >> >> >> > > > > > > Thanks,
>> > > >> >> >> >> > > > > > >
>> > > >> >> >> >> > > > > > If user is going to choose the alias, why does
>> > > >> >> >> >> > > > > > it have to be limited to
>> > > >> >> >> >> sha1?
>> > > >> >> >> >> > > > > > Or you just told it as an example?
>> > > >> >> >> >> > > > > >
>> > > >> >> >> >> > > > > > It can be an alpha-numeric string.
>> > > >> >> >> >> > > > >
>> > > >> >> >> >> > > > > No, I'm proposing a different solution where
>> > > >> >> >> >> > > > > mdev-core creates an alias based on an
>> > > >> >> >> >> > > > > abbreviated sha1.  The user does not provide the
>> > > >> >> >> >> alias.
>> > > >> >> >> >> > > > >
>> > > >> >> >> 

Re: [PATCH v2 0/3] PCI: Add PCI_ERROR_RESPONSE, check for errors

[Keith Busch]

On Thu, Aug 22, 2019 at 03:05:48PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas 
> 
> Reads from a PCI device may fail if the device has been turned off (put
> into D3cold), removed, or if some other error occurs.  The PCI host bridge
> typically fabricates ~0 data to complete the CPU's read.
> 
> We check for that in a few places, but not in a consistent way.  This
> series adds a PCI_ERROR_RESPONSE definition to make the checks more
> consistent and easier to find.  Note that ~0 may indicate a PCI error, but
> it may also be valid read data, so you need more information (such as
> knowing that a register can never contain ~0) before concluding that it's
> an error.
> 
> This series also adds a new check for PCI_ERROR_RESPONSE in the power
> management code because that code frequently encounters devices in D3cold,
> where we previously misinterpreted ~0 data.  It also uses pci_power_name()
> to print D-state names more consistently.
> 
> Rafael, I didn't add your Reviewed-by to "PCI / PM: Return error when
> changing power state from D3cold" because I made small changes to try to
> make the messages more consistent, and I didn't want to presume they'd be
> OK with you.
> 
> Changes since v1:
>   - Add Rafael's Reviewed-By to the first two patches
>   - Drop "PCI / PM: Check for error when reading PME status" because Rafael
> pointed out that some devices can signal PME even when in D3cold, so
> this would require additional rework
>   - Drop "PCI / PM: Check for error when reading Power State" because
> Rafael thinks it's mostly redundant
> 
> Bjorn Helgaas (3):
>   PCI: Add PCI_ERROR_RESPONSE definition
>   PCI / PM: Decode D3cold power state correctly
>   PCI / PM: Return error when changing power state from D3cold

Series looks good to me.

Reviewed-by: Keith Busch 

Re: [PATCH 2/5] soc: amlogic: Add support for Everything-Else power domains controller

[Kevin Hilman]

Neil Armstrong  writes:

[...]

>>> It's for legacy when VPU is initialized from vendor U-Boot, look at commit :
>>> 339cd0ea082287ea8e2b7e7159a5a33665a2cbe3 "soc: amlogic: meson-gx-pwrc-vpu: 
>>> fix power-off when powered by bootloader"
>>>
>>> In the case the VPU power domain has been powered on by the bootloader
>>> and no driver are attached to this power domain, the genpd will power it
>>> off after a certain amount of time, but the clocks hasn't been enabled
>>> by the kernel itself and the power-off will trigger some faults.
>>> This patch enable the clocks to have a coherent state for an eventual
>>> poweroff and switches to the pm_domain_always_on_gov governor.
>> 
>> The key phrase there being "and no driver is attached".  Now that we
>> have a driver, it claims this domain so I don't think it will be
>> powered off:
>> 
>> # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary 
>> domain  status  slaves
>> /device runtime status
>> --
>> ETH on  
>> /devices/platform/soc/ff3f.ethernet unsupported
>> AUDIO   off-0   
>> GE2Doff-0   
>> PCI off-0   
>> USB on  
>> /devices/platform/soc/ffe09000.usb  active
>> NNA off-0   
>> VPU on  
>> /devices/platform/soc/ff90.vpu  unsupported
>> 
>> In my tests with a framebuffer console (over HDMI), I don't see the
>> display being powered off.
>
> It's in the case where the driver is a module loaded by the post-initramfs
> system after the genpd timeout, or if the display driver is disabled.
>
> In the later I had some system failures when vendor u-boot enabled the
> display and genpd disabled the power domain later on.

OK, thanks for the explanation.  I get it now.

>> 
>>> I could set always-on governor only if the domain was already enabled,
>>> what do you think ?
>> 
>> I don't think that's necessary now that we have a driver.  We really
>> want to be able to power-down this domain when the display is not in
>> use, and if you use always_on, that will never happen.
>> 
>>> And seems I'm also missing the "This patch enable the clocks".
>> 
>> I'm not sure what patch you're referring to.
>
> It's also added in 339cd0ea082287ea8e2b7e7159a5a33665a2cbe3 "soc: amlogic: 
> meson-gx-pwrc-vpu: fix power-off when powered by bootloader"
>
> I would like to keep the same behavior as meson-gx-pwrc-vpu, since it works 
> fine
> and we debugged all the issues we got.

OK, that's fine with me.

We'll have to revist when we start using runtime PM enabled drviers and
want to power down the display IPs on idle, but that's fine to do later.

Thanks,

Kevin

Re: Aw: Re: Re: BUG: devm_regulator_get returns EPROBE_DEFER (5.3-rc5..next-20190822) for bpi-r2/mt7623/mt7530

[Frank Wunderlich]

Hi

Am 23. August 2019 16:43:47 MESZ schrieb Matthias Brugger 
:
>On 23/08/2019 14:00, Frank Wunderlich wrote:
>> in working version i only get this message in dmesg which
>> looks like a device-binding:
>> 
>> mt6323-regulator mt6323-regulator: Chip ID = 0x2023

>> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0

>These are commit IDs from linux-next. At least file from 20190822
>should
>pinpoint you to the correct commits.
>
>@frank: please don't use commit IDs from linux-next as the history
>get's
>rewritten every day and the IDs can change. Better search the tree to
>which they
>got applied and use the commit IDs from there (stating, of course,
>which tree
>you are looking at).

Is there any easy way to get the right tree?

Can you give me an example bases on this commit? I thought adding the 
commit-subject is enough to find it also in a dynamic tree

>Looking at commit
>a4872e80ce7d ("mfd: mt6397: Extract IRQ related code from core driver")
>
>you can see that it doesn't just move the code but also adds new logic
>in
>mt6397_irq_init(). :(

I take a look at this function,thank you pointing to it

>It seems your chip_id is not supported yet. So you will have to find
>out which
>one it is and add it to the switch.

have posted it above ;) (0x2023)

Re: [PATCH v3 7/8] EDAC/amd64: Support Asymmetric Dual-Rank DIMMs

[Borislav Petkov]

On Fri, Aug 23, 2019 at 01:27:50PM +, Ghannam, Yazen wrote:
> Yes, sorry I missed that.

Ok, fixed. Version below. So I'm queueing all patches up to and
including this one. I have some more comments for the remaining ones but
they can wait.

Thx.

---
From: Yazen Ghannam 
Date: Thu, 22 Aug 2019 00:00:02 +
Subject: [PATCH] EDAC/amd64: Support asymmetric dual-rank DIMMs

Future AMD systems will support asymmetric dual-rank DIMMs. These are
DIMMs where the ranks are of different sizes.

The even rank will use the Primary Even Chip Select registers and the
odd rank will use the Secondary Odd Chip Select registers.

Recognize if a Secondary Odd Chip Select is being used. Use the
Secondary Odd Address Mask when calculating the chip select size.

 [ bp: move csrow_sec_enabled() to the header, fix CS_ODD define and
   tone-down the capitalized words spelling. ]

Signed-off-by: Yazen Ghannam 
Signed-off-by: Borislav Petkov 
Cc: "linux-e...@vger.kernel.org" 
Cc: James Morse 
Cc: Mauro Carvalho Chehab 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/20190821235938.118710-8-yazen.ghan...@amd.com
---
 drivers/edac/amd64_edac.c | 16 +---
 drivers/edac/amd64_edac.h |  3 ++-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 23251bba8eb6..18ba9c898389 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -790,9 +790,11 @@ static void debug_dump_dramcfg_low(struct amd64_pvt *pvt, 
u32 dclr, int chan)
 
 #define CS_EVEN_PRIMARYBIT(0)
 #define CS_ODD_PRIMARY BIT(1)
+#define CS_EVEN_SECONDARY  BIT(2)
+#define CS_ODD_SECONDARY   BIT(3)
 
-#define CS_EVENCS_EVEN_PRIMARY
-#define CS_ODD CS_ODD_PRIMARY
+#define CS_EVEN(CS_EVEN_PRIMARY | CS_EVEN_SECONDARY)
+#define CS_ODD (CS_ODD_PRIMARY | CS_ODD_SECONDARY)
 
 static int f17_get_cs_mode(int dimm, u8 ctrl, struct amd64_pvt *pvt)
 {
@@ -804,6 +806,10 @@ static int f17_get_cs_mode(int dimm, u8 ctrl, struct 
amd64_pvt *pvt)
if (csrow_enabled(2 * dimm + 1, ctrl, pvt))
cs_mode |= CS_ODD_PRIMARY;
 
+   /* Asymmetric dual-rank DIMM support. */
+   if (csrow_sec_enabled(2 * dimm + 1, ctrl, pvt))
+   cs_mode |= CS_ODD_SECONDARY;
+
return cs_mode;
 }
 
@@ -1600,7 +1606,11 @@ static int f17_addr_mask_to_cs_size(struct amd64_pvt 
*pvt, u8 umc,
 */
dimm = csrow_nr >> 1;
 
-   addr_mask_orig = pvt->csels[umc].csmasks[dimm];
+   /* Asymmetric dual-rank DIMM support. */
+   if ((csrow_nr & 1) && (cs_mode & CS_ODD_SECONDARY))
+   addr_mask_orig = pvt->csels[umc].csmasks_sec[dimm];
+   else
+   addr_mask_orig = pvt->csels[umc].csmasks[dimm];
 
/*
 * The number of zero bits in the mask is equal to the number of bits
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index 68f12de6e654..8addc4d95577 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd64_edac.h
@@ -169,7 +169,8 @@
 #define DCSM0  0x60
 #define DCSM1  0x160
 
-#define csrow_enabled(i, dct, pvt) ((pvt)->csels[(dct)].csbases[(i)] & 
DCSB_CS_ENABLE)
+#define csrow_enabled(i, dct, pvt) ((pvt)->csels[(dct)].csbases[(i)] & 
DCSB_CS_ENABLE)
+#define csrow_sec_enabled(i, dct, pvt) ((pvt)->csels[(dct)].csbases_sec[(i)] & 
DCSB_CS_ENABLE)
 
 #define DRAM_CONTROL   0x78
 
-- 
2.21.0


-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v5 03/10] mfd: mt6397: modify suspend/resume behavior

[Matthias Brugger]

On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> Some pmics don't need backup interrupt settings, so we change to use
> pm notifier for the pmics which are necessary to store settings.
> 
> Acked-for-mfd-by: Lee Jones 
> Signed-off-by: Hsin-Hsiung Wang 
> ---
>  drivers/mfd/mt6397-core.c   | 89 
> +
>  drivers/mfd/mt6397-irq.c| 33 +++
>  include/linux/mfd/mt6397/core.h |  3 ++
>  3 files changed, 73 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 93c8881..8f94187 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -4,7 +4,6 @@
>   * Author: Flora Fu, MediaTek
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -82,40 +81,27 @@
>   }
>  };
>  
> -#ifdef CONFIG_PM_SLEEP
> -static int mt6397_irq_suspend(struct device *dev)
> -{
> - struct mt6397_chip *chip = dev_get_drvdata(dev);
> -
> - regmap_write(chip->regmap, chip->int_con[0], chip->wake_mask[0]);
> - regmap_write(chip->regmap, chip->int_con[1], chip->wake_mask[1]);
> -
> - enable_irq_wake(chip->irq);
> -
> - return 0;
> -}
> -
> -static int mt6397_irq_resume(struct device *dev)
> -{
> - struct mt6397_chip *chip = dev_get_drvdata(dev);
> -
> - regmap_write(chip->regmap, chip->int_con[0], chip->irq_masks_cur[0]);
> - regmap_write(chip->regmap, chip->int_con[1], chip->irq_masks_cur[1]);
> -
> - disable_irq_wake(chip->irq);
> +struct chip_data {
> + u32 cid_addr;
> + u32 cid_shift;
> +};
>  
> - return 0;
> -}
> -#endif
> +static const struct chip_data mt6323_core = {
> + .cid_addr = MT6323_CID,
> + .cid_shift = 0,
> +};
>  
> -static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_irq_suspend,
> - mt6397_irq_resume);
> +static const struct chip_data mt6397_core = {
> + .cid_addr = MT6397_CID,
> + .cid_shift = 0,
> +};
>  
>  static int mt6397_probe(struct platform_device *pdev)
>  {
>   int ret;
>   unsigned int id;
>   struct mt6397_chip *pmic;
> + const struct chip_data *pmic_core;
>  
>   pmic = devm_kzalloc(>dev, sizeof(*pmic), GFP_KERNEL);
>   if (!pmic)
> @@ -131,28 +117,30 @@ static int mt6397_probe(struct platform_device *pdev)
>   if (!pmic->regmap)
>   return -ENODEV;
>  
> - platform_set_drvdata(pdev, pmic);
> + pmic_core = of_device_get_match_data(>dev);
> + if (!pmic_core)
> + return -ENODEV;
>  
> - ret = regmap_read(pmic->regmap, MT6397_CID, );
> + ret = regmap_read(pmic->regmap, pmic_core->cid_addr, );
>   if (ret) {
> - dev_err(pmic->dev, "Failed to read chip id: %d\n", ret);
> + dev_err(>dev, "Failed to read chip id: %d\n", ret);
>   return ret;
>   }
>  
> + pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
> +
> + platform_set_drvdata(pdev, pmic);
> +

What do this changes have to do with the commit message/subject?

>   pmic->irq = platform_get_irq(pdev, 0);
>   if (pmic->irq <= 0)
>   return pmic->irq;
>  
> - switch (id & 0xff) {
> - case MT6323_CHIP_ID:
> - pmic->int_con[0] = MT6323_INT_CON0;
> - pmic->int_con[1] = MT6323_INT_CON1;
> - pmic->int_status[0] = MT6323_INT_STATUS0;
> - pmic->int_status[1] = MT6323_INT_STATUS1;
> - ret = mt6397_irq_init(pmic);
> - if (ret)
> - return ret;

This looks to me as if it should be part of 02/10.

> + ret = mt6397_irq_init(pmic);
> + if (ret)
> + return ret;
>  
> + switch (pmic->chip_id) {
> + case MT6323_CHIP_ID:
>   ret = devm_mfd_add_devices(>dev, -1, mt6323_devs,
>  ARRAY_SIZE(mt6323_devs), NULL,
>  0, pmic->irq_domain);
> @@ -160,21 +148,13 @@ static int mt6397_probe(struct platform_device *pdev)
>  
>   case MT6391_CHIP_ID:
>   case MT6397_CHIP_ID:
> - pmic->int_con[0] = MT6397_INT_CON0;
> - pmic->int_con[1] = MT6397_INT_CON1;
> - pmic->int_status[0] = MT6397_INT_STATUS0;
> - pmic->int_status[1] = MT6397_INT_STATUS1;
> - ret = mt6397_irq_init(pmic);
> - if (ret)
> - return ret;
> -

Same here.

Regards,
Matthias

>   ret = devm_mfd_add_devices(>dev, -1, mt6397_devs,
>  ARRAY_SIZE(mt6397_devs), NULL,
>  0, pmic->irq_domain);
>   break;
>  
>   default:
> - dev_err(>dev, "unsupported chip: %d\n", id);
> + dev_err(>dev, "unsupported chip: %d\n", pmic->chip_id);
>   return -ENODEV;
>   }
>  
> @@ -187,9 +167,15 @@ static int mt6397_probe(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id mt6397_of_match[] = {
> - 

[GIT PULL] modules fixes for v5.3-rc6

[Jessica Yu]

Hi Linus,

The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:

 Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)

are available in the Git repository at:

 ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git 
tags/modules-for-v5.3-rc6

for you to fetch changes up to 3b5be16c7e90a69c93349d210766250fffcb54bd:

 modules: page-align module section allocations only for arches supporting 
strict module rwx (2019-08-21 10:43:56 +0200)


Modules fixes for v5.3-rc6

- Fix BUG_ON() being triggered in frob_text() due to non-page-aligned module
 sections

Signed-off-by: Jessica Yu 


He Zhe (1):
 modules: page-align module section allocations only for arches supporting 
strict module rwx

Jessica Yu (1):
 modules: always page-align module section allocations

kernel/module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

[GIT PULL] interconnect changes for 5.4

[Georgi Djakov]

Hi Greg,

This is a pull request with interconnect patches for the 5.4 merge window.
The patches have been for a while in linux-next without reported issues. The
details are in the signed tag. Please consider pulling into char-misc-next.

Thanks,
Georgi

The following changes since commit d45331b00ddb179e291766617259261c112db872:

  Linux 5.3-rc4 (2019-08-11 13:26:41 -0700)

are available in the Git repository at:

  https://git.linaro.org/people/georgi.djakov/linux.git tags/icc-5.4-rc1

for you to fetch changes up to 6311b6521bcc804e4d2fd45a5640562a7b8b5241:

  drivers: qcom: Add BCM vote macro to header (2019-08-20 10:09:56 +0300)


interconnect patches for 5.4

Here are the interconnect driver updates for the 5.4-rc1 merge window.

- New feature is the path tagging support that helps with grouping and
aggregating the bandwidth requests into separate buckets based on a tag.
- The first user of the path tagging is the Qualcomm sdm845 driver that
now implements support for wake/sleep sets. This allows consumer drivers
to express their bandwidth needs for the different CPU power states.
- New interconnect driver for the qcs404 platforms and a driver that
communicates bandwidth requests with remote processor over shared memory.
- Cleanups and fixes.

Signed-off-by: Georgi Djakov 


Bjorn Andersson (1):
  interconnect: qcom: Add QCS404 interconnect provider driver

David Dai (1):
  interconnect: qcom: Add tagging and wake/sleep support for sdm845

Georgi Djakov (4):
  interconnect: Add support for path tags
  interconnect: Add pre_aggregate() callback
  dt-bindings: interconnect: Add Qualcomm QCS404 DT bindings
  interconnect: qcom: Add interconnect RPM over SMD driver

Jordan Crouse (1):
  drivers: qcom: Add BCM vote macro to header

Mao Wenan (1):
  interconnect: qcom: remove COMPILE_TEST from 
CONFIG_INTERCONNECT_QCOM_QCS404

 Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt |  45 +
 drivers/clk/qcom/clk-rpmh.c|  16 +---
 drivers/interconnect/core.c|  27 +-
 drivers/interconnect/qcom/Kconfig  |  12 +++
 drivers/interconnect/qcom/Makefile |   4 +
 drivers/interconnect/qcom/qcs404.c | 539
+
 drivers/interconnect/qcom/sdm845.c | 160
+--
 drivers/interconnect/qcom/smd-rpm.c|  77
+++
 drivers/interconnect/qcom/smd-rpm.h|  15 +++
 include/dt-bindings/interconnect/qcom,qcs404.h |  88
+
 include/linux/interconnect-provider.h  |   7 +-
 include/linux/interconnect.h   |   5 +
 include/soc/qcom/tcs.h |  20 +++-
 13 files changed, 948 insertions(+), 67 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
 create mode 100644 drivers/interconnect/qcom/qcs404.c
 create mode 100644 drivers/interconnect/qcom/smd-rpm.c
 create mode 100644 drivers/interconnect/qcom/smd-rpm.h
 create mode 100644 include/dt-bindings/interconnect/qcom,qcs404.h

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

[Daniel Vetter]

On Fri, Aug 23, 2019 at 4:06 PM Peter Zijlstra  wrote:
> On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
> > I'm assuming the lockdep one will land, so not going to resend that.
>
> I was assuming you'd wake the might_lock_nested() along with the i915
> user through the i915/drm tree. If want me to take some or all of that,
> lemme know.

might_lock_nested() is a different patch series, that one will indeed
go in through the drm/i915 tree, thx for the ack there. What I meant
here is some mmu notifier lockdep map in this series that Jason said
he's going to pick up into hmm.git. I'm doing about 3 or 4 different
lockdep annotations series in parallel right now :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] PCI: dwc: Use dev_info() instead of dev_err()

[Vidya Sagar]

When a platform has an open PCIe slot, not having a device connected to
it doesn't have to result in a dev_err() print saying that the link is
not up but a dev_info() would suffice.

Signed-off-by: Vidya Sagar 
---
 drivers/pci/controller/dwc/pcie-designware.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 59eaeeb21dbe..4d6690b6ca36 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -456,7 +456,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
}
 
-   dev_err(pci->dev, "Phy link never came up\n");
+   dev_info(pci->dev, "Phy link never came up\n");
 
return -ETIMEDOUT;
 }
-- 
2.17.1

Re: [RFC PATCH v2 06/19] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range

[Vivek Goyal]

On Fri, Aug 09, 2019 at 03:58:20PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny 
> 
> Callers of dax_layout_busy_page() are only rarely operating on the
> entire file of concern.
> 
> Teach dax_layout_busy_page() to operate on a sub-range of the
> address_space provided.  Specifying 0 - ULONG_MAX however, will continue
> to operate on the "entire file" and XFS is split out to a separate patch
> by this method.
> 
> This could potentially speed up dax_layout_busy_page() as well.

I need this functionality as well for virtio_fs and posted a patch for
this.

https://lkml.org/lkml/2019/8/21/825

Given this is an optimization which existing users can benefit from already,
this patch could probably be pushed upstream independently.

> 
> Signed-off-by: Ira Weiny 
> 
> ---
> Changes from RFC v1
>   Fix 0-day build errors
> 
>  fs/dax.c| 15 +++
>  fs/ext4/ext4.h  |  2 +-
>  fs/ext4/extents.c   |  6 +++---
>  fs/ext4/inode.c | 19 ---
>  fs/xfs/xfs_file.c   |  3 ++-
>  include/linux/dax.h |  6 --
>  6 files changed, 33 insertions(+), 18 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index a14ec32255d8..3ad19c384454 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -573,8 +573,11 @@ bool dax_mapping_is_dax(struct address_space *mapping)
>  EXPORT_SYMBOL_GPL(dax_mapping_is_dax);
>  
>  /**
> - * dax_layout_busy_page - find first pinned page in @mapping
> + * dax_layout_busy_page - find first pinned page in @mapping within
> + *the range @off - @off + @len
>   * @mapping: address space to scan for a page with ref count > 1
> + * @off: offset to start at
> + * @len: length to scan through
>   *
>   * DAX requires ZONE_DEVICE mapped pages. These pages are never
>   * 'onlined' to the page allocator so they are considered idle when
> @@ -587,9 +590,13 @@ EXPORT_SYMBOL_GPL(dax_mapping_is_dax);
>   * to be able to run unmap_mapping_range() and subsequently not race
>   * mapping_mapped() becoming true.
>   */
> -struct page *dax_layout_busy_page(struct address_space *mapping)
> +struct page *dax_layout_busy_page(struct address_space *mapping,
> +   loff_t off, loff_t len)
>  {
> - XA_STATE(xas, >i_pages, 0);
> + unsigned long start_idx = off >> PAGE_SHIFT;
> + unsigned long end_idx = (len == ULONG_MAX) ? ULONG_MAX
> + : start_idx + (len >> PAGE_SHIFT);
> + XA_STATE(xas, >i_pages, start_idx);
>   void *entry;
>   unsigned int scanned = 0;
>   struct page *page = NULL;
> @@ -612,7 +619,7 @@ struct page *dax_layout_busy_page(struct address_space 
> *mapping)
>   unmap_mapping_range(mapping, 0, 0, 1);

Should we unmap only those pages which fall in the range specified by caller.
Unmapping whole file seems to be less efficient.

Thanks
Vivek

[PATCH] PCI: tegra: Don't print an error on -EPROBE_DEFER

[Vidya Sagar]

APIs like devm_regulator_get() and devm_phy_get() have the potential to
return -EPROBE_DEFER when the respective sub-systems are not ready yet.
So avoid printing an error message as .probe() will be tried out again
at a later point of time anyway.

Signed-off-by: Vidya Sagar 
---
 drivers/pci/controller/dwc/pcie-tegra194.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
b/drivers/pci/controller/dwc/pcie-tegra194.c
index fc0dbeb31d78..c730986ed34d 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1368,9 +1368,11 @@ static int tegra_pcie_dw_probe(struct platform_device 
*pdev)
 
pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
if (IS_ERR(pcie->pex_ctl_supply)) {
-   dev_err(dev, "Failed to get regulator: %ld\n",
-   PTR_ERR(pcie->pex_ctl_supply));
-   return PTR_ERR(pcie->pex_ctl_supply);
+   ret = PTR_ERR(pcie->pex_ctl_supply);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get regulator: %ld\n",
+   PTR_ERR(pcie->pex_ctl_supply));
+   return ret;
}
 
pcie->core_clk = devm_clk_get(dev, "core");
@@ -1412,7 +1414,8 @@ static int tegra_pcie_dw_probe(struct platform_device 
*pdev)
kfree(name);
if (IS_ERR(phys[i])) {
ret = PTR_ERR(phys[i]);
-   dev_err(dev, "Failed to get PHY: %d\n", ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get PHY: %d\n", ret);
return ret;
}
}
-- 
2.17.1

Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver

[Frank Wunderlich]

Am 23. August 2019 16:56:13 MESZ schrieb Matthias Brugger 
:
>are you sure that you provide the correct chip_id here? I saw 0x2023
>(if I
>remember correctly), while this switch checks for 0x23, 0x91 and 0x97,
>so I'm
>not sure if the problem really lies here. I didn't dig into the code to
>find out
>how the chip_id is created.

The chip-id 0x2023 is reported with 5.3-rc5, next-code says 0x0. So i guess the 
chipid is read out/calculated the wrong way. If calculation is not changed the 
read is changed compared to 5.3

RE: [PATCH v3 0/8] AMD64 EDAC fixes

[Ghannam, Yazen]

> -Original Message-
> From: linux-edac-ow...@vger.kernel.org  On 
> Behalf Of Ghannam, Yazen
> Sent: Thursday, August 22, 2019 1:54 PM
> To: Adam Borowski 
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@alien8.de
> Subject: RE: [PATCH v3 0/8] AMD64 EDAC fixes
> 
...
> I wonder if the module is being loaded multiple times. I'll try to reproduce 
> this and track it down.
> 

I was able to reproduce a similar failure. I do see that the module is being 
loaded multiple times on failure.

Here's a call trace from one dump_stack() output:
[  +0.004964] CPU: 132 PID: 2680 Comm: systemd-udevd Not tainted 
4.20.0-edac-debug+ #36
[  +0.009802] Call Trace:
[  +0.002727]  dump_stack+0x63/0x85
[  +0.003696]  amd64_edac_init+0x2163/0x3000 [amd64_edac_mod]
[  +0.006216]  ? __wake_up+0x13/0x20
[  +0.003790]  ? 0xc120d000
[  +0.003694]  do_one_initcall+0x4a/0x1c9
[  +0.004277]  ? _cond_resched+0x19/0x40
[  +0.004178]  ? kmem_cache_alloc_trace+0x15c/0x1d0
[  +0.005244]  do_init_module+0x5f/0x216
[  +0.004180]  load_module+0x21d5/0x2ac0
[  +0.004179]  ? wait_woken+0x80/0x80
[  +0.003889]  __do_sys_finit_module+0xfc/0x120
[  +0.004858]  ? __do_sys_finit_module+0xfc/0x120
[  +0.005052]  __x64_sys_finit_module+0x1a/0x20
[  +0.004857]  do_syscall_64+0x5a/0x120
[  +0.004081]  entry_SYSCALL_64_after_hwframe+0x44/0xa9


So it seems that userspace (systemd-udevd) keeps trying to load the module. I'm 
not sure how to prevent this from within the module.

Boris,
Do you think it'd be appropriate to change the return values for some cases?

For example, ECC disabled is a hardware configuration. This doesn't mean that 
the module failed any operations in this case.

In other words, the module checks for a feature. If the feature is not present, 
then return without failure (and maybe give a message).

Thanks,
Yazen

Re: [Resubmit] Read battery voltage from Logitech Gaming mice

[Benjamin Tissoires]

On Fri, Aug 23, 2019 at 4:48 PM Filipe Laíns  wrote:
>
> On Fri, 2019-08-23 at 16:32 +0200, Benjamin Tissoires wrote:
> > The problem I have with quirks, and that I explained to Filipe on IRC
> > is that this is kernel ABI. Even if there is a very low chance we have
> > someone using this, re-using the same drv_data bit in the future might
> > break someone's device.
>
> But we can reserve those bits. I don't expect there to be a ton of
> devices that need to be quirked, so using the remaining bits should be
> perfectly fine. Do you agree?

Nope. If the code is not ready for upstream, it should not be included.

Cheers,
Benjamin

Re: [patch V2 01/38] posix-cpu-timers: Provide task validation functions

[Thomas Gleixner]

On Thu, 22 Aug 2019, Frederic Weisbecker wrote:
> On Thu, Aug 22, 2019 at 12:33:56AM +0200, Frederic Weisbecker wrote:
> > On Wed, Aug 21, 2019 at 09:08:48PM +0200, Thomas Gleixner wrote:
> > > The code contains three slightly different copies of validating whether a
> > > given clock resolves to a valid task and whether the current caller has
> > > permissions to access it.
> > > 
> > > Create central functions. Replace check_clock() as a first step and rename
> > > it to something sensible.
> > > 
> > > Signed-off-by: Thomas Gleixner 
> > > ---
> > >  kernel/time/posix-cpu-timers.c |   65 
> > > +++--
> > >  1 file changed, 44 insertions(+), 21 deletions(-)
> > > 
> > > --- a/kernel/time/posix-cpu-timers.c
> > > +++ b/kernel/time/posix-cpu-timers.c
> > > @@ -35,27 +35,52 @@ void update_rlimit_cpu(struct task_struc
> > >   spin_unlock_irq(>sighand->siglock);
> > >  }
> > >  
> > > -static int check_clock(const clockid_t which_clock)
> > > +/*
> > > + * Functions for validating access to tasks.
> > > + */
> > > +static struct task_struct *lookup_task(const pid_t pid, bool thread)
> > >  {
> > > - int error = 0;
> > >   struct task_struct *p;
> > > - const pid_t pid = CPUCLOCK_PID(which_clock);
> > >  
> > > - if (CPUCLOCK_WHICH(which_clock) >= CPUCLOCK_MAX)
> > > - return -EINVAL;
> > > + if (!pid)
> > > + return thread ? current : current->group_leader;
> > >  
> > > - if (pid == 0)
> > > - return 0;
> > > + p = find_task_by_vpid(pid);
> > > + if (!p || p == current)
> > > + return p;
> > 
> > What if (p == current && !thread && !has_group_leader_pid(p)) ?
> 
> Ah looking at the next patch, posix_cpu_clock_get_task() and 
> posix_cpu_clock_getres()
> had different ad-hoc checks for this specific case.
> 
> clock_getres() used to return -EINVAL while clock_get() doesn't
> care. They certainly should agree in their behaviour. I'm not sure which
> one is correct. It probably doesn't matter much.

Let me stare on the different variants again

Thanks,

tglx

Re: [PATCH v14 01/18] kunit: test: add KUnit test runner core

[shuah]

Hi Brendan,

On 8/20/19 5:20 PM, Brendan Higgins wrote:

Add core facilities for defining unit tests; this provides a common way
to define test cases, functions that execute code which is under test
and determine whether the code under test behaves as expected; this also
provides a way to group together related test cases in test suites (here
we call them test_modules).

Just define test cases and how to execute them for now; setting
expectations on code will be defined later.

Signed-off-by: Brendan Higgins 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Logan Gunthorpe 
Reviewed-by: Luis Chamberlain 
Reviewed-by: Stephen Boyd 
---
  include/kunit/test.h | 179 
  kunit/Kconfig|  17 
  kunit/Makefile   |   1 +
  kunit/test.c | 191 +++
  4 files changed, 388 insertions(+)
  create mode 100644 include/kunit/test.h
  create mode 100644 kunit/Kconfig
  create mode 100644 kunit/Makefile
  create mode 100644 kunit/test.c

diff --git a/include/kunit/test.h b/include/kunit/test.h
new file mode 100644
index 0..e0b34acb9ee4e
--- /dev/null
+++ b/include/kunit/test.h
@@ -0,0 +1,179 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Base unit test (KUnit) API.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#ifndef _KUNIT_TEST_H
+#define _KUNIT_TEST_H
+
+#include 
+
+struct kunit;
+
+/**
+ * struct kunit_case - represents an individual test case.
+ * @run_case: the function representing the actual test case.
+ * @name: the name of the test case.
+ *
+ * A test case is a function with the signature, ``void (*)(struct kunit *)``
+ * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. 
Each
+ * test case is associated with a  kunit_suite and will be run after the
+ * suite's init function and followed by the suite's exit function.
+ *
+ * A test case should be static and should only be created with the 
KUNIT_CASE()
+ * macro; additionally, every array of test cases should be terminated with an
+ * empty test case.
+ *
+ * Example:


Can you fix these line continuations. It makes it very hard to read.
Sorry for this late comment. These comments lines are longer than 80
and wrap.

There are several comment lines in the file that are way too long.

thanks,
-- Shuah

Re: [patch V2 17/38] posix-cpu-timers: Create a container struct

[Thomas Gleixner]

On Thu, 22 Aug 2019, Frederic Weisbecker wrote:

> On Wed, Aug 21, 2019 at 09:09:04PM +0200, Thomas Gleixner wrote:
> > --- a/include/linux/posix-timers.h
> > +++ b/include/linux/posix-timers.h
> > @@ -62,6 +62,40 @@ static inline int clockid_to_fd(const cl
> > return ~(clk >> 3);
> >  }
> 
> Shouldn't you start the #ifdef CONFIG_POSIX_TIMERS here?
> Because you're redefining struct posix_cputimers otherwise.

Yeah...

Re: [RESEND PATCH 07/13] KVM: x86: Add explicit flag for forced emulation on #UD

[Liran Alon]

> On 23 Aug 2019, at 17:44, Sean Christopherson 
>  wrote:
> 
> On Fri, Aug 23, 2019 at 04:47:14PM +0300, Liran Alon wrote:
>> 
>> 
>>> On 23 Aug 2019, at 4:07, Sean Christopherson 
>>>  wrote:
>>> 
>>> Add an explicit emulation type for forced #UD emulation and use it to
>>> detect that KVM should unconditionally inject a #UD instead of falling
>>> into its standard emulation failure handling.
>>> 
>>> Signed-off-by: Sean Christopherson 
>> 
>> The name "forced emulation on #UD" is not clear to me.
>> 
>> If I understand correctly, EMULTYPE_TRAP_UD is currently used to indicate
>> that in case the x86 emulator fails to decode instruction, the caller would
>> like the x86 emulator to fail early such that it can handle this condition
>> properly.  Thus, I would rename it EMULTYPE_TRAP_DECODE_FAILURE.
> 
> EMULTYPE_TRAP_UD is used when KVM intercepts a #UD from hardware.  KVM
> only emulates select instructions in this case in order to minmize the
> emulator attack surface, e.g.:
> 
>   if (unlikely(ctxt->ud) && likely(!(ctxt->d & EmulateOnUD)))
>   return EMULATION_FAILED;
> 
> To enable testing of the emulator, KVM recognizes a special "opcode" that
> triggers full emulation on #UD, e.g. ctxt->ud is false when the #UD was
> triggered with the magic prefix.  The prefix is only recognized when the
> module param force_emulation_prefix is toggled on, hence the name
> EMULTYPE_TRAP_UD_FORCED.

Ah-ha. This makes sense. Thanks for the explanation.
I would say it’s worth putting a comment in it in code…

> 
>> But this new flag seems to do the same. So I’m left confused.  I’m probably
>> missing something trivial here.

Re: [alsa-devel] [PATCH v3 0/4] soundwire: debugfs support for 5.4

[Pierre-Louis Bossart]

On 8/23/19 1:34 AM, Vinod Koul wrote:

On 21-08-19, 13:58, Pierre-Louis Bossart wrote:

This patchset enables debugfs support and corrects all the feedback
provided on an earlier RFC ('soundwire: updates for 5.4')

There is one remaining hard-coded value in intel.c that will need to
be fixed in a follow-up patchset not specific to debugfs: we need to
remove hard-coded Intel-specific configurations from cadence_master.c
(PDI offsets, etc).


Applied all (i did hand edit of patch 4 to resolve dependency), thanks


Thanks for the edit, appreciate not having to resend a series.

Re: [PATCH v5 09/10] rtc: mt6397: fix alarm register overwrite

[Matthias Brugger]

On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> From: Ran Bi 
> 
> Alarm registers high byte was reserved for other functions.
> This add mask in alarm registers operation functions.
> This also fix error condition in interrupt handler.
> 
> Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
> 
> Acked-by: Alexandre Belloni 
> Signed-off-by: Ran Bi 

Misses your Signed-off-by.

Regards,
Matthias

> ---
>  drivers/rtc/rtc-mt6397.c | 47 +--
>  1 file changed, 33 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index b46ed4d..828def7 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -47,6 +47,14 @@
>  
>  #define RTC_AL_SEC   0x0018
>  
> +#define RTC_AL_SEC_MASK  0x003f
> +#define RTC_AL_MIN_MASK  0x003f
> +#define RTC_AL_HOU_MASK  0x001f
> +#define RTC_AL_DOM_MASK  0x001f
> +#define RTC_AL_DOW_MASK  0x0007
> +#define RTC_AL_MTH_MASK  0x000f
> +#define RTC_AL_YEA_MASK  0x007f
> +
>  #define RTC_PDN2 0x002e
>  #define RTC_PDN2_PWRON_ALARM BIT(4)
>  
> @@ -103,7 +111,7 @@ static irqreturn_t mtk_rtc_irq_handler_thread(int irq, 
> void *data)
>   irqen = irqsta & ~RTC_IRQ_EN_AL;
>   mutex_lock(>lock);
>   if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
> -  irqen) < 0)
> +  irqen) == 0)
>   mtk_rtc_write_trigger(rtc);
>   mutex_unlock(>lock);
>  
> @@ -225,12 +233,12 @@ static int mtk_rtc_read_alarm(struct device *dev, 
> struct rtc_wkalrm *alm)
>   alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
>   mutex_unlock(>lock);
>  
> - tm->tm_sec = data[RTC_OFFSET_SEC];
> - tm->tm_min = data[RTC_OFFSET_MIN];
> - tm->tm_hour = data[RTC_OFFSET_HOUR];
> - tm->tm_mday = data[RTC_OFFSET_DOM];
> - tm->tm_mon = data[RTC_OFFSET_MTH];
> - tm->tm_year = data[RTC_OFFSET_YEAR];
> + tm->tm_sec = data[RTC_OFFSET_SEC] & RTC_AL_SEC_MASK;
> + tm->tm_min = data[RTC_OFFSET_MIN] & RTC_AL_MIN_MASK;
> + tm->tm_hour = data[RTC_OFFSET_HOUR] & RTC_AL_HOU_MASK;
> + tm->tm_mday = data[RTC_OFFSET_DOM] & RTC_AL_DOM_MASK;
> + tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
> + tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
>  
>   tm->tm_year += RTC_MIN_YEAR_OFFSET;
>   tm->tm_mon--;
> @@ -251,14 +259,25 @@ static int mtk_rtc_set_alarm(struct device *dev, struct 
> rtc_wkalrm *alm)
>   tm->tm_year -= RTC_MIN_YEAR_OFFSET;
>   tm->tm_mon++;
>  
> - data[RTC_OFFSET_SEC] = tm->tm_sec;
> - data[RTC_OFFSET_MIN] = tm->tm_min;
> - data[RTC_OFFSET_HOUR] = tm->tm_hour;
> - data[RTC_OFFSET_DOM] = tm->tm_mday;
> - data[RTC_OFFSET_MTH] = tm->tm_mon;
> - data[RTC_OFFSET_YEAR] = tm->tm_year;
> -
>   mutex_lock(>lock);
> + ret = regmap_bulk_read(rtc->regmap, rtc->addr_base + RTC_AL_SEC,
> +data, RTC_OFFSET_COUNT);
> + if (ret < 0)
> + goto exit;
> +
> + data[RTC_OFFSET_SEC] = ((data[RTC_OFFSET_SEC] & ~(RTC_AL_SEC_MASK)) |
> + (tm->tm_sec & RTC_AL_SEC_MASK));
> + data[RTC_OFFSET_MIN] = ((data[RTC_OFFSET_MIN] & ~(RTC_AL_MIN_MASK)) |
> + (tm->tm_min & RTC_AL_MIN_MASK));
> + data[RTC_OFFSET_HOUR] = ((data[RTC_OFFSET_HOUR] & ~(RTC_AL_HOU_MASK)) |
> + (tm->tm_hour & RTC_AL_HOU_MASK));
> + data[RTC_OFFSET_DOM] = ((data[RTC_OFFSET_DOM] & ~(RTC_AL_DOM_MASK)) |
> + (tm->tm_mday & RTC_AL_DOM_MASK));
> + data[RTC_OFFSET_MTH] = ((data[RTC_OFFSET_MTH] & ~(RTC_AL_MTH_MASK)) |
> + (tm->tm_mon & RTC_AL_MTH_MASK));
> + data[RTC_OFFSET_YEAR] = ((data[RTC_OFFSET_YEAR] & ~(RTC_AL_YEA_MASK)) |
> + (tm->tm_year & RTC_AL_YEA_MASK));
> +
>   if (alm->enabled) {
>   ret = regmap_bulk_write(rtc->regmap,
>   rtc->addr_base + RTC_AL_SEC,
> 

Re: cleanup the walk_page_range interface

[Steven Price]

On 23/08/2019 14:43, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote:
>> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
>>> On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig  wrote:

 this series is based on a patch from Linus to split the callbacks
 passed to walk_page_range and walk_page_vma into a separate structure
 that can be marked const, with various cleanups from me on top.
>>>
>>> The whole series looks good to me. Ack.
>>>
 Note that both Thomas and Steven have series touching this area pending,
 and there are a couple consumer in flux too - the hmm tree already
 conflicts with this series, and I have potential dma changes on top of
 the consumers in Thomas and Steven's series, so we'll probably need a
 git tree similar to the hmm one to synchronize these updates.
>>>
>>> I'd be willing to just merge this now, if that helps. The conversion
>>> is mechanical, and my only slight worry would be that at least for my
>>> original patch I didn't build-test the (few) non-x86
>>> architecture-specific cases. But I did end up looking at them fairly
>>> closely  (basically using some grep/sed scripts to see that the
>>> conversions I did matched the same patterns). And your changes look
>>> like obvious improvements too where any mistake would have been caught
>>> by the compiler.
>>>
>>> So I'm not all that worried from a functionality standpoint, and if
>>> this will help the next merge window, I'll happily pull now.
>>
>> So what is the plan forward?  Probably a little late for 5.3,
>> so queue it up in -mm for 5.4 and deal with the conflicts in at least
>> hmm?  Queue it up in the hmm tree even if it doesn't 100% fit?
> 
> Did we make a decision on this? Due to travel & LPC I'd like to
> finalize the hmm tree next week.

I was planning on rebasing my series on this and posting it for 5.4 - I
hadn't actually realised this hasn't been picked up yet. I haven't had
much time to look at this recently.

FWIW you can add for the series:

Acked-by: Steven Price 

Steve

Re: [PATCH 3/3] powerpc: use __builtin_trap() in BUG/WARN macros.

[Christophe Leroy]

On 08/19/2019 03:45 PM, Segher Boessenkool wrote:

On Mon, Aug 19, 2019 at 05:05:46PM +0200, Christophe Leroy wrote:

Le 19/08/2019 à 16:37, Segher Boessenkool a écrit :

On Mon, Aug 19, 2019 at 04:08:43PM +0200, Christophe Leroy wrote:

Le 19/08/2019 à 15:23, Segher Boessenkool a écrit :

On Mon, Aug 19, 2019 at 01:06:31PM +, Christophe Leroy wrote:

Note that we keep using an assembly text using "twi 31, 0, 0" for
inconditional traps because GCC drops all code after
__builtin_trap() when the condition is always true at build time.


As I said, it can also do this for conditional traps, if it can prove
the condition is always true.


But we have another branch for 'always true' and 'always false' using
__builtin_constant_p(), which don't use __builtin_trap(). Is there
anything wrong with that ?:


The compiler might not realise it is constant when it evaluates the
__builtin_constant_p, but only realises it later.  As the documentation
for the builtin says:
   A return of 0 does not indicate that the
   value is _not_ a constant, but merely that GCC cannot prove it is a
   constant with the specified value of the '-O' option.


So you mean GCC would not be able to prove that
__builtin_constant_p(cond) is always true but it would be able to prove
that if (cond)  is always true ?


Not sure what you mean, sorry.


And isn't there a away to tell GCC that '__builtin_trap()' is
recoverable in our case ?


No, GCC knows that a trap will never fall through.


I think it may work if you do

#define BUG_ON(x) do {  \
if (__builtin_constant_p(x)) {  \
if (x)  \
BUG();  \
} else {\
BUG_ENTRY("", 0); \
if (x)  \
__builtin_trap();   \
}   \
} while (0)


It doesn't work:


You need to make a BUG_ENTRY so that it refers to the *following* trap
instruction, if you go this way.


I don't know how BUG_ENTRY works exactly.


It's basic, maybe too basic: it adds an inline asm with a label, and
adds a .long in the __bug_table section with the address of that label.

When putting it after the __builtin_trap(), I changed it to using the
address before the one of the label which is always the twxx instruction
as far as I can see.

#define BUG_ENTRY(insn, flags, ...) \
__asm__ __volatile__(   \
"1:" insn "\n"  \
".section __bug_table,\"aw\"\n" \
"2:\t" PPC_LONG "1b, %0\n"  \
"\t.short %1, %2\n"   \
".org 2b+%3\n"\
".previous\n" \
: : "i" (__FILE__), "i" (__LINE__), \
  "i" (flags),\
  "i" (sizeof(struct bug_entry)), \
  ##__VA_ARGS__)


#define MY_BUG_ENTRY(lab, flags)\
__asm__ __volatile__(   \
".section __bug_table,\"aw\"\n" \
"2:\t" PPC_LONG "%4, %0\n"  \
"\t.short %1, %2\n"   \
".org 2b+%3\n"\
".previous\n" \
: : "i" (__FILE__), "i" (__LINE__), \
  "i" (flags),\
  "i" (sizeof(struct bug_entry)), \
  "i" (lab))

called as

#define BUG_ON(x) do {  \
MY_BUG_ENTRY(&, 0); \
lab: if (x) \
__builtin_trap();   \
} while (0)

not sure how reliable that works -- *if* it works, I just typed that in
without testing or anything -- but hopefully you get the idea.



I've not been able to make it work. GCC puts the label (.L2 and .L6) 
outside of the function, so the instruction preceding the label is blr, 
not the trap.


#define _EMIT_BUG_ENTRY \
".section __bug_table,\"aw\"\n" \
"2:\t" PPC_LONG "%4, %0\n"  \
"\t.short %1, %2\n"   \
".org 2b+%3\n"\
".previous\n"

#define BUG_ENTRY(flags, label) \
__asm__ __volatile__(   \
_EMIT_BUG_ENTRY \
: : "i" (__FILE__), "i" (__LINE__), \
  "i" 

Re: [PATCH v14 09/18] kunit: test: add support for test abort

[shuah]

Hi Brendan,

On 8/20/19 5:20 PM, Brendan Higgins wrote:

Add support for aborting/bailing out of test cases, which is needed for
implementing assertions.

An assertion is like an expectation, but bails out of the test case
early if the assertion is not met. The idea with assertions is that you
use them to state all the preconditions for your test. Logically
speaking, these are the premises of the test case, so if a premise isn't
true, there is no point in continuing the test case because there are no
conclusions that can be drawn without the premises. Whereas, the
expectation is the thing you are trying to prove.

Signed-off-by: Brendan Higgins 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Logan Gunthorpe 
Reviewed-by: Stephen Boyd 
---
  include/kunit/test.h  |   2 +
  include/kunit/try-catch.h |  75 +
  kunit/Makefile|   3 +-
  kunit/test.c  | 137 +-
  kunit/try-catch.c | 118 
  5 files changed, 319 insertions(+), 16 deletions(-)
  create mode 100644 include/kunit/try-catch.h
  create mode 100644 kunit/try-catch.c

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 6917b186b737a..390ce02f717b6 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -10,6 +10,7 @@
  #define _KUNIT_TEST_H
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -167,6 +168,7 @@ struct kunit {
  
  	/* private: internal use only. */

const char *name; /* Read only after initialization! */
+   struct kunit_try_catch try_catch;
/*
 * success starts as true, and may only be set to false during a test
 * case; thus, it is safe to update this across multiple threads using
diff --git a/include/kunit/try-catch.h b/include/kunit/try-catch.h
new file mode 100644
index 0..404f336cbdc85
--- /dev/null
+++ b/include/kunit/try-catch.h
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * An API to allow a function, that may fail, to be executed, and recover in a
+ * controlled manner.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins 
+ */
+
+#ifndef _KUNIT_TRY_CATCH_H
+#define _KUNIT_TRY_CATCH_H
+
+#include 
+
+typedef void (*kunit_try_catch_func_t)(void *);
+
+struct completion;
+struct kunit;
+
+/**
+ * struct kunit_try_catch - provides a generic way to run code which might 
fail.
+ * @test: The test case that is currently being executed.
+ * @try_completion: Completion that the control thread waits on while test 
runs.
+ * @try_result: Contains any errno obtained while running test case.
+ * @try: The function, the test case, to attempt to run.
+ * @catch: The function called if @try bails out.
+ * @context: used to pass user data to the try and catch functions.
+ *
+ * kunit_try_catch provides a generic, architecture independent way to execute
+ * an arbitrary function of type kunit_try_catch_func_t which may bail out by
+ * calling kunit_try_catch_throw(). If kunit_try_catch_throw() is called, @try
+ * is stopped at the site of invocation and @catch is called.
+ *
+ * struct kunit_try_catch provides a generic interface for the functionality
+ * needed to implement kunit->abort() which in turn is needed for implementing
+ * assertions. Assertions allow stating a precondition for a test simplifying
+ * how test cases are written and presented.
+ *
+ * Assertions are like expectations, except they abort (call
+ * kunit_try_catch_throw()) when the specified condition is not met. This is
+ * useful when you look at a test case as a logical statement about some piece
+ * of code, where assertions are the premises for the test case, and the
+ * conclusion is a set of predicates, rather expectations, that must all be
+ * true. If your premises are violated, it does not makes sense to continue.
+ */
+struct kunit_try_catch {
+   /* private: internal use only. */
+   struct kunit *test;
+   struct completion *try_completion;
+   int try_result;
+   kunit_try_catch_func_t try;
+   kunit_try_catch_func_t catch;
+   void *context;
+};
+
+void kunit_try_catch_init(struct kunit_try_catch *try_catch,
+ struct kunit *test,
+ kunit_try_catch_func_t try,
+ kunit_try_catch_func_t catch);
+
+void kunit_try_catch_run(struct kunit_try_catch *try_catch, void *context);
+
+void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch);
+
+static inline int kunit_try_catch_get_result(struct kunit_try_catch *try_catch)
+{
+   return try_catch->try_result;
+}
+
+/*
+ * Exposed for testing only.
+ */
+void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch);
+
+#endif /* _KUNIT_TRY_CATCH_H */
diff --git a/kunit/Makefile b/kunit/Makefile
index 4e46450bcb3a8..c9176c9c578c6 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,6 +1,7 @@
  obj-$(CONFIG_KUNIT) +=test.o \
  

Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver

[Frank Wunderlich]

As far as i understand does old init-function not rely on the chip-id, so it 
seems that with this commit a prior bug is shown.
maybe the chip-id (should be 0x23 like constant) is set later after irq-request 
or completely missing for mt6323

Re: [PATCH v3 0/8] AMD64 EDAC fixes

[Borislav Petkov]

On Fri, Aug 23, 2019 at 03:28:59PM +, Ghannam, Yazen wrote:
> Boris, Do you think it'd be appropriate to change the return values
> for some cases?
>
> For example, ECC disabled is a hardware configuration. This doesn't
> mean that the module failed any operations in this case.
>
> In other words, the module checks for a feature. If the feature is not
> present, then return without failure (and maybe give a message).

That makes sense but AFAICT if probe_one_instance() sees that ECC is not
enabled, it returns 0.

The "if (!edac_has_mcs())" check later is to verify that at least once
instance was loaded successfully and, if not, then return an error.

So where does it return failure?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH trivial] mtd: nand: fix typo, s/erasablocks/eraseblocks

[Tudor.Ambarus]

From: Tudor Ambarus 

Signed-off-by: Tudor Ambarus 
---
 include/linux/mtd/nand.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index cebc38b6d6f5..0c7483843a32 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -346,7 +346,7 @@ static inline unsigned int nanddev_ntargets(const struct 
nand_device *nand)
 }
 
 /**
- * nanddev_neraseblocks() - Get the total number of erasablocks
+ * nanddev_neraseblocks() - Get the total number of eraseblocks
  * @nand: NAND device
  *
  * Return: the total number of eraseblocks exposed by @nand.
-- 
2.9.5

[PATCH trivial] mtd: spi-nor: Remove unused macro

[Tudor.Ambarus]

From: Tudor Ambarus 

Remove leftover from nor->cmd_buf.

Signed-off-by: Tudor Ambarus 
---
 include/linux/mtd/spi-nor.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 63560b375168..3075ac73b171 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -225,7 +225,6 @@ static inline u8 spi_nor_get_protocol_width(enum 
spi_nor_protocol proto)
return spi_nor_get_protocol_data_nbits(proto);
 }
 
-#define SPI_NOR_MAX_CMD_SIZE   8
 enum spi_nor_ops {
SPI_NOR_OPS_READ = 0,
SPI_NOR_OPS_WRITE,
-- 
2.9.5

Re: [PATCH] PCI: dwc: Use dev_info() instead of dev_err()

[Lorenzo Pieralisi]

On Fri, Aug 23, 2019 at 08:46:18PM +0530, Vidya Sagar wrote:
> When a platform has an open PCIe slot, not having a device connected to
> it doesn't have to result in a dev_err() print saying that the link is
> not up but a dev_info() would suffice.
> 
> Signed-off-by: Vidya Sagar 
> ---
>  drivers/pci/controller/dwc/pcie-designware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Squashed in pci/tegra, thanks.

Lorenzo

> diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 59eaeeb21dbe..4d6690b6ca36 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -456,7 +456,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
>   usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
>   }
>  
> - dev_err(pci->dev, "Phy link never came up\n");
> + dev_info(pci->dev, "Phy link never came up\n");
>  
>   return -ETIMEDOUT;
>  }
> -- 
> 2.17.1
> 

Re: [alsa-devel] [RESEND PATCH v4 1/4] dt-bindings: soundwire: add slave bindings

[Pierre-Louis Bossart]

On 8/22/19 6:37 PM, Srinivas Kandagatla wrote:

This patch adds bindings for Soundwire Slave devices that includes how
SoundWire enumeration address and Link ID are used to represented in
SoundWire slave device tree nodes.

Signed-off-by: Srinivas Kandagatla 
---
  .../soundwire/soundwire-controller.yaml   | 75 +++
  1 file changed, 75 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml

diff --git 
a/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml 
b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
new file mode 100644
index ..91aa6c6d6266
--- /dev/null
+++ b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soundwire/soundwire-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SoundWire Controller Generic Binding
+
+maintainers:
+  - Srinivas Kandagatla 
+
+description: |
+  SoundWire busses can be described with a node for the SoundWire controller
+  device and a set of child nodes for each SoundWire slave on the bus.
+
+properties:
+  $nodename:
+pattern: "^soundwire(@.*|-[0-9a-f])*$"
+
+  "#address-cells":
+const: 2
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^.*@[0-9a-f]+$":
+type: object
+
+properties:
+  compatible:
+  pattern: "^sdw[0-9][0-9a-f]{4}[0-9a-f]{4}[0-9a-f]{2}$"


So is this a 64-bit value, as in the MIPI spec, or is this part of the 
_ADR description?

I also don't get why the first item in in base10?



+  description:
+ Is the textual representation of SoundWire Enumeration
+ address. compatible string should contain SoundWire Version ID,
+ Manufacturer ID, Part ID and Class ID in order and shall be in
+ lower-case hexadecimal with leading zeroes.
+ Valid sizes of these fields are
+ Version ID is 1 nibble, number '0x1' represents SoundWire 1.0
+ and '0x2' represents SoundWire 1.1 and so on.
+ MFD is 4 nibbles
+ PID is 4 nibbles
+ CID is 2 nibbles
+ More Information on detail of encoding of these fields can be
+ found in MIPI Alliance DisCo & SoundWire 1.0 Specifications.
+
+  reg:
+maxItems: 1
+description:
+  Instance ID and Link ID of SoundWire Device Address.
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+soundwire@c2d {
+#address-cells = <2>;
+#size-cells = <0>;
+compatible = "qcom,soundwire-v1.5.0";
+reg = <0x0c2d 0x2000>;
+
+speaker@1 {
+compatible = "sdw10217201000";
+reg = <1 0>;
+};
+
+speaker@2 {
+compatible = "sdw10217201000";
+reg = <2 0>;
+};
+};
+
+...

Re: [PATCH] PCI: tegra: Don't print an error on -EPROBE_DEFER

[Lorenzo Pieralisi]

On Fri, Aug 23, 2019 at 08:48:32PM +0530, Vidya Sagar wrote:
> APIs like devm_regulator_get() and devm_phy_get() have the potential to
> return -EPROBE_DEFER when the respective sub-systems are not ready yet.
> So avoid printing an error message as .probe() will be tried out again
> at a later point of time anyway.
> 
> Signed-off-by: Vidya Sagar 
> ---
>  drivers/pci/controller/dwc/pcie-tegra194.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

Squashed in pci/tegra, thanks.

Lorenzo

> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
> b/drivers/pci/controller/dwc/pcie-tegra194.c
> index fc0dbeb31d78..c730986ed34d 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -1368,9 +1368,11 @@ static int tegra_pcie_dw_probe(struct platform_device 
> *pdev)
>  
>   pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
>   if (IS_ERR(pcie->pex_ctl_supply)) {
> - dev_err(dev, "Failed to get regulator: %ld\n",
> - PTR_ERR(pcie->pex_ctl_supply));
> - return PTR_ERR(pcie->pex_ctl_supply);
> + ret = PTR_ERR(pcie->pex_ctl_supply);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get regulator: %ld\n",
> + PTR_ERR(pcie->pex_ctl_supply));
> + return ret;
>   }
>  
>   pcie->core_clk = devm_clk_get(dev, "core");
> @@ -1412,7 +1414,8 @@ static int tegra_pcie_dw_probe(struct platform_device 
> *pdev)
>   kfree(name);
>   if (IS_ERR(phys[i])) {
>   ret = PTR_ERR(phys[i]);
> - dev_err(dev, "Failed to get PHY: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get PHY: %d\n", ret);
>   return ret;
>   }
>   }
> -- 
> 2.17.1
> 

Re: [PATCH v10 2/3] fdt: add support for rng-seed

[Will Deacon]

On Fri, Aug 23, 2019 at 02:24:51PM +0800, Hsin-Yi Wang wrote:
> Introducing a chosen node, rng-seed, which is an entropy that can be
> passed to kernel called very early to increase initial device
> randomness. Bootloader should provide this entropy and the value is
> read from /chosen/rng-seed in DT.
> 
> Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(),
> since early_init_dt_scan_chosen() would modify fdt to erase rng-seed.
> 
> Add a new interface add_bootloader_randomness() for rng-seed use case.
> Depends on whether the seed is trustworthy, rng seed would be passed to
> add_hwgenerator_randomness(). Otherwise it would be passed to
> add_device_randomness(). Decision is controlled by kernel config
> RANDOM_TRUST_BOOTLOADER.
> 
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Stephen Boyd 
> Reviewed-by: Rob Herring 
> ---
> Change from v9:
> * reword kconfig
> * use IS_ENABLED for config

Given that these aren't functional changes, I've kept Ted's ack from v9
and I'll queue these via arm64 assuming they pass testing.

Ted -- please shout if you're not happy about that, and I'll drop the
series.

Thanks,

Will

Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver

[Matthias Brugger]

On 23/08/2019 17:26, Frank Wunderlich wrote:
> 
> 
> Am 23. August 2019 16:56:13 MESZ schrieb Matthias Brugger 
> :
>> are you sure that you provide the correct chip_id here? I saw 0x2023
>> (if I
>> remember correctly), while this switch checks for 0x23, 0x91 and 0x97,
>> so I'm
>> not sure if the problem really lies here. I didn't dig into the code to
>> find out
>> how the chip_id is created.
> 
> The chip-id 0x2023 is reported with 5.3-rc5, next-code says 0x0. So i guess 
> the chipid is read out/calculated the wrong way. If calculation is not 
> changed the read is changed compared to 5.3
> 

I suppose that's because 3/10 has code that should be in 2/10 and for some
reason 3/10 was not pushed for linux-next inclusion. Although it has the same
Acked-for-mfd-by tag.

@Frank, can you test if adding 3/10 to your code base fixes the issue?

Regards,
Matthias

Re: [PATCH 3/3] firmware: add mutex fw_lock_fallback for race condition

[Luis Chamberlain]

On Fri, Aug 23, 2019 at 12:31:40PM +0200, Takashi Iwai wrote:
> So, if any, we'd need put a mutex around the fallback loader code.
> And, the mutex should be rather per device, not a global one.
> 
> Or we may trick it by appending the second parallel caller into the
> same wait queue, but the code will be more complex, so I don't think
> worth for it.

For now I'm thinking of a new API with a devname prefix to the driver.
I'll have to test if that works, but not sure if I'll get to it today
before my vacation starts (today).

  Luis

Re: [RESEND PATCHv4 1/1] drivers/amba: add reset control to amba bus probe

[Dinh Nguyen]

On 8/23/19 4:19 AM, Linus Walleij wrote:
> On Tue, Aug 20, 2019 at 4:58 PM Dinh Nguyen  wrote:
> 
>> @@ -401,6 +402,26 @@ static int amba_device_try_add(struct amba_device *dev, 
>> struct resource *parent)
>> ret = amba_get_enable_pclk(dev);
>> if (ret == 0) {
>> u32 pid, cid;
>> +   int count;
>> +   struct reset_control *rstc;
>> +
>> +   /*
>> +* Find reset control(s) of the amba bus and de-assert them.
>> +*/
>> +   count = reset_control_get_count(>dev);
>> +   while (count > 0) {
>> +   rstc = 
>> of_reset_control_get_shared_by_index(dev->dev.of_node, count - 1);
>> +   if (IS_ERR(rstc)) {
>> +   if (PTR_ERR(rstc) == -EPROBE_DEFER)
>> +   ret = -EPROBE_DEFER;
>> +   else
>> +   dev_err(>dev, "Can't get amba 
>> reset!\n");
>> +   break;
>> +   }
>> +   reset_control_deassert(rstc);
>> +   reset_control_put(rstc);
>> +   count--;
>> +   }
> 
> I'm not normally a footprint person, but the looks of the stubs in
>  makes me suspicious whether this will have zero impact
> in size on platforms without reset controllers.
> 
> Can you just ls -al on the kernel without CONFIG_RESET_CONTROLLER
> before and after this patch and ascertain that it has zero footprint effect?

Thanks for the review. I checked it, and indeed, it does have a zero
footprint effect.

> 
> If it doesn't I'd sure like to break this into its own function and
> stick a if (!IS_ENABLED(CONFIG_RESET_CONTROLLER)) return 0;
> in there to make sure the compiler drops it.
> 
> Also it'd be nice to get Philipp's ACK on the semantics, though they
> look correct to me.
> 

Dinh

[PATCH v2 0/2] ASoC: meson: axg-tdm-formatter: add g12a reset

[Jerome Brunet]

This patchset add the possibility to provide a reset to the tdm formatter.
Such reset is available on the g12a SoC family and helps solve a random
channel output shift when using more than one output lane.

Changes since v1 [0]:
- Rebased on kevin's tree

[0]: https://lkml.kernel.org/r/20190820121551.18398-1-jbru...@baylibre.com

Jerome Brunet (2):
  arm64: dts: meson: g12a: audio clock controller provides resets
  arm64: dts: meson: g12a: add reset to tdm formatters

 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 9 +
 1 file changed, 9 insertions(+)

-- 
2.21.0

[PATCH v2 1/2] arm64: dts: meson: g12a: audio clock controller provides resets

[Jerome Brunet]

The clock controller dedicated to audio clocks also provides reset lines
on the g12 SoC family

Reviewed-by: Neil Armstrong 
Signed-off-by: Jerome Brunet 
---
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index cd3d23d2c6a2..edbc30572958 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1434,6 +1434,7 @@
compatible = "amlogic,g12a-audio-clkc";
reg = <0x0 0x0 0x0 0xb4>;
#clock-cells = <1>;
+   #reset-cells = <1>;
 
clocks = < CLKID_AUDIO>,
 < CLKID_MPLL0>,
-- 
2.21.0

[tip: x86/urgent] x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386

[tip-bot2 for Sean Christopherson]

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: b63f20a778c88b6a04458ed6ffc69da953d3a109
Gitweb:
https://git.kernel.org/tip/b63f20a778c88b6a04458ed6ffc69da953d3a109
Author:Sean Christopherson 
AuthorDate:Thu, 22 Aug 2019 14:11:22 -07:00
Committer: Thomas Gleixner 
CommitterDate: Fri, 23 Aug 2019 17:38:13 +02:00

x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386

Use 'lea' instead of 'add' when adjusting %rsp in CALL_NOSPEC so as to
avoid clobbering flags.

KVM's emulator makes indirect calls into a jump table of sorts, where
the destination of the CALL_NOSPEC is a small blob of code that performs
fast emulation by executing the target instruction with fixed operands.

  adcb_al_dl:
 0x000339f8 <+0>:   adc%dl,%al
 0x000339fa <+2>:   ret

A major motiviation for doing fast emulation is to leverage the CPU to
handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is
both an input and output to the target of CALL_NOSPEC.  Clobbering flags
results in all sorts of incorrect emulation, e.g. Jcc instructions often
take the wrong path.  Sans the nops...

  asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
 0x0003595a <+58>:  mov0xc0(%ebx),%eax
 0x00035960 <+64>:  mov0x60(%ebx),%edx
 0x00035963 <+67>:  mov0x90(%ebx),%ecx
 0x00035969 <+73>:  push   %edi
 0x0003596a <+74>:  popf
 0x0003596b <+75>:  call   *%esi
 0x000359a0 <+128>: pushf
 0x000359a1 <+129>: pop%edi
 0x000359a2 <+130>: mov%eax,0xc0(%ebx)
 0x000359b1 <+145>: mov%edx,0x60(%ebx)

  ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
 0x000359a8 <+136>: mov-0x10(%ebp),%eax
 0x000359ab <+139>: and$0x8d5,%edi
 0x000359b4 <+148>: and$0xf72a,%eax
 0x000359b9 <+153>: or %eax,%edi
 0x000359bd <+157>: mov%edi,0x4(%ebx)

For the most part this has gone unnoticed as emulation of guest code
that can trigger fast emulation is effectively limited to MMIO when
running on modern hardware, and MMIO is rarely, if ever, accessed by
instructions that affect or consume flags.

Breakage is almost instantaneous when running with unrestricted guest
disabled, in which case KVM must emulate all instructions when the guest
has invalid state, e.g. when the guest is in Big Real Mode during early
BIOS.

Fixes: 776b043848fd2 ("x86/retpoline: Add initial retpoline support")
Fixes: 1a29b5b7f347a ("KVM: x86: Make indirect calls in emulator speculation 
safe")
Signed-off-by: Sean Christopherson 
Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/20190822211122.27579-1-sean.j.christopher...@intel.com

---
 arch/x86/include/asm/nospec-branch.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/nospec-branch.h 
b/arch/x86/include/asm/nospec-branch.h
index 109f974..80bc209 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -192,7 +192,7 @@
"   lfence;\n"  \
"   jmp902b;\n" \
"   .align 16\n"\
-   "903:   addl   $4, %%esp;\n"\
+   "903:   lea4(%%esp), %%esp;\n"  \
"   pushl  %[thunk_target];\n"  \
"   ret;\n" \
"   .align 16\n"\

Re: [alsa-devel] [RESEND PATCH v4 2/4] soundwire: core: add device tree support for slave devices

[Pierre-Louis Bossart]

On 8/22/19 6:37 PM, Srinivas Kandagatla wrote:

This patch adds support to parsing device tree based
SoundWire slave devices.

Signed-off-by: Srinivas Kandagatla 
---
  drivers/soundwire/bus.c   |  2 ++
  drivers/soundwire/bus.h   |  1 +
  drivers/soundwire/slave.c | 52 +++
  3 files changed, 55 insertions(+)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 49f64b2115b9..c2eaeb5c38ed 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -77,6 +77,8 @@ int sdw_add_bus_master(struct sdw_bus *bus)
 */
if (IS_ENABLED(CONFIG_ACPI) && ACPI_HANDLE(bus->dev))
ret = sdw_acpi_find_slaves(bus);
+   else if (IS_ENABLED(CONFIG_OF) && bus->dev->of_node)
+   ret = sdw_of_find_slaves(bus);
else
ret = -ENOTSUPP; /* No ACPI/DT so error out */
  
diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h

index 3048ca153f22..ee46befedbd1 100644
--- a/drivers/soundwire/bus.h
+++ b/drivers/soundwire/bus.h
@@ -15,6 +15,7 @@ static inline int sdw_acpi_find_slaves(struct sdw_bus *bus)
  }
  #endif
  
+int sdw_of_find_slaves(struct sdw_bus *bus);

  void sdw_extract_slave_id(struct sdw_bus *bus,
  u64 addr, struct sdw_slave_id *id);
  
diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c

index f39a5815e25d..3ef265d2ee89 100644
--- a/drivers/soundwire/slave.c
+++ b/drivers/soundwire/slave.c
@@ -2,6 +2,7 @@
  // Copyright(c) 2015-17 Intel Corporation.
  
  #include 

+#include 
  #include 
  #include 
  #include "bus.h"
@@ -35,6 +36,7 @@ static int sdw_slave_add(struct sdw_bus *bus,
  
  	slave->dev.release = sdw_slave_release;

slave->dev.bus = _bus_type;
+   slave->dev.of_node = of_node_get(to_of_node(fwnode));
slave->bus = bus;
slave->status = SDW_SLAVE_UNATTACHED;
slave->dev_num = 0;
@@ -112,3 +114,53 @@ int sdw_acpi_find_slaves(struct sdw_bus *bus)
  }
  
  #endif

+
+/*
+ * sdw_of_find_slaves() - Find Slave devices in master device tree node
+ * @bus: SDW bus instance
+ *
+ * Scans Master DT node for SDW child Slave devices and registers it.
+ */
+int sdw_of_find_slaves(struct sdw_bus *bus)
+{
+   struct device *dev = bus->dev;
+   struct device_node *node;
+
+   for_each_child_of_node(bus->dev->of_node, node) {
+   int link_id, sdw_version, ret, len;
+   const char *compat = NULL;
+   struct sdw_slave_id id;
+   const __be32 *addr;
+
+   compat = of_get_property(node, "compatible", NULL);
+   if (!compat)
+   continue;
+
+   ret = sscanf(compat, "sdw%01x%04hx%04hx%02hhx", _version,
+_id, _id, _id);
+
+   if (ret != 4) {
+   dev_err(dev, "Invalid compatible string found %s\n",
+   compat);
+   continue;
+   }
+
+   addr = of_get_property(node, "reg", );
+   if (!addr || (len < 2 * sizeof(u32))) {
+   dev_err(dev, "Invalid Instance and Link ID\n");
+   continue;
+   }
+
+   id.unique_id = be32_to_cpup(addr++);
+   link_id = be32_to_cpup(addr);


So here the link ID is obviously not in the address, so you are not 
using the MIPI spec as we discussed initially?



+   id.sdw_version = sdw_version;
+
+   /* Check for link_id match */
+   if (link_id != bus->link_id)
+   continue;
+
+   sdw_slave_add(bus, , of_fwnode_handle(node));
+   }
+
+   return 0;
+}

Re: [PATCH v2 03/11] dt-bindings: irq: mtk,sysirq: add support for mt6779

[Matthias Brugger]

On 19/08/2019 11:21, Mars Cheng wrote:
> Add binding documentation of mediatek,sysirq for mt6779 SoC.
> 
> Signed-off-by: Mars Cheng 

Reviewed-by: Matthias Brugger 

> ---
>  .../interrupt-controller/mediatek,sysirq.txt   |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
> b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
> index 0e312fe..84ced3f 100644
> --- 
> a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
> @@ -15,6 +15,7 @@ Required properties:
>   "mediatek,mt7629-sysirq", "mediatek,mt6577-sysirq": for MT7629
>   "mediatek,mt6795-sysirq", "mediatek,mt6577-sysirq": for MT6795
>   "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq": for MT6797
> + "mediatek,mt6779-sysirq", "mediatek,mt6577-sysirq": for MT6779
>   "mediatek,mt6765-sysirq", "mediatek,mt6577-sysirq": for MT6765
>   "mediatek,mt6755-sysirq", "mediatek,mt6577-sysirq": for MT6755
>   "mediatek,mt6592-sysirq", "mediatek,mt6577-sysirq": for MT6592
>