All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: pinctrl-single: num_maps in generic pinconf support?
From: Tony Lindgren @ 2020-05-29 17:40 UTC (permalink / raw)
  To: Drew Fustini; +Cc: Haojian Zhuang, Linus Walleij, linux-omap
In-Reply-To: <20200528125323.GA3074222@x1>

* Drew Fustini <drew@beagleboard.org> [200528 12:54]:
> Would you be able to describe what you think AM33XX_PADCONF would look
> like if the mux and conf are seperated?

Yes it would just slightly change, see your example below.

> Is there an example you know of for another SoC?

I think the other driver already keep the padconf and mux separate.

So not sure where all #pinctrl-cells could be used. It would make
pinctrl-single.c a bit nicer though, and probably would make it
easier to implement further features.

Some hardware may need it to have #pinctrl-cells = <3> if GPIO
features are there too, ideally pinctrl-single would not even
care but just work for what is configured for the hardware.

> Currently, the macro takes dir and mux:
> 
> include/dt-bindings/pinctrl/omap.h:
> #define AM33XX_PADCONF(pa, dir, mux) OMAP_IOPAD_OFFSET((pa), 0x0800) ((dir) | (mux))

So after fixing up pinctrl-single.c, and changing the SoC dts
to have #pinctrl-cells = <2> instead of <1>, the macro would
then need to be:

#define AM33XX_PADCONF(pa, dir, mux) OMAP_IOPAD_OFFSET((pa), 0x0800) (dir), (mux))

> For example, in arch/arm/boot/dts/am335x-bone-common.dtsi:
> AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0)

Yeah so no change needed for the use.

> I think it might be more accurate to rename 'dir' to 'conf'.

Sure makes sense to rename it in the macro.

Regards,

Tony

^ permalink raw reply
* Re: [XEN PATCH] xen/build: introduce CLANG_FLAGS for testing other CFLAGS
From: Andrew Cooper @ 2020-05-29 17:40 UTC (permalink / raw)
  To: Anthony PERARD, xen-devel
  Cc: Stefano Stabellini, Julien Grall, Wei Liu, Ian Jackson,
	George Dunlap, Jan Beulich, Roger Pau Monné
In-Reply-To: <20200529154343.1616925-1-anthony.perard@citrix.com>

On 29/05/2020 16:43, Anthony PERARD wrote:
> Commit 534519f0514f ("xen: Have Kconfig check $(CC)'s version")
> introduced the use of CLANG_FLAGS in Kconfig which is used when
> testing for other CFLAGS via $(cc-option ...) but CLANG_FLAGS doesn't
> exist in the Xen build system. (It's a Linux/Kbuild variable that
> haven't been added yet.)
>
> The missing CLANG_FLAGS isn't an issue for $(cc-option ..) but it
> would be when $(as-instr ..) gets imported from Kbuild to tests
> assembly instruction. We need to know if we are going to use clang's
> assembler or not.
>
> CLANG_FLAGS needs to be calculated before we call Kconfig.
>
> So, this patch adds CLANG_FLAGS which may contain two flags which are
> needed for further testing of $(CC)'s capabilities:
>   -no-integrated-as
>     This flags isn't new, but simply tested earlier so that it can be
>     used in Kconfig. The flags is only added for x86 builds like
>     before.
>   -Werror=unknown-warning-option
>     The one is new and is to make sure that the warning is enabled,
>     even though it is by default but could be disabled in a particular
>     build of clang, see Linux's commit e8de12fb7cde ("kbuild: Check
>     for unknown options with cc-option usage in Kconfig and clang")
>
>     It is present in clang 3.0.0, according Linux's commit
>     589834b3a009 ("kbuild: Add -Werror=unknown-warning-option to
>     CLANG_FLAGS").
>
> (The "note" that say that the flags was only added once wasn't true
> when tested on CentOS 6, so the patch uses $(or) and the flag will only
> be added once.)
>
> Fixes: 534519f0514f ("xen: Have Kconfig check $(CC)'s version")
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


^ permalink raw reply
* Re: [PATCH v2 1/3] seccomp: Add find_notification helper
From: Sargun Dhillon @ 2020-05-29 17:40 UTC (permalink / raw)
  To: Kees Cook
  Cc: christian.brauner, containers, cyphar, jannh, jeffv, linux-api,
	linux-kernel, palmer, rsesek, tycho, Matt Denton
In-Reply-To: <202005282319.2BA6AD88@keescook>

> 
> While the comment is good, let's actually enforce this with:
> 
> if (WARN_ON(!mutex_is_locked(&filter->notif_lock)))
> 	return NULL;
> 
I don't see much use of lockdep in seccomp (well, any), but
wouldn't a stronger statement be to use lockdep, and just have:

lockdep_assert_held(&filter->notify_lock);

As that checks that the lock is held by the current task.
Although, that does put this check behind lockdep, which means
that running in "normal" circumstances is less safe (but faster?).

^ permalink raw reply
* Re: [PATCH v2 for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0
From: Tamas K Lengyel @ 2020-05-29 17:39 UTC (permalink / raw)
  To: Ian Jackson
  Cc: Anthony Perard, Andrew Cooper, Wei Liu,
	xen-devel@lists.xenproject.org
In-Reply-To: <24273.14616.523593.758476@mariner.uk.xensource.com>

On Fri, May 29, 2020 at 10:32 AM Ian Jackson <ian.jackson@citrix.com> wrote:
>
> Andrew Cooper writes ("Re: [PATCH v2 for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0"):
> > On 29/05/2020 17:22, Tamas K Lengyel wrote:
> > > The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> > > boolean. This is incorrect and breaks external-only usecases of altp2m that
> > > is set with a value of 2.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> >
> > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >
> > Sorry for breaking it to begin with.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> and pushed.

Thanks for the fast turn around.

Tamas


^ permalink raw reply
* Re: [PATCH v3] airo: Fix read overflows sending packets
From: Kalle Valo @ 2020-05-29 17:40 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Hu Jiahui, Eric Dumazet, security, linux-wireless, Jakub Kicinski
In-Reply-To: <20200527184830.GA1164846@mwanda>

Dan Carpenter <dan.carpenter@oracle.com> wrote:

> The problem is that we always copy a minimum of ETH_ZLEN (60) bytes from
> skb->data even when skb->len is less than ETH_ZLEN so it leads to a read
> overflow.
> 
> The fix is to pad skb->data to at least ETH_ZLEN bytes.
> 
> Cc: <stable@vger.kernel.org>
> Reported-by: Hu Jiahui <kirin.say@gmail.com>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>

Patch applied to wireless-drivers-next.git, thanks.

11e7a91994c2 airo: Fix read overflows sending packets

-- 
https://patchwork.kernel.org/patch/11573765/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply
* Re: [PATCH] dl-runtime: reloc_{offset,index} now functions arch overide'able
From: Vineet Gupta @ 2020-05-29 17:39 UTC (permalink / raw)
  To: Adhemerval Zanella, libc-alpha@sourceware.org
  Cc: linux-snps-arc@lists.infradead.org
In-Reply-To: <4c346276-085a-6e2d-16a4-c2b88252a74d@linaro.org>

On 5/29/20 5:58 AM, Adhemerval Zanella via Libc-alpha wrote:
> 
> 
> On 28/05/2020 16:43, Vineet Gupta wrote:
>> The existing macros are fragile and expect local variables with a
>> certain name. Fix this by defining them as functions with defaul
>> timplementation in a new header dl-runtime.h which arches can overrid
>> eif need be.
>>
>> This came up during ARC port review.
>>
>> This patch potentially only affects hppa/x86 ports,
>> build tested for both those configs and a few more.
>>
>> Suggested-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> 
> LGTM, thanks.
> 
> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Sorry I didn't think through this before, but ARC port needs pltgot arg (runtime
address of plt0) in reloc_index not reloc_offset. I'll swap them and repost.

>>  /* This function is called through a special trampoline from the PLT the
>>     first time each PLT entry is called.  We must perform the relocation
>>     specified in the PLT of the given shared object, and return the resolved
>> @@ -68,8 +62,11 @@ _dl_fixup (
>>      = (const void *) D_PTR (l, l_info[DT_SYMTAB]);
>>    const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
>>  
>> +  const uintptr_t pltgot = (uintptr_t) D_PTR (l, l_info[DT_PLTGOT]);
>> +
>>    const PLTREL *const reloc
>> -    = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset);
>> +    = (const void *) (D_PTR (l, l_info[DT_JMPREL])
>> +		      + reloc_offset (pltgot, reloc_arg));
>>    const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)];
>>    const ElfW(Sym) *refsym = sym;
>>    void *const rel_addr = (void *)(l->l_addr + reloc->r_offset);
> 
> Ok (it should be dead code eliminated by compiler if reloc_offset does not
> use the pltgot field, as for default implementation).

Yep.

> 
>> diff --git a/elf/dl-runtime.h b/elf/dl-runtime.h
>> new file mode 100644
>> index 000000000000..ed5db3ba51b7
>> --- /dev/null
>> +++ b/elf/dl-runtime.h
>> @@ -0,0 +1,30 @@
>> +/* Helpers for On-demand PLT fixup for shared objects, Generic version.
> 
> Maybe period here?

OK


>> diff --git a/sysdeps/hppa/dl-runtime.h b/sysdeps/hppa/dl-runtime.h
>> new file mode 100644
>> index 000000000000..cfde0ec991e3
>> --- /dev/null
>> +++ b/sysdeps/hppa/dl-runtime.h
>> @@ -0,0 +1,31 @@
>> +/* Helpers for On-demand PLT fixup for shared objects, HPAA version.
> 
> Maybe period instead of comma here?

OK.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply
* [PATCH v8 1/2] ACPI / APEI: Add support to notify the vendor specific HW errors
From: Shiju Jose @ 2020-05-29 17:38 UTC (permalink / raw)
  To: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse,
	helgaas, lenb, tony.luck, dan.carpenter, gregkh, zhangliguang,
	tglx
  Cc: Shiju Jose, linuxarm, yangyicong
In-Reply-To: <20200529173854.2521-1-shiju.jose@huawei.com>

Add support to report the vendor specific non-fatal HW errors
to the drivers for the error recovery.

Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
---
 drivers/acpi/apei/ghes.c | 126 ++++++++++++++++++++++++++++++++++++++-
 include/acpi/ghes.h      |  28 +++++++++
 2 files changed, 153 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 24c9642e8fc7..d89a74dfae6a 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -33,6 +33,7 @@
 #include <linux/irq_work.h>
 #include <linux/llist.h>
 #include <linux/genalloc.h>
+#include <linux/kfifo.h>
 #include <linux/pci.h>
 #include <linux/pfn.h>
 #include <linux/aer.h>
@@ -63,6 +64,11 @@
 #define GHES_ESTATUS_CACHES_SIZE	4
 
 #define GHES_ESTATUS_IN_CACHE_MAX_NSEC	10000000000ULL
+
+#define GHES_EVENT_RING_SIZE	256
+#define GHES_GDATA_POOL_MIN_ALLOC_ORDER	3
+#define GHES_GDATA_POOL_MIN_SIZE	65536
+
 /* Prevent too many caches are allocated because of RCU */
 #define GHES_ESTATUS_CACHE_ALLOCED_MAX	(GHES_ESTATUS_CACHES_SIZE * 3 / 2)
 
@@ -122,6 +128,19 @@ static DEFINE_MUTEX(ghes_list_mutex);
  */
 static DEFINE_SPINLOCK(ghes_notify_lock_irq);
 
+struct ghes_event_entry {
+	struct acpi_hest_generic_data *gdata;
+	int error_severity;
+};
+
+static DEFINE_KFIFO(ghes_event_ring, struct ghes_event_entry,
+		    GHES_EVENT_RING_SIZE);
+
+static DEFINE_SPINLOCK(ghes_event_ring_lock);
+
+static struct gen_pool *ghes_gdata_pool;
+static unsigned long ghes_gdata_pool_size_request;
+
 static struct gen_pool *ghes_estatus_pool;
 static unsigned long ghes_estatus_pool_size_request;
 
@@ -188,6 +207,40 @@ int ghes_estatus_pool_init(int num_ghes)
 	return -ENOMEM;
 }
 
+int ghes_gdata_pool_init(void)
+{
+	unsigned long addr, len;
+	int rc;
+
+	ghes_gdata_pool = gen_pool_create(GHES_GDATA_POOL_MIN_ALLOC_ORDER, -1);
+	if (!ghes_gdata_pool)
+		return -ENOMEM;
+
+	if (ghes_gdata_pool_size_request < GHES_GDATA_POOL_MIN_SIZE)
+		ghes_gdata_pool_size_request = GHES_GDATA_POOL_MIN_SIZE;
+
+	len = ghes_gdata_pool_size_request;
+	addr = (unsigned long)vmalloc(PAGE_ALIGN(len));
+	if (!addr)
+		goto err_pool_alloc;
+
+	vmalloc_sync_mappings();
+
+	rc = gen_pool_add(ghes_gdata_pool, addr, PAGE_ALIGN(len), -1);
+	if (rc)
+		goto err_pool_add;
+
+	return 0;
+
+err_pool_add:
+	vfree((void *)addr);
+
+err_pool_alloc:
+	gen_pool_destroy(ghes_gdata_pool);
+
+	return -ENOMEM;
+}
+
 static int map_gen_v2(struct ghes *ghes)
 {
 	return apei_map_generic_address(&ghes->generic_v2->read_ack_register);
@@ -247,6 +300,10 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
 		goto err_unmap_status_addr;
 	}
 
+	ghes_gdata_pool_size_request += generic->records_to_preallocate *
+					generic->max_sections_per_record *
+					generic->max_raw_data_length;
+
 	return ghes;
 
 err_unmap_status_addr:
@@ -490,6 +547,48 @@ static void ghes_handle_aer(struct acpi_hest_generic_data *gdata)
 #endif
 }
 
+static BLOCKING_NOTIFIER_HEAD(ghes_event_notify_list);
+
+/**
+ * ghes_register_event_notifier - register an event notifier
+ * for the non-fatal HW errors.
+ * @nb: pointer to the notifier_block structure of the event handler.
+ *
+ * return 0 : SUCCESS, non-zero : FAIL
+ */
+int ghes_register_event_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&ghes_event_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(ghes_register_event_notifier);
+
+/**
+ * ghes_unregister_event_notifier - unregister the previously
+ * registered event notifier.
+ * @nb: pointer to the notifier_block structure of the event handler.
+ */
+void ghes_unregister_event_notifier(struct notifier_block *nb)
+{
+	blocking_notifier_chain_unregister(&ghes_event_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(ghes_unregister_event_notifier);
+
+static void ghes_event_work_func(struct work_struct *work)
+{
+	struct ghes_event_entry entry;
+	u32 len;
+
+	while (kfifo_get(&ghes_event_ring, &entry)) {
+		blocking_notifier_call_chain(&ghes_event_notify_list,
+					     entry.error_severity,
+					     entry.gdata);
+		len = acpi_hest_get_record_size(entry.gdata);
+		gen_pool_free(ghes_gdata_pool, (unsigned long)entry.gdata, len);
+	}
+}
+
+static DECLARE_WORK(ghes_event_work, ghes_event_work_func);
+
 static void ghes_do_proc(struct ghes *ghes,
 			 const struct acpi_hest_generic_status *estatus)
 {
@@ -498,6 +597,8 @@ static void ghes_do_proc(struct ghes *ghes,
 	guid_t *sec_type;
 	const guid_t *fru_id = &guid_null;
 	char *fru_text = "";
+	struct ghes_event_entry event_entry;
+	u32 len;
 
 	sev = ghes_severity(estatus->error_severity);
 	apei_estatus_for_each_section(estatus, gdata) {
@@ -527,6 +628,21 @@ static void ghes_do_proc(struct ghes *ghes,
 		} else {
 			void *err = acpi_hest_get_payload(gdata);
 
+			len = acpi_hest_get_record_size(gdata);
+			event_entry.gdata =
+				(void *)gen_pool_alloc(ghes_gdata_pool, len);
+			if (event_entry.gdata) {
+				memcpy(event_entry.gdata, gdata, len);
+				event_entry.error_severity = sev;
+
+				if (kfifo_in_spinlocked(&ghes_event_ring,
+							&event_entry, 1,
+							&ghes_event_ring_lock))
+					schedule_work(&ghes_event_work);
+				else
+					pr_warn(GHES_PFX "ghes event queue full\n");
+			}
+
 			log_non_standard_event(sec_type, fru_id, fru_text,
 					       sec_sev, err,
 					       gdata->error_data_length);
@@ -1334,7 +1450,7 @@ static int __init ghes_init(void)
 
 	rc = platform_driver_register(&ghes_platform_driver);
 	if (rc)
-		goto err;
+		goto exit;
 
 	rc = apei_osc_setup();
 	if (rc == 0 && osc_sb_apei_support_acked)
@@ -1346,8 +1462,16 @@ static int __init ghes_init(void)
 	else
 		pr_info(GHES_PFX "Failed to enable APEI firmware first mode.\n");
 
+	rc = ghes_gdata_pool_init();
+	if (rc) {
+		pr_warn(GHES_PFX "ghes_gdata_pool_init failed\n");
+		goto err;
+	}
+
 	return 0;
 err:
+	platform_driver_unregister(&ghes_platform_driver);
+exit:
 	return rc;
 }
 device_initcall(ghes_init);
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index e3f1cddb4ac8..a3dd82069069 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -50,6 +50,34 @@ enum {
 	GHES_SEV_PANIC = 0x3,
 };
 
+
+#ifdef CONFIG_ACPI_APEI_GHES
+/**
+ * ghes_register_event_notifier - register an event notifier
+ * for the non-fatal HW errors.
+ * @nb: pointer to the notifier_block structure of the event notifier.
+ *
+ * Return : 0 - SUCCESS, non-zero - FAIL.
+ */
+int ghes_register_event_notifier(struct notifier_block *nb);
+
+/**
+ * ghes_unregister_event_notifier - unregister the previously
+ * registered event notifier.
+ * @nb: pointer to the notifier_block structure of the event notifier.
+ */
+void ghes_unregister_event_notifier(struct notifier_block *nb);
+#else
+static inline int ghes_register_event_notifier(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+
+static inline void ghes_unregister_event_notifier(struct notifier_block *nb)
+{
+}
+#endif
+
 int ghes_estatus_pool_init(int num_ghes);
 
 /* From drivers/edac/ghes_edac.c */
-- 
2.17.1



^ permalink raw reply related
* [PATCH v8 0/2] ACPI / APEI: Add support to notify the vendor specific HW errors
From: Shiju Jose @ 2020-05-29 17:38 UTC (permalink / raw)
  To: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse,
	helgaas, lenb, tony.luck, dan.carpenter, gregkh, zhangliguang,
	tglx
  Cc: Shiju Jose, linuxarm, yangyicong

Presently the vendor drivers are unable to do the recovery for the
vendor specific recoverable HW errors because APEI driver does not
support reporting the error to the vendor drivers.

patch set
1. add new interface to the APEI driver for reporting the 
   vendor specific non-fatal HW errors to the drivers.

2. add driver to handle HiSilicon hip PCIe controller's errors.

V8:
1. Removed reporting the standard errors through the interface
   because of the conflict with the changes in the
   memory error handling path.
2. Fix comments by Dan Carpenter.
   
V7:
1. Add changes in the APEI driver suggested by Borislav Petkov, for
   queuing up all the non-fatal HW errors to the work queue and
   notify the registered kernel drivers from the bottom half using
   blocking notifier, common interface for both standard and
   vendor-spcific errors.
2. Fix for further feedbacks in v5 HIP PCIe error handler driver
   by Bjorn Helgaas.

V6:
1. Fix few changes in the patch subject line suggested by Bjorn Helgaas.

V5:
1. Fix comments from James Morse.
1.1 Changed the notification method to use the atomic_notifier_chain.
1.2 Add the error handled status for the user space.  

V4:
1. Fix for the following smatch warning in the PCIe error driver,
   reported by kbuild test robot<lkp@intel.com>:
   warn: should '((((1))) << (9 + i))' be a 64 bit type?
   if (err->val_bits & BIT(HISI_PCIE_LOCAL_VALID_ERR_MISC + i))
	^^^ This should be BIT_ULL() because it goes up to 9 + 32.

V3:
1. Fix the comments from Bjorn Helgaas.

V2:
1. Changes in the HiSilicon PCIe controller's error handling driver
   for the comments from Bjorn Helgaas.
   
2. Changes in the APEI interface to support reporting the vendor error
   for module with multiple devices, but use the same section type.
   In the error handler will use socket id/sub module id etc to distinguish
   the device.

V1:  
1. Fix comments from James Morse.

2. add driver to handle HiSilicon hip08 PCIe controller's errors,
   which is an application of the above interface.   
   
Shiju Jose (1):
  ACPI / APEI: Add support to notify the vendor specific HW errors

Yicong Yang (1):
  PCI: hip: Add handling of HiSilicon HIP PCIe controller errors

 drivers/acpi/apei/ghes.c                 | 126 ++++++++-
 drivers/pci/controller/Kconfig           |   8 +
 drivers/pci/controller/Makefile          |   1 +
 drivers/pci/controller/pcie-hisi-error.c | 321 +++++++++++++++++++++++
 include/acpi/ghes.h                      |  28 ++
 5 files changed, 483 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/controller/pcie-hisi-error.c

-- 
2.17.1



^ permalink raw reply
* [PATCH v8 2/2] PCI: hip: Add handling of HiSilicon HIP PCIe controller errors
From: Shiju Jose @ 2020-05-29 17:38 UTC (permalink / raw)
  To: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse,
	helgaas, lenb, tony.luck, dan.carpenter, gregkh, zhangliguang,
	tglx
  Cc: Yicong Yang, linuxarm, Shiju Jose
In-Reply-To: <20200529173854.2521-1-shiju.jose@huawei.com>

From: Yicong Yang <yangyicong@hisilicon.com>

The HiSilicon HIP PCIe controller is capable of handling errors
on root port and perform port reset separately at each root port.

This patch add error handling driver for HIP PCIe controller to log
and report recoverable errors. Perform root port reset and restore
link status after the recovery.

Following are some of the PCIe controller's recoverable errors
1. completion transmission timeout error.
2. CRS retry counter over the threshold error.
3. ECC 2 bit errors
4. AXI bresponse/rresponse errors etc.

The driver placed in the drivers/pci/controller/ because the
HIP PCIe controller does not use DWC ip.

Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
--
drivers/pci/controller/Kconfig           |   8 +
drivers/pci/controller/Makefile          |   1 +
drivers/pci/controller/pcie-hisi-error.c | 336 +++++++++++++++++++++++++++++++
3 files changed, 345 insertions(+)
create mode 100644 drivers/pci/controller/pcie-hisi-error.c
---
 drivers/pci/controller/Kconfig           |   8 +
 drivers/pci/controller/Makefile          |   1 +
 drivers/pci/controller/pcie-hisi-error.c | 321 +++++++++++++++++++++++
 3 files changed, 330 insertions(+)
 create mode 100644 drivers/pci/controller/pcie-hisi-error.c

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 91bfdb784829..7ba4b94f8604 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -258,6 +258,14 @@ config PCI_HYPERV_INTERFACE
 	  The Hyper-V PCI Interface is a helper driver allows other drivers to
 	  have a common interface with the Hyper-V PCI frontend driver.
 
+config PCIE_HISI_ERR
+	depends on ARM64 || COMPILE_TEST
+	depends on ACPI
+	bool "HiSilicon HIP PCIe controller error handling driver"
+	help
+	  Say Y here if you want error handling support
+	  for the PCIe controller's errors on HiSilicon HIP SoCs
+
 source "drivers/pci/controller/dwc/Kconfig"
 source "drivers/pci/controller/mobiveil/Kconfig"
 source "drivers/pci/controller/cadence/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index 158c59771824..ab3a528bf988 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
 obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
 obj-$(CONFIG_VMD) += vmd.o
 obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
+obj-$(CONFIG_PCIE_HISI_ERR) += pcie-hisi-error.o
 # pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
 obj-y				+= dwc/
 obj-y				+= mobiveil/
diff --git a/drivers/pci/controller/pcie-hisi-error.c b/drivers/pci/controller/pcie-hisi-error.c
new file mode 100644
index 000000000000..7886df01fd8a
--- /dev/null
+++ b/drivers/pci/controller/pcie-hisi-error.c
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for handling the PCIe controller errors on
+ * HiSilicon HIP SoCs.
+ *
+ * Copyright (c) 2018-2019 HiSilicon Limited.
+ */
+
+#include <linux/acpi.h>
+#include <acpi/ghes.h>
+#include <linux/delay.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/kfifo.h>
+#include <linux/spinlock.h>
+
+#define	HISI_PCIE_ERR_INFO_SIZE	1024
+
+/* HISI PCIe controller error definitions */
+#define HISI_PCIE_ERR_MISC_REGS	33
+
+#define HISI_PCIE_SUB_MODULE_ID_AP	0
+#define HISI_PCIE_SUB_MODULE_ID_TL	1
+#define HISI_PCIE_SUB_MODULE_ID_MAC	2
+#define HISI_PCIE_SUB_MODULE_ID_DL	3
+#define HISI_PCIE_SUB_MODULE_ID_SDI	4
+
+#define HISI_PCIE_LOCAL_VALID_VERSION		BIT(0)
+#define HISI_PCIE_LOCAL_VALID_SOC_ID		BIT(1)
+#define HISI_PCIE_LOCAL_VALID_SOCKET_ID		BIT(2)
+#define HISI_PCIE_LOCAL_VALID_NIMBUS_ID		BIT(3)
+#define HISI_PCIE_LOCAL_VALID_SUB_MODULE_ID	BIT(4)
+#define HISI_PCIE_LOCAL_VALID_CORE_ID		BIT(5)
+#define HISI_PCIE_LOCAL_VALID_PORT_ID		BIT(6)
+#define HISI_PCIE_LOCAL_VALID_ERR_TYPE		BIT(7)
+#define HISI_PCIE_LOCAL_VALID_ERR_SEVERITY	BIT(8)
+#define HISI_PCIE_LOCAL_VALID_ERR_MISC		9
+
+#define HISI_ERR_SEV_RECOVERABLE	0
+#define HISI_ERR_SEV_FATAL		1
+#define HISI_ERR_SEV_CORRECTED		2
+#define HISI_ERR_SEV_NONE		3
+
+static guid_t hisi_pcie_sec_type = GUID_INIT(0xB2889FC9, 0xE7D7, 0x4F9D,
+			0xA8, 0x67, 0xAF, 0x42, 0xE9, 0x8B, 0xE7, 0x72);
+
+#define HISI_PCIE_CORE_ID(v)             ((v) >> 3)
+#define HISI_PCIE_PORT_ID(core, v)       (((v) >> 1) + ((core) << 3))
+#define HISI_PCIE_CORE_PORT_ID(v)        (((v) % 8) << 1)
+
+struct hisi_pcie_error_data {
+	u64	val_bits;
+	u8	version;
+	u8	soc_id;
+	u8	socket_id;
+	u8	nimbus_id;
+	u8	sub_module_id;
+	u8	core_id;
+	u8	port_id;
+	u8	err_severity;
+	u16	err_type;
+	u8	reserv[2];
+	u32	err_misc[HISI_PCIE_ERR_MISC_REGS];
+};
+
+struct hisi_pcie_error_private {
+	struct notifier_block	nb;
+	struct platform_device	*pdev;
+};
+
+static char *hisi_pcie_sub_module_name(u8 id)
+{
+	switch (id) {
+	case HISI_PCIE_SUB_MODULE_ID_AP: return "AP Layer";
+	case HISI_PCIE_SUB_MODULE_ID_TL: return "TL Layer";
+	case HISI_PCIE_SUB_MODULE_ID_MAC: return "MAC Layer";
+	case HISI_PCIE_SUB_MODULE_ID_DL: return "DL Layer";
+	case HISI_PCIE_SUB_MODULE_ID_SDI: return "SDI Layer";
+	}
+
+	return "unknown";
+}
+
+static char *hisi_pcie_error_severity(u8 err_sev)
+{
+	switch (err_sev) {
+	case HISI_ERR_SEV_RECOVERABLE: return "recoverable";
+	case HISI_ERR_SEV_FATAL: return "fatal";
+	case HISI_ERR_SEV_CORRECTED: return "corrected";
+	case HISI_ERR_SEV_NONE: return "none";
+	}
+
+	return "unknown";
+}
+
+static int hisi_pcie_port_reset(struct platform_device *pdev,
+				u32 chip_id, u32 port_id)
+{
+	struct device *dev = &pdev->dev;
+	acpi_handle handle = ACPI_HANDLE(dev);
+	union acpi_object arg[3];
+	struct acpi_object_list arg_list;
+	acpi_status s;
+	unsigned long long data = 0;
+
+	arg[0].type = ACPI_TYPE_INTEGER;
+	arg[0].integer.value = chip_id;
+	arg[1].type = ACPI_TYPE_INTEGER;
+	arg[1].integer.value = HISI_PCIE_CORE_ID(port_id);
+	arg[2].type = ACPI_TYPE_INTEGER;
+	arg[2].integer.value = HISI_PCIE_CORE_PORT_ID(port_id);
+
+	arg_list.count = 3;
+	arg_list.pointer = arg;
+
+	s = acpi_evaluate_integer(handle, "RST", &arg_list, &data);
+	if (ACPI_FAILURE(s)) {
+		dev_err(dev, "No RST method\n");
+		return -EIO;
+	}
+
+	if (data) {
+		dev_err(dev, "Failed to Reset\n");
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int hisi_pcie_port_do_recovery(struct platform_device *dev,
+				      u32 chip_id, u32 port_id)
+{
+	acpi_status s;
+	struct device *device = &dev->dev;
+	acpi_handle root_handle = ACPI_HANDLE(device);
+	struct acpi_pci_root *pci_root;
+	struct pci_bus *root_bus;
+	struct pci_dev *pdev;
+	u32 domain, busnr, devfn;
+
+	s = acpi_get_parent(root_handle, &root_handle);
+	if (ACPI_FAILURE(s))
+		return -ENODEV;
+	pci_root = acpi_pci_find_root(root_handle);
+	if (!pci_root)
+		return -ENODEV;
+	root_bus = pci_root->bus;
+	domain = pci_root->segment;
+
+	busnr = root_bus->number;
+	devfn = PCI_DEVFN(port_id, 0);
+	pdev = pci_get_domain_bus_and_slot(domain, busnr, devfn);
+	if (!pdev) {
+		dev_info(device, "Fail to get root port %04x:%02x:%02x.%d device\n",
+			 domain, busnr, PCI_SLOT(devfn), PCI_FUNC(devfn));
+		return -ENODEV;
+	}
+
+	pci_stop_and_remove_bus_device_locked(pdev);
+	pci_dev_put(pdev);
+
+	if (hisi_pcie_port_reset(dev, chip_id, port_id))
+		return -EIO;
+
+	/*
+	 * The initialization time of subordinate devices after
+	 * hot reset is no more than 1s, which is required by
+	 * the PCI spec v5.0 sec 6.6.1. The time will shorten
+	 * if Readiness Notifications mechanisms are used. But
+	 * wait 1s here to adapt any conditions.
+	 */
+	ssleep(1UL);
+
+	/* add root port and downstream devices */
+	pci_lock_rescan_remove();
+	pci_rescan_bus(root_bus);
+	pci_unlock_rescan_remove();
+
+	return 0;
+}
+
+static void hisi_pcie_handle_error(const struct hisi_pcie_error_data *error,
+				   struct platform_device *pdev)
+{
+	char buf[HISI_PCIE_ERR_INFO_SIZE];
+	char *p = buf, *end = buf + sizeof(buf);
+	struct device *dev = &pdev->dev;
+	u32 i;
+	int rc;
+
+	if (error->val_bits == 0) {
+		dev_warn(dev, "%s: no valid error information\n", __func__);
+		return;
+	}
+
+	/* Logging */
+	p += snprintf(p, end - p, "[ Table version=%d ", error->version);
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_SOC_ID)
+		p += snprintf(p, end - p, "SOC ID=%d ", error->soc_id);
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_SOCKET_ID)
+		p += snprintf(p, end - p, "socket ID=%d ", error->socket_id);
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_NIMBUS_ID)
+		p += snprintf(p, end - p, "nimbus ID=%d ", error->nimbus_id);
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_SUB_MODULE_ID)
+		p += snprintf(p, end - p, "sub module=%s ",
+			      hisi_pcie_sub_module_name(error->sub_module_id));
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_CORE_ID)
+		p += snprintf(p, end - p, "core ID=core%d ", error->core_id);
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_PORT_ID)
+		p += snprintf(p, end - p, "port ID=port%d ", error->port_id);
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_ERR_SEVERITY)
+		p += snprintf(p, end - p, "error severity=%s ",
+			      hisi_pcie_error_severity(error->err_severity));
+
+	if (error->val_bits & HISI_PCIE_LOCAL_VALID_ERR_TYPE)
+		p += snprintf(p, end - p, "error type=0x%x ", error->err_type);
+
+	p += snprintf(p, end - p, "]\n");
+	dev_info(dev, "\nHISI : HIP : PCIe controller error\n");
+	dev_info(dev, "%s\n", buf);
+
+	dev_info(dev, "Reg Dump:\n");
+	for (i = 0; i < HISI_PCIE_ERR_MISC_REGS; i++) {
+		if (error->val_bits &
+				BIT_ULL(HISI_PCIE_LOCAL_VALID_ERR_MISC + i))
+			dev_info(dev,
+				 "ERR_MISC_%d=0x%x\n", i, error->err_misc[i]);
+	}
+
+	/* Recovery for the PCIe controller errors */
+	if (error->err_severity == HISI_ERR_SEV_RECOVERABLE) {
+		/* try reset PCI port for the error recovery */
+		rc = hisi_pcie_port_do_recovery(pdev, error->socket_id,
+			HISI_PCIE_PORT_ID(error->core_id, error->port_id));
+		if (rc) {
+			dev_info(dev, "fail to do hisi pcie port reset\n");
+			return;
+		}
+	}
+}
+
+static int hisi_pcie_notify_error(struct notifier_block *nb,
+				  unsigned long event, void *data)
+{
+	struct acpi_hest_generic_data *gdata = data;
+	const struct hisi_pcie_error_data *error_data =
+				acpi_hest_get_payload(gdata);
+	struct hisi_pcie_error_private *priv =
+			container_of(nb, struct hisi_pcie_error_private, nb);
+	struct platform_device *pdev = priv->pdev;
+	struct device *dev = &pdev->dev;
+	u8 socket;
+
+	if (device_property_read_u8(dev, "socket", &socket))
+		return NOTIFY_DONE;
+
+	if (!guid_equal((guid_t *)gdata->section_type, &hisi_pcie_sec_type) ||
+	    error_data->socket_id != socket)
+		return NOTIFY_DONE;
+
+	hisi_pcie_handle_error(error_data, pdev);
+
+	return NOTIFY_OK;
+}
+
+static int hisi_pcie_error_handler_probe(struct platform_device *pdev)
+{
+	struct hisi_pcie_error_private *priv;
+	int ret;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->nb.notifier_call = hisi_pcie_notify_error;
+	priv->pdev = pdev;
+	ret = ghes_register_event_notifier(&priv->nb);
+	if (ret) {
+		dev_err(&pdev->dev, "%s : ghes_register_event_notifier fail\n",
+			__func__);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, priv);
+
+	return 0;
+}
+
+static int hisi_pcie_error_handler_remove(struct platform_device *pdev)
+{
+	struct hisi_pcie_error_private *priv = platform_get_drvdata(pdev);
+
+	ghes_unregister_event_notifier(&priv->nb);
+	kfree(priv);
+
+	return 0;
+}
+
+static const struct acpi_device_id hisi_pcie_acpi_match[] = {
+	{ "HISI0361", 0 },
+	{ }
+};
+
+static struct platform_driver hisi_pcie_error_handler_driver = {
+	.driver = {
+		.name	= "hisi-pcie-error-handler",
+		.acpi_match_table = hisi_pcie_acpi_match,
+	},
+	.probe		= hisi_pcie_error_handler_probe,
+	.remove		= hisi_pcie_error_handler_remove,
+};
+module_platform_driver(hisi_pcie_error_handler_driver);
+
+MODULE_DESCRIPTION("HiSilicon HIP PCIe controller error handling driver");
+MODULE_LICENSE("GPL v2");
-- 
2.17.1



^ permalink raw reply related
* Re: [PATCH] mwifiex: Parse all API_VER_ID properties
From: Kalle Valo @ 2020-05-29 17:41 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Amitkumar Karwar, Ganapathi Bhat, Xinming Hu, David S. Miller,
	Marek Behún, linux-wireless, netdev, linux-kernel
In-Reply-To: <20200521123444.28957-1-pali@kernel.org>

Pali Rohár <pali@kernel.org> wrote:

> During initialization of SD8997 wifi chip kernel prints warnings:
> 
>   mwifiex_sdio mmc0:0001:1: Unknown api_id: 3
>   mwifiex_sdio mmc0:0001:1: Unknown api_id: 4
> 
> This patch adds support for parsing all api ids provided by SD8997
> firmware.
> 
> Signed-off-by: Pali Rohár <pali@kernel.org>
> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>

Patch applied to wireless-drivers-next.git, thanks.

86cffb2c0a59 mwifiex: Parse all API_VER_ID properties

-- 
https://patchwork.kernel.org/patch/11562833/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply
* (no subject)
From: John Paul Adrian Glaubitz @ 2020-05-29 17:34 UTC (permalink / raw)
  To: linux-sh
  Cc: Rich Felker, Yoshinori Sato, Geert Uytterhoeven, Michael Karcher,
	linux-kernel


Hi!

This is my attempt of implementing a 64-bit get_user() for SH to address the
build problem when CONFIG_INFINIBAND_USER_ACCESS is enabled.

I have carefully looked at the existing implementations of __get_user_asm(),
__put_user_asm() and the 64-bit __put_user_u64() to come up with the 64-bit
__get_user_u64().

I'm admittedly not an expert when it comes to writing GCC contraints, so the
code might be completely wrong. However, it builds fine without warnings
and fixes the aforementioned issue for me.

Hopefully someone from the more experienced group of kernel developers can
review my code and help me get it into proper shape for submission.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply
* [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
From: John Paul Adrian Glaubitz @ 2020-05-29 17:34 UTC (permalink / raw)
  To: linux-sh
  Cc: Rich Felker, Yoshinori Sato, Geert Uytterhoeven, Michael Karcher,
	linux-kernel, John Paul Adrian Glaubitz
In-Reply-To: <20200529173419.4185337-1-glaubitz@physik.fu-berlin.de>

Trying to build the kernel with CONFIG_INFINIBAND_USER_ACCESS enabled fails

     ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko] undefined!

with on SH since the kernel misses a 64-bit implementation of get_user().

Implement the missing 64-bit get_user() as __get_user_u64(), matching the
already existing __put_user_u64() which implements the 64-bit put_user().

Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
---
 arch/sh/include/asm/uaccess_32.h | 49 ++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
index 624cf55acc27..8bc1cb50f8bf 100644
--- a/arch/sh/include/asm/uaccess_32.h
+++ b/arch/sh/include/asm/uaccess_32.h
@@ -26,6 +26,9 @@ do {								\
 	case 4:							\
 		__get_user_asm(x, ptr, retval, "l");		\
 		break;						\
+	case 8:							\
+		__get_user_u64(x, ptr, retval);			\
+		break;						\
 	default:						\
 		__get_user_unknown();				\
 		break;						\
@@ -66,6 +69,52 @@ do {							\
 
 extern void __get_user_unknown(void);
 
+#if defined(CONFIG_CPU_LITTLE_ENDIAN)
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+	"1:\n\t" \
+	"mov.l	%2,%R1\n\t" \
+	"mov.l	%T2,%S1\n\t" \
+	"2:\n" \
+	".section	.fixup,\"ax\"\n" \
+	"3:\n\t" \
+	"mov	#0, %1\n\t" \
+	"mov.l	4f, %0\n\t" \
+	"jmp	@%0\n\t" \
+	" mov	%3, %0\n\t" \
+	".balign	4\n" \
+	"4:	.long	2b\n\t" \
+	".previous\n" \
+	".section	__ex_table,\"a\"\n\t" \
+	".long	1b, 3b\n\t" \
+	".previous" \
+	:"=&r" (err), "=&r" (x) \
+	:"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#else
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+	"1:\n\t" \
+	"mov.l	%2,%S1\n\t" \
+	"mov.l	%T2,%R1\n\t" \
+	"2:\n" \
+	".section	.fixup,\"ax\"\n" \
+	"3:\n\t" \
+	"mov	#0, %1\n\t" \
+	"mov.l	4f, %0\n\t" \
+	"jmp	@%0\n\t" \
+	" mov	%3, %0\n\t" \
+	".balign	4\n" \
+	"4:	.long	2b\n\t" \
+	".previous\n" \
+	".section	__ex_table,\"a\"\n\t" \
+	".long	1b, 3b\n\t" \
+	".previous" \
+	:"=&r" (err), "=&r" (x) \
+	:"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#endif
+
 #define __put_user_size(x,ptr,size,retval)		\
 do {							\
 	retval = 0;					\
-- 
2.27.0.rc2


^ permalink raw reply related
* [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
From: Patrick Williams @ 2020-05-29 17:42 UTC (permalink / raw)
  To: linux-aspeed
In-Reply-To: <49485085-7cc7-9e29-a719-98d1e184378b@roeck-us.net>

Hi Guenter,

Thanks for the initial look at this.

One question for you below...

On Fri, May 29, 2020 at 10:30:16AM -0700, Guenter Roeck wrote:
> On 5/29/20 5:46 AM, Manikandan Elumalai wrote:
> > +		/* Enable TEMP1 by default */
> > +		config |= ADM1278_TEMP1_EN;
> > +		ret = i2c_smbus_write_byte_data(client,
> > +					ADM1275_PMON_CONFIG,
> > +					config);
> > +		if (ret < 0) {
> > +		dev_err(&client->dev,
> > +			"Failed to enable temperature config\n");
> > +		return -ENODEV;
> > +		}
> 
> This can be handled in a single operation, together with ADM1278_VOUT_EN
> below. There is no need for two separate write operations.

I don't know if you noticed here but the change ends up enabling
TEMP1_EN in all cases.  Is this acceptable?  If not, do you have any
preference on how it is selected for enablement?

> >  		/* Enable VOUT if not enabled (it is disabled by default) */
> >  		if (!(config & ADM1278_VOUT_EN)) {
> > @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
> >  			}
> >  		}
> >  
> > -		if (config & ADM1278_TEMP1_EN)
> > -			info->func[0] |=
> > -				PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> >  		if (config & ADM1278_VIN_EN)
> >  			info->func[0] |= PMBUS_HAVE_VIN;
> >  		break;
> > 
> 

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20200529/9450a289/attachment-0001.sig>

^ permalink raw reply
* Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
From: Patrick Williams @ 2020-05-29 17:42 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Manikandan Elumalai, linux-hwmon, linux-aspeed, linux-kernel,
	openbmc, manikandan.e, saipsdasari, patrickw3, vijaykhemka
In-Reply-To: <49485085-7cc7-9e29-a719-98d1e184378b@roeck-us.net>

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

Hi Guenter,

Thanks for the initial look at this.

One question for you below...

On Fri, May 29, 2020 at 10:30:16AM -0700, Guenter Roeck wrote:
> On 5/29/20 5:46 AM, Manikandan Elumalai wrote:
> > +		/* Enable TEMP1 by default */
> > +		config |= ADM1278_TEMP1_EN;
> > +		ret = i2c_smbus_write_byte_data(client,
> > +					ADM1275_PMON_CONFIG,
> > +					config);
> > +		if (ret < 0) {
> > +		dev_err(&client->dev,
> > +			"Failed to enable temperature config\n");
> > +		return -ENODEV;
> > +		}
> 
> This can be handled in a single operation, together with ADM1278_VOUT_EN
> below. There is no need for two separate write operations.

I don't know if you noticed here but the change ends up enabling
TEMP1_EN in all cases.  Is this acceptable?  If not, do you have any
preference on how it is selected for enablement?

> >  		/* Enable VOUT if not enabled (it is disabled by default) */
> >  		if (!(config & ADM1278_VOUT_EN)) {
> > @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
> >  			}
> >  		}
> >  
> > -		if (config & ADM1278_TEMP1_EN)
> > -			info->func[0] |=
> > -				PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> >  		if (config & ADM1278_VIN_EN)
> >  			info->func[0] |= PMBUS_HAVE_VIN;
> >  		break;
> > 
> 

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev5)
From: Patchwork @ 2020-05-29 17:42 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20200529085809.23691-1-chris@chris-wilson.co.uk>

== Series Details ==

Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev5)
URL   : https://patchwork.freedesktop.org/series/77781/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8553_full -> Patchwork_17819_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_17819_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17819_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_17819_full:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_lease@page_flip_implicit_plane:
    - shard-skl:          [PASS][1] -> [TIMEOUT][2] +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_lease@page_flip_implicit_plane.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@kms_lease@page_flip_implicit_plane.html

  
#### Warnings ####

  * igt@i915_pm_dc@dc6-dpms:
    - shard-skl:          [FAIL][3] ([i915#454]) -> [TIMEOUT][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@i915_pm_dc@dc6-dpms.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
    - shard-skl:          [SKIP][5] ([fdo#109271]) -> [TIMEOUT][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt.html

  
Known issues
------------

  Here are the changes found in Patchwork_17819_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gen9_exec_parse@allowed-all:
    - shard-apl:          [PASS][7] -> [DMESG-WARN][8] ([i915#1436] / [i915#716])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl1/igt@gen9_exec_parse@allowed-all.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl1/igt@gen9_exec_parse@allowed-all.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-random:
    - shard-kbl:          [PASS][9] -> [FAIL][10] ([i915#54] / [i915#93] / [i915#95])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-64x64-random.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-64x64-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-apl:          [PASS][11] -> [DMESG-WARN][12] ([i915#180])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl8/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-glk:          [PASS][13] -> [FAIL][14] ([i915#1121] / [i915#118] / [i915#95])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-glk9/igt@kms_fbcon_fbt@fbc-suspend.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-glk5/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt:
    - shard-skl:          [PASS][15] -> [TIMEOUT][16] ([i915#123])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt.html

  * igt@kms_hdr@bpc-switch-dpms:
    - shard-skl:          [PASS][17] -> [FAIL][18] ([i915#1188])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl5/igt@kms_hdr@bpc-switch-dpms.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-kbl:          [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-iclb6/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109441])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-iclb6/igt@kms_psr@psr2_cursor_render.html

  
#### Possible fixes ####

  * {igt@gem_exec_reloc@basic-concurrent0}:
    - shard-glk:          [FAIL][25] ([i915#1930]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-glk4/igt@gem_exec_reloc@basic-concurrent0.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-glk2/igt@gem_exec_reloc@basic-concurrent0.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-kbl:          [DMESG-WARN][27] ([i915#180]) -> [PASS][28] +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@i915_suspend@fence-restore-untiled.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl7/igt@i915_suspend@fence-restore-untiled.html

  * {igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c}:
    - shard-kbl:          [DMESG-WARN][29] ([i915#165] / [i915#180]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl2/igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl6/igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [SKIP][31] ([fdo#109349]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb8/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  * igt@kms_fbcon_fbt@psr-suspend:
    - shard-iclb:         [INCOMPLETE][33] ([i915#1185]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb3/igt@kms_fbcon_fbt@psr-suspend.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-iclb1/igt@kms_fbcon_fbt@psr-suspend.html

  * {igt@kms_flip@flip-vs-expired-vblank@b-edp1}:
    - shard-skl:          [FAIL][35] ([i915#79]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl8/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html

  * igt@kms_hdr@bpc-switch:
    - shard-skl:          [FAIL][37] ([i915#1188]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl8/igt@kms_hdr@bpc-switch.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl5/igt@kms_hdr@bpc-switch.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
    - shard-skl:          [FAIL][39] ([fdo#108145] / [i915#265]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl10/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [SKIP][41] ([fdo#109441]) -> [PASS][42] +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
    - shard-apl:          [DMESG-WARN][43] ([i915#180]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl4/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl7/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
    - shard-kbl:          [INCOMPLETE][45] ([i915#155]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl3/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl7/igt@kms_vblank@pipe-b-ts-continuation-suspend.html

  * igt@perf@mi-rpc:
    - shard-hsw:          [INCOMPLETE][47] ([i915#61]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw5/igt@perf@mi-rpc.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-hsw2/igt@perf@mi-rpc.html

  * {igt@perf@polling-parameterized}:
    - shard-hsw:          [FAIL][49] ([i915#1542]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw6/igt@perf@polling-parameterized.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-hsw7/igt@perf@polling-parameterized.html

  
#### Warnings ####

  * igt@i915_pm_dc@dc3co-vpb-simulation:
    - shard-iclb:         [SKIP][51] ([i915#658]) -> [SKIP][52] ([i915#588])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb1/igt@i915_pm_dc@dc3co-vpb-simulation.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-tglb:         [FAIL][53] ([i915#454]) -> [SKIP][54] ([i915#468])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-tglb3/igt@i915_pm_dc@dc6-dpms.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-tglb2/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_content_protection@atomic:
    - shard-apl:          [FAIL][55] ([fdo#110321] / [fdo#110336]) -> [TIMEOUT][56] ([i915#1319])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl6/igt@kms_content_protection@atomic.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl8/igt@kms_content_protection@atomic.html

  * igt@kms_content_protection@atomic-dpms:
    - shard-apl:          [TIMEOUT][57] ([i915#1319] / [i915#1635]) -> [FAIL][58] ([fdo#110321] / [fdo#110336])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl3/igt@kms_content_protection@atomic-dpms.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl1/igt@kms_content_protection@atomic-dpms.html

  * igt@kms_content_protection@lic:
    - shard-apl:          [TIMEOUT][59] ([i915#1319]) -> [TIMEOUT][60] ([i915#1319] / [i915#1635])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl7/igt@kms_content_protection@lic.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl4/igt@kms_content_protection@lic.html

  * igt@kms_content_protection@srm:
    - shard-apl:          [TIMEOUT][61] ([i915#1319] / [i915#1635]) -> [FAIL][62] ([fdo#110321])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl8/igt@kms_content_protection@srm.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl6/igt@kms_content_protection@srm.html

  * igt@kms_plane_lowres@pipe-b-tiling-yf:
    - shard-hsw:          [SKIP][63] ([fdo#109271] / [i915#1927]) -> [SKIP][64] ([fdo#109271])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw2/igt@kms_plane_lowres@pipe-b-tiling-yf.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-hsw4/igt@kms_plane_lowres@pipe-b-tiling-yf.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110321]: https://bugs.freedesktop.org/show_bug.cgi?id=110321
  [fdo#110336]: https://bugs.freedesktop.org/show_bug.cgi?id=110336
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [i915#1121]: https://gitlab.freedesktop.org/drm/intel/issues/1121
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1185]: https://gitlab.freedesktop.org/drm/intel/issues/1185
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#123]: https://gitlab.freedesktop.org/drm/intel/issues/123
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1927]: https://gitlab.freedesktop.org/drm/intel/issues/1927
  [i915#1930]: https://gitlab.freedesktop.org/drm/intel/issues/1930
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#588]: https://gitlab.freedesktop.org/drm/intel/issues/588
  [i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
  [i915#93]: https://gitlab.freedesktop.org/drm/intel/issues/93
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * Linux: CI_DRM_8553 -> Patchwork_17819

  CI-20190529: 20190529
  CI_DRM_8553: 9f1b8b4fcb466dc714b1f825fd93e3bbd29c7de6 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17819: 2192b036ccb7f6662671f183f6f643094daeb84b @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply
* Re: [PATCH] mwifiex: Add support for NL80211_ATTR_MAX_AP_ASSOC_STA
From: Kalle Valo @ 2020-05-29 17:42 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Amitkumar Karwar, Ganapathi Bhat, Xinming Hu, David S. Miller,
	Marek Behún, linux-wireless, netdev, linux-kernel
In-Reply-To: <20200521123559.29028-1-pali@kernel.org>

Pali Rohár <pali@kernel.org> wrote:

> SD8997 firmware sends TLV_TYPE_MAX_CONN with struct hw_spec_max_conn to
> inform kernel about maximum number of p2p connections and stations in AP
> mode.
> 
> During initialization of SD8997 wifi chip kernel prints warning:
> 
>   mwifiex_sdio mmc0:0001:1: Unknown GET_HW_SPEC TLV type: 0x217
> 
> This patch adds support for parsing TLV_TYPE_MAX_CONN (0x217) and sets
> appropriate cfg80211 member 'max_ap_assoc_sta' from retrieved structure.
> 
> It allows userspace to retrieve NL80211_ATTR_MAX_AP_ASSOC_STA attribute.
> 
> Signed-off-by: Pali Rohár <pali@kernel.org>

Patch applied to wireless-drivers-next.git, thanks.

982d7287f8da mwifiex: Add support for NL80211_ATTR_MAX_AP_ASSOC_STA

-- 
https://patchwork.kernel.org/patch/11562835/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply
* Re: [PATCH for-next 1/1] null_blk: force complete for timeout request
From: Jens Axboe @ 2020-05-29 17:42 UTC (permalink / raw)
  To: Dongli Zhang, linux-block; +Cc: linux-kernel
In-Reply-To: <20200529173108.25198-1-dongli.zhang@oracle.com>

On 5/29/20 11:31 AM, Dongli Zhang wrote:
> The commit 7b11eab041da ("blk-mq: blk-mq: provide forced completion
> method") exports new API to force a request to complete without error
> injection.
> 
> There should be no error injection when completing a request by timeout
> handler.
> 
> Otherwise, the below would hang because timeout handler is failed.
> 
> echo 100 > /sys/kernel/debug/fail_io_timeout/probability
> echo 1000 > /sys/kernel/debug/fail_io_timeout/times
> echo 1 > /sys/block/nullb0/io-timeout-fail
> dd if=/dev/zero of=/dev/nullb0 bs=512 count=1 oflag=direct
> 
> With this patch, the timeout handler is able to complete the IO.

Applied, thanks.

-- 
Jens Axboe


^ permalink raw reply
* Re: pull request: mt76 2019-05-22
From: Kalle Valo @ 2020-05-29 17:42 UTC (permalink / raw)
  To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <d0de94c9-f367-0f57-950b-c76e1808bdcb@nbd.name>

Felix Fietkau <nbd@nbd.name> wrote:

> Hi Kalle,
> 
> here's another pull request for 5.8, replacing the previous one.
> 
> - Felix
> 
> The following changes since commit 50ce4c099bebf56be86c9448f7f4bcd34f33663c:
> 
>   sctp: fix typo sctp_ulpevent_nofity_peer_addr_change (2020-05-27 15:08:02 -0700)
> 
> are available in the Git repository at:
> 
>   https://github.com/nbd168/wireless tags/mt76-for-kvalo-2020-05-28
> 
> for you to fetch changes up to d9045b18cd445e0d0a53903ffd5d79793d9df59e:
> 
>   mt76: mt7915: remove set but not used variable 'msta' (2020-05-28 17:57:25 +0200)
> 
> ----------------------------------------------------------------
> mt76 patches for 5.8
> 
> * fixes for sparse warnings
> * DBDC fixes
> * mt7663 remain-on-channel support
> * mt7915 spatial reuse support
> * mt7915 radiotap fix
> * station wcid allocation fix
> * mt7663 powersave fix
> * mt7663 scan fix
> * mt7611n support
> * cleanup
> 
> ----------------------------------------------------------------
> Colin Ian King (1):
>       mt76: mt7915: fix a handful of spelling mistakes
> 
> DENG Qingfang (1):
>       mt76: mt7615: add support for MT7611N
> 
> Felix Fietkau (3):
>       mt76: fix per-driver wcid range checks after wcid array size bump
>       mt76: fix wcid allocation issues
>       mt76: only iterate over initialized rx queues
> 
> Lorenzo Bianconi (5):
>       mt76: mt7615: introduce remain_on_channel support
>       mt76: mt76x02: remove check in mt76x02_mcu_msg_send
>       mt76: mt7615: fix NULL pointer deref in mt7615_register_ext_phy
>       mt76: mt7615: switch to per-vif power_save support
>       mt76: mt7915: fix possible NULL pointer dereference in mt7915_register_ext_phy
> 
> Ryder Lee (5):
>       mt76: mt7915: add spatial reuse support
>       mt76: mt7915: fix some sparse warnings
>       mt76: mt7915: fix sparse warnings: incorrect type initializer
>       mt76: mt7915: fix decoded radiotap HE flags
>       mt76: mt7915: fix some sparse warnings
> 
> Sean Wang (1):
>       mt76: mt7615: fix hw_scan with ssid_type for specified SSID only
> 
> YueHaibing (2):
>       mt76: mt7615: Use kmemdup in mt7615_queue_key_update()
>       mt76: mt7915: remove set but not used variable 'msta'
> 
>  drivers/net/wireless/mediatek/mt76/debugfs.c        |   2 +-
>  drivers/net/wireless/mediatek/mt76/dma.c            |   4 +--
>  drivers/net/wireless/mediatek/mt76/mt76.h           |  10 +++++---
>  drivers/net/wireless/mediatek/mt76/mt7603/mac.c     |   7 ++---
>  drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c  |   7 +++++
>  drivers/net/wireless/mediatek/mt76/mt7615/init.c    |  22 +++++++++++-----
>  drivers/net/wireless/mediatek/mt76/mt7615/mac.c     |  17 +++++++++----
>  drivers/net/wireless/mediatek/mt76/mt7615/main.c    | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------
>  drivers/net/wireless/mediatek/mt76/mt7615/mcu.c     |  66 +++++++++++++++++++++++++++++++++++++++++++-----
>  drivers/net/wireless/mediatek/mt76/mt7615/mcu.h     |  25 ++++++++++++++++--
>  drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h  |  19 +++++++++++---
>  drivers/net/wireless/mediatek/mt76/mt7615/pci.c     |   9 ++++---
>  drivers/net/wireless/mediatek/mt76/mt7615/usb.c     |   3 ++-
>  drivers/net/wireless/mediatek/mt76/mt76x02.h        |   3 ++-
>  drivers/net/wireless/mediatek/mt76/mt76x02_mac.c    |   2 +-
>  drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c    |   2 +-
>  drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c   |   5 ++--
>  drivers/net/wireless/mediatek/mt76/mt76x02_util.c   |   2 +-
>  drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c |   6 ++---
>  drivers/net/wireless/mediatek/mt76/mt7915/init.c    |   3 ++-
>  drivers/net/wireless/mediatek/mt76/mt7915/mac.c     |  58 +++++++++++++++++++++++-------------------
>  drivers/net/wireless/mediatek/mt76/mt7915/main.c    |   9 +++++--
>  drivers/net/wireless/mediatek/mt76/mt7915/mcu.c     |  41 ++++++++++++++++++++++--------
>  drivers/net/wireless/mediatek/mt76/mt7915/mcu.h     |   1 +
>  drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h  |   2 ++
>  drivers/net/wireless/mediatek/mt76/util.c           |  12 ++++-----
>  drivers/net/wireless/mediatek/mt76/util.h           |  14 +++++-----
>  27 files changed, 335 insertions(+), 124 deletions(-)

Pulled, thanks.

5cf2740f1d45 Merge tag 'mt76-for-kvalo-2020-05-28' of https://github.com/nbd168/wireless

-- 
https://patchwork.kernel.org/patch/11576267/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply
* Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Andy Shevchenko @ 2020-05-29 17:43 UTC (permalink / raw)
  To: Serge Semin
  Cc: Mark Brown, Serge Semin, Ekaterina Skachko, Feng Tang, devicetree,
	Thomas Bogendoerfer, Georgy Vlasov, Pavel Parkhomenko,
	Alexey Kolotnikov, linux-spi, linux-kernel, Vadim Vlasov,
	Alexey Malahov, linux-mips, Rob Herring, Ramil Zaripov,
	Arnd Bergmann, Maxim Kaurkin
In-Reply-To: <20200529172642.hcnvyzv2ocizsvpy@mobilestation>

On Fri, May 29, 2020 at 08:26:42PM +0300, Serge Semin wrote:
> On Fri, May 29, 2020 at 06:18:32PM +0100, Mark Brown wrote:
> > On Fri, 29 May 2020 16:11:49 +0300, Serge Semin wrote:
> > > Baikal-T1 SoC provides a DW DMA controller to perform low-speed peripherals
> > > Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
> > > APB SSI devices embedded into the SoC. Currently the DMA-based transfers
> > > are supported by the DW APB SPI driver only as a middle layer code for
> > > Intel MID/Elkhart PCI devices. Seeing the same code can be used for normal
> > > platform DMAC device we introduced a set of patches to fix it within this
> > > series.

> As you can see it has been acked by Rob. So you can also merge it into your
> repo. Though It has to be rebased first due to the Dinh Nguyen patches
> recently merged in. Do you want me to do the rebasing?

I guess now you need to rebase it, because as I see the Dinh's patches are in
the tree as well as yours.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply
* Re: [PATCH 2/2] soc: samsung: Add simple voltage coupler for Exynos5800
From: Krzysztof Kozlowski @ 2020-05-29 17:43 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: linux-kernel, linux-pm, Mark Brown, Dmitry Osipenko,
	Liam Girdwood, Lucas Stach, Bartlomiej Zolnierkiewicz,
	Viresh Kumar, peron.clem, Nishanth Menon, Stephen Boyd,
	Vincent Guittot, Rafael Wysocki, linux-samsung-soc, Chanwoo Choi
In-Reply-To: <20200529124940.10675-3-m.szyprowski@samsung.com>

On Fri, May 29, 2020 at 02:49:40PM +0200, Marek Szyprowski wrote:
> Add custom voltage regulator coupler for Exynos5800 SoCs, which require
> coupling between "vdd_arm" and "vdd_int" regulators. This coupler ensures
> that coupled regulators voltage balancing is done only when clients for
> each regulator (cpufreq for "vdd_arm" and devfreq for "vdd_int") apply
> their constraints, so the voltage values don't go beyond the
> bootloader-selected operation point during the boot process. This also
> ensures proper voltage balancing if any of those drivers is missing.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  arch/arm/mach-exynos/Kconfig                  |  1 +
>  drivers/soc/samsung/Kconfig                   |  3 +
>  drivers/soc/samsung/Makefile                  |  1 +
>  .../soc/samsung/exynos-regulator-coupler.c    | 59 +++++++++++++++++++
>  4 files changed, 64 insertions(+)
>  create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 76838255b5fa..f185cd3d4c62 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -118,6 +118,7 @@ config SOC_EXYNOS5800
>  	bool "Samsung EXYNOS5800"
>  	default y
>  	depends on SOC_EXYNOS5420
> +	select EXYNOS_REGULATOR_COUPLER
>  
>  config EXYNOS_MCPM
>  	bool
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index c7a2003687c7..264185664594 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -37,4 +37,7 @@ config EXYNOS_PM_DOMAINS
>  	bool "Exynos PM domains" if COMPILE_TEST
>  	depends on PM_GENERIC_DOMAINS || COMPILE_TEST
>  
> +config EXYNOS_REGULATOR_COUPLER
> +	bool "Exynos SoC Regulator Coupler" if COMPILE_TEST
> +	depends on ARCH_EXYNOS || COMPILE_TEST
>  endif
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index edd1d6ea064d..ecc3a32f6406 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_EXYNOS_PMU)	+= exynos-pmu.o
>  obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS)	+= exynos3250-pmu.o exynos4-pmu.o \
>  					exynos5250-pmu.o exynos5420-pmu.o
>  obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_EXYNOS_REGULATOR_COUPLER) += exynos-regulator-coupler.o
> diff --git a/drivers/soc/samsung/exynos-regulator-coupler.c b/drivers/soc/samsung/exynos-regulator-coupler.c
> new file mode 100644
> index 000000000000..54445918bd75
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-regulator-coupler.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Samsung Electronics Co., Ltd.
> + *	      http://www.samsung.com/
> + * Author: Marek Szyprowski <m.szyprowski@samsung.com>
> + *
> + * Samsung Exynos SoC voltage coupler
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/regulator/coupler.h>
> +#include <linux/regulator/driver.h>
> +
> +static int exynos_coupler_balance_voltage(struct regulator_coupler *coupler,
> +					  struct regulator_dev *rdev,
> +					  suspend_state_t state)
> +{
> +	struct coupling_desc *c_desc = &rdev->coupling_desc;
> +	int ret, cons_uV = 0, cons_max_uV = INT_MAX;
> +	bool skip_coupled = false;
> +
> +	/* get coupled regulator constraints */
> +	ret = regulator_check_consumers(c_desc->coupled_rdevs[1], &cons_uV,
> +					&cons_max_uV, state);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* skip adjusting coupled regulator if it has no constraints set yet */
> +	if (cons_uV == 0)
> +		skip_coupled = true;
> +
> +	return regulator_do_balance_voltage(rdev, state, skip_coupled);
> +}
> +
> +static int exynos_coupler_attach(struct regulator_coupler *coupler,
> +				 struct regulator_dev *rdev)
> +{
> +	if (strcmp(rdev_get_name(rdev), "vdd_arm") == 0 ||
> +	    strcmp(rdev_get_name(rdev), "vdd_int") == 0)

Thanks for the patch!

You hard-coded specific names of regulators existing
only in DTS. They do not come from any driver nor bindings, therefore
they could change making driver unusable. Someone could add a new DTS
with different names and expect this to work as well.

You need bindings for this. Something like:
Documentation/devicetree/bindings/regulator/nvidia,tegra-regulators-coupling.txt
But better in YAML, if possible.

Best regards,
Krzysztof

^ permalink raw reply
* linusw/fixes boot: 56 boots: 1 failed, 55 passed (v5.7-rc6-9-ge9bdf7e655b9)
From: kernelci.org bot @ 2020-05-29 17:43 UTC (permalink / raw)
  To: linux-gpio, fellows

******************************************
* WARNING: Boot tests are now deprecated *
******************************************

As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated.  Boot results are scheduled to be dropped on
*5th June 2020*.  The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238

The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr

See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/linusw/branch/fixes/kernel/v5.7-rc6-9-ge9bdf7e655b9/plan/baseline/

-------------------------------------------------------------------------------

linusw/fixes boot: 56 boots: 1 failed, 55 passed (v5.7-rc6-9-ge9bdf7e655b9)

Full Boot Summary: https://kernelci.org/boot/all/job/linusw/branch/fixes/kernel/v5.7-rc6-9-ge9bdf7e655b9/
Full Build Summary: https://kernelci.org/build/linusw/branch/fixes/kernel/v5.7-rc6-9-ge9bdf7e655b9/

Tree: linusw
Branch: fixes
Git Describe: v5.7-rc6-9-ge9bdf7e655b9
Git Commit: e9bdf7e655b9ee81ee912fae1d59df48ce7311b6
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Tested: 49 unique boards, 14 SoC families, 2 builds out of 5

Boot Regressions Detected:

arm:

    multi_v7_defconfig:
        gcc-8:
          bcm2836-rpi-2-b:
              lab-collabora: failing since 108 days (last pass: gpio-v5.5-4 - first fail: v5.6-rc1-10-ga924eae75106)

Boot Failure Detected:

arm:
    multi_v7_defconfig:
        gcc-8:
            bcm2836-rpi-2-b: 1 failed lab

---
For more info write to <info@kernelci.org>

^ permalink raw reply
* Re: pull-request: iwlwifi-next 2020-05-29
From: Kalle Valo @ 2020-05-29 17:43 UTC (permalink / raw)
  To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <28366747f660fca49a5abef38b8be1cd93af005d.camel@coelho.fi>

Luca Coelho <luca@coelho.fi> wrote:

> Hi Kalle,
> 
> Here's the third batch of patches intended for v5.8.  This includes
> the last patchset I sent out.  Usual development work.  More details
> about the contents in the tag description.
> 
> Please let me know if there are any issues.
> 
> Cheers,
> Luca.
> 
> 
> The following changes since commit 50ce4c099bebf56be86c9448f7f4bcd34f33663c:
> 
>   sctp: fix typo sctp_ulpevent_nofity_peer_addr_change (2020-05-27 15:08:02 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2020-05-29
> 
> for you to fetch changes up to e6d4318c049574dcfa040725903add2790cfbd7b:
> 
>   iwlwifi: bump FW API to 56 for AX devices (2020-05-29 10:32:46 +0300)
> 
> ----------------------------------------------------------------
> Third set of iwlwifi patches intended for v5.8
> 
> * Update range request API;
> * Add ACPI DSM support;
> * Support enabling 5.2GHz bands in Indonesia via ACPI;
> * Bump FW API version to 56;
> * TX queues refactoring started;
> * Fix one memory leak;
> * Some other small fixes and clean-ups;
> 
> ----------------------------------------------------------------
> Avraham Stern (1):
>       iwlwifi: mvm: add support for range request version 10
> 
> Gil Adam (2):
>       iwlwifi: acpi: support device specific method (DSM)
>       iwlwifi: acpi: evaluate dsm to enable 5.2 bands in Indonesia
> 
> Haim Dreyfuss (2):
>       iwlwifi: set NO_HE if the regulatory domain forbids it
>       iwlwifi: pcie: don't count on the FW to set persistence mode
> 
> Johannes Berg (1):
>       iwlwifi: pcie: gen3: indicate 8k/12k RB size to device
> 
> Luca Coelho (1):
>       iwlwifi: bump FW API to 56 for AX devices
> 
> Mordechay Goodstein (3):
>       iwlwifi: pcie: keep trans instead of trans_pcie in iwl_txq
>       iwlwifi: move iwl_txq and substructures to a common trans header
>       iwlwifi: move txq-specific from trans_pcie to common trans
> 
> Sharon (1):
>       iwlwifi: mvm: fix aux station leak
> 
>  drivers/net/wireless/intel/iwlwifi/cfg/22000.c             |   2 +-
>  drivers/net/wireless/intel/iwlwifi/fw/acpi.c               |  99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
>  drivers/net/wireless/intel/iwlwifi/fw/acpi.h               |  22 ++++++++++++++++
>  drivers/net/wireless/intel/iwlwifi/fw/api/location.h       |  14 +++++-----
>  drivers/net/wireless/intel/iwlwifi/fw/api/nvm-reg.h        |  34 ++++++++++++++++++++++--
>  drivers/net/wireless/intel/iwlwifi/iwl-context-info-gen3.h |  12 +++++++--
>  drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c         |   5 ++++
>  drivers/net/wireless/intel/iwlwifi/iwl-trans.h             | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c     |  42 +++++++++++++++++++++++++++---
>  drivers/net/wireless/intel/iwlwifi/mvm/fw.c                |  43 ++++++++++++++++++++++++++++++
>  drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c          |   5 ++--
>  drivers/net/wireless/intel/iwlwifi/mvm/sta.c               |  18 +++++++++----
>  drivers/net/wireless/intel/iwlwifi/mvm/sta.h               |   6 ++---
>  drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c   |  10 ++++++-
>  drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c        |   6 ++---
>  drivers/net/wireless/intel/iwlwifi/pcie/internal.h         | 121 ++-----------------------------------------------------------------------------------
>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c               |   6 ++---
>  drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c       |  11 ++++----
>  drivers/net/wireless/intel/iwlwifi/pcie/trans.c            |  47 +++++++++++++--------------------
>  drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c          |  70 +++++++++++++++++++++++--------------------------
>  drivers/net/wireless/intel/iwlwifi/pcie/tx.c               | 120 ++++++++++++++++++++++++++++++++++++++++++------------------------------------------
>  21 files changed, 524 insertions(+), 297 deletions(-)

Pulled, thanks.

6bb986e940dc Merge tag 'iwlwifi-next-for-kalle-2020-05-29' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next

-- 
https://patchwork.kernel.org/patch/11577945/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply
* Re: [PATCH v8 3/8] PM / EM: update callback structure and add device pointer
From: Daniel Lezcano @ 2020-05-29 17:43 UTC (permalink / raw)
  To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
	linux-omap, linux-mediatek, linux-arm-msm, linux-imx
  Cc: Dietmar.Eggemann, cw00.choi, b.zolnierkie, rjw, sudeep.holla,
	viresh.kumar, nm, sboyd, rui.zhang, amit.kucheria, mingo, peterz,
	juri.lelli, vincent.guittot, rostedt, qperret, bsegall, mgorman,
	shawnguo, s.hauer, festevam, kernel, khilman, agross,
	bjorn.andersson, robh, matthias.bgg, steven.price, tomeu.vizoso,
	alyssa.rosenzweig, airlied, daniel, liviu.dudau,
	lorenzo.pieralisi, patrick.bellasi, orjan.eide, rdunlap, mka
In-Reply-To: <20200527095854.21714-4-lukasz.luba@arm.com>

On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
> 
> Update the related users to use new function and new callback from the
> Energy Model.
> 
> Acked-by: Quentin Perret <qperret@google.com>
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>

Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

[ ... ]


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

^ permalink raw reply
* Re: [PATCH v8 3/8] PM / EM: update callback structure and add device pointer
From: Daniel Lezcano @ 2020-05-29 17:43 UTC (permalink / raw)
  To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
	linux-omap, linux-mediatek, linux-arm-msm, linux-imx
  Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
	bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
	lorenzo.pieralisi, khilman, steven.price, cw00.choi, mingo,
	mgorman, rui.zhang, alyssa.rosenzweig, orjan.eide, daniel,
	b.zolnierkie, s.hauer, rostedt, matthias.bgg, Dietmar.Eggemann,
	airlied, tomeu.vizoso, qperret, sboyd, rdunlap, rjw, agross,
	kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <20200527095854.21714-4-lukasz.luba@arm.com>

On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
> 
> Update the related users to use new function and new callback from the
> Energy Model.
> 
> Acked-by: Quentin Perret <qperret@google.com>
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>

Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

[ ... ]


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: [PATCH v8 3/8] PM / EM: update callback structure and add device pointer
From: Daniel Lezcano @ 2020-05-29 17:43 UTC (permalink / raw)
  To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
	linux-omap, linux-mediatek, linux-arm-msm, linux-imx
  Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
	bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
	lorenzo.pieralisi, vincent.guittot, khilman, steven.price,
	cw00.choi, mingo, mgorman, rui.zhang, alyssa.rosenzweig,
	orjan.eide, daniel, b.zolnierkie, s.hauer, rostedt, matthias.bgg,
	Dietmar.Eggemann, airlied, tomeu.vizoso, qperret, sboyd, rdunlap,
	rjw, agross, kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <20200527095854.21714-4-lukasz.luba@arm.com>

On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
> 
> Update the related users to use new function and new callback from the
> Energy Model.
> 
> Acked-by: Quentin Perret <qperret@google.com>
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>

Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

[ ... ]


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.