linux-next: build failure after merge of the xarray tree
Hi all,
After merging the xarray tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: modpost: "xa_delete_node" [lib/test_xarray.ko] undefined!
Caused by commit
e95150e70fe1 ("XArray: Add private interface for workingset node deletion")
I have added the following hack for today:
From: Stephen Rothwell
Date: Thu, 8 Oct 2020 17:52:11 +1100
Subject: [PATCH] XArray: export xa_delete_node()
Signed-off-by: Stephen Rothwell
---
lib/xarray.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/xarray.c b/lib/xarray.c
index 3f0b143bfdcd..be9166b45db3 100644
--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -1993,6 +1993,7 @@ void xa_delete_node(struct xa_node *node,
xa_update_node_t update)
xas_store(&xas, NULL);
}
+EXPORT_SYMBOL(xa_delete_node);
/**
* xa_destroy() - Free all internal data structures.
--
2.28.0
--
Cheers,
Stephen Rothwell
pgpnHLsHoCQyZ.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 3/3] dt-bindings: touchscreen: Add binding for Novatek NT36xxx series driver
On Wed, 7 Oct 2020 at 20:22, wrote:
>
> From: AngeloGioacchino Del Regno
>
> Add binding for the Novatek NT36xxx series touchscreen driver.
>
> Signed-off-by: AngeloGioacchino Del Regno
> ---
> .../input/touchscreen/novatek,nt36xxx.yaml| 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
> b/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
> new file mode 100644
> index ..9f350f4e6d6a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/novatek,nt36xxx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Novatek NT36xxx series touchscreen controller Bindings
> +
> +maintainers:
> + - TBD
Hi,
It is surprising that this is your v3 and you put here TBD. In such
case, add here subsystem maintainer:
Dmitry Torokhov
> +
> +allOf:
> + - $ref: touchscreen.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - novatek,nt36xxx
This is not an enum, but one const.
> +
> + reg:
> +enum: [ 0x62 ]
Usually addresses are fixed in schema, because they could change (e.g.
by some pin configuration). Just use maxItems: 1.
> +
> + interrupts:
> +maxItems: 1
> +
> + reset-gpio:
> +maxItems: 1
> +
> + vdd-supply:
> +description: Power supply regulator for VDD pin
> +
> + vio-reg-name:
> +description: Power supply regulator on VDD-IO pin
What is this for? Is it a supply for the device or the device is a
regulator provider?
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + nt36xxx@62 {
Incorrect node name - should be touchscreen.
Best regards,
Krzysztof
[PATCH] pnp: remove the now unused pnp_find_card function
All user of the pnp_find_card compat wrapper are gone, so remove
the function as well.
Signed-off-by: Christoph Hellwig
---
Documentation/admin-guide/pnp.rst | 4
drivers/pnp/isapnp/compat.c | 23 ---
include/linux/isapnp.h| 6 --
3 files changed, 33 deletions(-)
diff --git a/Documentation/admin-guide/pnp.rst
b/Documentation/admin-guide/pnp.rst
index bab2d10631f00d..3eda08191d139a 100644
--- a/Documentation/admin-guide/pnp.rst
+++ b/Documentation/admin-guide/pnp.rst
@@ -281,10 +281,6 @@ ISAPNP drivers. They should serve as a temporary solution
only.
They are as follows::
- struct pnp_card *pnp_find_card(unsigned short vendor,
- unsigned short device,
- struct pnp_card *from)
-
struct pnp_dev *pnp_find_dev(struct pnp_card *card,
unsigned short vendor,
unsigned short function,
diff --git a/drivers/pnp/isapnp/compat.c b/drivers/pnp/isapnp/compat.c
index 6c845b6283163d..035e9509248968 100644
--- a/drivers/pnp/isapnp/compat.c
+++ b/drivers/pnp/isapnp/compat.c
@@ -21,28 +21,6 @@ static void pnp_convert_id(char *buf, unsigned short vendor,
(device >> 12) & 0x0f, (device >> 8) & 0x0f);
}
-struct pnp_card *pnp_find_card(unsigned short vendor, unsigned short device,
- struct pnp_card *from)
-{
- char id[8];
- char any[8];
- struct list_head *list;
-
- pnp_convert_id(id, vendor, device);
- pnp_convert_id(any, ISAPNP_ANY_ID, ISAPNP_ANY_ID);
-
- list = from ? from->global_list.next : pnp_cards.next;
-
- while (list != &pnp_cards) {
- struct pnp_card *card = global_to_pnp_card(list);
-
- if (compare_pnp_id(card->id, id) || (memcmp(id, any, 7) == 0))
- return card;
- list = list->next;
- }
- return NULL;
-}
-
struct pnp_dev *pnp_find_dev(struct pnp_card *card, unsigned short vendor,
unsigned short function, struct pnp_dev *from)
{
@@ -86,5 +64,4 @@ struct pnp_dev *pnp_find_dev(struct pnp_card *card, unsigned
short vendor,
return NULL;
}
-EXPORT_SYMBOL(pnp_find_card);
EXPORT_SYMBOL(pnp_find_dev);
diff --git a/include/linux/isapnp.h b/include/linux/isapnp.h
index 11edb2109a68f6..dba18c95844bde 100644
--- a/include/linux/isapnp.h
+++ b/include/linux/isapnp.h
@@ -75,9 +75,6 @@ static inline int isapnp_proc_done(void) { return 0; }
#endif
/* compat */
-struct pnp_card *pnp_find_card(unsigned short vendor,
- unsigned short device,
- struct pnp_card *from);
struct pnp_dev *pnp_find_dev(struct pnp_card *card,
unsigned short vendor,
unsigned short function,
@@ -92,9 +89,6 @@ static inline int isapnp_cfg_end(void) { return -ENODEV; }
static inline unsigned char isapnp_read_byte(unsigned char idx) { return 0xff;
}
static inline void isapnp_write_byte(unsigned char idx, unsigned char val) { ;
}
-static inline struct pnp_card *pnp_find_card(unsigned short vendor,
-unsigned short device,
-struct pnp_card *from) { return
NULL; }
static inline struct pnp_dev *pnp_find_dev(struct pnp_card *card,
unsigned short vendor,
unsigned short function,
--
2.28.0
linux-next: build failure after merge of the xarray tree
Hi all,
After merging the xarray tree, today's linux-next build (x86_64
allmodconfig) failed like this:
lib/test_xarray.c: In function 'check_xa_mark_3':
lib/test_xarray.c:305:3: error: implicit declaration of function 'assert'
[-Werror=implicit-function-declaration]
305 | assert(1);
| ^~
lib/test_xarray.c:11:1: note: 'assert' is defined in header ''; did
you forget to '#include '?
10 | #include
+++ |+#include
11 |
Caused by commit
5c8052d7925b ("XArray test: Add new test")
I have added the following hack for today:
From: Stephen Rothwell
Date: Thu, 8 Oct 2020 17:46:26 +1100
Subject: [PATCH] XArray test: remove assert()
Signed-off-by: Stephen Rothwell
---
lib/test_xarray.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/test_xarray.c b/lib/test_xarray.c
index 9d9c09d1f781..21bb06c213a2 100644
--- a/lib/test_xarray.c
+++ b/lib/test_xarray.c
@@ -302,7 +302,6 @@ static noinline void check_xa_mark_3(struct xarray *xa)
rcu_read_lock();
xas_for_each_marked(&xas, entry, ULONG_MAX, XA_MARK_0) {
count++;
- assert(1);
}
XA_BUG_ON(xa, count != 1);
rcu_read_unlock();
--
2.28.0
--
Cheers,
Stephen Rothwell
pgpBHVyXqp5IQ.pgp
Description: OpenPGP digital signature
RE: [PATCH v2 1/2] media: i2c: Add driver for the Analog Devices ADDI9036 ToF front-end
Thank you Sakari for review
> Hi Bogdan,
>
> On Fri, Oct 02, 2020 at 04:35:16PM +0300, Bogdan Togorean wrote:
> > The ADDI9036 is a complete, 45 MHz, front-end solution for charge
> > coupled device (CCD) time of flight (TOF) imaging applications.
> >
> > It has 2-lane MIPI CSI-2 RAW12 data output and i2c control interface.
> >
> > The programming of calibration and firmware is performed by driver
> > using Linux Firmware API.
> >
> > Signed-off-by: Bogdan Togorean
> > ---
> >
> > v2: implemented reading of FW using Linux Firmware API
> > removed custom controls for FW programming
> > added custom control to select operating mode
> > implemented V1 review remarks
> > cleaned includes list
> > ---
> > MAINTAINERS| 10 +
> > drivers/media/i2c/Kconfig | 14 +
> > drivers/media/i2c/Makefile | 1 +
> > drivers/media/i2c/addi9036.c | 754 +
> > include/uapi/linux/v4l2-controls.h | 6 +
> > 5 files changed, 785 insertions(+)
> > create mode 100644 drivers/media/i2c/addi9036.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0d0862b19ce5..4e3878e6c0ba 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -477,6 +477,16 @@ W: http://wiki.analog.com/AD7879
> > W: http://ez.analog.com/community/linux-device-drivers
> > F: drivers/input/touchscreen/ad7879.c
> >
> > +ADDI9036 TOF FRONTEND DRIVER
> > +M: Bogdan Togorean
> > +L: linux-me...@vger.kernel.org
> > +S: Supported
> > +W: https://www.analog.com/en/products/addi9036.html
> > +W: http://ez.analog.com/community/linux-device-drivers
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml
> > +F: drivers/media/i2c/addi9036.c
> > +
> > ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR)
> > M: Jiri Kosina
> > S: Maintained
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index c7ba76fee599..087dd307505d 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -725,6 +725,20 @@ config VIDEO_APTINA_PLL
> > config VIDEO_SMIAPP_PLL
> > tristate
> >
> > +config VIDEO_ADDI9036
> > + tristate "Analog Devices ADDI9036 ToF front-end support"
> > + depends on I2C && VIDEO_V4L2
> > + select MEDIA_CONTROLLER
> > + select VIDEO_V4L2_SUBDEV_API
> > + select V4L2_FWNODE
> > + select REGMAP_I2C
> > + help
> > + This is a Video4Linux2 driver for Analog Devices ADDI9036
> > + Time of Flight front-end.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called addi9036.
> > +
> > config VIDEO_HI556
> > tristate "Hynix Hi-556 sensor support"
> > depends on I2C && VIDEO_V4L2
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> > index f0a77473979d..631a7c7612ca 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
> > obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
> > obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
> > obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
> > +obj-$(CONFIG_VIDEO_ADDI9036) += addi9036.o
> > obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
> > obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
> > obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
> > diff --git a/drivers/media/i2c/addi9036.c b/drivers/media/i2c/addi9036.c
> > new file mode 100644
> > index ..e38e70afd23d
> > --- /dev/null
> > +++ b/drivers/media/i2c/addi9036.c
> > @@ -0,0 +1,754 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Driver for the Analog Devices ADDI9036 ToF camera sensor.
> > + *
> > + * Copyright (C) 2019-2020 Analog Devices, All Rights Reserved.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define FW_FILE_NAME "adi/addi9036-fw.bin"
> > +#define ADDI_MAGIC "ADDI9036"
> > +
> > +struct addi9036_mode_info {
> > + u32 width;
> > + u32 height;
> > + u32 pixel_rate;
> > + u32 link_freq_idx;
> > +};
> > +
> > +struct addi9036_mode_fw_block {
> > + const struct reg_sequence *mode_regs;
> > + ssize_t regs_count;
> > +};
> > +
> > +struct addi9036_fw_header {
> > + unsigned char magic[8];
> > + __le32 modes_nr;
> > +} __packed;
> > +
> > +struct addi9036_mode_block {
> > + __le32 mode_id;
> > + __le32 size_bytes;
> > + __le16 data[];
> > +} __packed;
> > +
> > +struct addi9036 {
> > + struct regmap *regmap;
> > + struct device *dev;
> > + struct v4l2_subdev sd;
> > + struct media_pad pad;
> > + struct v4l2_fwnode_endpoint ep;
> > + struct v4l2_mbus_framefmt fmt;
> > + struct v4l2_rect crop;
> > +
> > + const struct addi9036_mode_info *current_mode;
> > +
> > + struct v4l2_ctrl_handler ctrls;
> > + struct v4l2_ctrl *pixel_rate;
> > + struct v4l2_ctrl *link_freq;
> > + /* custom controls */
> > + struct v4l2_ctrl *set_o
Re: [tip: x86/pasid] x86/asm: Carve out a generic movdir64b() helper for general usage
On Wed, Oct 07, 2020 at 11:13:27PM +0200, Borislav Petkov wrote:
> On Wed, Oct 07, 2020 at 07:08:35PM +0200, Peter Zijlstra wrote:
> > (%rdx), %rax, surely?
>
> Right, later. Already tagged the branch so that Vinod can base stuff ontop.
>
> > Also, that's a horrible convention, but I suppose (%rdx), (%rax) was
> > out?
>
> See the end of this mail:
>
> https://lkml.kernel.org/r/alpine.lsu.2.20.2009241356020.20...@wotan.suse.de
That, 100x that. Why wasn't it fixed then? How about we fix binutils to
accept the sane mnemonic as well?
> > Can we pretty please get a binutils version that knows about this
> > instruction, such that we know when we can get rid of the silly .byte
> > encoded mess?
>
> It looks like support for this insn got introduced in this binutils commit:
>
> c0a30a9f0ab4 ("Enable Intel MOVDIRI, MOVDIR64B instructions")
>
> So I guess from 2.31 onwards:
Then we'll just keep the byte code around until we reach the min
binutils that's sane, but at least we can fix the comment to not be
insane.
Re: [PATCH 2/2] usb: serial: option: add Cellient MPL200 card
On Tue, 6 Oct 2020 09:02:01 +0200 Johan Hovold wrote: > On Mon, Oct 05, 2020 at 02:07:23PM +0200, Wilken Gottwalt wrote: > > On Mon, 5 Oct 2020 18:36:36 +0700 Lars Melin wrote: > > > On 10/5/2020 18:06, Johan Hovold wrote: > > > > > Do you remember the interface layout and why you blacklisted interface > > > > 1? > > > > It is very likely that Cellient has replaced the VID with their own and > > > kept the PID, it is something other mfgrs has done when buying modules > > > from Qualcomm's series of devices with predefined composition. > > > > > > The MS Windows driver for 05c6:9025 describes the interfaces as: > > > > > > MI_00 Qualcomm HS-USB Diagnostics 9025 > > > MI_01 Android Composite ADB Interface > > > MI_02 Qualcomm HS-USB Android Modem 9025 > > > MI_03 Qualcomm HS-USB NMEA 9025 > > > MI_04 Qualcomm Wireless HS-USB Ethernet Adapter 9025 > > > MI_05 USB Mass Storage Device > > > > > > where the net interface is for QMI/RMNET. > > > It fully matches the blacklisting Wilken has done for 2692:9025 > > > > Does your device have a GPS connector? Mine had not and I'm not sure > > if the description of MI_01 is actually correct. I remember looking at > > this port and seeing bogus NMEA data. > > Well if it's NMEA then the interface shouldn't be blacklisted (even if > the values are bogus on your device), but if it's ADB it should be as > that is handled by userspace. > > Here's some lsusb output from a Cellient MPL200 that still uses the > Qualcomm VID: > > > https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg04523.html > > which gives some support to Lars's hypothesis. I guess we'll just keep > the first interface reserved. Lars and Johan are right here. I found an older external Gobi driver where I actually added comments saying interface 1 is ADB and interface 3 is NMEA delivering only zeroed values because of the missing antenna connector, at least for the models I had access to. Will
Re: [PATCH v2 04/11] drivers/base/devcoredump: convert devcd_count to counter_atomic32
On Wed, 2020-10-07 at 13:43 -0700, Kees Cook wrote: > > > > I actually wonder if this should use refcount_t just because it is > > > > designed to be an alway-unique value. It is hard to imagine ever causing > > > > this to overflow, but why not let it be protected? > > > > > > > > > > This is one of the cases where devcd_count doesn't guard lifetimes, > > > however if it ever overflows, refcount_t is a better choice. > > > > > > If we decide refcount_t is a better choice, I can drop this patch > > > and send refcount_t conversion patch instead. > > > > > > Greg! Any thoughts on refcount_t for this being a better choice? > > > > I'm not Greg, but ... there's a 5 minute timeout. So in order to cause a > > clash you'd have to manage to overflow the counter within a 5 minute > > interval, otherwise you can actually reuse the numbers starting again > > from 0 without any ill effect. > > That's not true as far as I can see: there's no reset in here. It's a > global heap variable with function-level visibility (note the "static"), > so it is only ever initialized once: Yes, obviously it is a static variable. You'll note that I also never claimed anything regarding reset. What I said was two things (perhaps with too many words :-) ): 1) each value that we derive from this ever-incrementing (modulo 2^32) variable only get used for a limited amount of time (max. 5 minutes) 2) if you manage to overflow within 5 minutes, then the following device_add() will just fail and nothing else/bad will happen Therefore, there's no problem with wrapping, and IMHO it'd be *better* than saturating because (1) means that the wrapping almost certainly doesn't matter, and (2) means that even if you do manage to wrap and cause a "clash" (what I wrote in the text you quoted) this is entirely harmless. OTOH, if you saturate, then - again under the premise of actually getting there, however unlikely it may be - you are afterwards *always* hitting (2), regardless of (1), which seems counter-productive given that (1) means that (2) almost certainly won't happen. IOW, I disagree with you, and think that counter_atomic_32 is more appropriate here than refcount_t. johannes
RE: [PATCH v2 2/2] media: dt-bindings: media: i2c: Add bindings for ADDI9036
Hi Sakari, > Hi Bogdan, > > On Thu, Oct 08, 2020 at 06:23:33AM +, Togorean, Bogdan wrote: > > Thank you Rob for review > > > On Fri, Oct 02, 2020 at 04:35:17PM +0300, Bogdan Togorean wrote: > > > > Add YAML device tree bindings for Analog Devices Inc. ADDI9036 CCD TOF > > > > front-end. > > > > > > > > Signed-off-by: Bogdan Togorean > > > > --- > > > > v2: added reg property description > > > > --- > > > > .../bindings/media/i2c/adi,addi9036.yaml | 76 +++ > > > > 1 file changed, 76 insertions(+) > > > > create mode 100644 > > > Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > > > > > > diff --git > a/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > b/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > > new file mode 100644 > > > > index ..7c4af704db98 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > > @@ -0,0 +1,76 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: > > > > https://urldefense.com/v3/__http://devicetree.org/schemas/media/i2c/adi,add > > > > i9036.yaml*__;Iw!!A3Ni8CS0y2Y!vLJoRikiVhmxm8p3bhGjRkFIWgjXvVlcJ8ATa9okn > > > JqDbtobtK46hHICblE2i2Yj2sZL$ > > > > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta- > > > > schemas/core.yaml*__;Iw!!A3Ni8CS0y2Y!vLJoRikiVhmxm8p3bhGjRkFIWgjXvVlcJ > > > 8ATa9oknJqDbtobtK46hHICblE2iz34fu4o$ > > > > + > > > > +title: Analog Devices ADDI9036 VGA CCD Time of Flight Sensor > > > > + > > > > +maintainers: > > > > + - Bogdan Togorean > > > > + > > > > +description: |- > > > > + The ADDI9036 is a complete, 45 MHz, front-end solution for charge > coupled > > > > + device (CCD) time of flight (TOF) imaging applications. It is > > > > programmable > > > > + through I2C interface. Image data is sent through MIPI CSI-2 2 lanes > > > > and > > > > + can output two RAW12 packed data streams. One is IR and the other is > > > Depth. > > > > + Each data stream is on a separate or same MIPI Virtual Channel, > depending > > > > + on configuration and each have 640x480 resolution. > > > > + > > > > +properties: > > > > + compatible: > > > > +const: adi,addi9036 > > > > + > > > > + reg: > > > > +description: I2C device address > > > > > > Can drop this. > > ACK > > > > > > > +maxItems: 1 > > > > + > > > > + reset-gpios: > > > > > > maxItems: 1 > > ACK > > > > > > > +description: |- > > > > + Reference to the GPIO connected to the RST/SYNC pin, if any. > > > > + Must be released (set high) after all supplies are applied. > > > > + > > > > + # See ../video-interfaces.txt for more details > > > > + port: > > > > +type: object > > > > +properties: > > > > + endpoint: > > > > +type: object > > > > +properties: > > > > + data-lanes: > > > > +description: |- > > > > + The sensor supports two-lane operation. > > > > + For two-lane operation the property must be set to <1 2>. > > > > +items: > > > > + - const: 1 > > > > + - const: 2 > > > > > > If this is the only possible setting, then why does it need to be in DT? > > If this is not set the bus_type will be not be correctly set after call of > > v4l2_fwnode_endpoint_parse. > > That's not a DT binding issue. The driver needs to set the field before > calling v4l2_fwnode_endpoint_parse. > > Does the device not support one lane operation? > Now I was reading your response to driver review and understood the problem. Sorry for this an I'll set the bus_type in driver before call of v4l2_fwnode_endpoint_parse. And the camera does not support one lane. > -- > Regards, > > Sakari Ailus
Re: [PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback
On 07/10/2020 18.55, Vinod Koul wrote: > On 07-10-20, 11:08, Peter Ujfalusi wrote: > >> Not really. In DT an event triggered channel can be requested via router >> (when this is used) for example: >> >> dmas = <&inta_l2g a b c>; >> a - the input number of the DMA request in l2g >> b - edge or level trigger to be selected >> c - ASEL number for the channel for coherency >> >> The l2g router driver then translate this to: >> <&main_bcdma 1 0 c> >> 1 - Global trigger 0 is used by the DMA >> 0 - ignored >> c - ASEL number. >> >> The router needs to send an event which is going to be received by the >> channel we have picked up, this event number can only be known when we >> do have the channel. >> >> So the flow in this case: >> router converts the dma_spec for the DMA, but it does not yet know what >> is the event number it has to use. >> The BCDMA driver will pick an available bchan and notes that the >> transfers will be triggered by global event 0. >> When we have the channel, the core saves the router information and >> calls the device_router_config of BCDMA. >> In there we call back to the router and give the event number it has to >> use to send the trigger for the channel. > > Ah that is intresting, so you would call router driver foo_set_event() > and would send the event number Yes, that's correct. > why not call that API from alloc > channel or even xlate? at alloc / xlate time the DMA driver does not have information about router. The alloc/xlate will result the channel, but in my case it will result a broken setup as the router does not know which event to send. > Why do you need new callback? When I added the DMA event router support, it was designed in a way that the DMA driver itself must not know anything about the router, it has to be transparent. One can just add a router on front of any DMA and everything will work. This is the right thing to do, and it works for existing setups. > Or did i miss something.. The BCDMA triggered channel setup is a chicken-egg setup. For this case the channel can be triggered by a global event. A channel can receive two global event, but this is not a concern atm. The event number depends on the channel we use, for simplicity let's say: bchan_id + trigger_offset = bchan_trigger_evt. of_dma_router_xlate does this: 1. calls the dma router's of_dma_route_allocate callback to allocate a route and craft a dma_spec for the DMA to configure a channel. 2. using this crafted dma_spec we request a channel via of_dma_xlate callback 3. if we got the channel, we save the router information, so it can be deallocated when the channel is disabled. I need a fourth step to do a final configuration since only at this time (after it has been allocated) the channel has information about possible router. In the new optional callback the DMA driver can figure out the event number which must be used by the router to send the event to the desired global event target of the channel. Other DMAs might need something different, but imho if there is going to be a need for such post alloc router config, then it is most likely will come from the need to feed back some sort of channel information to the router. Or take parameter from the router itself for the channel. To summarize: In of_dma_route_allocate() the router does not yet know the channel we are going to get. In of_dma_xlate() the DMA driver does not yet know if the channel will use router or not. I need to tell the router the event number it has to send, which is based on the channel number I got. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [v2 PATCH] crypto: sun4i-ss - Fix sparse endianness markers
On Thu, Oct 08, 2020 at 04:52:38PM +1100, Herbert Xu wrote: > On Thu, Sep 24, 2020 at 03:27:38PM +0200, Corentin Labbe wrote: > > > > This is an example on next-20200923+BigEndian > > alg: ahash: sha1 test failed (wrong result) on test vector \"random: > > psize=194 ksize=0\", cfg=\"random: inplace may_sleep use_finup > > src_divs=[98.25%@+1124, 1.75%@+5] iv_offset=18\" > > Hmm, the only way I can see this happening is if it was triggered > by tcrypt. Were you using tcrypt by any chance? > > Ccing Eric in case he has any insight. > > > === DUMP /proc/crypto === > > name : sha1 > > driver : sha1-sun4i-ss > > module : kernel > > priority : 300 > > refcnt : 1 > > selftest : passed > > internal : no > > type : ahash > > async: no > > blocksize: 64 > > digestsize : 20 > > ... > > > name : sha1 > > driver : sha1-generic > > module : kernel > > priority : 100 > > refcnt : 1 > > selftest : passed > > internal : no > > type : shash > > blocksize: 64 > > digestsize : 20 > > Thanks, Yes I use tcrypt to force all algos to be tested.
[PATCH v2] selftests/tls: Add {} to avoid static checker warning
This silences a static checker warning due to the unusual macro
construction of EXPECT_*() by adding explicit {}s around the enclosing
while loop.
Reported-by: Dan Carpenter
Fixes: 7f657d5bf507 ("selftests: tls: add selftests for TLS sockets")
Signed-off-by: Kees Cook
---
v2: rebase to v5.9-rc2; oops, I lost this patch and just found it again
v1: https://lore.kernel.org/lkml/20190108214159.GA33292@beast/
---
tools/testing/selftests/net/tls.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/tls.c
b/tools/testing/selftests/net/tls.c
index b599f1fa99b5..44984741bd41 100644
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@ -387,8 +387,9 @@ TEST_F(tls, sendmsg_large)
EXPECT_EQ(sendmsg(self->cfd, &msg, 0), send_len);
}
- while (recvs++ < sends)
+ while (recvs++ < sends) {
EXPECT_NE(recv(self->fd, mem, send_len, 0), -1);
+ }
free(mem);
}
--
2.25.1
Re: [PATCH v2 2/2] media: dt-bindings: media: i2c: Add bindings for ADDI9036
Hi Bogdan, On Thu, Oct 08, 2020 at 06:23:33AM +, Togorean, Bogdan wrote: > Thank you Rob for review > > On Fri, Oct 02, 2020 at 04:35:17PM +0300, Bogdan Togorean wrote: > > > Add YAML device tree bindings for Analog Devices Inc. ADDI9036 CCD TOF > > > front-end. > > > > > > Signed-off-by: Bogdan Togorean > > > --- > > > v2: added reg property description > > > --- > > > .../bindings/media/i2c/adi,addi9036.yaml | 76 +++ > > > 1 file changed, 76 insertions(+) > > > create mode 100644 > > Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > b/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > new file mode 100644 > > > index ..7c4af704db98 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > @@ -0,0 +1,76 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > https://urldefense.com/v3/__http://devicetree.org/schemas/media/i2c/adi,add > > i9036.yaml*__;Iw!!A3Ni8CS0y2Y!vLJoRikiVhmxm8p3bhGjRkFIWgjXvVlcJ8ATa9okn > > JqDbtobtK46hHICblE2i2Yj2sZL$ > > > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta- > > schemas/core.yaml*__;Iw!!A3Ni8CS0y2Y!vLJoRikiVhmxm8p3bhGjRkFIWgjXvVlcJ > > 8ATa9oknJqDbtobtK46hHICblE2iz34fu4o$ > > > + > > > +title: Analog Devices ADDI9036 VGA CCD Time of Flight Sensor > > > + > > > +maintainers: > > > + - Bogdan Togorean > > > + > > > +description: |- > > > + The ADDI9036 is a complete, 45 MHz, front-end solution for charge > > > coupled > > > + device (CCD) time of flight (TOF) imaging applications. It is > > > programmable > > > + through I2C interface. Image data is sent through MIPI CSI-2 2 lanes > > > and > > > + can output two RAW12 packed data streams. One is IR and the other is > > Depth. > > > + Each data stream is on a separate or same MIPI Virtual Channel, > > > depending > > > + on configuration and each have 640x480 resolution. > > > + > > > +properties: > > > + compatible: > > > +const: adi,addi9036 > > > + > > > + reg: > > > +description: I2C device address > > > > Can drop this. > ACK > > > > > +maxItems: 1 > > > + > > > + reset-gpios: > > > > maxItems: 1 > ACK > > > > > +description: |- > > > + Reference to the GPIO connected to the RST/SYNC pin, if any. > > > + Must be released (set high) after all supplies are applied. > > > + > > > + # See ../video-interfaces.txt for more details > > > + port: > > > +type: object > > > +properties: > > > + endpoint: > > > +type: object > > > +properties: > > > + data-lanes: > > > +description: |- > > > + The sensor supports two-lane operation. > > > + For two-lane operation the property must be set to <1 2>. > > > +items: > > > + - const: 1 > > > + - const: 2 > > > > If this is the only possible setting, then why does it need to be in DT? > If this is not set the bus_type will be not be correctly set after call of > v4l2_fwnode_endpoint_parse. That's not a DT binding issue. The driver needs to set the field before calling v4l2_fwnode_endpoint_parse. Does the device not support one lane operation? -- Regards, Sakari Ailus
Re: [PATCH v9 02/15] usb: typec: tcpci: Add set_vbus tcpci callback
On Sat, Oct 3, 2020 at 8:56 AM Greg Kroah-Hartman wrote: > > On Fri, Oct 02, 2020 at 09:08:00AM -0700, Badhri Jagan Sridharan wrote: > > Hi Greg, > > > > Yes I tested it on usb-next before sending it out. > > > > 630 | tcpci->tcpc.enable_frs = tcpci_enable_frs; > > > > In https://patchwork.kernel.org/project/linux-usb/list/?series=356837 > > i.e v9 version of this series, > > Patch 7 i.e. https://patchwork.kernel.org/patch/11804847/ is where the > > above line is added. > > > > I restested in combinations [1] [2] [3] [4]. All of them were clear > > cherry-picks. I didnt any merge conflicts. > > > > Maybe you are applying patches in a different order ? > > I didn't think so. Can you try applying the patches, in order, and > building after each one to see if you get the same error or not? Tried this as well. Not sure what I am doing differently. Also was manually looking for "tcpci_enable_frs" in the series and it's first occurrence is in: "[PATCH v9 07/15] usb: typec: tcpci: Implement callbacks for FRS". Just sent out the v10 after addressing a couple of comments from Rob Herring. Thanks, Badhri > > My usb-next branch is up to date with all of the recent patches. > > thanks, > > greg k-h
Re: [PATCH v2] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
Em Thu, 8 Oct 2020 08:14:43 +0200 Greg Kroah-Hartman escreveu: > On Thu, Oct 08, 2020 at 07:30:27AM +0200, Mauro Carvalho Chehab wrote: > > As warned by Randy: > > > > on x86_64: > > CONFIG_USB_ROLE_SWITCH=m > > and HISI_HIKEY_USB=y. > > > > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': > > hisi_hikey_usb.c:(.text+0x61): undefined reference to > > `usb_role_switch_unregister' > > ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to > > `usb_role_switch_put' > > ld: drivers/misc/hisi_hikey_usb.o: in function > > `hub_usb_role_switch_set': > > hisi_hikey_usb.c:(.text+0xd3): undefined reference to > > `usb_role_switch_get_drvdata' > > ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': > > hisi_hikey_usb.c:(.text+0x54d): undefined reference to > > `usb_role_switch_set_role' > > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': > > hisi_hikey_usb.c:(.text+0x8a5): undefined reference to > > `usb_role_switch_get' > > ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to > > `usb_role_switch_register' > > ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to > > `usb_role_switch_put' > > > > Make it dependent on CONFIG_USB_ROLE_SWITCH. > > > > Reported-by: Randy Dunlap > > Signed-off-by: Mauro Carvalho Chehab > > --- > > drivers/misc/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > > index e19e1dcceb41..d5ce8082b0a0 100644 > > --- a/drivers/misc/Kconfig > > +++ b/drivers/misc/Kconfig > > @@ -459,6 +459,7 @@ config PVPANIC > > config HISI_HIKEY_USB > > tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" > > depends on (OF && GPIOLIB) || COMPILE_TEST > > + depends on USB_ROLE_SWITCH > > help > > If you say yes here this adds support for the on-board USB GPIO hub > > found on HiKey 960/970 boards, which is necessary to support > > I can't rebase my tree, so can you send the fix-up patch instead, with > the proper "reported-by:"? Sent. You may need to adjust the Fixes: line there, in order to point to the right changeset on your tree. Thanks, Mauro
Re: [PATCH] misc: Kconfig: fix a HISI_HIKEY_USB dependency
On Thu, Oct 08, 2020 at 08:24:53AM +0200, Mauro Carvalho Chehab wrote:
> The dependency should be just USB_ROLE_SWITCH, instead
> of CONFIG_USB_ROLE_SWITCH.
>
> Fixes: 2827d98bc5d6 ("misc: Kconfig: add a new dependency for HISI_HIKEY_USB")
>
> Reported-by: Nathan Chancellor
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Nathan Chancellor
> ---
> drivers/misc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 7cee2b72c09e..d5ce8082b0a0 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -459,7 +459,7 @@ config PVPANIC
> config HISI_HIKEY_USB
> tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform"
> depends on (OF && GPIOLIB) || COMPILE_TEST
> - depends on CONFIG_USB_ROLE_SWITCH
> + depends on USB_ROLE_SWITCH
> help
> If you say yes here this adds support for the on-board USB GPIO hub
> found on HiKey 960/970 boards, which is necessary to support
> --
> 2.26.2
>
[PATCH] misc: Kconfig: fix a HISI_HIKEY_USB dependency
The dependency should be just USB_ROLE_SWITCH, instead
of CONFIG_USB_ROLE_SWITCH.
Fixes: 2827d98bc5d6 ("misc: Kconfig: add a new dependency for HISI_HIKEY_USB")
Reported-by: Nathan Chancellor
Signed-off-by: Mauro Carvalho Chehab
---
drivers/misc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 7cee2b72c09e..d5ce8082b0a0 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -459,7 +459,7 @@ config PVPANIC
config HISI_HIKEY_USB
tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform"
depends on (OF && GPIOLIB) || COMPILE_TEST
- depends on CONFIG_USB_ROLE_SWITCH
+ depends on USB_ROLE_SWITCH
help
If you say yes here this adds support for the on-board USB GPIO hub
found on HiKey 960/970 boards, which is necessary to support
--
2.26.2
RE: [PATCH v2 2/2] media: dt-bindings: media: i2c: Add bindings for ADDI9036
Thank you Rob for review
> On Fri, Oct 02, 2020 at 04:35:17PM +0300, Bogdan Togorean wrote:
> > Add YAML device tree bindings for Analog Devices Inc. ADDI9036 CCD TOF
> > front-end.
> >
> > Signed-off-by: Bogdan Togorean
> > ---
> > v2: added reg property description
> > ---
> > .../bindings/media/i2c/adi,addi9036.yaml | 76 +++
> > 1 file changed, 76 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml
> b/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml
> > new file mode 100644
> > index ..7c4af704db98
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml
> > @@ -0,0 +1,76 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> https://urldefense.com/v3/__http://devicetree.org/schemas/media/i2c/adi,add
> i9036.yaml*__;Iw!!A3Ni8CS0y2Y!vLJoRikiVhmxm8p3bhGjRkFIWgjXvVlcJ8ATa9okn
> JqDbtobtK46hHICblE2i2Yj2sZL$
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-
> schemas/core.yaml*__;Iw!!A3Ni8CS0y2Y!vLJoRikiVhmxm8p3bhGjRkFIWgjXvVlcJ
> 8ATa9oknJqDbtobtK46hHICblE2iz34fu4o$
> > +
> > +title: Analog Devices ADDI9036 VGA CCD Time of Flight Sensor
> > +
> > +maintainers:
> > + - Bogdan Togorean
> > +
> > +description: |-
> > + The ADDI9036 is a complete, 45 MHz, front-end solution for charge coupled
> > + device (CCD) time of flight (TOF) imaging applications. It is
> > programmable
> > + through I2C interface. Image data is sent through MIPI CSI-2 2 lanes and
> > + can output two RAW12 packed data streams. One is IR and the other is
> Depth.
> > + Each data stream is on a separate or same MIPI Virtual Channel, depending
> > + on configuration and each have 640x480 resolution.
> > +
> > +properties:
> > + compatible:
> > +const: adi,addi9036
> > +
> > + reg:
> > +description: I2C device address
>
> Can drop this.
ACK
>
> > +maxItems: 1
> > +
> > + reset-gpios:
>
> maxItems: 1
ACK
>
> > +description: |-
> > + Reference to the GPIO connected to the RST/SYNC pin, if any.
> > + Must be released (set high) after all supplies are applied.
> > +
> > + # See ../video-interfaces.txt for more details
> > + port:
> > +type: object
> > +properties:
> > + endpoint:
> > +type: object
> > +properties:
> > + data-lanes:
> > +description: |-
> > + The sensor supports two-lane operation.
> > + For two-lane operation the property must be set to <1 2>.
> > +items:
> > + - const: 1
> > + - const: 2
>
> If this is the only possible setting, then why does it need to be in DT?
If this is not set the bus_type will be not be correctly set after call of
v4l2_fwnode_endpoint_parse.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +i2c0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +addi9036: addi9036_tof@64 {
> > +compatible = "adi,addi9036";
> > +reg = <0x64>;
> > +
> > +reset-gpios = <&gpio 41 1>;
> > +
> > +port {
> > +addi9036_ep: endpoint {
> > +remote-endpoint = <&csi1_ep>;
> > +data-lanes = <1 2>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 2.28.0
> >
Will send V3 with updates.
Re: [v5 01/12] struct device: Add function callback durable_name
On Wed, 7 Oct 2020, Tony Asleson wrote:
> The log information is not helpful without the information to correlate
> to the actual device.
Log messages that associate one entity with another can be generated
whenever such an association comes into existence, which is probably when
devices get probed.
E.g. a host:channel:target:lun identifier gets associated with a block
device name by the dev_printk() calls in sd_probe():
[3.60] sd 0:0:0:0: [sda] Attached SCSI disk
BTW, if you think of {"0:0:0:0","sda"} as a row in some normalized table
and squint a bit, this problem is not unlike the replication of database
tables over a message queue.
Re: [PATCH 1/2] mm/mprotect: Call arch_validate_prot under mmap_lock and with length
On Wed, Oct 07, 2020 at 04:42:55PM +0200, Jann Horn wrote:
> > > @@ -43,7 +43,7 @@ static inline long do_mmap2(unsigned long addr, size_t
> > > len,
> > > {
> > > long ret = -EINVAL;
> > >
> > > - if (!arch_validate_prot(prot, addr))
> > > + if (!arch_validate_prot(prot, addr, len))
> >
> > This call isn't under mmap lock. I also find it rather weird as the
> > generic code only calls arch_validate_prot from mprotect, only powerpc
> > also calls it from mmap.
> >
> > This seems to go back to commit ef3d3246a0d0
> > ("powerpc/mm: Add Strong Access Ordering support")
>
> I'm _guessing_ the idea in the generic case might be that mmap()
> doesn't check unknown bits in the protection flags, and therefore
> maybe people wanted to avoid adding new error cases that could be
> caused by random high bits being set? So while the mprotect() case
> checks the flags and refuses unknown values, the mmap() code just lets
> the architecture figure out which bits are actually valid to set (via
> arch_calc_vm_prot_bits()) and silently ignores the rest?
>
> And powerpc apparently decided that they do want to error out on bogus
> prot values passed to their version of mmap(), and in exchange, assume
> in arch_calc_vm_prot_bits() that the protection bits are valid?
The problem really is that now programs behave different on powerpc
compared to all other architectures.
> powerpc's arch_validate_prot() doesn't actually need the mmap lock, so
> I think this is fine-ish for now (as in, while the code is a bit
> unclean, I don't think I'm making it worse, and I don't think it's
> actually buggy). In theory, we could move the arch_validate_prot()
> call over into the mmap guts, where we're holding the lock, and gate
> it on the architecture or on some feature CONFIG that powerpc can
> activate in its Kconfig. But I'm not sure whether that'd be helping or
> making things worse, so when I sent this patch, I deliberately left
> the powerpc stuff as-is.
For now I'd just duplicate the trivial logic from arch_validate_prot
in the powerpc version of do_mmap2 and add a comment that this check
causes a gratious incompatibility to all other architectures. And then
hope that the powerpc maintainers fix it up :)
arceb-elf-ld: include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c85fb28b6f999db9928b841f63f1beeb3074eeca commit: 92a81562e695628086acb92f95090ab09d9b9ec0 leds: lp55xx: Add multicolor framework support to lp55xx date: 3 months ago config: arc-randconfig-r035-20201008 (attached as .config) compiler: arceb-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92a81562e695628086acb92f95090ab09d9b9ec0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 92a81562e695628086acb92f95090ab09d9b9ec0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arceb-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' arceb-elf-ld: lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' arceb-elf-ld: lib/stackdepot.o: in function `in_irqentry_text': lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' arceb-elf-ld: lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' arceb-elf-ld: lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' arceb-elf-ld: lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' arceb-elf-ld: lib/stackdepot.c:325: undefined reference to `__softirqentry_text_end' arceb-elf-ld: lib/stackdepot.c:325: undefined reference to `__softirqentry_text_end' arceb-elf-ld: drivers/leds/leds-lp55xx-common.o: in function `devm_led_classdev_register': include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext' >> arceb-elf-ld: include/linux/leds.h:193: undefined reference to >> `devm_led_classdev_register_ext' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH v10 02/15] usb: typec: tcpci: Add set_vbus tcpci callback
set_vbus callback allows TCPC which are TCPCI based, however,
does not support turning on sink and source mode through
Command.SinkVbus and Command.SourceVbusDefaultVoltage.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Rebase on usb-next
Changes since v7:
- Added Reviewed-by: Heikki
- Rebase change
Change since v8:
- None
Change since v9:
- None
---
drivers/usb/typec/tcpm/tcpci.c | 7 +++
drivers/usb/typec/tcpm/tcpci.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index b960fe5a0f28..d6a6fac82d48 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -328,6 +328,13 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool
source, bool sink)
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
int ret;
+ if (tcpci->data->set_vbus) {
+ ret = tcpci->data->set_vbus(tcpci, tcpci->data, source, sink);
+ /* Bypass when ret > 0 */
+ if (ret != 0)
+ return ret < 0 ? ret : 0;
+ }
+
/* Disable both source and sink first before enabling anything */
if (!source) {
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 04c49a0b0368..4d441bdf24d5 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -144,6 +144,7 @@ struct tcpci_data {
bool enable);
int (*start_drp_toggling)(struct tcpci *tcpci, struct tcpci_data *data,
enum typec_cc_status cc);
+ int (*set_vbus)(struct tcpci *tcpci, struct tcpci_data *data, bool
source, bool sink);
};
struct tcpci *tcpci_register_port(struct device *dev, struct tcpci_data *data);
--
2.28.0.806.g8561365e88-goog
[PATCH v10 03/15] dt-bindings: usb: Maxim type-c controller device tree binding document
Add device tree binding document for Maxim TCPCI based Type-C chip driver
Signed-off-by: Badhri Jagan Sridharan
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Migrated to yaml format.
Changes since v7:
- Rebase on usb-next
Changes since v8:
- Fix errors from make dt_binding_check as suggested by
Rob Herring.
Changes since v9:
- additionalProperties: false as suggested by Rob Herring.
---
.../devicetree/bindings/usb/maxim,tcpci.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/maxim,tcpci.yaml
diff --git a/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml
b/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml
new file mode 100644
index ..12e0ece1b515
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/maxim,tcpci.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Maxim TCPCI Type-C PD controller DT bindings
+
+maintainers:
+ - Badhri Jagan Sridharan
+
+description: Maxim TCPCI Type-C PD controller
+
+properties:
+ compatible:
+enum:
+ - maxim,tcpci
+
+ interrupts:
+maxItems: 1
+
+ connector:
+type: object
+$ref: ../connector/usb-connector.yaml#
+description:
+ Properties for usb c connector.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+maxtcpc@25 {
+compatible = "maxim,tcpc";
+reg = <0x25>;
+interrupt-parent = <&gpa8>;
+interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+connector {
+compatible = "usb-c-connector";
+label = "USB-C";
+data-role = "dual";
+power-role = "dual";
+try-power-role = "sink";
+self-powered;
+op-sink-microwatt = <260>;
+source-pdos = ;
+sink-pdos = ;
+};
+};
+};
+...
--
2.28.0.806.g8561365e88-goog
[PATCH v10 13/15] usb: typec: tcpm: Implement enabling Auto Discharge disconnect support
TCPCI spec allows TCPC hardware to autonomously discharge the vbus
capacitance upon disconnect. The expectation is that the TCPM enables
AutoDischargeDisconnect while entering SNK/SRC_ATTACHED states. Hardware
then automously discharges vbus when the vbus falls below a certain
threshold i.e. VBUS_SINK_DISCONNECT_THRESHOLD.
Apart from enabling the vbus discharge circuit, AutoDischargeDisconnect
is also used a flag to move TCPCI based TCPC implementations into
Attached.Snk/Attached.Src state as mentioned in
Figure 4-15. TCPC State Diagram before a Connection of the
USB Type-C Port Controller Interface Specification.
In such TCPC implementations, setting AutoDischargeDisconnect would
prevent TCPC into entering "Connection_Invalid" state as well.
Signed-off-by: Badhri Jagan Sridharan
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Fixed incorrect data_role error that I introduced by mistake in
the previous version.
Changes since v7:
- Rebase on usb-next
Changes since v8:
- Removing the call to tcpm_set_auto_vbus_discharge_threshold
in the source path.
- Changes since v9:
- None
---
drivers/usb/typec/tcpm/tcpm.c | 60 ---
include/linux/usb/tcpm.h | 15 +
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index d5a3e2b3bea2..51a14d282109 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -1701,6 +1701,24 @@ static void tcpm_handle_alert(struct tcpm_port *port,
const __le32 *payload,
}
}
+static int tcpm_set_auto_vbus_discharge_threshold(struct tcpm_port *port,
+ enum typec_pwr_opmode mode,
bool pps_active,
+ u32 requested_vbus_voltage)
+{
+ int ret;
+
+ if (!port->tcpc->set_auto_vbus_discharge_threshold)
+ return 0;
+
+ ret = port->tcpc->set_auto_vbus_discharge_threshold(port->tcpc, mode,
pps_active,
+
requested_vbus_voltage);
+ tcpm_log_force(port,
+ "set_auto_vbus_discharge_threshold mode:%d pps_active:%c
vbus:%u ret:%d",
+ mode, pps_active ? 'y' : 'n', requested_vbus_voltage,
ret);
+
+ return ret;
+}
+
static void tcpm_pd_data_request(struct tcpm_port *port,
const struct pd_message *msg)
{
@@ -1871,6 +1889,10 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
port->current_limit,
port->supply_voltage);
port->explicit_contract = true;
+ tcpm_set_auto_vbus_discharge_threshold(port,
+
TYPEC_PWR_MODE_PD,
+
port->pps_data.active,
+
port->supply_voltage);
tcpm_set_state(port, SNK_READY, 0);
} else {
/*
@@ -2785,8 +2807,12 @@ static int tcpm_src_attach(struct tcpm_port *port)
if (ret < 0)
return ret;
- ret = tcpm_set_roles(port, true, TYPEC_SOURCE,
-tcpm_data_role_for_source(port));
+ if (port->tcpc->enable_auto_vbus_discharge) {
+ ret = port->tcpc->enable_auto_vbus_discharge(port->tcpc, true);
+ tcpm_log_force(port, "enable vbus discharge ret:%d", ret);
+ }
+
+ ret = tcpm_set_roles(port, true, TYPEC_SOURCE,
tcpm_data_role_for_source(port));
if (ret < 0)
return ret;
@@ -2853,6 +2879,12 @@ static void tcpm_unregister_altmodes(struct tcpm_port
*port)
static void tcpm_reset_port(struct tcpm_port *port)
{
+ int ret;
+
+ if (port->tcpc->enable_auto_vbus_discharge) {
+ ret = port->tcpc->enable_auto_vbus_discharge(port->tcpc, false);
+ tcpm_log_force(port, "Disable vbus discharge ret:%d", ret);
+ }
tcpm_unregister_altmodes(port);
tcpm_typec_disconnect(port);
port->attached = false;
@@ -2917,8 +2949,13 @@ static int tcpm_snk_attach(struct tcpm_port *port)
if (ret < 0)
return ret;
- ret = tcpm_set_roles(port, true, TYPEC_SINK,
-tcpm_data_role_for_sink(port));
+ if (port->tcpc->enable_auto_vbus_discharge) {
+ tcpm_set_auto_vbus_discharge_threshold(port,
TYPEC_PWR_MODE_USB, false, VSAFE5V);
+ ret = port->tcpc->enable_auto_vbus_discharge(port->tcpc, true);
+ tcpm_log_force(port, "enable vbus discharge ret:%d", ret);
+ }
+
+ ret = tc
[PATCH v10 06/15] usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)
PD 3.0 spec defines a new mechanism for power role swap called
Fast role swap. This change enables TCPM to support FRS when
acting as sink.
Once the explicit contract is negotiated, sink port is
expected to query the source port for sink caps to
determine whether the source is FRS capable.
Bits 23 & 24 of fixed pdo of the sink caps from the source, when
set, indicates the current needed by the source when fast role
swap is in progress(Implicit contract phasae). 0 indicates that
the source does not support Fast Role Swap.
Upon receiving the FRS signal from the source,
TCPC(TCPM_FRS_EVENT) informs TCPM to start the Fast role swap sequence.
1. TCPM sends FRS PD message: FR_SWAP_SEND
2. If response is not received within the expiry of
SenderResponseTimer, Error recovery is triggered.:
FR_SWAP_SEND_TIMEOUT
3. Upon receipt of the accept message, TCPM waits for
PSSourceOffTimer for PS_READY message from the partner:
FR_SWAP_SNK_SRC_NEW_SINK_READY.
TCPC is expected to autonomously turn on vbus once the FRS
signal is received and vbus voltage falls below vsafe5v within
tSrcFrSwap. This is different from traditional power role swap
where the vbus sourcing is turned on by TCPM.
4. By this time, TCPC most likely would have started to
source vbus, TCPM waits for tSrcFrSwap to see if the
lower level TCPC driver signals TCPM_SOURCING_VBUS event:
FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED.
5. When TCPC signals sourcing vbus, TCPM sends PS_READY msg and
changes the CC pin from Rd to Rp. This is the end of fast
role swap sequence and TCPM initiates the sequnce to negotiate
explicit contract by transitioning into SRC_STARTUP after
SwapSrcStart.
The code is written based on the sequence described in "Figure 8-107:
Dual-role Port in Sink to Source Fast Role Swap State Diagram" of
USB Power Delivery Specification Revision 3.0, Version 1.2.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
- Rebased on top of usb-next and resolved conflicts due to the below
changes:
3ed8e1c2ac99 usb: typec: tcpm: Migrate workqueue to RT priority for
processing events
6bbe2a90a0bb usb: typec: tcpm: During PR_SWAP, source caps should be sent
only after tSwapSourceStart
- enable_frs sequence is now run as part of the same kthread that runs
the state machines.
- Fixed the implicit fallthrough warning in the switch case for
FR_SWAP_CANCEL case.
Changes since v6:
- Moved frs_current from caps to tcpm_port as Heikki suggested.
Changes since v7:
- Added Reviewed-by: Heikki
Changes since v8:
- No change.
Changes since v9:
- No change
---
drivers/usb/typec/tcpm/tcpm.c | 229 +-
include/linux/usb/pd.h| 19 +--
include/linux/usb/tcpm.h | 8 +-
3 files changed, 244 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 92806547f485..55535c4f66bf 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -106,6 +106,13 @@
S(VCONN_SWAP_TURN_ON_VCONN),\
S(VCONN_SWAP_TURN_OFF_VCONN), \
\
+ S(FR_SWAP_SEND),\
+ S(FR_SWAP_SEND_TIMEOUT),\
+ S(FR_SWAP_SNK_SRC_TRANSITION_TO_OFF), \
+ S(FR_SWAP_SNK_SRC_NEW_SINK_READY), \
+ S(FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED), \
+ S(FR_SWAP_CANCEL), \
+ \
S(SNK_TRY), \
S(SNK_TRY_WAIT),\
S(SNK_TRY_WAIT_DEBOUNCE), \
@@ -127,6 +134,9 @@
S(GET_PPS_STATUS_SEND), \
S(GET_PPS_STATUS_SEND_TIMEOUT), \
\
+ S(GET_SINK_CAP),\
+ S(GET_SINK_CAP_TIMEOUT),\
+ \
S(ERROR_RECOVERY), \
S(PORT_RESET), \
S(PORT_RESET_WAIT_OFF)
@@ -170,11 +180,25 @@ enum adev_actions {
ADEV_ATTENTION,
};
+/*
+ * Initial current capability of the new source when vSafe5V is applied during
PD3.0 Fast Role Swap.
+ * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery
Specification Revision 3.0,
+ * Version 1.2"
+ */
+enum frs_typec_current {
+ FRS_NOT_SUPPORTED,
+ FRS_DEFAULT_POWER,
+ FRS_5V_1P5A,
+ FRS_5V_3A,
+};
+
/* Events from low level driver */
#define TCPM_CC_EVENT BIT(0)
#define TCPM_VBUS_EVENTBIT(1)
#define TCPM_RESET_EVENT BIT(2)
+#define TCPM_FRS_EVENT BIT(3)
+#define TCPM_SOURCING_VBUS BIT(4)
#define LOG_BUFFER_ENTRIES 1024
#define LOG_BUFFER_ENTRY_SIZE 128
@@ -184,6 +208,8 @@ enum
[PATCH v10 10/15] usb: typec: tcpci: frs sourcing vbus callback
During FRS hardware autonomously starts to source vbus. Provide
callback to perform chip specific operations.
Signed-off-by: Badhri Jagan Sridharan
---
v9 is the first version of this patch in the series. Added to fix
occasional bug of vbus turning back on when disconnecting the FRS accessory
after disconnect. No changes since v9.
---
drivers/usb/typec/tcpm/tcpci.c | 9 +
drivers/usb/typec/tcpm/tcpci.h | 4
2 files changed, 13 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index f9f0af64da5f..f91688e43991 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -284,6 +284,14 @@ static int tcpci_enable_frs(struct tcpc_dev *dev, bool
enable)
return ret;
}
+static void tcpci_frs_sourcing_vbus(struct tcpc_dev *dev)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+
+ if (tcpci->data->frs_sourcing_vbus)
+ tcpci->data->frs_sourcing_vbus(tcpci, tcpci->data);
+}
+
static int tcpci_set_bist_data(struct tcpc_dev *tcpc, bool enable)
{
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
@@ -628,6 +636,7 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data)
tcpci->tcpc.pd_transmit = tcpci_pd_transmit;
tcpci->tcpc.set_bist_data = tcpci_set_bist_data;
tcpci->tcpc.enable_frs = tcpci_enable_frs;
+ tcpci->tcpc.frs_sourcing_vbus = tcpci_frs_sourcing_vbus;
err = tcpci_parse_config(tcpci);
if (err < 0)
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 5ef07a56d67a..b418fe11b527 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -143,6 +143,9 @@
/*
* @TX_BUF_BYTE_x_hidden
* optional; Set when TX_BUF_BYTE_x can only be accessed through
I2C_WRITE_BYTE_COUNT.
+ * @frs_sourcing_vbus:
+ * Optional; Callback to perform chip specific operations when FRS
+ * is sourcing vbus.
*/
struct tcpci;
struct tcpci_data {
@@ -154,6 +157,7 @@ struct tcpci_data {
int (*start_drp_toggling)(struct tcpci *tcpci, struct tcpci_data *data,
enum typec_cc_status cc);
int (*set_vbus)(struct tcpci *tcpci, struct tcpci_data *data, bool
source, bool sink);
+ void (*frs_sourcing_vbus)(struct tcpci *tcpci, struct tcpci_data *data);
};
struct tcpci *tcpci_register_port(struct device *dev, struct tcpci_data *data);
--
2.28.0.806.g8561365e88-goog
[PATCH v10 09/15] usb: typec: tcpm: frs sourcing vbus callback
During FRS hardware autonomously starts to source vbus. Provide
callback to perform chip specific operations.
Signed-off-by: Badhri Jagan Sridharan
---
Introduced in v9. No chages since then.
---
drivers/usb/typec/tcpm/tcpm.c | 9 +
include/linux/usb/tcpm.h | 4
2 files changed, 13 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 55535c4f66bf..02b7f623f584 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4090,7 +4090,16 @@ static void _tcpm_pd_vbus_on(struct tcpm_port *port)
case SRC_TRY_DEBOUNCE:
/* Do nothing, waiting for sink detection */
break;
+ case FR_SWAP_SEND:
+ case FR_SWAP_SEND_TIMEOUT:
+ case FR_SWAP_SNK_SRC_TRANSITION_TO_OFF:
+ case FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED:
+ if (port->tcpc->frs_sourcing_vbus)
+ port->tcpc->frs_sourcing_vbus(port->tcpc);
+ break;
case FR_SWAP_SNK_SRC_NEW_SINK_READY:
+ if (port->tcpc->frs_sourcing_vbus)
+ port->tcpc->frs_sourcing_vbus(port->tcpc);
tcpm_set_state(port, FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED, 0);
break;
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 09762d26fa0c..7303f518ba49 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -83,6 +83,9 @@ enum tcpm_transmit_type {
* Optional; Called to enable/disable PD 3.0 fast role swap.
* Enabling frs is accessory dependent as not all PD3.0
* accessories support fast role swap.
+ * @frs_sourcing_vbus:
+ * Optional; Called to notify that vbus is now being sourced.
+ * Low level drivers can perform chip specific operations, if any.
*/
struct tcpc_dev {
struct fwnode_handle *fwnode;
@@ -109,6 +112,7 @@ struct tcpc_dev {
const struct pd_message *msg);
int (*set_bist_data)(struct tcpc_dev *dev, bool on);
int (*enable_frs)(struct tcpc_dev *dev, bool enable);
+ void (*frs_sourcing_vbus)(struct tcpc_dev *dev);
};
struct tcpm_port;
--
2.28.0.806.g8561365e88-goog
[PATCH v10 15/15] usb: typec: tcpci_maxim: Enable auto discharge disconnect
Enable auto discharge disconnect for Maxim TCPC. Signed-off-by: Badhri Jagan Sridharan --- Changes since v1: - Changing patch version to v6 to fix version number confusion. Changes since v6: - Rebase on usb-next. Changes since v7: - Heikki's suggestion: Moved the actual write of TCPC_VBUS_SINK_DISCONNECT_THRES register to tcpci code. Changes since v8: - Moved the logic to program the default values of TCPC_VBUS_SINK_DISCONNECT_THRESH into the tcpci code. Changes since v9: - none. --- drivers/usb/typec/tcpm/tcpci_maxim.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c b/drivers/usb/typec/tcpm/tcpci_maxim.c index 43dcad95e897..55dea33387ec 100644 --- a/drivers/usb/typec/tcpm/tcpci_maxim.c +++ b/drivers/usb/typec/tcpm/tcpci_maxim.c @@ -441,6 +441,7 @@ static int max_tcpci_probe(struct i2c_client *client, const struct i2c_device_id chip->data.TX_BUF_BYTE_x_hidden = true; chip->data.init = tcpci_init; chip->data.frs_sourcing_vbus = max_tcpci_frs_sourcing_vbus; + chip->data.auto_discharge_disconnect = true; max_tcpci_init_regs(chip); chip->tcpci = tcpci_register_port(chip->dev, &chip->data); -- 2.28.0.806.g8561365e88-goog
[PATCH v10 08/15] usb: typec: tcpci_maxim: Add support for Sink FRS
Upon receiving ALERT_EXTENDED.TCPC_SINK_FAST_ROLE_SWAP signal
tcpm to start Sink fast role swap signal.
Inform when TCPM is sourcing vbus.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- rebase on usb-next
- Added Reviewed-by: Heikki
Changes since v7:
- Rebase on usb-next
Changes since v8:
- None.
Changes since v9:
- None.
---
drivers/usb/typec/tcpm/tcpci_maxim.c | 50 +---
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
b/drivers/usb/typec/tcpm/tcpci_maxim.c
index 91337ddb4962..723d7dd38f75 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
@@ -106,13 +106,22 @@ static void max_tcpci_init_regs(struct max_tcpci_chip
*chip)
return;
}
+ ret = max_tcpci_write8(chip, TCPC_ALERT_EXTENDED, 0xff);
+ if (ret < 0) {
+ dev_err(chip->dev, "Unable to clear TCPC_ALERT_EXTENDED
ret:%d\n", ret);
+ return;
+ }
+
alert_mask = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_DISCARDED |
TCPC_ALERT_TX_FAILED |
TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_RX_STATUS |
TCPC_ALERT_CC_STATUS |
- TCPC_ALERT_VBUS_DISCNCT | TCPC_ALERT_RX_BUF_OVF |
TCPC_ALERT_POWER_STATUS;
+ TCPC_ALERT_VBUS_DISCNCT | TCPC_ALERT_RX_BUF_OVF |
TCPC_ALERT_POWER_STATUS |
+ /* Enable Extended alert for detecting Fast Role Swap Signal */
+ TCPC_ALERT_EXTND;
ret = max_tcpci_write16(chip, TCPC_ALERT_MASK, alert_mask);
if (ret < 0) {
- dev_err(chip->dev, "Error writing to TCPC_ALERT_MASK ret:%d\n",
ret);
+ dev_err(chip->dev,
+ "Error enabling TCPC_ALERT: TCPC_ALERT_MASK write
failed ret:%d\n", ret);
return;
}
@@ -122,6 +131,10 @@ static void max_tcpci_init_regs(struct max_tcpci_chip
*chip)
dev_err(chip->dev, "Error writing to TCPC_POWER_CTRL ret:%d\n",
ret);
return;
}
+
+ ret = max_tcpci_write8(chip, TCPC_ALERT_EXTENDED_MASK,
TCPC_SINK_FAST_ROLE_SWAP);
+ if (ret < 0)
+ return;
}
static void process_rx(struct max_tcpci_chip *chip, u16 status)
@@ -225,10 +238,23 @@ static void process_power_status(struct max_tcpci_chip
*chip)
if (ret < 0)
return;
- if (pwr_status == 0xff)
+ if (pwr_status == 0xff) {
max_tcpci_init_regs(chip);
- else
+ } else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS) {
+ tcpm_sourcing_vbus(chip->port);
+ /*
+* Alawys re-enable boost here.
+* In normal case, when say an headset is attached, TCPM would
+* have instructed to TCPC to enable boost, so the call is a
+* no-op.
+* But for Fast Role Swap case, Boost turns on autonomously
without
+* AP intervention, but, needs AP to enable source mode
explicitly
+* for AP to regain control.
+*/
+ max_tcpci_set_vbus(chip->tcpci, &chip->data, true, false);
+ } else {
tcpm_vbus_change(chip->port);
+ }
}
static void process_tx(struct max_tcpci_chip *chip, u16 status)
@@ -249,6 +275,7 @@ static irqreturn_t _max_tcpci_irq(struct max_tcpci_chip
*chip, u16 status)
{
u16 mask;
int ret;
+ u8 reg_status;
/*
* Clear alert status for everything except RX_STATUS, which shouldn't
@@ -274,6 +301,21 @@ static irqreturn_t _max_tcpci_irq(struct max_tcpci_chip
*chip, u16 status)
}
}
+ if (status & TCPC_ALERT_EXTND) {
+ ret = max_tcpci_read8(chip, TCPC_ALERT_EXTENDED, ®_status);
+ if (ret < 0)
+ return ret;
+
+ ret = max_tcpci_write8(chip, TCPC_ALERT_EXTENDED, reg_status);
+ if (ret < 0)
+ return ret;
+
+ if (reg_status & TCPC_SINK_FAST_ROLE_SWAP) {
+ dev_info(chip->dev, "FRS Signal");
+ tcpm_sink_frs(chip->port);
+ }
+ }
+
if (status & TCPC_ALERT_RX_STATUS)
process_rx(chip, status);
--
2.28.0.806.g8561365e88-goog
[PATCH v10 14/15] usb: typec: tcpci: Implement Auto discharge disconnect callbacks
vImplement callbacks for enabling/disabling
POWER_CONTROL.AutoDischargeDisconnect.
Programs VBUS_SINK_DISCONNECT_THRESHOLD based on the
voltage requested as sink, mode of operation.
The programmed threshold is based on vSinkDisconnect and
vSinkDisconnectPD values.
Add auto_discharge_disconnect to tdata to allow TCPC chip
level drivers enable AutoDischargeDisconnect.
Signed-off-by: Badhri Jagan Sridharan
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Rebase on usb-next.
Changes since v7:
Heikki's suggestion:
- Moved the actual write to TCPC_VBUS_SINK_DISCONNECT_THRESH
as it's common to all chip drivers.
- Renaming the tcpci_data callback as
get_auto_vbus_discharge_threshold
Changes since v8:
- Removed get_auto_vbus_discharge_threshold callback and moved the logic
to program the default threshold for TCPC_VBUS_SINK_DISCONNECT_THRESH
into the TCPCI code.
Changes since v9:
- none
---
drivers/usb/typec/tcpm/tcpci.c | 63 +-
drivers/usb/typec/tcpm/tcpci.h | 14 ++--
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index f91688e43991..12d983a75510 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -18,7 +18,10 @@
#include "tcpci.h"
-#define PD_RETRY_COUNT 3
+#definePD_RETRY_COUNT 3
+#defineAUTO_DISCHARGE_DEFAULT_THRESHOLD_MV 3500
+#defineAUTO_DISCHARGE_PD_HEADROOM_MV 850
+#defineAUTO_DISCHARGE_PPS_HEADROOM_MV 1250
struct tcpci {
struct device *dev;
@@ -268,6 +271,58 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool
enable)
enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
}
+static int tcpci_enable_auto_vbus_discharge(struct tcpc_dev *dev, bool enable)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+ int ret;
+
+ ret = regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
TCPC_POWER_CTRL_AUTO_DISCHARGE,
+enable ? TCPC_POWER_CTRL_AUTO_DISCHARGE : 0);
+ return ret;
+}
+
+static int tcpci_set_auto_vbus_discharge_threshold(struct tcpc_dev *dev, enum
typec_pwr_opmode mode,
+ bool pps_active, u32
requested_vbus_voltage_mv)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+ unsigned int pwr_ctrl, threshold = 0;
+ int ret;
+
+ /*
+* Indicates that vbus is going to go away due PR_SWAP, hard reset etc.
+* Do not discharge vbus here.
+*/
+ if (requested_vbus_voltage_mv == 0)
+ goto write_thresh;
+
+ ret = regmap_read(tcpci->regmap, TCPC_POWER_CTRL, &pwr_ctrl);
+ if (ret < 0)
+ return ret;
+
+ if (pwr_ctrl & TCPC_FAST_ROLE_SWAP_EN) {
+ /* To prevent disconnect when the source is fast role swap is
capable. */
+ threshold = AUTO_DISCHARGE_DEFAULT_THRESHOLD_MV;
+ } else if (mode == TYPEC_PWR_MODE_PD) {
+ if (pps_active)
+ threshold = (95 * requested_vbus_voltage_mv / 100) -
+ AUTO_DISCHARGE_PD_HEADROOM_MV;
+ else
+ threshold = (95 * requested_vbus_voltage_mv / 100) -
+ AUTO_DISCHARGE_PPS_HEADROOM_MV;
+ } else {
+ /* 3.5V for non-pd sink */
+ threshold = AUTO_DISCHARGE_DEFAULT_THRESHOLD_MV;
+ }
+
+ threshold = threshold / TCPC_VBUS_SINK_DISCONNECT_THRESH_LSB_MV;
+
+ if (threshold > TCPC_VBUS_SINK_DISCONNECT_THRESH_MAX)
+ return -EINVAL;
+
+write_thresh:
+ return tcpci_write16(tcpci, TCPC_VBUS_SINK_DISCONNECT_THRESH,
threshold);
+}
+
static int tcpci_enable_frs(struct tcpc_dev *dev, bool enable)
{
struct tcpci *tcpci = tcpc_to_tcpci(dev);
@@ -638,6 +693,12 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data)
tcpci->tcpc.enable_frs = tcpci_enable_frs;
tcpci->tcpc.frs_sourcing_vbus = tcpci_frs_sourcing_vbus;
+ if (tcpci->data->auto_discharge_disconnect) {
+ tcpci->tcpc.enable_auto_vbus_discharge =
tcpci_enable_auto_vbus_discharge;
+ tcpci->tcpc.set_auto_vbus_discharge_threshold =
+ tcpci_set_auto_vbus_discharge_threshold;
+ }
+
err = tcpci_parse_config(tcpci);
if (err < 0)
return ERR_PTR(err);
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index b418fe11b527..3fe313655f0c 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -8,6 +8,8 @@
#ifndef __LINUX_USB_TCPCI_H
#define __LINUX_USB_TCPCI_H
+#include
+
#define TCPC_VENDOR_ID 0x0
#define TCPC_PRODUCT_ID0x2
#define TCPC_BCD_DEV
[PATCH v10 07/15] usb: typec: tcpci: Implement callbacks for FRS
Implement tcpc.enable_frs to enable TCPC to receive
Fast role swap signal.
Additionally set the sink disconnect threshold to 4v
to prevent disconnect during Fast Role swap.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Rebase on usb-next.
- Fixed formatting error.
- Added Reviewed-by: Heikki.
Changes since v7:
- Rebase on usb-next.
Changes since v8:
- None.
Changes since v9:
- None.
---
drivers/usb/typec/tcpm/tcpci.c | 17 +
drivers/usb/typec/tcpm/tcpci.h | 8
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index d6a6fac82d48..f9f0af64da5f 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -268,6 +268,22 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool
enable)
enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
}
+static int tcpci_enable_frs(struct tcpc_dev *dev, bool enable)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+ int ret;
+
+ /* To prevent disconnect during FRS, set disconnect threshold to 3.5V */
+ ret = tcpci_write16(tcpci, TCPC_VBUS_SINK_DISCONNECT_THRESH, enable ? 0
: 0x8c);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
TCPC_FAST_ROLE_SWAP_EN, enable ?
+TCPC_FAST_ROLE_SWAP_EN : 0);
+
+ return ret;
+}
+
static int tcpci_set_bist_data(struct tcpc_dev *tcpc, bool enable)
{
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
@@ -611,6 +627,7 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data)
tcpci->tcpc.set_roles = tcpci_set_roles;
tcpci->tcpc.pd_transmit = tcpci_pd_transmit;
tcpci->tcpc.set_bist_data = tcpci_set_bist_data;
+ tcpci->tcpc.enable_frs = tcpci_enable_frs;
err = tcpci_parse_config(tcpci);
if (err < 0)
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 82f021a82456..5ef07a56d67a 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -16,6 +16,7 @@
#define TCPC_PD_INT_REV0xa
#define TCPC_ALERT 0x10
+#define TCPC_ALERT_EXTND BIT(14)
#define TCPC_ALERT_EXTENDED_STATUS BIT(13)
#define TCPC_ALERT_VBUS_DISCNCTBIT(11)
#define TCPC_ALERT_RX_BUF_OVF BIT(10)
@@ -37,6 +38,9 @@
#define TCPC_EXTENDED_STATUS_MASK 0x16
#define TCPC_EXTENDED_STATUS_MASK_VSAFE0V BIT(0)
+#define TCPC_ALERT_EXTENDED_MASK 0x17
+#define TCPC_SINK_FAST_ROLE_SWAP BIT(0)
+
#define TCPC_CONFIG_STD_OUTPUT 0x18
#define TCPC_TCPC_CTRL 0x19
@@ -63,6 +67,7 @@
#define TCPC_POWER_CTRL0x1c
#define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0)
+#define TCPC_FAST_ROLE_SWAP_EN BIT(7)
#define TCPC_CC_STATUS 0x1d
#define TCPC_CC_STATUS_TOGGLINGBIT(5)
@@ -74,11 +79,14 @@
#define TCPC_POWER_STATUS 0x1e
#define TCPC_POWER_STATUS_UNINIT BIT(6)
+#define TCPC_POWER_STATUS_SOURCING_VBUSBIT(4)
#define TCPC_POWER_STATUS_VBUS_DET BIT(3)
#define TCPC_POWER_STATUS_VBUS_PRESBIT(2)
#define TCPC_FAULT_STATUS 0x1f
+#define TCPC_ALERT_EXTENDED0x21
+
#define TCPC_COMMAND 0x23
#define TCPC_CMD_WAKE_I2C 0x11
#define TCPC_CMD_DISABLE_VBUS_DETECT 0x22
--
2.28.0.806.g8561365e88-goog
[PATCH v10 11/15] usb: typec: tcpci_max77759: Fix vbus stuck on upon diconnecting sink
Occasionally, POWER_STATUS.sourcing_vbus takes a while to clear after
writing to MAX_BUCK_BOOST_OP register. This causes vbus to turn back
on while disconnecting the sink. Overcome this issue by writing into
MAX_BUCK_BOOST_OP during frs while sourcing vbu, instead of always
into the register whenever POWER_STATUS.sourcing_vbus is set.
Signed-off-by: Badhri Jagan Sridharan
---
v9 is the first version of this patch. Added to fix
occasional bug of vbus turning back on when disconnecting the FRS accessory
after disconnect. No changes since v9.
---
drivers/usb/typec/tcpm/tcpci_maxim.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
b/drivers/usb/typec/tcpm/tcpci_maxim.c
index 723d7dd38f75..43dcad95e897 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
@@ -238,23 +238,22 @@ static void process_power_status(struct max_tcpci_chip
*chip)
if (ret < 0)
return;
- if (pwr_status == 0xff) {
+ if (pwr_status == 0xff)
max_tcpci_init_regs(chip);
- } else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS) {
+ else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS)
tcpm_sourcing_vbus(chip->port);
- /*
-* Alawys re-enable boost here.
-* In normal case, when say an headset is attached, TCPM would
-* have instructed to TCPC to enable boost, so the call is a
-* no-op.
-* But for Fast Role Swap case, Boost turns on autonomously
without
-* AP intervention, but, needs AP to enable source mode
explicitly
-* for AP to regain control.
-*/
- max_tcpci_set_vbus(chip->tcpci, &chip->data, true, false);
- } else {
+ else
tcpm_vbus_change(chip->port);
- }
+}
+
+static void max_tcpci_frs_sourcing_vbus(struct tcpci *tcpci, struct tcpci_data
*tdata)
+{
+ /*
+* For Fast Role Swap case, Boost turns on autonomously without
+* AP intervention, but, needs AP to enable source mode explicitly
+* for AP to regain control.
+*/
+ max_tcpci_set_vbus(tcpci, tdata, true, false);
}
static void process_tx(struct max_tcpci_chip *chip, u16 status)
@@ -441,6 +440,7 @@ static int max_tcpci_probe(struct i2c_client *client, const
struct i2c_device_id
chip->data.start_drp_toggling = max_tcpci_start_toggling;
chip->data.TX_BUF_BYTE_x_hidden = true;
chip->data.init = tcpci_init;
+ chip->data.frs_sourcing_vbus = max_tcpci_frs_sourcing_vbus;
max_tcpci_init_regs(chip);
chip->tcpci = tcpci_register_port(chip->dev, &chip->data);
--
2.28.0.806.g8561365e88-goog
[PATCH v10 12/15] usb: typec: tcpm: Parse frs type-c current from device tree
New source's current capability is now defined as string based
device tree property through new-source-frs-typec-current.
Refactor tcpm code to parse new-source-frs-typec-current and
infer local port's new source current capability during frs.
Signed-off-by: Badhri Jagan Sridharan
---
v9 is the first version of this patch in this series to rebase
TCPM code to read new source frs current from
new-source-frs-typec-current. No changes since v9.
---
drivers/usb/typec/tcpm/tcpm.c | 41 +++
include/linux/usb/typec.h | 12 ++
2 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 02b7f623f584..d5a3e2b3bea2 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -180,16 +180,11 @@ enum adev_actions {
ADEV_ATTENTION,
};
-/*
- * Initial current capability of the new source when vSafe5V is applied during
PD3.0 Fast Role Swap.
- * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery
Specification Revision 3.0,
- * Version 1.2"
- */
-enum frs_typec_current {
- FRS_NOT_SUPPORTED,
- FRS_DEFAULT_POWER,
- FRS_5V_1P5A,
- FRS_5V_3A,
+static const char * const typec_new_source_frs_current[] = {
+ [FRS_NOT_SUPPORTED] = "not-supported",
+ [FRS_DEFAULT_POWER] = "default",
+ [FRS_5V_1P5A] = "1.5A",
+ [FRS_5V_3A] = "3.0A",
};
/* Events from low level driver */
@@ -364,7 +359,7 @@ struct tcpm_port {
bool self_powered;
/* FRS */
- enum frs_typec_current frs_current;
+ enum typec_new_source_frs_current new_source_frs_current;
/* Sink caps have been queried */
bool sink_cap_done;
@@ -1713,7 +1708,7 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
unsigned int cnt = pd_header_cnt_le(msg->header);
unsigned int rev = pd_header_rev_le(msg->header);
unsigned int i;
- enum frs_typec_current frs_current;
+ enum typec_new_source_frs_current partner_frs_current;
bool frs_enable;
int ret;
@@ -1786,12 +1781,13 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
for (i = 0; i < cnt; i++)
port->sink_caps[i] = le32_to_cpu(msg->payload[i]);
- frs_current = (port->sink_caps[0] & PDO_FIXED_FRS_CURR_MASK) >>
+ partner_frs_current = (port->sink_caps[0] &
PDO_FIXED_FRS_CURR_MASK) >>
PDO_FIXED_FRS_CURR_SHIFT;
- frs_enable = frs_current && (frs_current <= port->frs_current);
+ frs_enable = partner_frs_current && (partner_frs_current <=
+
port->new_source_frs_current);
tcpm_log(port,
"Port partner FRS capable partner_frs_current:%u
port_frs_current:%u enable:%c",
-frs_current, port->frs_current, frs_enable ? 'y' :
'n');
+partner_frs_current, port->new_source_frs_current,
frs_enable ? 'y' : 'n');
if (frs_enable) {
ret = port->tcpc->enable_frs(port->tcpc, true);
tcpm_log(port, "Enable FRS %s, ret:%d\n", ret ? "fail"
: "success", ret);
@@ -4746,7 +4742,8 @@ static int tcpm_fw_get_caps(struct tcpm_port *port,
{
const char *cap_str;
int ret;
- u32 mw, frs_current;
+ u32 mw;
+ const char *new_source_frs_current;
if (!fwnode)
return -EINVAL;
@@ -4817,9 +4814,15 @@ static int tcpm_fw_get_caps(struct tcpm_port *port,
/* FRS can only be supported byb DRP ports */
if (port->port_type == TYPEC_PORT_DRP) {
- ret = fwnode_property_read_u32(fwnode, "frs-typec-current",
&frs_current);
- if (ret >= 0 && frs_current <= FRS_5V_3A)
- port->frs_current = frs_current;
+ ret = fwnode_property_read_string(fwnode,
"new-source-frs-typec-current",
+ &new_source_frs_current);
+ if (!ret) {
+ ret = match_string(typec_new_source_frs_current,
+
ARRAY_SIZE(typec_new_source_frs_current),
+ new_source_frs_current);
+ if (ret >= 0)
+ port->new_source_frs_current = ret;
+ }
}
return 0;
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 6be558045942..3198b89fa451 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -72,6 +72,18 @@ enum typec_orientation {
TYPEC_ORIENTATION_REVERSE,
};
+/*
+ * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery
Specification Revision 3.0,
+ * Version 1.2"
+ * Initial current capability of the new sou
[PATCH v10 04/15] usb: typec: tcpci_maxim: Chip level TCPC driver
Chip level TCPC driver for Maxim's TCPCI implementation.
This TCPC implementation does not support the following
commands: COMMAND.SinkVbus, COMMAND.SourceVbusDefaultVoltage,
COMMAND.SourceVbusHighVoltage. Instead the sinking and sourcing
from vbus is supported by writes to custom registers.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
- Removed setting USB_PSY and terminating description with period as
suggested by Randy.
Changes since v6:
- Addressed Heikki comments:
- Removed TX discarded message
- Removed the redundant TCPC_POWER_STATUS_UNINIT check
- Cleaned up irq setup routine
Changes since v7:
- Added reviewed-by: Heikki
Changes since v8:
- None
Changes since v9:
- None
---
drivers/usb/typec/tcpm/Kconfig | 6 +
drivers/usb/typec/tcpm/Makefile | 15 +-
drivers/usb/typec/tcpm/tcpci.h | 1 +
drivers/usb/typec/tcpm/tcpci_maxim.c | 461 +++
4 files changed, 476 insertions(+), 7 deletions(-)
create mode 100644 drivers/usb/typec/tcpm/tcpci_maxim.c
diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index 58a64e1bf627..557f392fe24d 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -35,6 +35,12 @@ config TYPEC_MT6360
USB Type-C. It works with Type-C Port Controller Manager
to provide USB PD and USB Type-C functionalities.
+config TYPEC_TCPCI_MAXIM
+ tristate "Maxim TCPCI based Type-C chip driver"
+ help
+ MAXIM TCPCI based Type-C/PD chip driver. Works with
+ with Type-C Port Controller Manager.
+
endif # TYPEC_TCPCI
config TYPEC_FUSB302
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index 7592ccb8c526..7d499f3569fd 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -1,8 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
-obj-$(CONFIG_TYPEC_FUSB302)+= fusb302.o
-obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
-typec_wcove-y := wcove.o
-obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
-obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
-obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
+obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
+obj-$(CONFIG_TYPEC_FUSB302)+= fusb302.o
+obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
+typec_wcove-y := wcove.o
+obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
+obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
+obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
+obj-$(CONFIG_TYPEC_TCPCI_MAXIM)+= tcpci_maxim.o
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 4d441bdf24d5..82f021a82456 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -109,6 +109,7 @@
#define TCPC_RX_BYTE_CNT 0x30
#define TCPC_RX_BUF_FRAME_TYPE 0x31
+#define TCPC_RX_BUF_FRAME_TYPE_SOP 0
#define TCPC_RX_HDR0x32
#define TCPC_RX_DATA 0x34 /* through 0x4f */
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
b/drivers/usb/typec/tcpm/tcpci_maxim.c
new file mode 100644
index ..91337ddb4962
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020, Google LLC
+ *
+ * MAXIM TCPCI based TCPC driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tcpci.h"
+
+#define PD_ACTIVITY_TIMEOUT_MS 1
+
+#define TCPC_VENDOR_ALERT 0x80
+
+#define TCPC_RECEIVE_BUFFER_COUNT_OFFSET 0
+#define TCPC_RECEIVE_BUFFER_FRAME_TYPE_OFFSET 1
+#define TCPC_RECEIVE_BUFFER_RX_BYTE_BUF_OFFSET 2
+
+/*
+ * LongMessage not supported, hence 32 bytes for buf to be read from
RECEIVE_BUFFER.
+ * DEVICE_CAPABILITIES_2.LongMessage = 0, the value in READABLE_BYTE_COUNT reg
shall be
+ * less than or equal to 31. Since, RECEIVE_BUFFER len = 31 +
1(READABLE_BYTE_COUNT).
+ */
+#define TCPC_RECEIVE_BUFFER_LEN32
+
+#define MAX_BUCK_BOOST_SID 0x69
+#define MAX_BUCK_BOOST_OP 0xb9
+#define MAX_BUCK_BOOST_OFF 0
+#define MAX_BUCK_BOOST_SOURCE 0xa
+#define MAX_BUCK_BOOST_SINK0x5
+
+struct max_tcpci_chip {
+ struct tcpci_data data;
+ struct tcpci *tcpci;
+ struct device *dev;
+ struct i2c_client *client;
+ struct tcpm_port *port;
+};
+
+static const struct regmap_range max_tcpci_tcpci_range[] = {
+ regmap_reg_range(0x00, 0x95)
+};
+
+const struct regmap_access_table max_tcpci_tcpci_write_table
[PATCH v10 01/15] usb: typec: tcpci: Add a getter method to retrieve tcpm_port reference
Allow chip level drivers to retrieve reference to tcpm_port.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Change since v1:
- Changing patch version to v6 to fix version number confusion.
Change since v6:
- Rebase on usb-next
- Added Reviewed-by from Heikki.
Change since v7:
- Rebase on usb-next
Change since v8:
- None
Change since v9:
- None
---
drivers/usb/typec/tcpm/tcpci.c | 6 ++
drivers/usb/typec/tcpm/tcpci.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index 7d9491ba62fb..b960fe5a0f28 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -38,6 +38,12 @@ struct tcpci_chip {
struct tcpci_data data;
};
+struct tcpm_port *tcpci_get_tcpm_port(struct tcpci *tcpci)
+{
+ return tcpci->port;
+}
+EXPORT_SYMBOL_GPL(tcpci_get_tcpm_port);
+
static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
{
return container_of(tcpc, struct tcpci, tcpc);
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index cf9d8b63adcb..04c49a0b0368 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -150,4 +150,6 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data);
void tcpci_unregister_port(struct tcpci *tcpci);
irqreturn_t tcpci_irq(struct tcpci *tcpci);
+struct tcpm_port;
+struct tcpm_port *tcpci_get_tcpm_port(struct tcpci *tcpci);
#endif /* __LINUX_USB_TCPCI_H */
--
2.28.0.806.g8561365e88-goog
[PATCH v10 00/15] TCPM support for FRS and AutoDischarge Disconnect
Hi, Made two changes: 1. Added "additionalProperties: false" as suggested by Rob Herring in https://lore.kernel.org/linux-usb/20201005144618.GA154206@bogus/ 2. Removed FRS dts binding constants to address Rob Herring's comment in https://lore.kernel.org/linux-usb/20201006182940.GA2574941@bogus/ Thanks, Badhri Badhri Jagan Sridharan (15): usb: typec: tcpci: Add a getter method to retrieve tcpm_port reference usb: typec: tcpci: Add set_vbus tcpci callback dt-bindings: usb: Maxim type-c controller device tree binding document usb: typec: tcpci_maxim: Chip level TCPC driver dt-bindings: connector: Add property to set initial current cap for FRS usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS) usb: typec: tcpci: Implement callbacks for FRS usb: typec: tcpci_maxim: Add support for Sink FRS usb: typec: tcpm: frs sourcing vbus callback usb: typec: tcpci: frs sourcing vbus callback usb: typec: tcpci_max77759: Fix vbus stuck on upon diconnecting sink usb: typec: tcpm: Parse frs type-c current from device tree usb: typec: tcpm: Implement enabling Auto Discharge disconnect support usb: typec: tcpci: Implement Auto discharge disconnect callbacks usb: typec: tcpci_maxim: Enable auto discharge disconnect .../bindings/connector/usb-connector.yaml | 26 + .../devicetree/bindings/usb/maxim,tcpci.yaml | 70 +++ drivers/usb/typec/tcpm/Kconfig| 6 + drivers/usb/typec/tcpm/Makefile | 15 +- drivers/usb/typec/tcpm/tcpci.c| 102 +++- drivers/usb/typec/tcpm/tcpci.h| 30 +- drivers/usb/typec/tcpm/tcpci_maxim.c | 504 ++ drivers/usb/typec/tcpm/tcpm.c | 299 ++- include/linux/usb/pd.h| 19 +- include/linux/usb/tcpm.h | 27 +- include/linux/usb/typec.h | 12 + 11 files changed, 1085 insertions(+), 25 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/maxim,tcpci.yaml create mode 100644 drivers/usb/typec/tcpm/tcpci_maxim.c -- 2.28.0.806.g8561365e88-goog
[PATCH v10 05/15] dt-bindings: connector: Add property to set initial current cap for FRS
This change adds frs-typec-current which allows setting the initial current capability of the new source when vSafe5V is applied during PD3.0 sink Fast Role Swap. Signed-off-by: Badhri Jagan Sridharan --- Changes since v1: - Changing patch version to v6 to fix version number confusion. Changes since v6: - Removed the redundant usb-connector.txt that I created by mistake. - Moved to yaml. Changes since v7: - Rebase Changes since v8: - Redefine new-source-frs-typec-current as string enums to address Rob Herring's comment. Changes since v9: - Removed FRS constants from usb bindings. --- .../bindings/connector/usb-connector.yaml | 26 +++ 1 file changed, 26 insertions(+) diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 9bd52e63c935..d9f65e81065e 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -142,6 +142,32 @@ properties: required: - port@0 + new-source-frs-typec-current: +description: Initial current capability of the new source when vSafe5V + is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO - Sink" + of "USB Power Delivery Specification Revision 3.0, Version 1.2" provides the + different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C Current" + provides a detailed description of the field. The sink PDO from current source + reflects the current source's(i.e. transmitter of the FRS signal) power + requirement during fr swap. The current sink (i.e. receiver of the FRS signal), + a.k.a new source, should check if it will be able to satisfy the current source's, + new sink's, requirement during frswap before enabling the frs signal reception. + This property refers to maximum current capability that the current sink can + satisfy. During FRS, VBUS voltage is at 5V, as the partners are in implicit + contract, hence, the power level is only a function of the current capability. + "not-supported" implies sink to source fast role swap not supported. + "default" refers to default USB power level as described by + "Table 6-14 Fixed Supply PDO - Sink". + "1.5A" refers to 1.5A@5V. + "3.0A" refers to 3.0A@5V. + +$ref: /schemas/types.yaml#/definitions/string +enum: + - not-supported + - default + - 1.5A + - 3.0A + required: - compatible -- 2.28.0.806.g8561365e88-goog
Re: [PATCH v2] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
On Thu, Oct 08, 2020 at 07:30:27AM +0200, Mauro Carvalho Chehab wrote: > As warned by Randy: > > on x86_64: > CONFIG_USB_ROLE_SWITCH=m > and HISI_HIKEY_USB=y. > > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': > hisi_hikey_usb.c:(.text+0x61): undefined reference to > `usb_role_switch_unregister' > ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to > `usb_role_switch_put' > ld: drivers/misc/hisi_hikey_usb.o: in function > `hub_usb_role_switch_set': > hisi_hikey_usb.c:(.text+0xd3): undefined reference to > `usb_role_switch_get_drvdata' > ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': > hisi_hikey_usb.c:(.text+0x54d): undefined reference to > `usb_role_switch_set_role' > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': > hisi_hikey_usb.c:(.text+0x8a5): undefined reference to > `usb_role_switch_get' > ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to > `usb_role_switch_register' > ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to > `usb_role_switch_put' > > Make it dependent on CONFIG_USB_ROLE_SWITCH. > > Reported-by: Randy Dunlap > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/misc/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index e19e1dcceb41..d5ce8082b0a0 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -459,6 +459,7 @@ config PVPANIC > config HISI_HIKEY_USB > tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" > depends on (OF && GPIOLIB) || COMPILE_TEST > + depends on USB_ROLE_SWITCH > help > If you say yes here this adds support for the on-board USB GPIO hub > found on HiKey 960/970 boards, which is necessary to support I can't rebase my tree, so can you send the fix-up patch instead, with the proper "reported-by:"? thanks, greg k-h
Re: [PATCH] docs: Make automarkup ready for Sphinx 3.1+
Em Thu, 8 Oct 2020 03:47:06 +0100 Matthew Wilcox escreveu: > On Thu, Oct 08, 2020 at 02:15:24AM +, Nícolas F. R. A. Prado wrote: > > > I have a feature request ... could you automarkup NULL as being > > > :c:macro? > > > Or maybe just anything matching \<[[:upper:]_[:digit:]]*\> > > > (i may have my regex syntax confused ... a word composed of any > > > arrangement of upper-case, digits and underscores.) > > > > I think what you are suggesting are two separate things. > > > > For NULL, what you're interested in is that it appears in a monospaced > > font, as > > if written ``NULL``, right? As I don't think a cross-reference to "the NULL > > macro definition" would make much sense. > > > > While "anything containing only upper-case, digits and underscores" would > > actually be for cross-referencing to the definition of the macro symbol in > > question, right? > > Well, maybe! What I'd really like is to remove all the markup from > xarray.rst. Jon managed to get rid of most of it with the (), but > there's still markup on: > > LONG_MAX > NULL > -EBUSY > true > XA_MARK_[012] > XA_FLAGS_* > ENOMEM > EINVAL > > I'm not sure there's much that automarkup can do about ``true``, but all > the others fit the all-caps-and-underscore-and-digits pattern. > > I don't know how much we want errnos to link to anything in particular. > So maybe split these into 'well-known' (eg defined by ANSI C or POSIX) > definitions and things which are local macros: > > LONG_MAX > NULL > -EBUSY > ENOMEM > EINVAL Yeah, a nice improvement would be to auto-markup error codes and NULL as literal blocks. > > vs > > XA_MARK_[012] > XA_FLAGS_* Actually, things that end with an * (but doesn't start with an *) are good candidates for being literals - although extra care should be taken on such case, as parsing those automatically will likely hit lots of false-positives. > I'm willing to add more inline kernel-doc to get this to work better. Why? inline kernel-doc should be evaluated just like normal blocks. Right now, kernel-doc handles constants like NULL and XA_FLAGS_* using two ways: %FOO or ``FOO`` The regex for those are: my $type_constant = '\b``([^\`]+)``\b'; my $type_constant2 = '\%([-_\w]+)'; In other words, "%FOO" should not contain any symbol, except for '-' and '_'. If there is any other symbol, like in "XA_FLAGS_*", the alternative syntax is needed. No matter if you use inline or block definitions, the same regexes are used. > Or even convert #defines to enums ... whatever gets this working better. Using enums where possible[1] is nicer, IMHO. [1] enums shouldn't be used on uAPI, as its size depends on the C compiler implementation. Thanks, Mauro
[PATCH] lib/mpi: Remove unused scalar_copied
On Mon, Sep 28, 2020 at 01:24:38PM -0500, Gustavo A. R. Silva wrote:
>
> I'm reporting the following bug detected by Coverity:
>
> The _scalar_copied_ variable is set to 0 at
>
> lib/mpi/ec.c:1255:
> 1255 int scalar_copied = 0;
>
> and it is never updated before reaching the code below:
>
> lib/mpi/ec.c:1317
> 1317 if (scalar_copied)
>
> 1318 mpi_free(scalar);
>
> This code was introduced by commit d58bb7e55a8a ("lib/mpi: Introduce ec
> implementation to MPI library")
>
> Any ideas on what's the right solution for this?
I think it should be removed.
---8<---
The scalar_copied variable is not as the scalar is never copied
in that block. This patch removes it.
Fixes: d58bb7e55a8a ("lib/mpi: Introduce ec implementation to...")
Reported-by: Gustavo A. R. Silva
Signed-off-by: Herbert Xu
diff --git a/lib/mpi/ec.c b/lib/mpi/ec.c
index c21470122dfc..40f5908e57a4 100644
--- a/lib/mpi/ec.c
+++ b/lib/mpi/ec.c
@@ -1252,7 +1252,6 @@ void mpi_ec_mul_point(MPI_POINT result,
MPI_POINT q1, q2, prd, sum;
unsigned long sw;
mpi_size_t rsize;
- int scalar_copied = 0;
/* Compute scalar point multiplication with Montgomery Ladder.
* Note that we don't use Y-coordinate in the points at all.
@@ -1314,8 +1313,6 @@ void mpi_ec_mul_point(MPI_POINT result,
point_free(&p2);
point_free(&p1_);
point_free(&p2_);
- if (scalar_copied)
- mpi_free(scalar);
return;
}
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [v5 01/12] struct device: Add function callback durable_name
On 10/7/20 10:10 PM, Tony Asleson wrote: On 10/1/20 6:48 AM, Greg Kroah-Hartman wrote: On Wed, Sep 30, 2020 at 09:35:52AM -0500, Tony Asleson wrote: On 9/30/20 2:38 AM, Greg Kroah-Hartman wrote: On Tue, Sep 29, 2020 at 05:04:32PM -0500, Tony Asleson wrote: I'm trying to figure out a way to positively identify which storage device an error belongs to over time. "over time" is not the kernel's responsibility. This comes up every 5 years or so. The kernel provides you, at runtime, a mapping between a hardware device and a "logical" device. It can provide information to userspace about this mapping, but once that device goes away, the kernel is free to reuse that logical device again. If you want to track what logical devices match up to what physical device, then do it in userspace, by parsing the log files. I don't understand why people think it's acceptable to ask user space to parse text that is subject to change. What text is changing? The format of of the prefix of dev_*() is well known and has been stable for 15+ years now, right? What is difficult in parsing it? Many of the storage layer messages are using printk, not dev_printk. So that would be the immediate angle of attack ... Thank you for supplying some feedback and asking questions. I've been asking for suggestions and would very much like to have a discussion on how this issue is best solved. I'm not attached to what I've provided. I'm just trying to get towards a solution. Again, solve this in userspace, you have the information there at runtime, why not use it? We usually don't have the needed information if you remove the expectation that user space should parse the human readable portion of the error message. I don't expect that userspace should have to parse any human readable portion, if they don't want to. But if you do want it to, it is pretty trivial to parse what you have today: scsi 2:0:0:0: Direct-Access Generic STORAGE DEVICE 1531 PQ: 0 ANSI: 6 If you really have a unique identifier, then great, parse it today: usb 4-1.3.1: Product: USB3.0 Card Reader usb 4-1.3.1: Manufacturer: Generic usb 4-1.3.1: SerialNumber: 1531 What's keeping that from working now? I believe these examples are using dev_printk. With dev_printk we don't need to parse the text, we can use the meta data. So it looks as most of your usecase would be solved by moving to dev_printk(). Why not work on that instead? I do presume this will have immediate benefits for everybody, and will have approval from everyone. Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
Re: [v2 PATCH] crypto: sun4i-ss - Fix sparse endianness markers
On Thu, Sep 24, 2020 at 03:27:38PM +0200, Corentin Labbe wrote: > > This is an example on next-20200923+BigEndian > alg: ahash: sha1 test failed (wrong result) on test vector \"random: > psize=194 ksize=0\", cfg=\"random: inplace may_sleep use_finup > src_divs=[98.25%@+1124, 1.75%@+5] iv_offset=18\" Hmm, the only way I can see this happening is if it was triggered by tcrypt. Were you using tcrypt by any chance? Ccing Eric in case he has any insight. > === DUMP /proc/crypto === > name : sha1 > driver : sha1-sun4i-ss > module : kernel > priority : 300 > refcnt : 1 > selftest : passed > internal : no > type : ahash > async: no > blocksize: 64 > digestsize : 20 ... > name : sha1 > driver : sha1-generic > module : kernel > priority : 100 > refcnt : 1 > selftest : passed > internal : no > type : shash > blocksize: 64 > digestsize : 20 Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] printk: handle blank console arguments passed in.
On (20/10/08 01:29), Sergey Senozhatsky wrote:
> On (20/10/07 08:57), Guenter Roeck wrote:
> > On 10/7/20 5:30 AM, Sergey Senozhatsky wrote:
>
> [..]
>
> > I can see to options: Link /dev/console to /dev/null if there is no console,
> > or do something like
> >
> > if (IS_ERR(file)) {
> > pr_warn("Warning: unable to open an initial console.\n");
> > file = filp_open("/dev/null", O_RDWR, 0);
> > if (IS_ERR(file))
> > return;
> > }
>
> As far as I can tell, /dev/null does not exist yet on this stage
> (at least not in my system). But generally the idea looks interesting.
Hmm. How about this. console= is undocumented and unspecified - it
may work sometimes or it may kill the system (and theoretically even
corrupt some files, depending on what fd 1 and fd 2 point to). So
maybe we can document console= and handle it in printk, rather than
somewhere deep in init/main.c
IOW add one more flag (yeah, I know) and set it when console_setup()
sees console= boot param. The idea is allow console registration,
but all consoles should be disabled (cleared CON_ENABLED bit). This
would be easier to document, at least.
Schematically:
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 929e86a01148..b71ff9d87693 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -281,6 +281,7 @@ static struct console_cmdline
console_cmdline[MAX_CMDLINECONSOLES];
static int preferred_console = -1;
static bool has_preferred_console;
+static bool mute_consoles = false;
int console_set_on_cmdline;
EXPORT_SYMBOL(console_set_on_cmdline);
@@ -2141,6 +2142,9 @@ static int __add_preferred_console(char *name, int idx,
char *options,
struct console_cmdline *c;
int i;
+ if (mute_consoles)
+ return;
+
/*
* See if this tty is not yet registered, and
* if we have a slot free.
@@ -2189,6 +2193,11 @@ static int __init console_setup(char *str)
char *s, *options, *brl_options = NULL;
int idx;
+ if (str[0] == 0) {
+ mute_consoles = true;
+ return 0;
+ }
+
if (_braille_console_setup(&str, &brl_options))
return 1;
@@ -2630,6 +2639,9 @@ EXPORT_SYMBOL(console_stop);
void console_start(struct console *console)
{
+ if (mute_consoles)
+ return;
+
console_lock();
console->flags |= CON_ENABLED;
console_unlock();
@@ -2811,6 +2823,9 @@ void register_console(struct console *newcon)
console_drivers->next = newcon;
}
+ if (mute_consoles)
+ newcon->flags &= ~CON_ENABLED;
+
if (newcon->flags & CON_EXTENDED)
nr_ext_console_drivers++;
Re: [PATCH-next 0/4] RDMA: sprintf to sysfs_emit conversions
On Thu, 2020-10-08 at 08:41 +0300, Leon Romanovsky wrote: > On Wed, Oct 07, 2020 at 07:36:23PM -0700, Joe Perches wrote: > > A recent commit added a sysfs_emit and sysfs_emit_at to allow various > > sysfs show functions to ensure that the PAGE_SIZE buffer argument is > > never overrun and always NUL terminated. > > Unfortunately but the sysfs_emit commit is not in rdma-next tree yet. Likely it'll still apply fairly well when the sysfs_emit commit is...
Re: [PATCH] KVM: SVM: Use a separate vmcb for the nested L2 guest
On 08/10/20 00:14, Maxim Levitsky wrote: >> >> +if (svm->vmcb01->control.asid == 0) >> +svm->vmcb01->control.asid = svm->nested.vmcb02->control.asid; > > I think that the above should be done always. The asid field is currently host > controlled only (that is L2 value is ignored, selective ASID tlb flush is not > advertized to the guest and lnvlpga is emulated as invlpg). Yes, in fact I suggested that ASID should be in svm->asid and moved to svm->vmcb->asid in svm_vcpu_run. Then there's no need to special case it in nested code. This should be a patch coming before this one. > > 1. Something wrong with memory types - like guest is using UC memory for > everything. > I can't completely rule that out yet You can print g_pat and see if it is all zeroes. In general I think it's better to be explicit with vmcb01 vs. vmcb02, like Cathy did, but I can see it's a matter of personal preference to some extent. Paolo
Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned
On Mon, Sep 28, 2020 at 12:50:03PM -0700, Linus Torvalds wrote: > On Mon, Sep 28, 2020 at 12:36 PM Linus Torvalds > wrote: > > > > So I'll do the pte wrprotect/restore removal. Anybody willing to do > > and test the sequence count approach? > > So the wrprotect removal is trivial, with most of it being about the comments. > > However, when I look at this, I am - once again - tempted to just add a > > if (__page_mapcount(page) > 1) > return 1; > > there too. Because we know it's a private mapping (shared mappings we > checked for with the "is_cow_mapping()" earlier), and the only case we > really care about is the one where the page is only mapped in the > current mm (because that's what a write pinning will have done, and as > mentioned, a read pinning doesn't do anything wrt fork() right now > anyway). > > So if it's mapped in another mm, the COW clearly hasn't been broken by > a pin, and a read pinned page had already gone through a fork. > > But the more I look at this code, the more I go "ok, I want somebody > to actually test this with the rdma case". > > So I'll attach my suggested patch, but I won't actually commit it. I'd > really like to have this tested, possibly _together_ with the sequence > count addition.. Hi Linus, We tested the suggested patch for last two weeks in our nightly regressions and didn't experience any new failures. It looks like it is safe to use it, but better to take the patch during/after merge window to minimize risk of delaying v5.9. Thanks > >Linus
Re: [PATCH v8 2/6] PCI/DPC: define a function to check and wait till port finish DPC handling
On Thu, Oct 8, 2020 at 2:16 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > Once root port DPC capability is enabled and triggered, at the beginning
> > of DPC is triggered, the DPC status bits are set by hardware and then
> > sends DPC/DLLSC/PDC interrupts to OS DPC and pciehp drivers, it will
> > take the port and software DPC interrupt handler 10ms to 50ms (test data
> > on ICS(Ice Lake SP platform, see
> > https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server)
> > & stable 5.9-rc6) to complete the DPC containment procedure
> This data is based on one particular architecture. So using this
> to create a timed loop in pci_wait_port_outdpc() looks incorrect.
>
> I still recommend looking for some locking model to fix this
> issue (may be atomic state flag or lock).
It is actually a device semaphore. DLLSC/PDC handler needs to wait
for the critical
area is clear to enter by monitoring the DPC triggered status is
cleaned or not.
Another problem is, DPC reset/interrupt is initiated by hardware,
you couldn't place
a software lock between interrupt handler and device resetting.
While device semaphore--- DPC triggered status is the right one to wait for.
Better idea ?
Thanks,
Ethan
> > till the DPC status is cleared at the end of the DPC interrupt handler.
> >
> > We use this function to check if the root port is in DPC handling status
> > and wait till the hardware and software completed the procedure.
> >
> > Signed-off-by: Ethan Zhao
> > Tested-by: Wen Jin
> > Tested-by: Shanshan Zhang
> > ---
> > changes:
> > v2：align ICS code name to public doc.
> > v3: no change.
> > v4: response to Christoph's (Christoph Hellwig )
> > tip, move pci_wait_port_outdpc() to DPC driver and its declaration
> > to pci.h.
> > v5: fix building issue reported by l...@intel.com with some config.
> > v6: move from [1/5] to [2/5].
> > v7: no change.
> > v8: no change.
> >
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/pcie/dpc.c | 27 +++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index fa12f7cbc1a0..455b32187abd 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -455,10 +455,12 @@ void pci_restore_dpc_state(struct pci_dev *dev);
> > void pci_dpc_init(struct pci_dev *pdev);
> > void dpc_process_error(struct pci_dev *pdev);
> > pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
> > +bool pci_wait_port_outdpc(struct pci_dev *pdev);
> > #else
> > static inline void pci_save_dpc_state(struct pci_dev *dev) {}
> > static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
> > static inline void pci_dpc_init(struct pci_dev *pdev) {}
> > +static inline bool pci_wait_port_outdpc(struct pci_dev *pdev) { return
> > false; }
> > #endif
> >
> > #ifdef CONFIG_PCI_ATS
> > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> > index daa9a4153776..2e0e091ce923 100644
> > --- a/drivers/pci/pcie/dpc.c
> > +++ b/drivers/pci/pcie/dpc.c
> > @@ -71,6 +71,33 @@ void pci_restore_dpc_state(struct pci_dev *dev)
> > pci_write_config_word(dev, dev->dpc_cap + PCI_EXP_DPC_CTL, *cap);
> > }
> >
> > +bool pci_wait_port_outdpc(struct pci_dev *pdev)
> > +{
> > + u16 cap = pdev->dpc_cap, status;
> > + u16 loop = 0;
> > +
> > + if (!cap) {
> > + pci_WARN_ONCE(pdev, !cap, "No DPC capability initiated\n");
> > + return false;
> > + }
> > + pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, &status);
> > + pci_dbg(pdev, "DPC status %x, cap %x\n", status, cap);
> > +
> > + while (status & PCI_EXP_DPC_STATUS_TRIGGER && loop < 100) {
> > + msleep(10);
> > + loop++;
> > + pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, &status);
> > + }
> > +
> > + if (!(status & PCI_EXP_DPC_STATUS_TRIGGER)) {
> > + pci_dbg(pdev, "Out of DPC %x, cost %d ms\n", status, loop*10);
> > + return true;
> > + }
> > +
> > + pci_dbg(pdev, "Timeout to wait port out of DPC status\n");
> > + return false;
> > +}
> > +
> > static int dpc_wait_rp_inactive(struct pci_dev *pdev)
> > {
> > unsigned long timeout = jiffies + HZ;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
>
Re: [PATCH] crypto: xor - Remove unused variable count in do_xor_speed
On Tue, Oct 06, 2020 at 12:58:48PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used
> here [-Wuninitialized]
> count++;
> ^
> crypto/xor.c:86:17: note: initialize the variable 'count' to silence
> this warning
> int i, j, count;
>^
> = 0
> 1 warning generated.
>
> After the refactoring to use ktime that happened in this function, count
> is only assigned, never read. Just remove the variable to get rid of the
> warning.
>
> Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1171
> Signed-off-by: Nathan Chancellor
> ---
> crypto/xor.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] docs: w1: w1_therm: Fix broken xref, mistakes, clarify text
sysfs attribute names are mixed with the same normal text terms.
Use ReST to distinguish.
Fix typos and mistakes.
Signed-off-by: Ivan Zaentsev
---
.../ABI/testing/sysfs-driver-w1_therm | 6 +-
Documentation/w1/slaves/w1_therm.rst | 83 +--
2 files changed, 43 insertions(+), 46 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm
b/Documentation/ABI/testing/sysfs-driver-w1_therm
index 9f05bcdcd762..8873bbb075cb 100644
--- a/Documentation/ABI/testing/sysfs-driver-w1_therm
+++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -146,7 +146,7 @@ Date: July 2020
Contact: Ivan Zaentsev
Description:
(RW) Control optional driver settings.
- Bit masks to read/write (logical OR):
+ Bit masks to read/write (bitwise OR):
1: Enable check for conversion success. If byte 6 of
scratchpad memory is 0xC after conversion, and
@@ -157,7 +157,7 @@ Description:
after the conversion start and wait for 1's. In parasite
power mode this feature is not available.
- *read*: Currently selected features, bitwise OR.
- *write*: Select features, bitwise OR.
+ *read*: Currently selected features.
+ *write*: Select features.
Users: An application using the w1_term device
diff --git a/Documentation/w1/slaves/w1_therm.rst
b/Documentation/w1/slaves/w1_therm.rst
index 00376501a5ef..e39202e2b000 100644
--- a/Documentation/w1/slaves/w1_therm.rst
+++ b/Documentation/w1/slaves/w1_therm.rst
@@ -27,75 +27,72 @@ W1_THERM_DS1825 0x3B
W1_THERM_DS28EA00 0x42
-Support is provided through the sysfs w1_slave file. Each open and
-read sequence will initiate a temperature conversion then provide two
+Support is provided through the sysfs entry ``w1_slave``. Each open and
+read sequence will initiate a temperature conversion, then provide two
lines of ASCII output. The first line contains the nine hex bytes
read along with a calculated crc value and YES or NO if it matched.
If the crc matched the returned values are retained. The second line
displays the retained values along with a temperature in millidegrees
Centigrade after t=.
-Alternatively, temperature can be read using temperature sysfs, it
-return only temperature in millidegrees Centigrade.
+Alternatively, temperature can be read using ``temperature`` sysfs, it
+returns only the temperature in millidegrees Centigrade.
-A bulk read of all devices on the bus could be done writing 'trigger'
-in the therm_bulk_read sysfs entry at w1_bus_master level. This will
-sent the convert command on all devices on the bus, and if parasite
-powered devices are detected on the bus (and strong pullup is enable
+A bulk read of all devices on the bus could be done writing ``trigger``
+to ``therm_bulk_read`` entry at w1_bus_master level. This will
+send the convert command to all devices on the bus, and if parasite
+powered devices are detected on the bus (and strong pullup is enabled
in the module), it will drive the line high during the longer conversion
time required by parasited powered device on the line. Reading
-therm_bulk_read will return 0 if no bulk conversion pending,
+``therm_bulk_read`` will return 0 if no bulk conversion pending,
-1 if at least one sensor still in conversion, 1 if conversion is complete
but at least one sensor value has not been read yet. Result temperature is
-then accessed by reading the temperature sysfs entry of each device, which
+then accessed by reading the ``temperature`` entry of each device, which
may return empty if conversion is still in progress. Note that if a bulk
read is sent but one sensor is not read immediately, the next access to
-temperature on this device will return the temperature measured at the
+``temperature`` on this device will return the temperature measured at the
time of issue of the bulk read command (not the current temperature).
A strong pullup will be applied during the conversion if required.
-``conv_time`` sysfs entry is used to get current conversion time (read), and
+``conv_time`` is used to get current conversion time (read), and
adjust it (write). A temperature conversion time depends on the device type and
it's current resolution. Default conversion time is set by the driver according
to the device datasheet. A conversion time for many original device clones
deviate from datasheet specs. There are three options: 1) manually set the
correct conversion time by writing a value in milliseconds to ``conv_time``; 2)
auto measure and set a conversion time by writing ``1`` to
-``conv_time``; 3) use ``features`` entry to enable poll for conversion
+``conv_time``; 3) use ``features`` to enable poll for conversion
completion. Options 2, 3 can't be used in parasite power mode. To get back to
the default conve
Re: [PATCH v2 5/5] PCI: dwc: Move dw_pcie_msi_init() from each users to designware host
On 9/24/2020 4:37 PM, Jisheng Zhang wrote:
External email: Use caution opening links or attachments
Currently, dw_pcie_msi_init() allocates and maps page for msi, then
program the PCIE_MSI_ADDR_LO and PCIE_MSI_ADDR_HI. The Root Complex
may lose power during suspend-to-RAM, so when we resume, we want to
redo the latter but not the former. If designware based driver (for
example, pcie-tegra194.c) calls dw_pcie_msi_init() in resume path, the
previous msi page will be leaked. From another side, except
pci-dra7xx.c we can move the dw_pcie_msi_init() from each users to
designware host, I.E move the msi page allocation and mapping to
dw_pcie_host_init() and move the PCIE_MSI_ADDR_* programming to
dw_pcie_setup_rc(). After this moving, we solve the msi page leakage
as well.
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pci-dra7xx.c | 1 +
drivers/pci/controller/dwc/pci-exynos.c | 2 --
drivers/pci/controller/dwc/pci-imx6.c | 3 ---
drivers/pci/controller/dwc/pci-meson.c| 8 ---
drivers/pci/controller/dwc/pcie-artpec6.c | 10
.../pci/controller/dwc/pcie-designware-host.c | 24 ---
.../pci/controller/dwc/pcie-designware-plat.c | 3 ---
drivers/pci/controller/dwc/pcie-designware.h | 5
drivers/pci/controller/dwc/pcie-histb.c | 3 ---
drivers/pci/controller/dwc/pcie-kirin.c | 3 ---
drivers/pci/controller/dwc/pcie-qcom.c| 3 ---
drivers/pci/controller/dwc/pcie-spear13xx.c | 1 -
drivers/pci/controller/dwc/pcie-tegra194.c| 2 --
drivers/pci/controller/dwc/pcie-uniphier.c| 9 +--
14 files changed, 22 insertions(+), 55 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c
b/drivers/pci/controller/dwc/pci-dra7xx.c
index dc387724cf08..d8b74389e353 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -210,6 +210,7 @@ static int dra7xx_pcie_host_init(struct pcie_port *pp)
dra7xx_pcie_establish_link(pci);
dw_pcie_wait_for_link(pci);
dw_pcie_msi_init(pp);
+ dw_pcie_msi_config(pp);
dra7xx_pcie_enable_interrupts(dra7xx);
return 0;
diff --git a/drivers/pci/controller/dwc/pci-exynos.c
b/drivers/pci/controller/dwc/pci-exynos.c
index 8d82c43ae299..9cca0ce79777 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -298,8 +298,6 @@ static void exynos_pcie_msi_init(struct exynos_pcie *ep)
struct pcie_port *pp = &pci->pp;
u32 val;
- dw_pcie_msi_init(pp);
-
/* enable MSI interrupt */
val = exynos_pcie_readl(ep->mem_res->elbi_base, PCIE_IRQ_EN_LEVEL);
val |= IRQ_MSI_ENABLE;
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 5fef2613b223..dba6e351e3df 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -848,9 +848,6 @@ static int imx6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
imx6_pcie_establish_link(imx6_pcie);
- if (IS_ENABLED(CONFIG_PCI_MSI))
- dw_pcie_msi_init(pp);
-
return 0;
}
diff --git a/drivers/pci/controller/dwc/pci-meson.c
b/drivers/pci/controller/dwc/pci-meson.c
index 4f183b96afbb..cd0d9dd8dd61 100644
--- a/drivers/pci/controller/dwc/pci-meson.c
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -377,12 +377,6 @@ static int meson_pcie_establish_link(struct meson_pcie *mp)
return dw_pcie_wait_for_link(pci);
}
-static void meson_pcie_enable_interrupts(struct meson_pcie *mp)
-{
- if (IS_ENABLED(CONFIG_PCI_MSI))
- dw_pcie_msi_init(&mp->pci.pp);
-}
-
static int meson_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
u32 *val)
{
@@ -467,8 +461,6 @@ static int meson_pcie_host_init(struct pcie_port *pp)
if (ret)
return ret;
- meson_pcie_enable_interrupts(mp);
-
return 0;
}
diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c
b/drivers/pci/controller/dwc/pcie-artpec6.c
index 97d50bb50f06..af1e6bb28e7a 100644
--- a/drivers/pci/controller/dwc/pcie-artpec6.c
+++ b/drivers/pci/controller/dwc/pcie-artpec6.c
@@ -346,15 +346,6 @@ static void artpec6_pcie_deassert_core_reset(struct
artpec6_pcie *artpec6_pcie)
usleep_range(100, 200);
}
-static void artpec6_pcie_enable_interrupts(struct artpec6_pcie *artpec6_pcie)
-{
- struct dw_pcie *pci = artpec6_pcie->pci;
- struct pcie_port *pp = &pci->pp;
-
- if (IS_ENABLED(CONFIG_PCI_MSI))
- dw_pcie_msi_init(pp);
-}
-
static int artpec6_pcie_host_init(struct pcie_port *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -368,7 +359,6 @@ static int artpec6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
artpec6_pcie_establish_link(pci);
dw_pcie_wait_for_link(pci);
-
Re: [PATCH] X.509: fix error return value on the failed path
On Mon, Oct 05, 2020 at 10:46:28PM +0800, Tianjia Zhang wrote:
> When memory allocation fails, an appropriate return value
> should be set.
>
> Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
> verification")
> Signed-off-by: Tianjia Zhang
> ---
> crypto/asymmetric_keys/public_key_sm2.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH-next 0/4] RDMA: sprintf to sysfs_emit conversions
On Wed, Oct 07, 2020 at 07:36:23PM -0700, Joe Perches wrote: > A recent commit added a sysfs_emit and sysfs_emit_at to allow various > sysfs show functions to ensure that the PAGE_SIZE buffer argument is > never overrun and always NUL terminated. Unfortunately but the sysfs_emit commit is not in rdma-next tree yet. Thanks
[PATCH v2 4/4] selftests/timens: added selftest for /proc/stat btime
Test that btime value of /proc/stat is as expected in the time namespace
using a simple parser to get btime from /proc/stat.
Signed-off-by: Michael Weiß
---
tools/testing/selftests/timens/procfs.c | 58 -
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/timens/procfs.c
b/tools/testing/selftests/timens/procfs.c
index 7f14f0fdac84..f2519154208a 100644
--- a/tools/testing/selftests/timens/procfs.c
+++ b/tools/testing/selftests/timens/procfs.c
@@ -93,6 +93,33 @@ static int read_proc_uptime(struct timespec *uptime)
return 0;
}
+static int read_proc_stat_btime(unsigned long long *boottime_sec)
+{
+ FILE *proc;
+ char line_buf[2048];
+
+ proc = fopen("/proc/stat", "r");
+ if (proc == NULL) {
+ pr_perror("Unable to open /proc/stat");
+ return -1;
+ }
+
+ while (fgets(line_buf, 2048, proc)) {
+ if (sscanf(line_buf, "btime %llu", boottime_sec) != 1)
+ continue;
+ fclose(proc);
+ return 0;
+ }
+ if (errno) {
+ pr_perror("fscanf");
+ fclose(proc);
+ return -errno;
+ }
+ pr_err("failed to parse /proc/stat");
+ fclose(proc);
+ return -1;
+}
+
static int check_uptime(void)
{
struct timespec uptime_new, uptime_old;
@@ -123,18 +150,47 @@ static int check_uptime(void)
return 0;
}
+static int check_stat_btime(void)
+{
+ unsigned long long btime_new, btime_old;
+ unsigned long long btime_expected;
+
+ if (switch_ns(parent_ns))
+ return pr_err("switch_ns(%d)", parent_ns);
+
+ if (read_proc_stat_btime(&btime_old))
+ return 1;
+
+ if (switch_ns(child_ns))
+ return pr_err("switch_ns(%d)", child_ns);
+
+ if (read_proc_stat_btime(&btime_new))
+ return 1;
+
+ btime_expected = btime_old - TEN_DAYS_IN_SEC;
+ if (btime_new != btime_expected) {
+ pr_fail("btime in /proc/stat: old %llu, new %llu [%llu]",
+ btime_old, btime_new, btime_expected);
+ return 1;
+ }
+
+ ksft_test_result_pass("Passed for /proc/stat btime\n");
+ return 0;
+}
+
int main(int argc, char *argv[])
{
int ret = 0;
nscheck();
- ksft_set_plan(1);
+ ksft_set_plan(2);
if (init_namespaces())
return 1;
ret |= check_uptime();
+ ret |= check_stat_btime();
if (ret)
ksft_exit_fail();
--
2.20.1
[PATCH v2 2/4] time: make getboottime64 aware of time namespace
getboottime64() provides the time stamp of system boot. In case of
time namespaces, the offset to the boot time stamp was not applied
earlier. However, getboottime64 is used e.g., in /proc/stat to print
the system boot time to userspace. In container runtimes which utilize
time namespaces to virtualize boottime of a container, this leaks
information about the host system boot time.
Therefore, we make getboottime64() to respect the time namespace offset
for boottime by subtracting the boottime offset.
Signed-off-by: Michael Weiß
---
kernel/time/timekeeping.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4c47f388a83f..67530cdb389e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2154,6 +2155,8 @@ void getboottime64(struct timespec64 *ts)
{
struct timekeeper *tk = &tk_core.timekeeper;
ktime_t t = ktime_sub(tk->offs_real, tk->offs_boot);
+ /* shift boot time stamp according to the timens offset */
+ t = timens_ktime_to_host(CLOCK_BOOTTIME, t);
*ts = ktime_to_timespec64(t);
}
--
2.20.1
[PATCH v2 1/4] timens: additional helper function to add boottime in nsec
Provide a helper function to apply the boottime offset to u64 types
in nanoseconds.
Signed-off-by: Michael Weiß
---
include/linux/time_namespace.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/time_namespace.h b/include/linux/time_namespace.h
index 5b6031385db0..5372181010f9 100644
--- a/include/linux/time_namespace.h
+++ b/include/linux/time_namespace.h
@@ -77,6 +77,13 @@ static inline void timens_add_boottime(struct timespec64 *ts)
*ts = timespec64_add(*ts, ns_offsets->boottime);
}
+static inline u64 timens_add_boottime_ns(u64 nsec)
+{
+ struct timens_offsets *ns_offsets = ¤t->nsproxy->time_ns->offsets;
+
+ return nsec + timespec64_to_ns(&ns_offsets->boottime);
+}
+
ktime_t do_timens_ktime_to_host(clockid_t clockid, ktime_t tim,
struct timens_offsets *offsets);
@@ -130,6 +137,12 @@ static inline int timens_on_fork(struct nsproxy *nsproxy,
static inline void timens_add_monotonic(struct timespec64 *ts) { }
static inline void timens_add_boottime(struct timespec64 *ts) { }
+
+static inline u64 timens_add_boottime_ns(u64 nsec)
+{
+ return nsec;
+}
+
static inline ktime_t timens_ktime_to_host(clockid_t clockid, ktime_t tim)
{
return tim;
--
2.20.1
[PATCH v2 3/4] fs/proc: apply timens offset for start_boottime of processes
Since start_boottime of processes are seconds since boottime and the
boottime stamp is now shifted according to the timens offset, the
offset of the time namespace also needs to be applied before the
process stats are given to userspace.
This avoids that processes shown, e.g., by 'ps' appear as time
travelers in the corresponding time namespace.
Signed-off-by: Michael Weiß
---
fs/proc/array.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 65ec2029fa80..277f654f289e 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -533,8 +534,9 @@ static int do_task_stat(struct seq_file *m, struct
pid_namespace *ns,
priority = task_prio(task);
nice = task_nice(task);
- /* convert nsec -> ticks */
- start_time = nsec_to_clock_t(task->start_boottime);
+ /* apply timens offset for boottime and convert nsec -> ticks */
+ start_time =
+ nsec_to_clock_t(timens_add_boottime_ns(task->start_boottime));
seq_put_decimal_ull(m, "", pid_nr_ns(pid, ns));
seq_puts(m, " (");
--
2.20.1
[PATCH v2 0/4] time namespace aware system boot time
Time namespaces make it possible to virtualize time inside of containers, e.g., it is feasible to reset the uptime of a container to zero by setting the time namespace offset for boottime to the negated current value of the CLOCK_BOOTTIME. However, the boot time stamp provided by getboottime64() does not take care of time namespaces. The resulting boot time stamp 'btime' provided by /proc/stat does not show a plausible time stamp inside the time namespace of a container. We address this by shifting the value returned by getboottime64() by subtracting the boottime offset of the time namespace. (A selftest to check the expected /proc/stat 'btime' inside the namespace is provided.) Further, to avoid to show processes as time travelers inside of the time namespace the boottime offset then needs to be added to the start_bootime provided by the task_struct. v2 Changes: Fixed compile errors with TIME_NS not set in config Reported-by: kernel test robot Michael Weiß (4): timens: additional helper function to add boottime in nsec time: make getboottime64 aware of time namespace fs/proc: apply timens offset for start_boottime of processes selftests/timens: added selftest for /proc/stat btime fs/proc/array.c | 6 ++- include/linux/time_namespace.h | 13 ++ kernel/time/timekeeping.c | 3 ++ tools/testing/selftests/timens/procfs.c | 58 - 4 files changed, 77 insertions(+), 3 deletions(-) -- 2.20.1
Re: [PATCH v8 1/6] PCI/ERR: get device before call device driver to avoid NULL pointer dereference
On Thu, Oct 8, 2020 at 1:24 AM Kuppuswamy, Sathyanarayanan wrote: > > > On 10/7/20 4:31 AM, Ethan Zhao wrote: > > During DPC error injection test we found there is race condition between > > pciehp and DPC driver, NULL pointer dereference caused panic as following > > > > # setpci -s 64:02.0 0x196.w=000a > >// 64:02.0 is rootport has DPC capability > > # setpci -s 65:00.0 0x04.w=0544 > >// 65:00.0 is NVMe SSD populated in above port > > # mount /dev/nvme0n1p1 nvme > > > > (tested on stable 5.8 & ICS(Ice Lake SP platform, see > > https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server)) > > > > BUG: kernel NULL pointer dereference, address: 0050 > > ... > > CPU: 12 PID: 513 Comm: irq/124-pcie-dp Not tainted > > 5.8.0-0.0.7.el8.x86_64+ #1 > > RIP: 0010:report_error_detected.cold.4+0x7d/0xe6 > > Code: b6 d0 e8 e8 fe 11 00 e8 16 c5 fb ff be 06 00 00 00 48 89 df e8 d3 > > 65 ff > > ff b8 06 00 00 00 e9 75 fc ff ff 48 8b 43 68 45 31 c9 <48> 8b 50 50 48 83 > > 3a 00 > > 41 0f 94 c1 45 31 c0 48 85 d2 41 0f 94 c0 > > RSP: 0018:ff8e06cf8762fda8 EFLAGS: 00010246 > > RAX: RBX: ff4e3eaacf42a000 RCX: ff4e3eb31f223c01 > > RDX: ff4e3eaacf42a140 RSI: ff4e3eb31f223c00 RDI: ff4e3eaacf42a138 > > RBP: ff8e06cf8762fdd0 R08: 00bf R09: > > R10: 00eb8ebeab53 R11: 93453258 R12: 0002 > > R13: ff4e3eaacf42a130 R14: ff8e06cf8762fe2c R15: ff4e3eab44733828 > > FS: () GS:ff4e3eab1fd0() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0050 CR3: 000f8f80a004 CR4: 00761ee0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > PKRU: 5554 > > Call Trace: > > ? report_normal_detected+0x20/0x20 > > report_frozen_detected+0x16/0x20 > > pci_walk_bus+0x75/0x90 > > ? dpc_irq+0x90/0x90 > > pcie_do_recovery+0x157/0x201 > > ? irq_finalize_oneshot.part.47+0xe0/0xe0 > > dpc_handler+0x29/0x40 > > irq_thread_fn+0x24/0x60 > > ... > > > > Debug shows when port DPC feature was enabled and triggered by errors, > > DLLSC/PDC/DPC interrupts will be sent to pciehp and DPC driver almost > > at the same time, and no delay between them is required by specification. > > so DPC driver and pciehp drivers may handle these interrupts cocurrently. > > > > While DPC driver is doing pci_walk_bus() and calling device driver's > > callback without pci_dev_get() to increase device reference count, the > > device and its driver instance are likely being freed by > > pci_stop_and_removed_bus_device() > > -> pci_dev_put(). > > > > So does pci_dev_get() before using the device instance to avoid NULL > > pointer dereference. > Won't it be better if you get this in pcie_do_recovery()? Don't think so, just like lock, we should keep the scope with lock protected as small as possible. Locking a big area unnecessarily isn't acceptable. Thanks, Ethan > > > > Signed-off-by: Ethan Zhao > > Tested-by: Wen Jin > > Tested-by: Shanshan Zhang > > --- > > Changes: > > v2: revise doc according to Andy's suggestion. > > v3: no change. > > v4: no change. > > v5: no change. > > v6: moved to [1/5] from [3/5] and revised comment according to Lukas' > > suggestion. > > v7: no change. > > v8: no change. > > > > drivers/pci/pcie/err.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c > > index c543f419d8f9..e35c4480c86b 100644 > > --- a/drivers/pci/pcie/err.c > > +++ b/drivers/pci/pcie/err.c > > @@ -52,6 +52,8 @@ static int report_error_detected(struct pci_dev *dev, > > pci_ers_result_t vote; > > const struct pci_error_handlers *err_handler; > > > > + if (!pci_dev_get(dev)) > > + return 0; > > device_lock(&dev->dev); > > if (!pci_dev_set_io_state(dev, state) || > > !dev->driver || > > @@ -76,6 +78,7 @@ static int report_error_detected(struct pci_dev *dev, > > pci_uevent_ers(dev, vote); > > *result = merge_result(*result, vote); > > device_unlock(&dev->dev); > > + pci_dev_put(dev); > > return 0; > > } > > > > @@ -94,6 +97,8 @@ static int report_mmio_enabled(struct pci_dev *dev, void > > *data) > > pci_ers_result_t vote, *result = data; > > const struct pci_error_handlers *err_handler; > > > > + if (!pci_dev_get(dev)) > > + return 0; > > device_lock(&dev->dev); > > if (!dev->driver || > > !dev->driver->err_handler || > > @@ -105,6 +110,7 @@ static int report_mmio_enabled(struct pci_dev *dev, > > void *data) > > *result = merge_result(*result, vote); > > out: > > device_unlock(&dev->dev); > > + pci_dev_put(dev); > > return 0; > > } > > > > @@ -113,6 +119,8 @@ static int report_slot_r
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Wed, Oct 7, 2020 at 12:44 AM Dan Carpenter wrote:
>
> Hi John,
>
> url:
> https://github.com/0day-ci/linux/commits/John-Stultz/dma-buf-Performance-improvements-for-system-heap-a-system-uncached-implementation/20201003-120520
> base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> bcf876870b95592b52519ed4aafcf9d95999bc9c
> config: i386-randconfig-m021-20201002 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
>
> smatch warnings:
> drivers/dma-buf/heaps/system_heap.c:496 system_heap_create() warn: passing
> zero to 'PTR_ERR'
>
> vim +/PTR_ERR +496 drivers/dma-buf/heaps/system_heap.c
>
> efa04fefebbd724 John Stultz 2019-12-03 478 static int
> system_heap_create(void)
> efa04fefebbd724 John Stultz 2019-12-03 479 {
> efa04fefebbd724 John Stultz 2019-12-03 480 struct
> dma_heap_export_info exp_info;
> efa04fefebbd724 John Stultz 2019-12-03 481
> 263e38f82cbb35b Andrew F. Davis 2019-12-16 482 exp_info.name =
> "system";
> efa04fefebbd724 John Stultz 2019-12-03 483 exp_info.ops =
> &system_heap_ops;
> efa04fefebbd724 John Stultz 2019-12-03 484 exp_info.priv = NULL;
> efa04fefebbd724 John Stultz 2019-12-03 485
> efa04fefebbd724 John Stultz 2019-12-03 486 sys_heap =
> dma_heap_add(&exp_info);
> efa04fefebbd724 John Stultz 2019-12-03 487 if (IS_ERR(sys_heap))
> a2e10cdd2e4d12a John Stultz 2020-10-03 488 return
> PTR_ERR(sys_heap);
> efa04fefebbd724 John Stultz 2019-12-03 489
> 553f4e0fafc5b3b John Stultz 2020-10-03 490 exp_info.name =
> "system-uncached";
> 553f4e0fafc5b3b John Stultz 2020-10-03 491 exp_info.ops =
> &system_uncached_heap_ops;
> 553f4e0fafc5b3b John Stultz 2020-10-03 492 exp_info.priv = NULL;
> 553f4e0fafc5b3b John Stultz 2020-10-03 493
> 553f4e0fafc5b3b John Stultz 2020-10-03 494 sys_uncached_heap =
> dma_heap_add(&exp_info);
> 553f4e0fafc5b3b John Stultz 2020-10-03 495 if
> (IS_ERR(sys_uncached_heap))
> 553f4e0fafc5b3b John Stultz 2020-10-03 @496 return
> PTR_ERR(sys_heap);
>
> ^
> This should be return PTR_ERR(sys_uncached_heap);
Oh nice! Very impressed that the tool caught that!
Thanks so much for the report! I'll fix it up here shortly.
-john
Re: [PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
On 08/10/2020 06:16, Srinivasa Rao Mandadapu wrote: These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V10: -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to lpass.h changes since V9: -- Removed unused structures lpass_hdmi.h changes since V8: -- Removed redundant structure wrapper for reg map field memebrs -- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true and others as false. changes since V7: -- Fixed typo errors -- Created Separate patch for buffer size change changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (7): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile| 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 249 - sound/soc/qcom/lpass-hdmi.c| 258 ++ sound/soc/qcom/lpass-hdmi.h| 102 ++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- sound/soc/qcom/lpass-platform.c| 395 + sound/soc/qcom/lpass-sc7180.c | 116 +- sound/soc/qcom/lpass.h | 124 ++- 13 files changed, 1240 insertions(+), 143 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h Tested this series on DragonBoard 410c Tested-by: Srinivas Kandagatla Reviewed-by: Srinivas Kandagatla
Re: [PATCH v11 5/7] ASoC: qcom: Add support for lpass hdmi driver
On 08/10/2020 06:17, Srinivasa Rao Mandadapu wrote: From: V Sujith Kumar Reddy Upadate lpass cpu and platform driver to support audio over dp. Also add lpass-hdmi.c and lpass-hdmi.h. Signed-off-by: V Sujith Kumar Reddy Signed-off-by: Srinivasa Rao --- sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 247 - sound/soc/qcom/lpass-hdmi.c | 258 ++ sound/soc/qcom/lpass-hdmi.h | 102 +++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 49 +++-- sound/soc/qcom/lpass-platform.c | 383 --- sound/soc/qcom/lpass.h | 118 +++- 10 files changed, 1075 insertions(+), 97 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h Reviewed-by: Srinivas Kandagatla
Re: [PATCH] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
Em Wed, 7 Oct 2020 19:52:56 -0700 Randy Dunlap escreveu: > On 10/7/20 7:18 PM, Nathan Chancellor wrote: > > On Wed, Oct 07, 2020 at 07:09:54AM +0200, Mauro Carvalho Chehab wrote: > >> As warned by Randy: > >> > >>on x86_64: > >>CONFIG_USB_ROLE_SWITCH=m > >>and HISI_HIKEY_USB=y. > >> > >>ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': > >>hisi_hikey_usb.c:(.text+0x61): undefined reference to > >> `usb_role_switch_unregister' > >>ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to > >> `usb_role_switch_put' > >>ld: drivers/misc/hisi_hikey_usb.o: in function > >> `hub_usb_role_switch_set': > >>hisi_hikey_usb.c:(.text+0xd3): undefined reference to > >> `usb_role_switch_get_drvdata' > >>ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': > >>hisi_hikey_usb.c:(.text+0x54d): undefined reference to > >> `usb_role_switch_set_role' > >>ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': > >>hisi_hikey_usb.c:(.text+0x8a5): undefined reference to > >> `usb_role_switch_get' > >>ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to > >> `usb_role_switch_register' > >>ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to > >> `usb_role_switch_put' > >> > >> Make it dependent on CONFIG_USB_ROLE_SWITCH. > >> > >> Reported-by: Randy Dunlap > >> Signed-off-by: Mauro Carvalho Chehab > >> --- > >> drivers/misc/Kconfig | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > >> index e19e1dcceb41..7cee2b72c09e 100644 > >> --- a/drivers/misc/Kconfig > >> +++ b/drivers/misc/Kconfig > >> @@ -459,6 +459,7 @@ config PVPANIC > >> config HISI_HIKEY_USB > >>tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" > >>depends on (OF && GPIOLIB) || COMPILE_TEST > >> + depends on CONFIG_USB_ROLE_SWITCH > > > > Shouldn't this be > > > > depends on USB_ROLE_SWITCH > > Obviously. Thanks for catching that. > > > ? Now it will never be selectable. Thanks for catching this one! Sent a v2 fixing this. (and double-checked that the driver was built after the changes). Thanks, Mauro
Re: [PATCH v2 0/5] PCI: dwc: improve msi handling
On 10/6/2020 12:06 PM, Jisheng Zhang wrote: External email: Use caution opening links or attachments On Tue, 6 Oct 2020 11:56:34 +0530 Vidya Sagar wrote: Hi, Hi, I would like to verify this series along with the other series "PCI: dwc: fix two MSI issues" on Tegra194. I tried to apply these series on both linux-next and Lorenzo's pci/dwc branches but there seem to be non trivial conflicts. Could you please tell me which branch I can use and apply these series cleanly? This is a fix, so I thought the series would be picked up in v5.9, so the series is patched against v5.9-rcN could you please try v5 https://lkml.org/lkml/2020/9/29/2511 on v5.9-rc7? I tried this series on top of v5.9-rc7 and it worked as expected on Tegra194 platform. Also, I couldn't cleanly apply the other series 'PCI: dwc: fix two MSI issues' on top. Could you please rebase them? Thanks, Vidya Sagar Thanks FWIW, I acknowledge that the existing code does leak MSI target page every time system goes through suspend-resume sequence on Tegra194. Thanks, Vidya Sagar On 9/24/2020 4:35 PM, Jisheng Zhang wrote: External email: Use caution opening links or attachments Improve the msi code: 1. Add proper error handling. 2. Move dw_pcie_msi_init() from each users to designware host to solve msi page leakage in resume path. Since v1: - add proper error handling patches. - solve the msi page leakage by moving dw_pcie_msi_init() from each users to designware host Jisheng Zhang (5): PCI: dwc: Call dma_unmap_page() before freeing the msi page PCI: dwc: Check alloc_page() return value PCI: dwc: Rename dw_pcie_free_msi to dw_pcie_msi_deinit PCI: dwc: Skip PCIE_MSI_INTR0* programming if MSI is disabled PCI: dwc: Move dw_pcie_msi_init() from each users to designware host drivers/pci/controller/dwc/pci-dra7xx.c | 1 + drivers/pci/controller/dwc/pci-exynos.c | 2 - drivers/pci/controller/dwc/pci-imx6.c | 3 -- drivers/pci/controller/dwc/pci-meson.c| 8 drivers/pci/controller/dwc/pcie-artpec6.c | 10 - .../pci/controller/dwc/pcie-designware-host.c | 43 +-- .../pci/controller/dwc/pcie-designware-plat.c | 3 -- drivers/pci/controller/dwc/pcie-designware.h | 9 +++- drivers/pci/controller/dwc/pcie-histb.c | 3 -- drivers/pci/controller/dwc/pcie-kirin.c | 3 -- drivers/pci/controller/dwc/pcie-qcom.c| 3 -- drivers/pci/controller/dwc/pcie-spear13xx.c | 1 - drivers/pci/controller/dwc/pcie-tegra194.c| 2 - drivers/pci/controller/dwc/pcie-uniphier.c| 9 +--- 14 files changed, 38 insertions(+), 62 deletions(-) -- 2.28.0
[PATCH v2] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
As warned by Randy: on x86_64: CONFIG_USB_ROLE_SWITCH=m and HISI_HIKEY_USB=y. ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': hisi_hikey_usb.c:(.text+0x61): undefined reference to `usb_role_switch_unregister' ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to `usb_role_switch_put' ld: drivers/misc/hisi_hikey_usb.o: in function `hub_usb_role_switch_set': hisi_hikey_usb.c:(.text+0xd3): undefined reference to `usb_role_switch_get_drvdata' ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': hisi_hikey_usb.c:(.text+0x54d): undefined reference to `usb_role_switch_set_role' ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': hisi_hikey_usb.c:(.text+0x8a5): undefined reference to `usb_role_switch_get' ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to `usb_role_switch_register' ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to `usb_role_switch_put' Make it dependent on CONFIG_USB_ROLE_SWITCH. Reported-by: Randy Dunlap Signed-off-by: Mauro Carvalho Chehab --- drivers/misc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index e19e1dcceb41..d5ce8082b0a0 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -459,6 +459,7 @@ config PVPANIC config HISI_HIKEY_USB tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" depends on (OF && GPIOLIB) || COMPILE_TEST + depends on USB_ROLE_SWITCH help If you say yes here this adds support for the on-board USB GPIO hub found on HiKey 960/970 boards, which is necessary to support -- 2.26.2
Re: [PATCH] docs: Make automarkup ready for Sphinx 3.1+
Hi Nícolas,
Em Wed, 07 Oct 2020 23:12:25 +
Nícolas F. R. A. Prado escreveu:
> While Sphinx 2 used a single c:type role for struct, union, enum and
> typedef, Sphinx 3 uses a specific role for each one.
> To keep backward compatibility, detect the Sphinx version and use the
> correct roles for that version.
>
> Also, Sphinx 3 is more strict with its C domain and generated warnings,
> exposing issues in the parsing.
> To fix the warnings, make the C regexes use ASCII, ensure the
> expressions only match the beginning of words and skip trying to
> cross-reference C reserved words.
>
> Signed-off-by: Nícolas F. R. A. Prado
> ---
>
> Hi,
>
> after Mauro's series making everything ready for Sphinx 3.1, only the
> automarkup
> was left to be ported.
> This patch makes the needed changes to automarkup so that we can soon flip the
> switch to Sphinx 3.1.
>
> This change was tested both with Sphinx 2.4.4 and Sphinx 3.1.
>
> This change doesn't add any warnings to the Documentation build.
> I tested it with Mauro's series but later rebased it to docs-next, and it can
> be
> accepted independently of that series.
>
> I ended up doing more than one thing in this single patch, but since it was
> all
> changing the same lines and for the same purpose, I felt it would be better to
> keep it as a single commit.
>
Thanks for doing this! That was the last missing part on fully supporting
Sphinx 3.1+.
> Mauro,
> if this patch is ok, the 3rd patch in your series, which disables automarkup
> for
> sphinx 3, should be dropped.
Yeah, sure.
> Although I'm not sure what the implications of your patches adding namespaces
> and using the c:macro for functions are.
With regards to namespaces:
Currently, only the media docs use namespaces, and it declares it at the
beginning of each file that needs it, without overriding it later[1].
[1] btw, the cdomain.py backward compat code doesn't support namespace
changes - as it parses namespaces before handling the C domain tags.
I doubt that we'll need to have a single .rst file using more than
one namespace anyway.
The main usage is to avoid conflicts for uAPI documentation for
syscalls - actually for libc userspace wrappers to syscalls. It documents
things like: open, close, read, write, ioctl, poll, select.
I'm not sure if the automarkup should be aware of it, or if the c.py code
at Sphinx 3.x will add the namespace automatically, but I suspect that
automarkup will need to handle it as well.
One file you could use for checking it is this one:
Documentation/userspace-api/media/v4l/hist-v4l2.rst
It contains a namespace directive and documents what changed without
using any explicit reference (after my patch series + linux-next).
With regards to c:macro vs c:function:
I suspect that automarkup should test both when trying to do
cross-references for function-like calls. E. g. test first if
there is a :c:function, falling back to check for :c:macro.
I would add a "sphinx3_c_func_ref" function that would handle
such special case, e. g. something like:
markup_func_sphinx3 = {RE_doc: markup_doc_ref,
RE_function: sphinx3_c_func_ref,
RE_struct: markup_c_ref,
RE_union: markup_c_ref,
RE_enum: markup_c_ref,
RE_typedef: markup_c_ref}
> All I did here was use the specific roles for sphinx 3 and fix the warnings,
> but
> that was enough to get correct cross-references even after your series.
>
> Thanks,
> Nícolas
>
>
> Documentation/sphinx/automarkup.py | 69 ++
> 1 file changed, 60 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/sphinx/automarkup.py
> b/Documentation/sphinx/automarkup.py
> index a1b0f554cd82..fd1e927408ad 100644
> --- a/Documentation/sphinx/automarkup.py
> +++ b/Documentation/sphinx/automarkup.py
> @@ -22,13 +22,34 @@ from itertools import chain
> # :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
> # bit tries to restrict matches to things that won't create trouble.
> #
> -RE_function = re.compile(r'(([\w_][\w\d_]+)\(\))')
> -RE_type = re.compile(r'(struct|union|enum|typedef)\s+([\w_][\w\d_]+)')
> +RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII)
> +
> +#
> +# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
> +#
> +RE_generic_type =
> re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
> + flags=re.ASCII)
> +
> +#
> +# Sphinx 3 uses a different C role for each one of struct, union, enum and
> +# typedef
> +#
> +RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +
> #
> # Detects a reference to a documentation
[PATCH v11 6/7] Asoc: qcom: lpass-platform : Increase buffer size
From: V Sujith Kumar Reddy
Increase buffer size to support audio over DP.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
sound/soc/qcom/lpass-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 49abbb2..36d1512 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -23,7 +23,7 @@ struct lpass_pcm_data {
int i2s_port;
};
-#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_BUFFER_SIZE (24 * 2 * 1024)
#define LPASS_PLATFORM_PERIODS 2
static const struct snd_pcm_hardware lpass_platform_pcm_hardware = {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 5/7] ASoC: qcom: Add support for lpass hdmi driver
From: V Sujith Kumar Reddy
Upadate lpass cpu and platform driver to support audio over dp.
Also add lpass-hdmi.c and lpass-hdmi.h.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/Kconfig | 5 +
sound/soc/qcom/Makefile | 2 +
sound/soc/qcom/lpass-apq8016.c | 4 +-
sound/soc/qcom/lpass-cpu.c | 247 -
sound/soc/qcom/lpass-hdmi.c | 258 ++
sound/soc/qcom/lpass-hdmi.h | 102 +++
sound/soc/qcom/lpass-ipq806x.c | 4 +-
sound/soc/qcom/lpass-lpaif-reg.h | 49 +++--
sound/soc/qcom/lpass-platform.c | 383 ---
sound/soc/qcom/lpass.h | 118 +++-
10 files changed, 1075 insertions(+), 97 deletions(-)
create mode 100644 sound/soc/qcom/lpass-hdmi.c
create mode 100644 sound/soc/qcom/lpass-hdmi.h
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index a7ef626..28e775f 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -12,6 +12,10 @@ config SND_SOC_LPASS_CPU
tristate
select REGMAP_MMIO
+config SND_SOC_LPASS_HDMI
+ tristate
+ select REGMAP_MMIO
+
config SND_SOC_LPASS_PLATFORM
tristate
select REGMAP_MMIO
@@ -30,6 +34,7 @@ config SND_SOC_LPASS_SC7180
tristate
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
+ select SND_SOC_LPASS_HDMI
config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 7972c94..0bd90d7 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -1,12 +1,14 @@
# SPDX-License-Identifier: GPL-2.0
# Platform
snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-hdmi-objs := lpass-hdmi.o
snd-soc-lpass-platform-objs := lpass-platform.o
snd-soc-lpass-ipq806x-objs := lpass-ipq806x.o
snd-soc-lpass-apq8016-objs := lpass-apq8016.o
snd-soc-lpass-sc7180-objs := lpass-sc7180.o
obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_HDMI) += snd-soc-lpass-hdmi.o
obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
obj-$(CONFIG_SND_SOC_LPASS_IPQ806X) += snd-soc-lpass-ipq806x.o
obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 5c8ae22..0aedb3a 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -125,7 +125,7 @@ static struct snd_soc_dai_driver
apq8016_lpass_cpu_dai_driver[] = {
};
static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
- int direction)
+ int direction, unsigned int dai_id)
{
struct lpass_variant *v = drvdata->variant;
int chan = 0;
@@ -151,7 +151,7 @@ static int apq8016_lpass_alloc_dma_channel(struct
lpass_data *drvdata,
return chan;
}
-static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int
chan, unsigned int dai_id)
{
clear_bit(chan, &drvdata->dma_ch_bit_map);
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 12950d2..ba2aca3 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -478,6 +478,206 @@ static struct regmap_config lpass_cpu_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static int lpass_hdmi_init_bitfields(struct device *dev, struct regmap *map)
+{
+ struct lpass_data *drvdata = dev_get_drvdata(dev);
+ struct lpass_variant *v = drvdata->variant;
+ unsigned int i;
+ struct lpass_hdmi_tx_ctl *tx_ctl;
+ struct regmap_field *legacy_en;
+ struct lpass_vbit_ctrl *vbit_ctl;
+ struct regmap_field *tx_parity;
+ struct lpass_dp_metadata_ctl *meta_ctl;
+ struct lpass_sstream_ctl *sstream_ctl;
+ struct regmap_field *ch_msb;
+ struct regmap_field *ch_lsb;
+ struct lpass_hdmitx_dmactl *tx_dmactl;
+ int rval;
+
+ tx_ctl = devm_kzalloc(dev, sizeof(*tx_ctl), GFP_KERNEL);
+ if (!tx_ctl)
+ return -ENOMEM;
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->soft_reset, tx_ctl->soft_reset);
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->force_reset, tx_ctl->force_reset);
+ drvdata->tx_ctl = tx_ctl;
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->legacy_en, legacy_en);
+ drvdata->hdmitx_legacy_en = legacy_en;
+
+ vbit_ctl = devm_kzalloc(dev, sizeof(*vbit_ctl), GFP_KERNEL);
+ if (!vbit_ctl)
+ return -ENOMEM;
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->replace_vbit,
vbit_ctl->replace_vbit);
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->vbit_stream,
vbit_ctl->vbit_stream);
+ drvdata->vbit_ctl = vbit_ctl;
+
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->calc_en, tx_parity);
+ drvdata->hdmitx_
[PATCH v11 1/7] ASoC: Add sc7180-lpass binding header hdmi define
From: V Sujith Kumar Reddy Add header defining hdmi dai-id for SC7180 lpass soc in dt bindings. Signed-off-by: V Sujith Kumar Reddy Acked-by: Rob Herring Signed-off-by: Srinivasa Rao --- include/dt-bindings/sound/sc7180-lpass.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/sound/sc7180-lpass.h b/include/dt-bindings/sound/sc7180-lpass.h index 7d988f6..56ecaaf 100644 --- a/include/dt-bindings/sound/sc7180-lpass.h +++ b/include/dt-bindings/sound/sc7180-lpass.h @@ -4,6 +4,7 @@ #define MI2S_PRIMARY 0 #define MI2S_SECONDARY 1 +#define LPASS_DP_RX2 #define LPASS_MCLK00 -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V10: -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to lpass.h changes since V9: -- Removed unused structures lpass_hdmi.h changes since V8: -- Removed redundant structure wrapper for reg map field memebrs -- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true and others as false. changes since V7: -- Fixed typo errors -- Created Separate patch for buffer size change changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (7): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile| 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 249 - sound/soc/qcom/lpass-hdmi.c| 258 ++ sound/soc/qcom/lpass-hdmi.h| 102 ++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- sound/soc/qcom/lpass-platform.c| 395 + sound/soc/qcom/lpass-sc7180.c | 116 +- sound/soc/qcom/lpass.h | 124 ++- 13 files changed, 1240 insertions(+), 143 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 3/7] Asoc:qcom:lpass-cpu:Update dts property read API
From: V Sujith Kumar Reddy
Update dts property read API call with platform get property
by name, as it make code more readable and avoid conflicts
when array of properties to be used.
Signed-off-by: V Sujith Kumar Reddy
Reviewed-by: Srinivas Kandagatla
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/lpass-cpu.c | 2 +-
sound/soc/qcom/lpass-platform.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 0718a0f..12950d2 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -575,7 +575,7 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
platform_device *pdev)
of_lpass_cpu_parse_dai_data(dev, drvdata);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpass-lpaif");
drvdata->lpaif = devm_ioremap_resource(dev, res);
if (IS_ERR((void const __force *)drvdata->lpaif)) {
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 7ac2629..e7cf4e5 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -621,7 +621,7 @@ int asoc_qcom_lpass_platform_register(struct
platform_device *pdev)
struct lpass_variant *v = drvdata->variant;
int ret;
- drvdata->lpaif_irq = platform_get_irq(pdev, 0);
+ drvdata->lpaif_irq = platform_get_irq_byname(pdev, "lpass-irq-lpaif");
if (drvdata->lpaif_irq < 0)
return -ENODEV;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC PATCH v3 2/2] mm: remove extra ZONE_DEVICE struct page refcount
On Thu, Oct 01, 2020 at 11:17:15AM -0700, Ralph Campbell wrote: > ZONE_DEVICE struct pages have an extra reference count that complicates the > code for put_page() and several places in the kernel that need to check the > reference count to see that a page is not being used (gup, compaction, > migration, etc.). Clean up the code so the reference count doesn't need to > be treated specially for ZONE_DEVICE. I was hoping this patch would resolve a page-reference issue that we run into at random times while migrating a page to a device page backed by secure-memory. Unfortunately I continue to see the problem. There is a reference held on that page, which fails the migration. FYI RP
[PATCH v11 4/7] Asoc: qcom: lpass:Update lpaif_dmactl members order
From: V Sujith Kumar Reddy
Update the lpaif_dmactl struct members order to match
HDMI reg map members sequence. Separate Interface reg map
as it is used for I2S control but not for HDMI control,
to make use of bulk API, which makes code more readable.
Signed-off-by: V Sujith Kumar Reddy
Reviewed-by: Srinivas Kandagatla
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/lpass-platform.c | 8
sound/soc/qcom/lpass.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index e7cf4e5..db0d959 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -71,13 +71,13 @@ static int lpass_platform_alloc_dmactl_fields(struct device
*dev,
rd_dmactl = drvdata->rd_dmactl;
wr_dmactl = drvdata->wr_dmactl;
- rval = devm_regmap_field_bulk_alloc(dev, map, &rd_dmactl->bursten,
- &v->rdma_bursten, 6);
+ rval = devm_regmap_field_bulk_alloc(dev, map, &rd_dmactl->intf,
+ &v->rdma_intf, 6);
if (rval)
return rval;
- return devm_regmap_field_bulk_alloc(dev, map, &wr_dmactl->bursten,
- &v->wrdma_bursten, 6);
+ return devm_regmap_field_bulk_alloc(dev, map, &wr_dmactl->intf,
+ &v->wrdma_intf, 6);
}
static int lpass_platform_pcmops_open(struct snd_soc_component *component,
diff --git a/sound/soc/qcom/lpass.h b/sound/soc/qcom/lpass.h
index 51c9991..7089d4c 100644
--- a/sound/soc/qcom/lpass.h
+++ b/sound/soc/qcom/lpass.h
@@ -31,9 +31,9 @@ struct lpaif_i2sctl {
struct lpaif_dmactl {
+ struct regmap_field *intf;
struct regmap_field *bursten;
struct regmap_field *wpscnt;
- struct regmap_field *intf;
struct regmap_field *fifowm;
struct regmap_field *enable;
struct regmap_field *dyncclk;
@@ -110,17 +110,17 @@ struct lpass_variant {
struct reg_field bitwidth;
/* RD_DMA Register fields */
+ struct reg_field rdma_intf;
struct reg_field rdma_bursten;
struct reg_field rdma_wpscnt;
- struct reg_field rdma_intf;
struct reg_field rdma_fifowm;
struct reg_field rdma_enable;
struct reg_field rdma_dyncclk;
/* WR_DMA Register fields */
+ struct reg_field wrdma_intf;
struct reg_field wrdma_bursten;
struct reg_field wrdma_wpscnt;
- struct reg_field wrdma_intf;
struct reg_field wrdma_fifowm;
struct reg_field wrdma_enable;
struct reg_field wrdma_dyncclk;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 2/7] ASoC: dt-bindings: Add dt binding for lpass hdmi
From: V Sujith Kumar Reddy
Adds bindings for lpass hdmi interface
which can support audio path over dp.
Signed-off-by: V Sujith Kumar Reddy
Reviewed-by: Rob Herring
Signed-off-by: Srinivasa Rao
---
.../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 +++---
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index 09c9bd2..f6f9fb4 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -24,9 +24,10 @@ properties:
- qcom,sc7180-lpass-cpu
reg:
-maxItems: 1
+maxItems: 2
description: LPAIF core registers
-
+ reg-names:
+ maxItems: 2
clocks:
minItems: 3
maxItems: 6
@@ -36,15 +37,16 @@ properties:
maxItems: 6
interrupts:
-maxItems: 1
+maxItems: 2
description: LPAIF DMA buffer interrupt
-
+ interrupt-names:
+maxItems: 2
qcom,adsp:
$ref: /schemas/types.yaml#/definitions/phandle
description: Phandle for the audio DSP node
iommus:
-maxItems: 1
+maxItems: 2
description: Phandle to apps_smmu node with sid mask
power-domains:
@@ -60,10 +62,12 @@ properties:
const: 0
patternProperties:
- "(^mi2s-[0-9a-f]$|mi2s)":
+ "^dai-link@[0-9a-f]$":
type: object
-description: Required properties for each DAI
-
+description: |
+ LPASS CPU dai node for each I2S device. Bindings of each node
+ depends on the specific driver providing the functionality and
+ properties.
properties:
reg:
maxItems: 1
@@ -85,9 +89,11 @@ patternProperties:
required:
- compatible
- reg
+ - reg-names
- clocks
- clock-names
- interrupts
+ - interrupt-names
- '#sound-dai-cells'
additionalProperties: false
@@ -134,13 +140,32 @@ allOf:
then:
properties:
clock-names:
- items:
-- const: pcnoc-sway-clk
-- const: audio-core
-- const: mclk0
-- const: pcnoc-mport-clk
-- const: mi2s-bit-clk0
-- const: mi2s-bit-clk1
+ oneOf:
+ - items: #for I2S
+ - const: pcnoc-sway-clk
+ - const: audio-core
+ - const: mclk0
+ - const: pcnoc-mport-clk
+ - const: mi2s-bit-clk0
+ - const: mi2s-bit-clk1
+ - items: #for HDMI
+ - const: pcnoc-sway-clk
+ - const: audio-core
+ - const: pcnoc-mport-clk
+reg-names:
+ anyOf:
+- items: #for I2S
+ - const: lpass-lpaif
+- items: #for I2S and HDMI
+ - const: lpass-hdmiif
+ - const: lpass-lpaif
+interrupt-names:
+ anyOf:
+- items: #for I2S
+ - const: lpass-irq-lpaif
+- items: #for I2S and HDMI
+ - const: lpass-irq-lpaif
+ - const: lpass-irq-hdmi
required:
- iommus
- power-domains
@@ -152,12 +177,15 @@ examples:
soc {
#address-cells = <2>;
#size-cells = <2>;
-lpass@62f0 {
+lpass@62d8 {
compatible = "qcom,sc7180-lpass-cpu";
-reg = <0 0x62f0 0 0x29000>;
-
-iommus = <&apps_smmu 0x1020 0>;
+reg = <0 0x62d87000 0 0x68000>,
+ <0 0x62f0 0 0x29000>;
+reg-names = "lpass-hdmiif",
+"lpass-lpaif";
+iommus = <&apps_smmu 0x1020 0>,
+ <&apps_smmu 0x1032 0>;
power-domains = <&lpass_hm 0>;
clocks = <&gcc 131>,
@@ -171,14 +199,16 @@ examples:
"mclk0", "pcnoc-mport-clk",
"mi2s-bit-clk0", "mi2s-bit-clk1";
-interrupts = <0 160 1>;
-
+interrupts = <0 160 1>,
+ <0 268 1>;
+interrupt-names = "lpass-irq-lpaif",
+ "lpass-irq-hdmi";
#sound-dai-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
/* Optional to set different MI2S SD lines */
-mi2s-primary@0 {
+dai-link@0 {
reg = ;
qcom,playback-sd-lines = <1>;
qcom,capture-sd-lines = <0>;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 7/7] ASoC: qcom: sc7180: Add support for audio over DP
From: V Sujith Kumar Reddy
Add support for audio playback over DP in lpass
sc7180 platform driver. Update lpass_variant
structure for hdmi data configuaration.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/lpass-sc7180.c | 116 +-
1 file changed, 102 insertions(+), 14 deletions(-)
diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index a8a3d8f..c6292f9e 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -60,38 +60,65 @@ static struct snd_soc_dai_driver
sc7180_lpass_cpu_dai_driver[] = {
.probe = &asoc_qcom_lpass_cpu_dai_probe,
.ops= &asoc_qcom_lpass_cpu_dai_ops,
},
+ [LPASS_DP_RX] = {
+ .id = LPASS_DP_RX,
+ .name = "Hdmi",
+ .playback = {
+ .stream_name = "Hdmi Playback",
+ .formats= SNDRV_PCM_FMTBIT_S24,
+ .rates = SNDRV_PCM_RATE_48000,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ .channels_min = 2,
+ .channels_max = 2,
+ },
+ .ops= &asoc_qcom_lpass_hdmi_dai_ops,
+ },
};
static int sc7180_lpass_alloc_dma_channel(struct lpass_data *drvdata,
- int direction)
+ int direction, unsigned int dai_id)
{
struct lpass_variant *v = drvdata->variant;
int chan = 0;
- if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
- chan = find_first_zero_bit(&drvdata->dma_ch_bit_map,
- v->rdma_channels);
+ if (dai_id == LPASS_DP_RX) {
+ if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ chan =
find_first_zero_bit(&drvdata->hdmi_dma_ch_bit_map,
+ v->hdmi_rdma_channels);
+
+ if (chan >= v->hdmi_rdma_channels)
+ return -EBUSY;
+ }
+ set_bit(chan, &drvdata->hdmi_dma_ch_bit_map);
+ } else {
+ if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ chan = find_first_zero_bit(&drvdata->dma_ch_bit_map,
+ v->rdma_channels);
if (chan >= v->rdma_channels)
return -EBUSY;
- } else {
- chan = find_next_zero_bit(&drvdata->dma_ch_bit_map,
+ } else {
+ chan = find_next_zero_bit(&drvdata->dma_ch_bit_map,
v->wrdma_channel_start +
v->wrdma_channels,
v->wrdma_channel_start);
- if (chan >= v->wrdma_channel_start + v->wrdma_channels)
- return -EBUSY;
- }
-
- set_bit(chan, &drvdata->dma_ch_bit_map);
+ if (chan >= v->wrdma_channel_start + v->wrdma_channels)
+ return -EBUSY;
+ }
+ set_bit(chan, &drvdata->dma_ch_bit_map);
+ }
return chan;
}
-static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan,
unsigned int dai_id)
{
- clear_bit(chan, &drvdata->dma_ch_bit_map);
+ if (dai_id == LPASS_DP_RX)
+ clear_bit(chan, &drvdata->hdmi_dma_ch_bit_map);
+ else
+ clear_bit(chan, &drvdata->dma_ch_bit_map);
return 0;
}
@@ -144,6 +171,9 @@ static struct lpass_variant sc7180_data = {
.rdma_reg_base = 0xC000,
.rdma_reg_stride= 0x1000,
.rdma_channels = 5,
+ .hdmi_rdma_reg_base = 0x64000,
+ .hdmi_rdma_reg_stride = 0x1000,
+ .hdmi_rdma_channels = 4,
.dmactl_audif_start = 1,
.wrdma_reg_base = 0x18000,
.wrdma_reg_stride = 0x1000,
@@ -163,7 +193,7 @@ static struct lpass_variant sc7180_data = {
.rdma_dyncclk = REG_FIELD_ID(0xC000, 21, 21, 5, 0x1000),
.rdma_bursten = REG_FIELD_ID(0xC000, 20, 20, 5, 0x1000),
.rdma_wpscnt= REG_FIELD_ID(0xC000, 16, 19, 5, 0x1000),
- .rdma_intf = REG_FIELD_ID(0xC000, 12, 15, 5, 0x1000),
+ .rdma_intf = REG_FIELD_ID(0xC000, 12, 15, 5,
0x1000),
.rdma_fifowm= REG_FIELD_ID(0xC000, 1, 5, 5, 0x1000),
.rdma_enable= REG_FIELD_ID(0xC000, 0, 0, 5, 0x1000),
@@ -174,6 +204,64 @@ static struct lpass_variant sc7180_data = {
.wrdma_fifowm = REG_FIELD_ID(0x18000, 1, 5, 4, 0x1000),
.wrdma_enable = REG_FI
Re: [PATCH] mmc: meson-gx: remove IRQF_ONESHOT
On 7/10/2020 10:32 pm, Jerome Brunet wrote:
With arm64 defconfig on Khadas vim3, no obvious regression. Looks good.
Tested-by: Jerome Brunet
I did not test with RT. Brad, Could you let us know is Thomas's patch
works for you ? Thx
There was a merge conflict in applying against v5.9-rc8-rt12 with
particular this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/kernel/irq/manage.c?h=linux-5.9.y-rt&id=18df00ef0b2b1513dc8f1a9ed26b11fff2261c30
I did manage to add the patch after attempting to resolve the conflict
which solves the deadlock issue I am seeing with mmc and works fine during
testing (a kernel compilation on preempt_rt configured kernel).
irq_thread in /kernel/irq/manage.c Looks like this (not 100% sure I
should have placed the irq_finalize_oneshot before
add_interrupt_randomness).
Based on this I can provide
Tested-by: Brad Harper
---
static int irq_thread(void *data)
{
struct callback_head on_exit_work;
struct irqaction *action = data;
struct irq_desc *desc = irq_to_desc(action->irq);
irqreturn_t (*handler_fn)(struct irq_desc *desc,
struct irqaction *action);
if (force_irqthreads && test_bit(IRQTF_FORCED_THREAD,
&action->thread_flags))
handler_fn = irq_forced_thread_fn;
else
handler_fn = irq_thread_fn;
init_task_work(&on_exit_work, irq_thread_dtor);
task_work_add(current, &on_exit_work, false);
irq_thread_check_affinity(desc, action);
while (!irq_wait_for_interrupt(action)) {
irqreturn_t action_ret;
irq_thread_check_affinity(desc, action);
action_ret = handler_fn(desc, action);
if (action_ret == IRQ_HANDLED)
atomic_inc(&desc->threads_handled);
if (action_ret == IRQ_WAKE_THREAD)
irq_wake_secondary(desc, action);
irq_finalize_oneshot(desc, action);
if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
migrate_disable();
add_interrupt_randomness(action->irq, 0,
desc->random_ip ^ (unsigned long) action);
migrate_enable();
}
wake_threads_waitq(desc);
}
/*
* This is the regular exit path. __free_irq() is stopping the
* thread via kthread_stop() after calling
* synchronize_hardirq(). So neither IRQTF_RUNTHREAD nor the
* oneshot mask bit can be set.
*/
task_work_cancel(current, irq_thread_dtor);
return 0;
}
---
Re: [PATCH v3 0/3] Support NVIDIA Tegra-based Ouya game console
07.10.2020 19:08, Stephen Warren пишет: ... > The facts[1] that Ouya published the code and that it used GPL-only > symbols certainly does imply that they *should* have published under GPL > or a compatible license, but doesn't mean that they definitely did. The > only way to know that for sure is for there to be evidence in the file > content or git history, such as license headers or Signed-off-by lines. The code wasn't only published, but also was distributed in a binary form to end users. This means that even if Ouya Inc. still existed and they made a mistake by using GPL-only symbols plus GPL-incompatible license for the driver, then they had to resilience the code. Hence either way it's okay to use downstream code as a reference for the upstream driver. This is my understanding.
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Mon, Oct 5, 2020 at 6:45 AM Christoph Hellwig wrote: > > How is this going to deal with VIVT caches? Hrm. That's a good question. I'm not sure I totally have my head around it but, I guess we could make sure to call invalidate_kernel_vmap_range() in begin_cpu_access() and flush_kernel_vmap_range() in end_cpu_access() rather then exiting out early as we do now? Unless you have better guidance? Worse case we could check CONFIG_CPU_CACHE_VIVT and not register the system-uncached heap. thanks -john
Re: [PATCH] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
On Wed, Oct 07, 2020 at 07:18:02PM -0700, Nathan Chancellor wrote:
> On Wed, Oct 07, 2020 at 07:09:54AM +0200, Mauro Carvalho Chehab wrote:
> > As warned by Randy:
> >
> > on x86_64:
> > CONFIG_USB_ROLE_SWITCH=m
> > and HISI_HIKEY_USB=y.
> >
> > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove':
> > hisi_hikey_usb.c:(.text+0x61): undefined reference to
> > `usb_role_switch_unregister'
> > ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to
> > `usb_role_switch_put'
> > ld: drivers/misc/hisi_hikey_usb.o: in function
> > `hub_usb_role_switch_set':
> > hisi_hikey_usb.c:(.text+0xd3): undefined reference to
> > `usb_role_switch_get_drvdata'
> > ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch':
> > hisi_hikey_usb.c:(.text+0x54d): undefined reference to
> > `usb_role_switch_set_role'
> > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe':
> > hisi_hikey_usb.c:(.text+0x8a5): undefined reference to
> > `usb_role_switch_get'
> > ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to
> > `usb_role_switch_register'
> > ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to
> > `usb_role_switch_put'
> >
> > Make it dependent on CONFIG_USB_ROLE_SWITCH.
> >
> > Reported-by: Randy Dunlap
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/misc/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index e19e1dcceb41..7cee2b72c09e 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -459,6 +459,7 @@ config PVPANIC
> > config HISI_HIKEY_USB
> > tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform"
> > depends on (OF && GPIOLIB) || COMPILE_TEST
> > + depends on CONFIG_USB_ROLE_SWITCH
>
> Shouldn't this be
>
> depends on USB_ROLE_SWITCH
>
> ? Now it will never be selectable.
{sigh}
Yes, that is correct.
Mauro, can you send a fix-up patch for this, as your original is now in
my tree.
thanks,
greg k-h
Re: [v5 01/12] struct device: Add function callback durable_name
On Wed, Oct 07, 2020 at 03:10:17PM -0500, Tony Asleson wrote: > On 10/1/20 6:48 AM, Greg Kroah-Hartman wrote: > > On Wed, Sep 30, 2020 at 09:35:52AM -0500, Tony Asleson wrote: > >> On 9/30/20 2:38 AM, Greg Kroah-Hartman wrote: > >>> On Tue, Sep 29, 2020 at 05:04:32PM -0500, Tony Asleson wrote: > I'm trying to figure out a way to positively identify which storage > device an error belongs to over time. > >>> > >>> "over time" is not the kernel's responsibility. > >>> > >>> This comes up every 5 years or so. The kernel provides you, at runtime, > >>> a mapping between a hardware device and a "logical" device. It can > >>> provide information to userspace about this mapping, but once that > >>> device goes away, the kernel is free to reuse that logical device again. > >>> > >>> If you want to track what logical devices match up to what physical > >>> device, then do it in userspace, by parsing the log files. > >> > >> I don't understand why people think it's acceptable to ask user space to > >> parse text that is subject to change. > > > > What text is changing? The format of of the prefix of dev_*() is well > > known and has been stable for 15+ years now, right? What is difficult > > in parsing it? > > Many of the storage layer messages are using printk, not dev_printk. Ok, then stop right there. Fix that up. Don't try to route around the standard way of displaying log messages by creating a totally different way of doing things. Just use the dev_*() calls, and all will be fine. Kernel log messages are not "ABI" in that they have to be preserved in any specific way, so adding a prefix to them as dev_*() does, will be fine. thanks, greg k-h
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
In file included from include/linux/clk.h:13,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_update_palette':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/kernel.h:47:33: note: in definition of macro 'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/kernel.h:47:48: note: in definition of macro 'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|^~~
In file included from include/linux/bits.h:22,
from include/linux/bitops.h:5,
from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
include/linux/build_bug.h:16:51: error: bit-field '' width not an
integer constant
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
|^
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:453:9: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
453 | priv->dma_hwdescs->palette[i] = color;
|
linux-next: build warning after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: modpost: EXPORT symbol "copy_mc_fragile" [vmlinux] version generation
failed, symbol will not be versioned.
Probably introduced by commit
ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,
kernel}()")
--
Cheers,
Stephen Rothwell
pgp_n7zVbctPr.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] PCI: vmd: Enable ASPM for mobile platforms
> On Oct 7, 2020, at 21:30, Bjorn Helgaas wrote:
>
> On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
>>> On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
>>> On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> On Oct 3, 2020, at 06:18, Bjorn Helgaas wrote:
> On Wed, Sep 30, 2020 at 04:24:54PM +0800, Kai-Heng Feng wrote:
>
> ...
I wonder whether other devices that add PCIe domain have the same
behavior? Maybe it's not a special case at all...
>>>
>>> What other devices are these?
>>
>> Controllers which add PCIe domain.
>
> I was looking for specific examples, not just a restatement of what
> you said before. I'm just curious because there are a lot of
> controllers I'm not familiar with, and I can't think of an example.
>
I understand the end goal is to keep consistency for the entire ASPM
logic. However I can't think of any possible solution right now.
> - If we built with CONFIG_PCIEASPM_POWERSAVE=y, would that solve the
> SoC power state problem?
Yes.
> - What issues would CONFIG_PCIEASPM_POWERSAVE=y introduce?
This will break many systems, at least for the 1st Gen Ryzen
desktops and laptops.
All PCIe ASPM are not enabled by BIOS, and those systems immediately
freeze once ASPM is enabled.
>>>
>>> That indicates a defect in the Linux ASPM code. We should fix that.
>>> It should be safe to use CONFIG_PCIEASPM_POWERSAVE=y on every system.
>>
>> On those systems ASPM are also not enabled on Windows. So I think
>> ASPM are disabled for a reason.
>
> If the platform knows ASPM needs to be disabled, it should be using
> ACPI_FADT_NO_ASPM or _OSC to prevent the OS from using it. And if
> CONFIG_PCIEASPM_POWERSAVE=y means Linux enables ASPM when it
> shouldn't, that's a Linux bug that we need to fix.
Yes that's a bug which fixed by Ian's new patch.
>
>>> Are there bug reports for these? The info we would need to start with
>>> includes "lspci -vv" and dmesg log (with CONFIG_PCIEASPM_DEFAULT=y).
>>> If a console log with CONFIG_PCIEASPM_POWERSAVE=y is available, that
>>> might be interesting, too. We'll likely need to add some
>>> instrumentation and do some experimentation, but in principle, this
>>> should be fixable.
>>
>> Doing this is asking users to use hardware settings that ODM/OEM
>> never tested, and I think the risk is really high.
>
> What? That's not what I said at all. I'm asking for information
> about these hangs so we can fix them. I'm not suggesting that you
> should switch to CONFIG_PCIEASPM_POWERSAVE=y for the distro.
Ah, I thought your suggestion is switching to CONFIG_PCIEASPM_POWERSAVE=y,
because I sense you want to use that to cover the VMD ASPM this patch tries to
solve.
Do we have a conclusion how to enable VMD ASPM with CONFIG_PCIEASPM_DEFAULT=y?
>
> Let's back up. You said:
>
> CONFIG_PCIEASPM_POWERSAVE=y ... will break many systems, at least
> for the 1st Gen Ryzen desktops and laptops.
>
> All PCIe ASPM are not enabled by BIOS, and those systems immediately
> freeze once ASPM is enabled.
>
> These system hangs might be caused by (1) some hardware issue that
> causes a hang when ASPM is enabled even if it is configured correctly
> or (2) Linux configuring ASPM incorrectly.
It's (2) here.
>
> For case (1), the platform should be using ACPI_FADT_NO_ASPM or _OSC
> to prevent the OS from enabling ASPM. Linux should pay attention to
> that even when CONFIG_PCIEASPM_POWERSAVE=y.
>
> If the platform *should* use these mechanisms but doesn't, the
> solution is a quirk, not the folklore that "we can't use
> CONFIG_PCIEASPM_POWERSAVE=y because it breaks some systems."
The platform in question doesn't prevent OS from enabling ASPM.
>
> For case (2), we should fix Linux so it configures ASPM correctly.
>
> We cannot use the build-time CONFIG_PCIEASPM settings to avoid these
> hangs. We need to fix the Linux run-time code so the system operates
> correctly no matter what CONFIG_PCIEASPM setting is used.
>
> We have sysfs knobs to control ASPM (see 72ea91afbfb0 ("PCI/ASPM: Add
> sysfs attributes for controlling ASPM link states")). They can do the
> same thing at run-time as CONFIG_PCIEASPM_POWERSAVE=y does at
> build-time. If those knobs cause hangs on 1st Gen Ryzen systems, we
> need to fix that.
Ian's patch solves the issue, at least for the systems I have.
Kai-Heng
>
> Bjorn
Investment!
Greetings, I want to inform you that my principal's family wishes to make huge financial investment in your home Country on areas of oil and gas, real estate, tourism and hotel,manufacturing and production company,agriculture,fishing, Mining & Trading of natural resources such as crude oil, coal, graphite, coke,refinery,energy etc. We needs a capable, trust worthy and understanding business partner. Highly confidential and trusted partner to manage funds in proxy Three Hundred Million US Dollars(US$300M) for investment purposes. Must be a dedicated and honest business person Please, I will provide more details about the transaction if you are Willing to handle such project and also let you know your entitlement for the solicited role I shall be expecting your quick reply. Email: vpetrus...@gmail.com Best Regards, Petrus Vermeulen.
RE: [PATCH 1/2] usb: cdns3: Rids of duplicate error message
Hi Roger,
>
>On 07/10/2020 06:35, Pawel Laszczak wrote:
>> On failure, the platform_get_irq_byname prints an error message
>> so, patch removes error message related to this function from
>> core.c file.
>>
>> A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
>>
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/cdns3/core.c | 7 +--
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> index a0f73d4711ae..4fd3c742d9d5 100644
>> --- a/drivers/usb/cdns3/core.c
>> +++ b/drivers/usb/cdns3/core.c
>> @@ -469,9 +469,6 @@ static int cdns3_probe(struct platform_device *pdev)
>> if (cdns->dev_irq == -EPROBE_DEFER)
>
>if (cdns->dev_irq < 0 && cdns->dev_irq == -EPROBE_DEFER)
It's the same - cdns->dev_irq == -EPROBE_DEFER < 0
>> return cdns->dev_irq;
>>
>> -if (cdns->dev_irq < 0)
>> -dev_err(dev, "couldn't get peripheral irq\n");
>> -
>> regs = devm_platform_ioremap_resource_byname(pdev, "dev");
>> if (IS_ERR(regs))
>> return PTR_ERR(regs);
>> @@ -481,10 +478,8 @@ static int cdns3_probe(struct platform_device *pdev)
>> if (cdns->otg_irq == -EPROBE_DEFER)
>
>if (cdns->otg_irq < 0 && cdns->otg_irq == -EPROBE_DEFER)
It should be:
if (cdns->dev_irq < 0 || cdns->dev_irq == -EPROBE_DEFER)
or event
if (cdns->dev_irq < 0)
Am I right ?
>
>> return cdns->otg_irq;
>>
>> -if (cdns->otg_irq < 0) {
>> -dev_err(dev, "couldn't get otg irq\n");
>> +if (cdns->otg_irq < 0)
>
>you can then get rid of this if {}.
>
>> return cdns->otg_irq;
>> -}
>>
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
>> if (!res) {
>>
Cheers,
Pawell
[PATCH] misc: rtsx: rts522a support L1 substate
From: Ricky Wu
add rts522a L1 substate functions for kernel 5.4
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rts5227.c | 111 -
drivers/misc/cardreader/rtsx_pcr.c | 30
drivers/misc/cardreader/rtsx_pcr.h | 2 +
include/linux/rtsx_pci.h | 5 ++
4 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cardreader/rts5227.c
b/drivers/misc/cardreader/rts5227.c
index 3a9467aaa435..0d59106c7228 100644
--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -89,10 +89,73 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
+static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
+{
+ struct pci_dev *pdev = pcr->pci;
+ int l1ss;
+ u32 lval;
+ struct rtsx_cr_option *option = &pcr->option;
+
+ l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
+ if (!l1ss)
+ return;
+
+ pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, &lval);
+
+ if (CHK_PCI_PID(pcr, 0x522A)) {
+ if (0 == (lval & 0x0F))
+ rtsx_pci_enable_oobs_polling(pcr);
+ else
+ rtsx_pci_disable_oobs_polling(pcr);
+ }
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
+ rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
+ rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
+ rtsx_set_dev_flag(pcr, PM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
+ rtsx_set_dev_flag(pcr, PM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
+
+ if (option->ltr_en) {
+ u16 val;
+
+ pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, &val);
+ if (val & PCI_EXP_DEVCTL2_LTR_EN) {
+ option->ltr_enabled = true;
+ option->ltr_active = true;
+ rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
+ } else {
+ option->ltr_enabled = false;
+ }
+ }
+
+ if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
+ | PM_L1_1_EN | PM_L1_2_EN))
+ option->force_clkreq_0 = false;
+ else
+ option->force_clkreq_0 = true;
+
+}
+
static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
{
u16 cap;
+ struct rtsx_cr_option *option = &pcr->option;
+ rts5227_init_from_cfg(pcr);
rtsx_pci_init_cmd(pcr);
/* Configure GPIO as output */
@@ -114,9 +177,17 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rts5227_fill_driving(pcr, OUTPUT_3V3);
/* Configure force_clock_req */
if (pcr->flags & PCR_REVERSE_SOCKET)
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x30);
+ else
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x00);
+
+ if (option->force_clkreq_0)
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW);
else
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH);
+
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
@@ -372,6 +443,28 @@ static int rts522a_switch_output_voltage(struct rtsx_pcr
*pcr, u8 voltage)
return rtsx_pci_send_cmd(pcr, 100);
}
+static void rts522a_set_l1off_cfg_sub_d0(struct rtsx_pcr *pcr, int active)
+{
+ struct rtsx_cr_option *option = &pcr->option;
+ int aspm_L1_1, aspm_L1_2;
+ u8 val = 0;
+
+ aspm_L1_1 = rtsx_check_dev_flag(pcr, ASPM_L1_1_EN);
+ aspm_L1_2 = rtsx_check_dev_flag(pcr, ASPM_L1_2_EN);
+
+ if (active) {
+ /* run, latency: 60us */
+ if (aspm_L1_1)
+ val = option->ltr_l1off_snooze_sspwrgate;
+ } else {
+ /* l1off, latency: 300us */
+ if (aspm_L1_2)
+ val = option->ltr_l1off_sspwrgate;
+ }
+
+ rtsx_set_l1off_sub(pcr, val);
+}
+
/* rts522a operations mainly derived from rts5227, except phy/hw init setting.
*/
@@ -389,15 +482,29 @@ static const struct pcr_ops rts522a_pcr_ops = {
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
.force_power_down
Re: [RFC V2] dt-bindings: mailbox : arm,mhuv2: Add bindings
Updated Morten's email id as he is no longer with ARM. On Wed, 7 Oct 2020 at 20:58, Viresh Kumar wrote: > > This patch adds device tree binding for ARM Message Handling Unit (MHU) > controller version 2. > > Based on earlier work by Morten Borup Petersen. > > Co-developed-by: Morten Borup Petersen > Signed-off-by: Morten Borup Petersen > Signed-off-by: Tushar Khandelwal > Signed-off-by: Viresh Kumar > > --- > Morten/Tushar, > > I have prepared this based on the best of my understanding about the > hardware, but since I haven't worked on the actual hardware yet there > are chances that I may have misunderstood some of it. Please lemme know > if any of my understanding is incorrect. > > Here is the link to the previous attempt by Tushar to get it upstreamed > long back: > > https://lore.kernel.org/lkml/20190717192616.1731-1-tushar.khandel...@arm.com/ > > This is very much a new approach and so I am not pointing out the > differences from the previous one. > > I haven't started with redesigning the driver as of now and would like > to get some feedback on the bindings first. Thanks in advance. > --- > .../bindings/mailbox/arm,mhuv2.yaml | 170 ++ > 1 file changed, 170 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > new file mode 100644 > index ..3cbdc97f1f4c > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > @@ -0,0 +1,170 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/arm,mhuv2.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM MHUv2 Mailbox Controller > + > +maintainers: > + - Morten Borup Petersen > + - Viresh Kumar > + > +description: | > + The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that > has > + between 1 and 124 channel windows (each 32-bit wide) to provide > unidirectional > + communication with remote processor(s), where the number of channel windows > + are implementation dependent. > + > + Given the unidirectional nature of the controller, an MHUv2 mailbox may > only > + be written to or read from. If a pair of MHU controllers is implemented > + between two processing elements to provide bidirectional communication, > these > + must be specified as two separate mailboxes. > + > + If the interrupts property is present in device tree node, then its > treated as > + a receiver mailbox, otherwise a sender. > + > + An MHU controller must be specified along with the supported transport > + protocols. The transport protocols determine the method of data > transmission > + as well as the number of provided mailbox channels. > + > + Following are the possible transport protocols. > + > + - Doorbell: Each transfer is made up of single bit flag, using any one of > the > +bits in a channel window. A channel window can support up to 32 doorbells > +and the entire window shall be used in doorbell mode. Optionally, data > may > +be transmitted through a shared memory region, wherein the MHU is used > +strictly as an interrupt generation mechanism but that is out of the > scope > +of these bindings. > + > + - Single-word: Each transfer is single word, using a single Channel window. > + > + - Multi-word: Each transfer is made of two or more words, using two or more > +channel windows. > + > +# We need a select here so we don't match all nodes with 'arm,primecell' > +select: > + properties: > +compatible: > + contains: > +const: arm,mhuv2 > + required: > +- compatible > + > +properties: > + compatible: > +items: > + - const: arm,mhuv2 > + - const: arm,primecell > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > + > + clock-names: > +items: > + - const: apb_pclk > + > + arm-mhuv2-mode: > +description: | > + The MHUv2 controller may contain up to 124 channel windows (each 32-bit > + wide). The hardware and the DT bindings allows any combination of > those to > + be used for various transport protocols. > + > + This property allows a platform to describe how these channel windows > are > + used in various transport protocols. The entries in this property > shall be > + present as an array of tuples, where each tuple describes details about > + one of the transport protocol being implemented over some channel > + window(s). > + > + The first field of a tuple signifies the transfer protocol, 0 is > reserved > + for doorbell protocol, 1 is reserved for single-word protocol and 2 is > + reserved for multi-word protocol. Using any other value in the first > field > + of a tuple makes it inv
[tip:ras/core] BUILD SUCCESS 300638101329e8f1569115f3d7197ef5ef754a3a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras/core branch HEAD: 300638101329e8f1569115f3d7197ef5ef754a3a x86/mce: Decode a kernel instruction to determine if it is copying from user elapsed time: 723m configs tested: 115 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig m68kq40_defconfig arm64alldefconfig armrealview_defconfig arm pxa255-idp_defconfig microblaze mmu_defconfig mips bigsur_defconfig powerpc eiger_defconfig mips rbtx49xx_defconfig arm tegra_defconfig powerpcicon_defconfig mipsmalta_qemu_32r6_defconfig armmagician_defconfig powerpc tqm8540_defconfig powerpc maple_defconfig arm zx_defconfig sh rts7751r2dplus_defconfig m68kstmark2_defconfig arm colibri_pxa300_defconfig sh rsk7203_defconfig sh urquell_defconfig powerpc mpc834x_itxgp_defconfig powerpc asp8347_defconfig sh secureedge5410_defconfig arm tango4_defconfig powerpc canyonlands_defconfig h8300 defconfig h8300 h8s-sim_defconfig m68k m5249evb_defconfig xtensasmp_lx200_defconfig armkeystone_defconfig mips pic32mzda_defconfig mips rb532_defconfig arm mv78xx0_defconfig arm assabet_defconfig powerpc tqm8548_defconfig armclps711x_defconfig arm ep93xx_defconfig sh ul2_defconfig sh r7780mp_defconfig microblaze defconfig mips ip22_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20201008 x86_64 randconfig-a003-20201008 x86_64 randconfig-a005-20201008 x86_64 randconfig-a001-20201008 x86_64 randconfig-a002-20201008 x86_64 randconfig-a006-20201008 i386 randconfig-a006-20201008 i386 randconfig-a005-20201008 i386 randconfig-a001-20201008 i386 randconfig-a004-20201008 i386 randconfig-a002-20201008 i386 randconfig-a003-20201008 i386 randconfig-a015-20201008 i386 randconfig-a013-20201008 i386 randconfig-a014-20201008 i386 randconfig-a016-20201008 i386 randconfig-a011-20201008 i386 randconfig-a012-20201008 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig r
Re: [PATCH v4 0/2] Control over userfaultfd kernel-fault handling
Hello Lokesh,
On Wed, Oct 07, 2020 at 01:26:55PM -0700, Lokesh Gidra wrote:
> On Wed, Sep 23, 2020 at 11:56 PM Lokesh Gidra wrote:
> >
> > This patch series is split from [1]. The other series enables SELinux
> > support for userfaultfd file descriptors so that its creation and
> > movement can be controlled.
> >
> > It has been demonstrated on various occasions that suspending kernel
> > code execution for an arbitrary amount of time at any access to
> > userspace memory (copy_from_user()/copy_to_user()/...) can be exploited
> > to change the intended behavior of the kernel. For instance, handling
> > page faults in kernel-mode using userfaultfd has been exploited in [2, 3].
> > Likewise, FUSE, which is similar to userfaultfd in this respect, has been
> > exploited in [4, 5] for similar outcome.
> >
> > This small patch series adds a new flag to userfaultfd(2) that allows
> > callers to give up the ability to handle kernel-mode faults with the
> > resulting UFFD file object. It then adds a 'user-mode only' option to
> > the unprivileged_userfaultfd sysctl knob to require unprivileged
> > callers to use this new flag.
> >
> > The purpose of this new interface is to decrease the chance of an
> > unprivileged userfaultfd user taking advantage of userfaultfd to
> > enhance security vulnerabilities by lengthening the race window in
> > kernel code.
> >
> > [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dan...@google.com/
> > [2] https://duasynt.com/blog/linux-kernel-heap-spray
> > [3] https://duasynt.com/blog/cve-2016-6187-heap-off-by-one-exploit
I've looking at those links and I've been trying to verify the link
[3] is relevant.
Specifically I've been trying to verify if 1) current state of the art
modern SLUB randomization techniques already enabled in production and
rightfully wasting some CPU in all enterprise kernels to prevent
things like above to become an issue in practice 2) combined with the
fact different memcg need to share the same kmemcaches (which was
incidentally fixed a few months ago upstream) and 3) further
robustness enhancements against exploits in the slub metadata, may
already render the exploit [3] from 2016 irrelevant in practice.
So I started by trying to reproduce [3] by building 4.5.1 with a
.config with no robustness features and I booted it on fedora-32 or
gentoo userland and I cannot even invoke call_usermodehelper. Calling
socket(22, AF_INET, 0) won't invoke such function. Can you reproduce
on 4.5.1? Which kernel .config should I use to build 4.5.1 in order
for call_usermodehelper to be invoked by the exploit? Could you help
to verify it?
It even has uninitialized variable spawning random perrors so it
doesn't give a warm fuzzy feeling:
int main(int argc, char **argv) {
void *region, *map;
^
pthread_t uffd_thread;
int uffd, msqid, i;
region = (void *)mmap((void *)0x4000, 0x2000, PROT_READ|PROT_WRITE,
MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0);
if (!region) {
perror("mmap");
exit(2);
}
setup_pagefault(region + 0x1000, 0x1000, 1);
printf("my pid = %d\n", getpid());
if (!map) {
perror("mmap");
The whole point of being able to reproduce on 4.5.1 is then to
simulate if the same exploit would also reproduce on current kernels
with all enterprise default robustness features enabled. Or did
anybody already verify it?
Anyway the links I was playing with are all in the cover letter, the
cover letter is not as important as the actual patches. The actual
patches looks fine to me.
The only improvement I can think of is, what about to add a
printk_once to suggest to toggle the sysctl if userfaultfd bails out
because the process lacks the CAP_SYS_PTRACE capability? That would
facilitate the /etc/sysctl.conf or tuned tweaking in case the apps
aren't verbose enough.
It's not relevant anymore with this latest patchset, but about the
previous argument that seccomp couldn't be used in all Android
processes because of performance concern, I'm slightly confused.
https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html
"Android O includes a single seccomp filter installed into zygote, the
process from which all the Android applications are derived. Because
the filter is installed into zygote—and therefore all apps—the Android
security team took extra caution to not break existing apps"
Example:
$ uname -mo
aarch64 Android
$ cat swapoff.c
#include
int main()
{
swapoff("");
}
$ gcc swapoff.c -o swapoff -O2
$ ./swapoff
Bad system call
$
It's hard to imagine what is more performance critical than the zygote
process and the actual apps as above?
It's also hard to imagine what kind of performance concern can arise
by adding seccomp filters also to background system apps that
generally should consume ~0% of CPU.
If performance is really a c
RE: [PATCH 2/2] usb: cdns3: Variable ‘length’ set but not used
Siergei,
>
>On 10/7/20 11:15 AM, Roger Quadros wrote:
>
>[...]
>>> Patch removes not used variable 'length' from
>>> cdns3_wa2_descmiss_copy_data function.
>>>
>>> Signed-off-by: Pawel Laszczak
>>
>> Fixes: commit 141e70fef4ee ("usb: cdns3: gadget: need to handle sg case for
>> workaround 2 case")
>
> No "commit" is needed here.
Can you explain why?
I guess it's because commit 141e70fef4ee is quite new and it's not yet included
in any stable kernel version,
or because it's only warning - not error.
Am I right ?
>
>> Acked-by: Roger Quadros
>[...]
>
Regards,
Pawel
Re: [PATCH 2/2] riscv: Fixup static_obj() fail v2
On Wed, 07 Oct 2020 08:08:33 PDT (-0700), guo...@kernel.org wrote:
From: Guo Ren
v1 is commit: 6184358da0004c8fd940afda6c0a0fa4027dc911 which has
been reverted.
When enable LOCKDEP, static_obj() will cause error:
[0.067192] INFO: trying to register non-static key.
[0.067325] the code is fine but needs lockdep annotation.
[0.067449] turning off the locking correctness validator.
[0.067718] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7-dirty #44
[0.067945] Call Trace:
[0.068369] [] walk_stackframe+0x0/0xa4
[0.068506] [] show_stack+0x2a/0x34
[0.068631] [] dump_stack+0x94/0xca
[0.068757] [] register_lock_class+0x5b8/0x5bc
[0.068969] [] __lock_acquire+0x6c/0x1d5c
[0.069101] [] lock_acquire+0xae/0x312
[0.069228] [] _raw_spin_lock_irqsave+0x40/0x5a
[0.069357] [] complete+0x1e/0x50
[0.069479] [] rest_init+0x1b0/0x28a
[0.069660] [] 0xffe016a2
[0.069779] [] 0xffe01b84
[0.069953] [] 0xffe01092
Because some __initdata static variables is before _stext:
static int static_obj(const void *obj)
{
unsigned long start = (unsigned long) &_stext,
end = (unsigned long) &_end,
addr = (unsigned long) obj;
/*
* static variable?
*/
if ((addr >= start) && (addr < end))
return 1;
if (arch_is_kernel_data(addr))
return 1;
We could implement arch_is_kernel_data to fixup it.
Link:
https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guo...@kernel.org/T/#t
Signed-off-by: Guo Ren
Reported-by: Aurelien Jarno
Cc: Palmer Dabbelt
Cc: Atish Patra
Cc: Andreas Schwab
Cc: Aurelien Jarno
---
arch/riscv/include/asm/sections.h | 20
arch/riscv/kernel/setup.c | 9 +
2 files changed, 29 insertions(+)
create mode 100644 arch/riscv/include/asm/sections.h
diff --git a/arch/riscv/include/asm/sections.h
b/arch/riscv/include/asm/sections.h
new file mode 100644
index ..2317b9e
--- /dev/null
+++ b/arch/riscv/include/asm/sections.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_RISCV_SECTIONS_H
+#define _ASM_RISCV_SECTIONS_H
+
+#define arch_is_kernel_data arch_is_kernel_data
+
+#include
+
+extern bool init_mem_is_free;
+
+static inline int arch_is_kernel_data(unsigned long addr)
+{
+ if (init_mem_is_free)
+ return 0;
+
+ return addr >= (unsigned long)__init_begin &&
+ addr < (unsigned long)__init_end;
+}
+#endif /* _ASM_RISCV_SECTIONS_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 2c6dd32..9ebd5eb4 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -112,3 +113,11 @@ static int __init topology_init(void)
return 0;
}
subsys_initcall(topology_init);
+
+bool init_mem_is_free = false;
+
+void free_initmem(void)
+{
+ free_initmem_default(POISON_FREE_INITMEM);
+ init_mem_is_free = true;
+}
I'm a bit confused as to what you're trying to do here. Yesterday I got
another version of this patch set that moves init data around, today a
different one. Yesterday's is tested and simpler, and given it's so late in
the process I'm inclined to take that as I don't want to break anything.
Right now I have
84814460eef9 ("riscv: Fixup bootup failure with HARDENED_USERCOPY")
a78c6f5956a9 ("RISC-V: Make sure memblock reserves the memory containing DT")
549738f15da0 ("Linux 5.9-rc8")
Unless there's some functional bug, that's what I'm going to send out for 5.9
-- I'm not all that worried about lacking the ability to free init data. The
above seems like fine 5.10 material.
Let me know if I'm missing something here.
[PATCH v2 8/8] blk-throttle: Re-use the throtl_set_slice_end()
Re-use throtl_set_slice_end() to remove duplicate code.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index fc5c14f..b771c42 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -808,7 +808,7 @@ static inline void throtl_set_slice_end(struct throtl_grp
*tg, bool rw,
static inline void throtl_extend_slice(struct throtl_grp *tg, bool rw,
unsigned long jiffy_end)
{
- tg->slice_end[rw] = roundup(jiffy_end, tg->td->throtl_slice);
+ throtl_set_slice_end(tg, rw, jiffy_end);
throtl_log(&tg->service_queue,
"[%c] extend slice start=%lu end=%lu jiffies=%lu",
rw == READ ? 'R' : 'W', tg->slice_start[rw],
--
1.8.3.1
[PATCH v2 0/8] Some improvements for blk throttle
Hi, This patch set did some improvements for blk throttle, please help to review. Thanks. Changes from v1: - Add another 4 new patches in this patch set. Baolin Wang (8): blk-throttle: Remove a meaningless parameter for throtl_downgrade_state() blk-throttle: Avoid getting the current time if tg->last_finish_time is 0 blk-throttle: Avoid tracking latency if low limit is invalid blk-throttle: Fix IO hang for a corner case blk-throttle: Move the list operation after list validation blk-throttle: Move service tree validation out of the throtl_rb_first() blk-throttle: Open code __throtl_de/enqueue_tg() blk-throttle: Re-use the throtl_set_slice_end() block/blk-throttle.c | 69 ++-- 1 file changed, 35 insertions(+), 34 deletions(-) -- 1.8.3.1
[PATCH v2 7/8] blk-throttle: Open code __throtl_de/enqueue_tg()
The __throtl_de/enqueue_tg() functions are only be called by
throtl_de/enqueue_tg(), thus we can just open code them to
make code more readable.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 38aed8b..fc5c14f 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -691,29 +691,21 @@ static void tg_service_queue_add(struct throtl_grp *tg)
leftmost);
}
-static void __throtl_enqueue_tg(struct throtl_grp *tg)
-{
- tg_service_queue_add(tg);
- tg->flags |= THROTL_TG_PENDING;
- tg->service_queue.parent_sq->nr_pending++;
-}
-
static void throtl_enqueue_tg(struct throtl_grp *tg)
{
- if (!(tg->flags & THROTL_TG_PENDING))
- __throtl_enqueue_tg(tg);
-}
-
-static void __throtl_dequeue_tg(struct throtl_grp *tg)
-{
- throtl_rb_erase(&tg->rb_node, tg->service_queue.parent_sq);
- tg->flags &= ~THROTL_TG_PENDING;
+ if (!(tg->flags & THROTL_TG_PENDING)) {
+ tg_service_queue_add(tg);
+ tg->flags |= THROTL_TG_PENDING;
+ tg->service_queue.parent_sq->nr_pending++;
+ }
}
static void throtl_dequeue_tg(struct throtl_grp *tg)
{
- if (tg->flags & THROTL_TG_PENDING)
- __throtl_dequeue_tg(tg);
+ if (tg->flags & THROTL_TG_PENDING) {
+ throtl_rb_erase(&tg->rb_node, tg->service_queue.parent_sq);
+ tg->flags &= ~THROTL_TG_PENDING;
+ }
}
/* Call with queue lock held */
--
1.8.3.1
[PATCH v2 3/8] blk-throttle: Avoid tracking latency if low limit is invalid
The IO latency tracking is only for LOW limit, so we should add a
validation to avoid redundant latency tracking if the LOW limit
is not valid.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 7e72102..b0d8f7c 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -2100,7 +2100,7 @@ static void throtl_update_latency_buckets(struct
throtl_data *td)
unsigned long last_latency[2] = { 0 };
unsigned long latency[2];
- if (!blk_queue_nonrot(td->queue))
+ if (!blk_queue_nonrot(td->queue) || !td->limit_valid[LIMIT_LOW])
return;
if (time_before(jiffies, td->last_calculate_time + HZ))
return;
@@ -2338,6 +2338,8 @@ void blk_throtl_bio_endio(struct bio *bio)
if (!blkg)
return;
tg = blkg_to_tg(blkg);
+ if (!tg->td->limit_valid[LIMIT_LOW])
+ return;
finish_time_ns = ktime_get_ns();
tg->last_finish_time = finish_time_ns >> 10;
--
1.8.3.1
[PATCH v2 4/8] blk-throttle: Fix IO hang for a corner case
It can not scale up in throtl_adjusted_limit() if we set bps or iops is 1, which will cause IO hang when enable low limit. Thus we should treat 1 as a illegal value to avoid this issue. Signed-off-by: Baolin Wang --- block/blk-throttle.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index b0d8f7c..0649bce 100644 --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -1687,13 +1687,13 @@ static ssize_t tg_set_limit(struct kernfs_open_file *of, goto out_finish; ret = -EINVAL; - if (!strcmp(tok, "rbps")) + if (!strcmp(tok, "rbps") && val > 1) v[0] = val; - else if (!strcmp(tok, "wbps")) + else if (!strcmp(tok, "wbps") && val > 1) v[1] = val; - else if (!strcmp(tok, "riops")) + else if (!strcmp(tok, "riops") && val > 1) v[2] = min_t(u64, val, UINT_MAX); - else if (!strcmp(tok, "wiops")) + else if (!strcmp(tok, "wiops") && val > 1) v[3] = min_t(u64, val, UINT_MAX); else if (off == LIMIT_LOW && !strcmp(tok, "idle")) idle_time = val; -- 1.8.3.1
[PATCH v2 2/8] blk-throttle: Avoid getting the current time if tg->last_finish_time is 0
We only update the tg->last_finish_time when the low limitaion is
enabled, so we can move the tg->last_finish_time validation a little
forward to avoid getting the unnecessary current time stamp if the
the low limitation is not enabled.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 4007b26..7e72102 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -2077,10 +2077,14 @@ static void throtl_downgrade_check(struct throtl_grp
*tg)
static void blk_throtl_update_idletime(struct throtl_grp *tg)
{
- unsigned long now = ktime_get_ns() >> 10;
+ unsigned long now;
unsigned long last_finish_time = tg->last_finish_time;
- if (now <= last_finish_time || last_finish_time == 0 ||
+ if (last_finish_time == 0)
+ return;
+
+ now = ktime_get_ns() >> 10;
+ if (now <= last_finish_time ||
last_finish_time == tg->checked_last_finish_time)
return;
--
1.8.3.1
[PATCH v2 6/8] blk-throttle: Move service tree validation out of the throtl_rb_first()
The throtl_schedule_next_dispatch() will validate if the service queue
is empty before calling update_min_dispatch_time(), and the
update_min_dispatch_time() will call throtl_rb_first(), which will
validate service queue again.
Thus we can move the service queue validation out of the
throtl_rb_first() to remove the redundant validation in the fast path.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index f1bcb5c..38aed8b 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -638,9 +638,6 @@ static void throtl_pd_free(struct blkg_policy_data *pd)
throtl_rb_first(struct throtl_service_queue *parent_sq)
{
struct rb_node *n;
- /* Service tree is empty */
- if (!parent_sq->nr_pending)
- return NULL;
n = rb_first_cached(&parent_sq->pending_tree);
WARN_ON_ONCE(!n);
@@ -1224,9 +1221,13 @@ static int throtl_select_dispatch(struct
throtl_service_queue *parent_sq)
unsigned int nr_disp = 0;
while (1) {
- struct throtl_grp *tg = throtl_rb_first(parent_sq);
+ struct throtl_grp *tg;
struct throtl_service_queue *sq;
+ if (!parent_sq->nr_pending)
+ break;
+
+ tg = throtl_rb_first(parent_sq);
if (!tg)
break;
--
1.8.3.1
[PATCH v2 1/8] blk-throttle: Remove a meaningless parameter for throtl_downgrade_state()
The throtl_downgrade_state() is always used to change to LIMIT_LOW
limitation, thus remove the latter meaningless parameter which
indicates the limitation index.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 36ba61c..4007b26 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -1970,7 +1970,7 @@ static void throtl_upgrade_state(struct throtl_data *td)
queue_work(kthrotld_workqueue, &td->dispatch_work);
}
-static void throtl_downgrade_state(struct throtl_data *td, int new)
+static void throtl_downgrade_state(struct throtl_data *td)
{
td->scale /= 2;
@@ -1980,7 +1980,7 @@ static void throtl_downgrade_state(struct throtl_data
*td, int new)
return;
}
- td->limit_index = new;
+ td->limit_index = LIMIT_LOW;
td->low_downgrade_time = jiffies;
}
@@ -2067,7 +2067,7 @@ static void throtl_downgrade_check(struct throtl_grp *tg)
* cgroups
*/
if (throtl_hierarchy_can_downgrade(tg))
- throtl_downgrade_state(tg->td, LIMIT_LOW);
+ throtl_downgrade_state(tg->td);
tg->last_bytes_disp[READ] = 0;
tg->last_bytes_disp[WRITE] = 0;
--
1.8.3.1
[PATCH v2 5/8] blk-throttle: Move the list operation after list validation
We should move the list operation after validation.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 0649bce..f1bcb5c 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -423,12 +423,13 @@ static void throtl_qnode_add_bio(struct bio *bio, struct
throtl_qnode *qn,
*/
static struct bio *throtl_peek_queued(struct list_head *queued)
{
- struct throtl_qnode *qn = list_first_entry(queued, struct throtl_qnode,
node);
+ struct throtl_qnode *qn;
struct bio *bio;
if (list_empty(queued))
return NULL;
+ qn = list_first_entry(queued, struct throtl_qnode, node);
bio = bio_list_peek(&qn->bios);
WARN_ON_ONCE(!bio);
return bio;
@@ -451,12 +452,13 @@ static struct bio *throtl_peek_queued(struct list_head
*queued)
static struct bio *throtl_pop_queued(struct list_head *queued,
struct throtl_grp **tg_to_put)
{
- struct throtl_qnode *qn = list_first_entry(queued, struct throtl_qnode,
node);
+ struct throtl_qnode *qn;
struct bio *bio;
if (list_empty(queued))
return NULL;
+ qn = list_first_entry(queued, struct throtl_qnode, node);
bio = bio_list_pop(&qn->bios);
WARN_ON_ONCE(!bio);
--
1.8.3.1
Re: [PATCH 2/2] Arm: dts: aspeed-g6: Add sgpio node and pinctrl setting
On Thu, 8 Oct 2020 at 01:51, Billy Tsai wrote:
>
> This patch is used to add sgpiom and sgpios nodes and add pinctrl setting
> for sgpiom1
The code looks good Billy.
Please split the change in two: device tree changes (arch/arm/dts) in
one, and pinctrl in the second, as they go through different
maintainers.
You also need to update the device tree bindings in Documentation with
the new compatible strings:
Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
That should go in it's own patch too.
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -366,6 +366,58 @@
> #interrupt-cells = <2>;
> };
>
> + sgpiom0: sgpiom@1e780500 {
> + #gpio-cells = <2>;
> + gpio-controller;
> + compatible = "aspeed,ast2600-sgpiom";
This is interesting. I didn't realise the sgpio driver we have in the
mainline kernel tree (drivers/gpio/gpio-aspeed-sgpio.c) is for the
sgpio master device. It might be best to update the naming of the
ast2400/ast2500 compatible in the future.
> + reg = <0x1e780500 0x100>;
> + interrupts = ;
> + ngpios = <128>;
> + clocks = <&syscon ASPEED_CLK_APB2>;
> + interrupt-controller;
> + bus-frequency = <1200>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sgpm1_default>;
> + status = "disabled";
> + };
> gpio1: gpio@1e780800 {
> #gpio-cells = <2>;
> gpio-controller;
> @@ -377,6 +429,7 @@
> clocks = <&syscon ASPEED_CLK_APB1>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + status = "disabled";
This should be in a different patch set, as it will break all of the
systems that expect GPIO to be enabled (which is all of them).
Considering all of them expect this gpio bank to be enabled, should we
leave it enabled here?
> };
>
> rtc: rtc@1e781000 {
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> index 34803a6c7664..b673a44ffa3b 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> @@ -46,8 +46,10 @@
> #define SCU620 0x620 /* Disable GPIO Internal Pull-Down #4 */
> #define SCU634 0x634 /* Disable GPIO Internal Pull-Down #5 */
> #define SCU638 0x638 /* Disable GPIO Internal Pull-Down #6 */
> +#define SCU690 0x690 /* Multi-function Pin Control #24 */
> #define SCU694 0x694 /* Multi-function Pin Control #25 */
> #define SCU69C 0x69C /* Multi-function Pin Control #27 */
> +#define SCU6D0 0x6D0 /* Multi-function Pin Control #28 */
> #define SCUC20 0xC20 /* PCIE configuration Setting Control */
>
> #define ASPEED_G6_NR_PINS 256
> @@ -81,13 +83,21 @@ FUNC_GROUP_DECL(I2C12, L26, K24);
> #define K26 4
> SIG_EXPR_LIST_DECL_SESG(K26, MACLINK1, MACLINK1, SIG_DESC_SET(SCU410, 4));
> SIG_EXPR_LIST_DECL_SESG(K26, SCL13, I2C13, SIG_DESC_SET(SCU4B0, 4));
> -PIN_DECL_2(K26, GPIOA4, MACLINK1, SCL13);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(K26, SGPM2CLK, SGPM2, SIG_DESC_SET(SCU6D0, 4),
> + SIG_DESC_CLEAR(SCU410, 4), SIG_DESC_CLEAR(SCU4B0,
> 4),
> + SIG_DESC_CLEAR(SCU690, 4));
> +PIN_DECL_3(K26, GPIOA4, SGPM2CLK, MACLINK1, SCL13);
> FUNC_GROUP_DECL(MACLINK1, K26);
>
> #define L24 5
> SIG_EXPR_LIST_DECL_SESG(L24, MACLINK2, MACLINK2, SIG_DESC_SET(SCU410, 5));
> SIG_EXPR_LIST_DECL_SESG(L24, SDA13, I2C13, SIG_DESC_SET(SCU4B0, 5));
> -PIN_DECL_2(L24, GPIOA5, MACLINK2, SDA13);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(L24, SGPM2LD, SGPM2, SIG_DESC_SET(SCU6D0, 5),
> + SIG_DESC_CLEAR(SCU410, 5), SIG_DESC_CLEAR(SCU4B0,
> 5),
> + SIG_DESC_CLEAR(SCU690, 5));
> +PIN_DECL_3(L24, GPIOA5, SGPM2LD, MACLINK2, SDA13);
> FUNC_GROUP_DECL(MACLINK2, L24);
>
> FUNC_GROUP_DECL(I2C13, K26, L24);
> @@ -95,16 +105,26 @@ FUNC_GROUP_DECL(I2C13, K26, L24);
> #define L23 6
> SIG_EXPR_LIST_DECL_SESG(L23, MACLINK3, MACLINK3, SIG_DESC_SET(SCU410, 6));
> SIG_EXPR_LIST_DECL_SESG(L23, SCL14, I2C14, SIG_DESC_SET(SCU4B0, 6));
> -PIN_DECL_2(L23, GPIOA6, MACLINK3, SCL14);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(L23, SGPM2O, SGPM2, SIG_DESC_SET(SCU6D0, 6),
> + SIG_DESC_CLEAR(SCU410, 6), SIG_DESC_CLEAR(SCU4B0,
> 6),
> +
