Re: [PATCH] crypto: s5p-sss: remove redundant null check
On Thu, Sep 03, 2020 at 08:37:38AM +, Xu Wang wrote: > Because clk_disable_unprepare already checked NULL clock > parameter, so the additional checks are unnecessary, just remove them. > > Signed-off-by: Xu Wang > --- > drivers/crypto/s5p-sss.c | 6 ++ > 1 file changed, 2 insertions(+), 4 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
Re: [PATCH v3 0/3] hwrng: add support for Xiphera XIP8001B
On Wed, Sep 02, 2020 at 01:28:14PM +0300, Atte Tommiska wrote: > This patchset introduces a linux driver for Xiphera's XIP8001B IP. > The IP is an FPGA-based TRNG which can be used in various FPGA families. > The IP is in use in multiple customer projects and in Xiphera's own products. > > changes in v2: > - fixed the 'make dt_binding_check' errors in the devicetree schema. > > changes in v3: > - added Rob's tags to the first and second patch > - fixed a typo in the subject line of the second patch > - removed a redundant line of code from the driver in the third patch > > Atte Tommiska (3): > dt-bindings: vendor-prefixes: Add Xiphera vendor prefix > dt-bindings: rng: add bindings for Xiphera XIP8001B hwrng > hwrng: xiphera-trng: add support for XIP8001B hwrng > > .../bindings/rng/xiphera,xip8001b-trng.yaml | 33 > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > drivers/char/hw_random/Kconfig| 10 ++ > drivers/char/hw_random/Makefile | 1 + > drivers/char/hw_random/xiphera-trng.c | 150 ++ > 5 files changed, 196 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml > create mode 100644 drivers/char/hw_random/xiphera-trng.c All 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] Bluetooth: btmtksdio: use NULL instead of zero
Hi Yue, > Fix sparse warnings: > > drivers/bluetooth/btmtksdio.c:499:57: warning: Using plain integer as NULL > pointer > drivers/bluetooth/btmtksdio.c:533:57: warning: Using plain integer as NULL > pointer > > Signed-off-by: YueHaibing > --- > drivers/bluetooth/btmtksdio.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] vfs: add fchmodat2 syscall
On Thu, Sep 10, 2020 at 01:02:56PM -0400, Rich Felker wrote: > Would you be happy with a pair of patches where the first blocks chmod > of symlinks in chmod_common and the second adds the syscall with > flags? I think this is a clearly understandable fix, but it does > eliminate the ability to *fix* link access modes that have been set to > ridiculous values (note: I don't think it really matters since the > modes don't do anything anyway) in the past. I'd be much happier with that, yes.
Re: [PATCH v1] Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support
Hi Rocky,
> This patch add support for WCN6855 i.e. patch and nvm download
> support.
>
> Signed-off-by: Rocky Liao
> ---
> drivers/bluetooth/btusb.c | 42 +++
> 1 file changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index fe80588c7bd3..e51e754ca9b8 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -59,6 +59,7 @@ static struct usb_driver btusb_driver;
> #define BTUSB_MEDIATEK0x20
> #define BTUSB_WIDEBAND_SPEECH 0x40
> #define BTUSB_VALID_LE_STATES 0x80
> +#define BTUSB_QCA_WCN68550x100
>
> static const struct usb_device_id btusb_table[] = {
> /* Generic Bluetooth USB device */
> @@ -273,6 +274,10 @@ static const struct usb_device_id blacklist_table[] = {
> { USB_DEVICE(0x13d3, 0x3496), .driver_info = BTUSB_QCA_ROME },
> { USB_DEVICE(0x13d3, 0x3501), .driver_info = BTUSB_QCA_ROME },
>
> + /* QCA WCN6855 chipset */
> + { USB_DEVICE(0x0cf3, 0xe600), .driver_info = BTUSB_QCA_WCN6855 |
> + BTUSB_WIDEBAND_SPEECH },
> +
> /* Broadcom BCM2035 */
> { USB_DEVICE(0x0a5c, 0x2009), .driver_info = BTUSB_BCM92035 },
> { USB_DEVICE(0x0a5c, 0x200a), .driver_info = BTUSB_WRONG_SCO_MTU },
> @@ -3391,6 +3396,26 @@ static int btusb_set_bdaddr_ath3012(struct hci_dev
> *hdev,
> return 0;
> }
>
> +static int btusb_set_bdaddr_wcn6855(struct hci_dev *hdev,
> + const bdaddr_t *bdaddr)
> +{
> + struct sk_buff *skb;
> + u8 buf[6];
> + long ret;
> +
> + memcpy(buf, bdaddr, sizeof(bdaddr_t));
> +
> + skb = __hci_cmd_sync(hdev, 0xfc14, sizeof(buf), buf, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb)) {
> + ret = PTR_ERR(skb);
> + bt_dev_err(hdev, "Change address command failed (%ld)", ret);
> + return ret;
> + }
> + kfree_skb(skb);
> +
> + return 0;
> +}
What is wrong with using qca_set_bdaddr() function.
> +
> #define QCA_DFU_PACKET_LEN4096
>
> #define QCA_GET_TARGET_VERSION0x09
> @@ -3428,6 +3453,8 @@ static const struct qca_device_info qca_devices_table[]
> = {
> { 0x0201, 28, 4, 18 }, /* Rome 2.1 */
> { 0x0300, 28, 4, 18 }, /* Rome 3.0 */
> { 0x0302, 28, 4, 18 }, /* Rome 3.2 */
> + { 0x00130100, 40, 4, 18 }, /* WCN6855 1.0 */
> + { 0x00130200, 40, 4, 18 } /* WCN6855 2.0 */
> };
>
> static int btusb_qca_send_vendor_req(struct usb_device *udev, u8 request,
> @@ -3530,7 +3557,7 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev
> *hdev,
> struct qca_rampatch_version *rver;
> const struct firmware *fw;
> u32 ver_rom, ver_patch;
> - u16 rver_rom, rver_patch;
> + u32 rver_rom, rver_patch;
> char fwname[64];
> int err;
>
> @@ -3552,6 +3579,9 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev
> *hdev,
> rver_rom = le16_to_cpu(rver->rom_version);
> rver_patch = le16_to_cpu(rver->patch_version);
>
> + if (ver_rom & ~0xU)
> + rver_rom = *(u16 *)(fw->data + 16) << 16 | rver_rom;
> +
You will require proper unaligned access unless you can guarantee things are
aligned properly. And since I assume the firmware data is in a specific endian
format, you need to convert it correctly.
In addition, you change the variables to u32, but still use le16_to_cpu
function above. Something is not adding up. Have you actually run a sparse
check?
> bt_dev_info(hdev, "QCA: patch rome 0x%x build 0x%x, "
> "firmware rome 0x%x build 0x%x",
> rver_rom, rver_patch, ver_rom, ver_patch);
> @@ -3625,9 +3655,6 @@ static int btusb_setup_qca(struct hci_dev *hdev)
> return err;
>
> ver_rom = le32_to_cpu(ver.rom_version);
> - /* Don't care about high ROM versions */
> - if (ver_rom & ~0xU)
> - return 0;
>
> for (i = 0; i < ARRAY_SIZE(qca_devices_table); i++) {
> if (ver_rom == qca_devices_table[i].rom_version)
> @@ -4063,6 +4090,13 @@ static int btusb_probe(struct usb_interface *intf,
> btusb_check_needs_reset_resume(intf);
> }
>
> + if (id->driver_info & BTUSB_QCA_WCN6855) {
> + data->setup_on_usb = btusb_setup_qca;
> + hdev->set_bdaddr = btusb_set_bdaddr_wcn6855;
> + hdev->cmd_timeout = btusb_qca_cmd_timeout;
> + set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
> + }
> +
Regards
Marcel
Re: [PATCH v2 01/15] dt-bindings: gpio: convert bindings for NXP PCA953x family to dtschema
On Fri, 11 Sep 2020 at 08:42, Geert Uytterhoeven wrote: > > Hi Krzysztof, > > On Thu, Sep 10, 2020 at 8:54 PM Krzysztof Kozlowski wrote: > > On Thu, 10 Sep 2020 at 20:28, Nishanth Menon wrote: > > > On 19:57-20200910, Krzysztof Kozlowski wrote: > > > [...] > > > > + wakeup-source: > > > > +$ref: /schemas/types.yaml#/definitions/flag > > > > + > > > > +patternProperties: > > > > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": > > > > > > I wonder if "hog" is too generic and might clash with "something-hog" in > > > the future? > > > > This pattern is already used in > > Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml. It will > > match only children and so far it did not find any other nodes in ARM > > and ARM64 dts. I don't expect clashes. Also the question is then - if > > one adds a child of GPIO expander named "foobar-hog" and it is not a > > GPIO hog, then what is it? > > Perhaps you didn't find any other nodes as children of pca953x > controllers? There shouldn't be.. unless one makes some i2c-gpio controller under such GPIO expander. But now it wouldn't be instantiated as expander is not a bus. > There are other hog nodes in other types of GPIO controllers. Typically > they're named after the purpose, e.g. "wifi-disable", "i2c3_mux_oe_n", > "pcie_sata_switch", "lcd0_mux". > > IMHO it's a hog if it contains a "gpio-hog" property, regardless of node > naming. Yes. The question is then whether to expect the "hog" in name. Just like we expect for all other device nodes to represent the class. Best regards, Krzysztof
Re: [PATCH v2 01/15] dt-bindings: gpio: convert bindings for NXP PCA953x family to dtschema
On Fri, 11 Sep 2020 at 08:24, Joel Stanley wrote:
>
> On Thu, 10 Sep 2020 at 17:57, Krzysztof Kozlowski wrote:
> >
> > Convert the NXP PCA953x family of GPIO expanders bindings to device tree
> > schema.
> >
> > Signed-off-by: Krzysztof Kozlowski
>
> > +patternProperties:
> > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
> > +type: object
> > +properties:
> > + gpio-hog: true
> > + gpios: true
> > + input: true
> > + output-high: true
> > + output-low: true
> > + line-name: true
> > +
> > +required:
> > + - gpio-hog
> > + - gpios
> > +
>
> > +usb3-sata-sel-hog {
> > +gpio-hog;
> > +gpios = <4 GPIO_ACTIVE_HIGH>;
> > +output-low;
> > +line-name = "usb3_sata_sel";
>
> I would prefer we didn't require the addition of hte -hog prefix. It's
> mostly just a matter of taste, but I can think of a few more concrete
> reasons:
>
> We don't require -high or -low prefixes, so the node name doesn't need
> to describe the properties that will be found below.
Thanks for the comments.
It is not about properties (high or low) but the role of a device
node. The node names should represent a generic class of device (ePAPR
and device tree spec) and "hog" is such class.
The Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml already
uses such naming so the best would be to unify.
>
> Changing around node names for existing boards carries with it the
> chance of userspace breakage (as sysfs paths change). I would prefer
> we avoid that if possible.
The impact on userspace is indeed important, but are you sure that
hogs are visible to user-space via sysfs and configurable? I guess you
think of deprecated CONFIG_GPIO_SYSFS?
Rob,
Any hints from you about hog-naming?
Best regards,
Krzysztof
Re: [PATCH] Bluetooth: hci_qca: remove redundant null check
Hi Xu, > Because clk_disable_unprepare already checked > NULL clock parameter, so the additional check is > unnecessary, just remove it. > > Signed-off-by: Xu Wang > --- > drivers/bluetooth/hci_qca.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH net] can: j1939: j1939_sk_bind(): return failure if netdev is down
On Mon, Sep 07, 2020 at 02:31:48PM +0800, Zhang Changzhong wrote:
> When a netdev down event occurs after a successful call to
> j1939_sk_bind(), j1939_netdev_notify() can handle it correctly.
>
> But if the netdev already in down state before calling j1939_sk_bind(),
> j1939_sk_release() will stay in wait_event_interruptible() blocked
> forever. Because in this case, j1939_netdev_notify() won't be called and
> j1939_tp_txtimer() won't call j1939_session_cancel() or other function
> to clear session for ENETDOWN error, this lead to mismatch of
> j1939_session_get/put() and jsk->skb_pending will never decrease to
> zero.
>
> To reproduce it use following commands:
> 1. ip link add dev vcan0 type vcan
> 2. j1939acd -r 100,80-120 1122334455667788 vcan0
> 3. presses ctrl-c and thread will be blocked forever
>
> This patch adds check for ndev->flags in j1939_sk_bind() to avoid this
> kind of situation and return with -ENETDOWN.
>
> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
> Signed-off-by: Zhang Changzhong
Acked-by: Oleksij Rempel
Thank you!
> ---
> net/can/j1939/socket.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/can/j1939/socket.c b/net/can/j1939/socket.c
> index 1be4c89..f239665 100644
> --- a/net/can/j1939/socket.c
> +++ b/net/can/j1939/socket.c
> @@ -475,6 +475,12 @@ static int j1939_sk_bind(struct socket *sock, struct
> sockaddr *uaddr, int len)
> goto out_release_sock;
> }
>
> + if (!(ndev->flags & IFF_UP)) {
> + dev_put(ndev);
> + ret = -ENETDOWN;
> + goto out_release_sock;
> + }
> +
> priv = j1939_netdev_start(ndev);
> dev_put(ndev);
> if (IS_ERR(priv)) {
> --
> 2.9.5
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] omap3: enable off mode automatically
Enabling off mode was only reachable deeply hidden
in the debugfs. As powersaving is an important feature,
move the option out of its shady place.
The debugfs file can still be used to override the default.
Use the presence of a device compatible to ti,twl4030-idle or
ti,twl4030-idle-osc-off as an indicator that the board is wired correctly
for off mode.
Signed-off-by: Andreas Kemnade
---
An earlier version of this patch was here:
https://patchwork.kernel.org/patch/10794121/
A config option was used instead of the suggested devicetree check.
arch/arm/mach-omap2/pm.h | 4
arch/arm/mach-omap2/pm34xx.c | 29 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2a883a0c1fcd..80e84ae66aee 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -49,11 +49,7 @@ static inline int omap4_opp_init(void)
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
-#ifdef CONFIG_PM_DEBUG
extern u32 enable_off_mode;
-#else
-#define enable_off_mode 0
-#endif
#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f5dfddf492e2..d069d581c372 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -51,6 +52,10 @@
/* pm34xx errata defined in pm.h */
u16 pm34xx_errata;
+#ifndef CONFIG_PM_DEBUG
+u32 enable_off_mode;
+#endif
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -410,7 +415,12 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
if (!pwrst)
return -ENOMEM;
pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_RET;
+
+ if (enable_off_mode)
+ pwrst->next_state = PWRDM_POWER_OFF;
+ else
+ pwrst->next_state = PWRDM_POWER_RET;
+
list_add(&pwrst->node, &pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
@@ -444,6 +454,21 @@ static void __init pm_errata_configure(void)
}
}
+static void __init omap3_pm_check_pmic(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "ti,twl4030-power-idle");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL,
"ti,twl4030-power-idle-osc-off");
+
+ if (np) {
+ of_node_put(np);
+ enable_off_mode = 1;
+ } else
+ enable_off_mode = 0;
+}
+
int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
@@ -477,6 +502,8 @@ int __init omap3_pm_init(void)
goto err2;
}
+ omap3_pm_check_pmic();
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err("Failed to setup powerdomains\n");
--
2.20.1
Re: [RESEND PATCH v12 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Miquel,
Thank you for your review comments...
On 7/9/2020 9:20 pm, Miquel Raynal wrote:
Hi Murugan,
A few more comments below, but I guess the driver looks better now.
+struct ebu_nand_controller {
+ struct nand_controller controller;
+ struct nand_chip chip;
+ struct device *dev;
+ void __iomem *ebu;
+ void __iomem *hsnand;
+ struct dma_chan *dma_tx;
+ struct dma_chan *dma_rx;
+ struct completion dma_access_complete;
+ unsigned long clk_rate;
+ struct clk *clk;
+ u32 nd_para0;
+ u8 cs_num;
+ struct ebu_nand_cs cs[MAX_CS];
+};
+
+static inline struct ebu_nand_controller *nand_to_ebu(struct nand_chip *chip)
+{
+ return container_of(chip, struct ebu_nand_controller, chip);
+}
+
+static u8 ebu_nand_readb(struct nand_chip *chip)
Can't you prefix with intel_ instead of ebu_ ?
+{
+ struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
+ void __iomem *nand_wait = ebu_host->ebu + EBU_WAIT;
+ u8 cs_num = ebu_host->cs_num;
+ u32 stat;
+ int ret;
+ u8 val;
+
+ val = readb(ebu_host->cs[cs_num].chipaddr + HSNAND_CS_OFFS);
+
+ ret = readl_poll_timeout(nand_wait, stat, stat & EBU_WAIT_WR_C,
+20, 1000);
If you do this operation each time a byte is read/written, you probable
want to shrink the polling delay a little bit, to 1 or even 0.
Ok, Noted.
+ if (ret)
+ dev_warn(ebu_host->dev,
+"ebu nand write timeout. nand_wait(0x%p)=0x%x\n",
+nand_wait, readl(nand_wait));
+
+ return val;
You should not return val if ret is !0 I guess
Yes, You're correct.
+}
+
+static void ebu_nand_writeb(struct nand_chip *chip, u32 offset, u8 value)
+{
+ struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
+ void __iomem *nand_wait = ebu_host->ebu + EBU_WAIT;
+ u8 cs_num = ebu_host->cs_num;
+ u32 stat;
+ int ret;
+
+ writeb(value, ebu_host->cs[cs_num].chipaddr + offset);
+
+ ret = readl_poll_timeout(nand_wait, stat, stat & EBU_WAIT_WR_C,
+20, 1000);
Here as well
Noted.
+ if (ret)
+ dev_warn(ebu_host->dev,
+"ebu nand write timeout. nand_wait(0x%p)=0x%x\n",
+nand_wait, readl(nand_wait));
If this can fail, then the helper should return an error and be treated.
Noted, will update.
+}
+
+static void ebu_read_buf(struct nand_chip *chip, u_char *buf, unsigned int len)
+{
+ int i;
+
+ for (i = 0; i < len; i++)
+ buf[i] = ebu_nand_readb(chip);
+}
+
+static void ebu_write_buf(struct nand_chip *chip, const u_char *buf, int len)
+{
+ int i;
+
+ for (i = 0; i < len; i++)
+ ebu_nand_writeb(chip, HSNAND_CS_OFFS, buf[i]);
+}
+
+static void ebu_nand_disable(struct nand_chip *chip)
+{
+ struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
+
+ writel(0, ebu_host->ebu + EBU_CON);
+}
+
+static void ebu_select_chip(struct nand_chip *chip)
+{
+ struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
+ void __iomem *nand_con = ebu_host->ebu + EBU_CON;
+ u32 cs = ebu_host->cs_num;
+
+ writel(EBU_CON_NANDM_EN | EBU_CON_CSMUX_E_EN | EBU_CON_CS_P_LOW |
+ EBU_CON_SE_P_LOW | EBU_CON_WP_P_LOW | EBU_CON_PRE_P_LOW |
+ EBU_CON_IN_CS_S(cs) | EBU_CON_OUT_CS_S(cs) |
+ EBU_CON_LAT_EN_CS_P, nand_con);
+}
+
+static void ebu_nand_setup_timing(struct ebu_nand_controller *ctrl,
+ const struct nand_sdr_timings *timings)
+{
+ unsigned int rate = clk_get_rate(ctrl->clk) / 100;
+ unsigned int period = DIV_ROUND_UP(100, rate);
+ u32 trecov, thold, twrwait, trdwait;
+ u32 reg = 0;
+
+ trecov = DIV_ROUND_UP(max(timings->tREA_max, timings->tREH_min),
+ period);
+ reg |= EBU_BUSCON_RECOVC(trecov);
+
+ thold = DIV_ROUND_UP(max(timings->tDH_min, timings->tDS_min), period);
+ reg |= EBU_BUSCON_HOLDC(thold);
+
+ trdwait = DIV_ROUND_UP(max(timings->tRC_min, timings->tREH_min),
+ period);
+ reg |= EBU_BUSCON_WAITRDC(trdwait);
+
+ twrwait = DIV_ROUND_UP(max(timings->tWC_min, timings->tWH_min), period);
+ reg |= EBU_BUSCON_WAITWRC(twrwait);
+
+ reg |= EBU_BUSCON_CMULT_V4 | EBU_BUSCON_BCGEN_CS | EBU_BUSCON_ALEC |
+ EBU_BUSCON_SETUP_EN;
+
+ writel(reg, ctrl->ebu + EBU_BUSCON(ctrl->cs_num));
+}
+
+static int ebu_nand_setup_data_interface(struct nand_chip *chip, int csline,
+const struct nand_data_interface *conf)
I recently changed the naming around the data interface, please
have a look at the recent commits and update the namings here as
well.
Sure, will go through update
Re: [PATCH 22/24] membarrier.2: Note that glibc does not provide a wrapper
On 9/10/20 11:13 PM, Alejandro Colomar wrote: > Notes: I copied .nf and .fi from futex.2, but they made no visual difference. > What do they actually do? > > Signed-off-by: Alejandro Colomar Thanks, Alex. Patch applied. Cheers, Michael > --- > man2/membarrier.2 | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/man2/membarrier.2 b/man2/membarrier.2 > index 8825de71e..f65c6be5c 100644 > --- a/man2/membarrier.2 > +++ b/man2/membarrier.2 > @@ -26,9 +26,15 @@ > .SH NAME > membarrier \- issue memory barriers on a set of threads > .SH SYNOPSIS > +.nf > +.PP > .B #include > .PP > .BI "int membarrier(int " cmd ", int " flags ");" > +.fi > +.PP > +.IR Note : > +There is no glibc wrapper for this system call; see NOTES. > .SH DESCRIPTION > The > .BR membarrier () > @@ -270,6 +276,9 @@ Examples where > .BR membarrier () > can be useful include implementations > of Read-Copy-Update libraries and garbage collectors. > +.PP > +Glibc does not provide a wrapper for this system call; call it using > +.BR syscall (2). > .SH EXAMPLES > Assuming a multithreaded application where "fast_path()" is executed > very frequently, and where "slow_path()" is executed infrequently, the > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH -next] drm/imx: fix unused but set variable warnings
On Fri, Sep 11, 2020 at 09:44:14AM +0800, Wang ShaoBo wrote:
> Fix unused but set variable warning building with `make W=1`:
>
> drivers/gpu/drm/imx/dcss/dcss-plane.c:270:6: warning:
> variable ‘pixel_format’ set but not used [-Wunused-but-set-variable]
> u32 pixel_format;
> ^~~~
>
> Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ")
> Reported-by: Hulk Robot
> Signed-off-by: Wang ShaoBo
pixel_format will be used in the next patches that will follow the
initial one and I probably forgot to remove it when I split the patches.
But, I guess, we could remove it for now to make the bots happy.
Reviewed-by: Laurentiu Palcu
> ---
> drivers/gpu/drm/imx/dcss/dcss-plane.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c
> b/drivers/gpu/drm/imx/dcss/dcss-plane.c
> index 961d671f171b..e13652e3a115 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-plane.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c
> @@ -267,7 +267,6 @@ static void dcss_plane_atomic_update(struct drm_plane
> *plane,
> struct dcss_plane *dcss_plane = to_dcss_plane(plane);
> struct dcss_dev *dcss = plane->dev->dev_private;
> struct drm_framebuffer *fb = state->fb;
> - u32 pixel_format;
> struct drm_crtc_state *crtc_state;
> bool modifiers_present;
> u32 src_w, src_h, dst_w, dst_h;
> @@ -277,7 +276,6 @@ static void dcss_plane_atomic_update(struct drm_plane
> *plane,
> if (!fb || !state->crtc || !state->visible)
> return;
>
> - pixel_format = state->fb->format->format;
> crtc_state = state->crtc->state;
> modifiers_present = !!(fb->flags & DRM_MODE_FB_MODIFIERS);
>
> --
> 2.17.1
>
Re: [PATCH 21/24] aio.7: Use perror() directly
On 9/10/20 11:13 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
Thanks, Alex. Patch applied.
Cheers,
Michael
> ---
> man7/aio.7 | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/man7/aio.7 b/man7/aio.7
> index ff099885e..9b2c44c48 100644
> --- a/man7/aio.7
> +++ b/man7/aio.7
> @@ -257,8 +257,6 @@ aio_return():
>
> #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
>
> -#define errMsg(msg) do { perror(msg); } while (0)
> -
> struct ioRequest { /* Application\-defined structure for tracking
> I/O requests */
> int reqNum;
> @@ -390,7 +388,7 @@ main(int argc, char *argv[])
> else if (s == AIO_ALLDONE)
> printf("I/O all done\en");
> else
> -errMsg("aio_cancel");
> +perror("aio_cancel");
> }
> }
>
> @@ -418,7 +416,7 @@ main(int argc, char *argv[])
> printf("Canceled\en");
> break;
> default:
> -errMsg("aio_error");
> +perror("aio_error");
> break;
> }
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH 16/24] getpwent_r.3: Declare variables with different types in different lines
On 9/10/20 11:13 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
Thanks, Alex. Patch applied.
Cheers,
Michael
> ---
> man3/getpwent_r.3 | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/man3/getpwent_r.3 b/man3/getpwent_r.3
> index 0f7581091..b6c1c281f 100644
> --- a/man3/getpwent_r.3
> +++ b/man3/getpwent_r.3
> @@ -184,7 +184,8 @@ in the stream with all other threads.
> int
> main(void)
> {
> -struct passwd pw, *pwp;
> +struct passwd pw;
> +struct passwd *pwp;
> char buf[BUFLEN];
> int i;
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH 17/24] get_phys_pages.3: Write 'long' instead of 'long int'
On 9/10/20 11:13 PM, Alejandro Colomar wrote: > For consistency. > > Most man pages use 'long' instead of 'long int'. > > Signed-off-by: Alejandro Colomar Thanks, Alex. Patch applied. Cheers, Michael > --- > man3/get_phys_pages.3 | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/man3/get_phys_pages.3 b/man3/get_phys_pages.3 > index 4a9177dfd..97ba625b7 100644 > --- a/man3/get_phys_pages.3 > +++ b/man3/get_phys_pages.3 > @@ -30,8 +30,8 @@ page counts > .nf > .B "#include " > .PP > -.B long int get_phys_pages(void); > -.B long int get_avphys_pages(void); > +.B long get_phys_pages(void); > +.B long get_avphys_pages(void); > .fi > .SH DESCRIPTION > The function > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH 20/24] loop.4: ffix
On 9/10/20 11:13 PM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar Thanks, Alex. Patch applied. Cheers, Michael > --- > man4/loop.4 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/man4/loop.4 b/man4/loop.4 > index 73b23871d..1b5d05666 100644 > --- a/man4/loop.4 > +++ b/man4/loop.4 > @@ -227,7 +227,7 @@ in > .IR loop_config.info.lo_flags ; > and > .IP * > -Explicitly request read-only mode by setting > +explicitly request read-only mode by setting > .BR LO_FLAGS_READ_ONLY > in > .IR loop_config.info.lo_flags . > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v2 9/9] iomap: Change calling convention for zeroing
On Fri, Sep 11, 2020 at 12:47:07AM +0100, Matthew Wilcox (Oracle) wrote: > Pass the full length to iomap_zero() and dax_iomap_zero(), and have > them return how many bytes they actually handled. This is preparatory > work for handling THP, although it looks like DAX could actually take > advantage of it if there's a larger contiguous area. Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v2 01/15] dt-bindings: gpio: convert bindings for NXP PCA953x family to dtschema
Hi Krzysztof,
On Thu, Sep 10, 2020 at 8:54 PM Krzysztof Kozlowski wrote:
> On Thu, 10 Sep 2020 at 20:28, Nishanth Menon wrote:
> > On 19:57-20200910, Krzysztof Kozlowski wrote:
> > [...]
> > > + wakeup-source:
> > > +$ref: /schemas/types.yaml#/definitions/flag
> > > +
> > > +patternProperties:
> > > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
> >
> > I wonder if "hog" is too generic and might clash with "something-hog" in
> > the future?
>
> This pattern is already used in
> Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml. It will
> match only children and so far it did not find any other nodes in ARM
> and ARM64 dts. I don't expect clashes. Also the question is then - if
> one adds a child of GPIO expander named "foobar-hog" and it is not a
> GPIO hog, then what is it?
Perhaps you didn't find any other nodes as children of pca953x
controllers?
There are other hog nodes in other types of GPIO controllers. Typically
they're named after the purpose, e.g. "wifi-disable", "i2c3_mux_oe_n",
"pcie_sata_switch", "lcd0_mux".
IMHO it's a hog if it contains a "gpio-hog" property, regardless of node
naming.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
drivers/android/binder.c:3689: Error: unrecognized keyword/register name `l.lwz
Hi Stafford,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 581cb3a26baf846ee9636214afaa5333919875b1
commit: af84b16e3423bd9c1c8d81c44bc0a217f763f6b7 openrisc: uaccess: Use static
inline function in access_ok
date: 5 weeks ago
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-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
git checkout af84b16e3423bd9c1c8d81c44bc0a217f763f6b7
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=openrisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/android/binder.c: Assembler messages:
>> drivers/android/binder.c:3689: Error: unrecognized keyword/register name
>> `l.lwz ?ap,4(r17)'
drivers/android/binder.c:3694: Error: unrecognized keyword/register name
`l.addi ?ap,r0,0'
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af84b16e3423bd9c1c8d81c44bc0a217f763f6b7
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout af84b16e3423bd9c1c8d81c44bc0a217f763f6b7
vim +3689 drivers/android/binder.c
44d8047f1d87ad drivers/android/binder.c Todd Kjos
2018-08-28 3594
fb07ebc3e82a98 drivers/staging/android/binder.c Bojan Prtvar
2013-09-02 3595 static int binder_thread_write(struct binder_proc *proc,
fb07ebc3e82a98 drivers/staging/android/binder.c Bojan Prtvar
2013-09-02 3596 struct binder_thread *thread,
da49889deb34d3 drivers/staging/android/binder.c Arve Hjønnevåg
2014-02-21 3597 binder_uintptr_t binder_buffer, size_t
size,
da49889deb34d3 drivers/staging/android/binder.c Arve Hjønnevåg
2014-02-21 3598 binder_size_t *consumed)
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3599 {
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3600 uint32_t cmd;
342e5c90b60134 drivers/android/binder.c Martijn Coenen
2017-02-03 3601 struct binder_context *context = proc->context;
da49889deb34d3 drivers/staging/android/binder.c Arve Hjønnevåg
2014-02-21 3602 void __user *buffer = (void __user
*)(uintptr_t)binder_buffer;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3603 void __user *ptr = buffer + *consumed;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3604 void __user *end = buffer + size;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3605
26549d17741035 drivers/android/binder.c Todd Kjos
2017-06-29 3606 while (ptr < end && thread->return_error.cmd == BR_OK)
{
372e3147df7016 drivers/android/binder.c Todd Kjos
2017-06-29 3607 int ret;
372e3147df7016 drivers/android/binder.c Todd Kjos
2017-06-29 3608
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3609 if (get_user(cmd, (uint32_t __user *)ptr))
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3610 return -EFAULT;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3611 ptr += sizeof(uint32_t);
975a1ac9a9fe65 drivers/staging/android/binder.c Arve Hjønnevåg
2012-10-16 3612 trace_binder_command(cmd);
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3613 if (_IOC_NR(cmd) <
ARRAY_SIZE(binder_stats.bc)) {
0953c7976c36ce drivers/android/binder.c Badhri Jagan Sridharan
2017-06-29 3614
atomic_inc(&binder_stats.bc[_IOC_NR(cmd)]);
0953c7976c36ce drivers/android/binder.c Badhri Jagan Sridharan
2017-06-29 3615
atomic_inc(&proc->stats.bc[_IOC_NR(cmd)]);
0953c7976c36ce drivers/android/binder.c Badhri Jagan Sridharan
2017-06-29 3616
atomic_inc(&thread->stats.bc[_IOC_NR(cmd)]);
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3617 }
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3618 switch (cmd) {
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3619 case BC_INCREFS:
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-
MAINTAINERS: Marking internal distribution lists
Hi Joe,
in my continued effort to clean up MAINTAINERS, I came across various
email "lists" that are actually just some kind of internal distribution
lists, but we cannot subscribe to them (no archives available) and they
are not affiliated to a specific person.
Some examples are:
- bcm-kernel-feedback-list.broadcom.com
- brcm80211-dev-list.cypress.com
- brcm80211-dev-list.pdl.broadcom.com
- coreteam.netfilter.org
- esc.storagedev.microsemi.com
- linux-imx.nxp.com
- megaraidlinux.pdl.broadcom.com
- MPT-FusionLinux.pdl.broadcom.com
- ocfs2-devel.oss.oracle.com
- oss-drivers.netronome.com
- patches.opensource.cirrus.com
- qat-linux.intel.com
- rds-devel.oss.oracle.com
- sparmaintainer.unisys.com
- wil6210.qti.qualcomm.com
- x86.kernel.org
One of the dots needs to be replaced by an @, of course, but let us not
make it too easy for spammers to pick something up ;)
Some of them are mentioned in MAINTAINERS with 'L:' entry as those above,
some others are mentioned in MAINTAINERS with an 'R:' or even a 'M:' entry.
Greg KH also called them email group aliases and does not want them to be
valid entries for maintainer roles ('M:') because it is unclear who really
is the maintainer for such sections (when is it orphaned, when does the
maintainer actually change, etc.).
Would you have any recommendation for marking/handling such email
addresses in MAINTAINERS?
I thought about the following options:
If the email address cannot be affiliated to one specific person and the
list is not subscribable,
A. should we then mark them as 'L: email (internal)'? (or
some other keyword, such as non-subscribable, restricted group...)
B. should we just make them 'R:' entries?
With a bit of searching and guessing, I can probably update all those
entries in MAINTAINERS and pass them to the according mailing lists for
review and inclusion.
Best regards,
Lukas
Re: [PATCH v6 09/18] crypto: sun8i-ce: split into prepare/run/unprepare
On Fri, Sep 04, 2020 at 11:09:54AM +, Corentin Labbe wrote:
>
> +static int sun8i_ce_cipher_unprepare(struct crypto_engine *engine, void
> *async_req)
> +{
> + struct skcipher_request *areq = container_of(async_req, struct
> skcipher_request, base);
> + struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(areq);
> + struct sun8i_cipher_tfm_ctx *op = crypto_skcipher_ctx(tfm);
> + struct sun8i_ce_dev *ce = op->ce;
> + struct sun8i_cipher_req_ctx *rctx = skcipher_request_ctx(areq);
> + struct sun8i_ce_flow *chan;
> + struct ce_task *cet;
> + unsigned int ivsize, offset;
> + int nr_sgs = rctx->nr_sgs;
> + int nr_sgd = rctx->nr_sgd;
> + int flow;
> +
> + flow = rctx->flow;
> + chan = &ce->chanlist[flow];
> + cet = chan->tl;
> + ivsize = crypto_skcipher_ivsize(tfm);
> +
> + if (areq->src == areq->dst) {
> + dma_unmap_sg(ce->dev, areq->src, nr_sgs, DMA_BIDIRECTIONAL);
> + } else {
> + if (nr_sgs > 0)
> + dma_unmap_sg(ce->dev, areq->src, nr_sgs, DMA_TO_DEVICE);
> + dma_unmap_sg(ce->dev, areq->dst, nr_sgd, DMA_FROM_DEVICE);
> + }
> +
> + if (areq->iv && ivsize > 0) {
> + if (cet->t_iv)
> + dma_unmap_single(ce->dev, cet->t_iv, rctx->ivlen,
> + DMA_TO_DEVICE);
This creates a sparse warning:
CHECK ../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c:311:25: warning:
incorrect type in argument 2 (different base types)
../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c:311:25:expected
unsigned long long [usertype] addr
../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c:311:25:got
restricted __le32 [usertype] t_iv
../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c:322:9: warning:
incorrect type in argument 2 (different base types)
../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c:322:9:expected
unsigned long long [usertype] addr
../drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c:322:9:got restricted
__le32 [usertype] t_key
Please fix. Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 3/3] Documentation: fpga: dfl: Add description for VFIO Mdev support
On Thu, Sep 10, 2020 at 09:49:03AM -0600, Alex Williamson wrote: > On Thu, 10 Sep 2020 16:32:30 +0800 > Xu Yilun wrote: > > > Hi Alex: > > > > Thanks for your quick response and is helpful to me. I did some more > > investigation and some comments inline. > > > > On Tue, Sep 08, 2020 at 03:10:02PM -0600, Alex Williamson wrote: > > > On Tue, 8 Sep 2020 15:13:32 +0800 > > > Xu Yilun wrote: > > > > > > > This patch adds description for VFIO Mdev support for dfl devices on > > > > dfl bus. > > > > > > > > Signed-off-by: Xu Yilun > > > > Signed-off-by: Matthew Gerlach > > > > --- > > > > Documentation/fpga/dfl.rst | 20 > > > > 1 file changed, 20 insertions(+) > > > > > > > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > > > > index 0404fe6..f077754 100644 > > > > --- a/Documentation/fpga/dfl.rst > > > > +++ b/Documentation/fpga/dfl.rst > > > > @@ -502,6 +502,26 @@ FME Partial Reconfiguration Sub Feature driver > > > > (see drivers/fpga/dfl-fme-pr.c) > > > > could be a reference. > > > > > > > > > > > > +VFIO Mdev support for DFL devices > > > > += > > > > +As we introduced a dfl bus for private features, they could be added > > > > to dfl bus > > > > +as independent dfl devices. There is a requirement to handle these > > > > devices > > > > +either by kernel drivers or by direct access from userspace. Usually > > > > we bind > > > > +the kernel drivers to devices which provide board management > > > > functions, and > > > > +gives user direct access to devices which cooperate closely with user > > > > +controlled Accelerated Function Unit (AFU). We realize this with a > > > > VFIO Mdev > > > > +implementation. When we bind the vfio-mdev-dfl driver to a dfl device, > > > > it > > > > +realizes a group of callbacks and registers to the Mdev framework as a > > > > +parent (physical) device. It could then create one > > > > (available_instances == 1) > > > > +mdev device. > > > > +Since dfl devices are sub devices of FPGA DFL physical devices (e.g. > > > > PCIE > > > > +device), which provide no DMA isolation for each sub device, this may > > > > leads to > > > > +DMA isolation problem if a private feature is designed to be capable > > > > of DMA. > > > > +The AFU user could potentially access the whole device addressing > > > > space and > > > > +impact the private feature. So now the general HW design rule is, no > > > > DMA > > > > +capability for private features. It eliminates the DMA isolation > > > > problem. > > > > > > What's the advantage of entangling mdev/vfio in this approach versus > > > simply exposing the MMIO region of the device via sysfs (similar to a > > > resource file in pci-sysfs)? This implementation doesn't support > > > interrupts, it doesn't support multiplexing of a device, it doesn't > > > perform any degree of mediation, it seems to simply say "please don't > > > do DMA". I don't think that's acceptable for an mdev driver. If you > > > want to play loose with isolation, do it somewhere else. Thanks, > > > > The intention of the patchset is to enable the userspace drivers for dfl > > devices. The dfl devices are actually different IP blocks integrated in > > FPGA to support different board functionalities. They are sub devices of > > the FPGA PCIe device. Their mmio blocks are in PCIE bar regions. And we > > want some of the dfl devices handled by the userspace drivers. > > > > Some dfl devices are capable of interrupt. I didn't add interrupt code > > in this patch cause now the IRQ capable dfl devices are all handled by > > kernel drivers. But as a generic FPGA platform, IRQ handling for userspace > > drivers should be supported. > > > > And I can see there are several ways to enable the userspace driver. > > > > 1. Some specific sysfs like pci do. But seems it is not the common way for > > userspace driver. It does't support interrupt. And potentially users > > operate on the same mmio region together with kernel driver at the same > > time. > > > > 2. VFIO driver with NOIOMMU enabled. I think it meets our needs. Do you > > think it is good we implement an VFIO driver for dfl devices? > > > > 3. VFIO mdev. I implemented it because it will not block us from lacking > > of valid iommu group. And since the driver didn't perform any mediation, > > I should give up. > > > > 4. UIO driver. It should work. I'm wondering if option 2 covers the > > functionalities of UIO and has more enhancement. So option 2 may be > > better? > > > > Thanks again for your time, and I really appreciate you would give some > > guide on it. > > > VFIO no-iommu was intended as a transition helper for platforms that do > not support an IOMMU, particularly running within a VM where we use > regular, IOMMU protected devices within the host, but allow no-iommu > within the guest such that the host is still protected from the guest > sandbox. There should be no new use cases of no-iommu,
[PATCH net-next] drivers/net/wan/x25_asy: Remove an unused flag "SLF_OUTWAIT"
The "SLF_OUTWAIT" flag defined in x25_asy.h is not actually used.
It is only cleared at one place in x25_asy.c but is never read or set.
So we can remove it.
Signed-off-by: Xie He
---
drivers/net/wan/x25_asy.c | 2 --
drivers/net/wan/x25_asy.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 7ee980575208..5a7cf8bf9d0d 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -243,8 +243,6 @@ static void x25_asy_encaps(struct x25_asy *sl, unsigned
char *icp, int len)
actual = sl->tty->ops->write(sl->tty, sl->xbuff, count);
sl->xleft = count - actual;
sl->xhead = sl->xbuff + actual;
- /* VSV */
- clear_bit(SLF_OUTWAIT, &sl->flags); /* reset outfill flag */
}
/*
diff --git a/drivers/net/wan/x25_asy.h b/drivers/net/wan/x25_asy.h
index eb4a4216ee94..87798287c9ca 100644
--- a/drivers/net/wan/x25_asy.h
+++ b/drivers/net/wan/x25_asy.h
@@ -35,7 +35,6 @@ struct x25_asy {
#define SLF_INUSE 0 /* Channel in use */
#define SLF_ESCAPE 1 /* ESC received */
#define SLF_ERROR 2 /* Parity, etc. error */
-#define SLF_OUTWAIT4 /* Waiting for output */
};
--
2.25.1
Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"
Hi David,
On Thu, Sep 10, 2020 at 9:20 PM David Miller wrote:
> From: Geert Uytterhoeven
> Date: Tue, 1 Sep 2020 17:02:37 +0200
>
> > This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
> >
> > Inami-san reported that this commit breaks bridge support in a Xen
> > environment, and that reverting it fixes this.
> >
> > During system resume, bridge ports are no longer enabled, as that relies
> > on the receipt of the NETDEV_CHANGE notification. This notification is
> > not sent, as netdev_state_change() is no longer called.
> >
> > Note that the condition this commit intended to fix never existed
> > upstream, as the patch triggering it and referenced in the commit was
> > never applied upstream. Hence I can confirm s2ram on r8a73a4/ape6evm
> > and sh73a0/kzm9g works fine before/after this revert.
> >
> > Reported-by Gaku Inami
> > Signed-off-by: Geert Uytterhoeven
>
> Maybe you cannot reproduce it, but the problem is there and it still
> looks very real to me.
>
> netdev_state_change() does two things:
>
> 1) Emit the NETDEV_CHANGE notification
>
> 2) Emit an rtmsg_ifinfo() netlink message, which in turn tries to access
>the device statistics via ->ndo_get_stats*().
>
> It is absolutely wrong to do #2 when netif_device_present() is false.
>
> So I cannot apply this patch as-is, sorry.
Thanks a lot for looking into this!
But doing #1 is still safe? That is the part that calls into the bridge
code. So would moving the netif_device_present() check from
linkwatch_do_dev() to netdev_state_change(), to prevent doing #2, be
acceptable?
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5] perf: arm_dsu: Support DSU ACPI devices
On 09/10/2020 08:07 PM, Tuan Phan wrote:
Hi Will,
On Sep 10, 2020, at 6:40 AM, kernel test robot wrote:
Hi Tuan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.9-rc4 next-20200910]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tuan-Phan/perf-arm_dsu-Support-DSU-ACPI-devices/20200910-105630
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
ab29a807a7ddaa7c84d2f4cb8d29e74e33759072
config: arm64-randconfig-r012-20200909 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
0a5dc7effb191eff740e0e7ae7bd8e1f6bdb3ad9)
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
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/perf/arm_dsu_pmu.c:799:36: warning: unused variable
'dsu_pmu_acpi_match' [-Wunused-const-variable]
static const struct acpi_device_id dsu_pmu_acpi_match[] = {
^
1 warning generated.
Do you need me to fix this warning when CONFIG_ACPI not defined?
Yes, please. The kernel should compile fine in any config. Any compiler
warning is not good (unless the compiler is wrong).
Cheers
Suzuki
Re: [PATCH] ide/macide: Convert Mac IDE driver to platform driver
Hi Finn,
On Fri, Sep 11, 2020 at 1:05 AM Finn Thain wrote:
> On Thu, 10 Sep 2020, Geert Uytterhoeven wrote:
> > On Thu, Sep 10, 2020 at 2:23 AM Finn Thain
> > wrote:
> > > > How does the driver know not to use the special port_ops after
> > > > this change?
> > > >
> > >
> > > The driver always uses the special port_ops after this change because it
> > > no longer handles the MAC_IDE_BABOON case. That case is handled by either
> >
> > non-MAC_IDE_BABOON case?
> >
> > > drivers/ata/pata_platform.c or drivers/ide/ide_platform.c, depending on
> > > .config.
> >
> > Ideally, we do need to differentiate, right?
> >
>
> Sorry, I'm lost.
>
> The commit log explains that the macide driver is only intended to support
> two of the three variants, because the generic drivers are already able to
> support the third variant (Baboon). Stan confirmed this on his PB 190.
>
> But, IIUC, you seem to want macide to continue to support all three
> variants (?) The existing code to implement that has an old bug that
> reassigns d.port_ops when it is const. IMO, the const is correct because
> macide should concern itself with mac hardware quirks and should not try
> to mimic a generic driver by setting d.port_ops = NULL. Does that make
> sense?
Sorry, I completely missed that the Baboon case registers a "pata_platform"
device instead of a "macide" device. Hence please ignore my comments
related to that. Sorry for the noise.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 4/4] bus: mhi: clients: Add userspace client interface driver
Hi Greg,
On 9/7/20 2:37 AM, Greg KH wrote:
On Wed, Aug 05, 2020 at 11:41:03PM -0700, Hemant Kumar wrote:
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Device file node is created with format
/dev/mhi__
Currently it supports LOOPBACK channel.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/Kconfig | 6 +
drivers/bus/mhi/Makefile | 1 +
drivers/bus/mhi/clients/Kconfig | 15 +
Why a whole new subdirectory for just one file?
Please keep it in the same directory until you get too many different
files.
Currently MHI core driver files are under bus/mhi/core. Since MHI
clients sit on top of core layer of MHI driver, i can move uci.c
directly under /bus/mhi/.
drivers/bus/mhi/clients/Makefile | 3 +
drivers/bus/mhi/clients/uci.c| 662 +++
5 files changed, 687 insertions(+)
create mode 100644 drivers/bus/mhi/clients/Kconfig
create mode 100644 drivers/bus/mhi/clients/Makefile
create mode 100644 drivers/bus/mhi/clients/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index 6a217ff..927c392 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,9 @@ config MHI_BUS_DEBUG
Enable debugfs support for use with the MHI transport. Allows
reading and/or modifying some values within the MHI controller
for debug and test purposes.
+
+if MHI_BUS
+
+source "drivers/bus/mhi/clients/Kconfig"
+
+endif
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..48f6028 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,3 @@
# core layer
obj-y += core/
+obj-y += clients/
diff --git a/drivers/bus/mhi/clients/Kconfig b/drivers/bus/mhi/clients/Kconfig
new file mode 100644
index 000..37aaf51
--- /dev/null
+++ b/drivers/bus/mhi/clients/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+menu "MHI clients support"
+
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+MHI based userspace client interface driver is used for transferring
+raw data between host and device using standard file operations from
+userspace. Open, read, write, and close operations are supported
+by this driver. Please check mhi_uci_match_table for all supported
+channels that are exposed to userspace.
+
Module name information?
Thanks for pointing it out, will add in next patch set.
+endmenu
diff --git a/drivers/bus/mhi/clients/Makefile b/drivers/bus/mhi/clients/Makefile
new file mode 100644
index 000..cd34282
--- /dev/null
+++ b/drivers/bus/mhi/clients/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_MHI_UCI) += uci.o
Why not mhi_ as a prefix? This is a very generic module name, right?
how about adding
mhi_uci-y := uci.o
obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/clients/uci.c b/drivers/bus/mhi/clients/uci.c
new file mode 100644
index 000..a25d5d0
--- /dev/null
+++ b/drivers/bus/mhi/clients/uci.c
@@ -0,0 +1,662 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS (128)
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_idr_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major = -1;
Why init this to -1?
Idea was to initialize with invalid value, i can leave it zero initialized.
+
+/**
+ * struct uci_chan - MHI channel for a uci device
+ * @wq: wait queue for reader/writer
+ * @lock: spin lock
+ * @pending: list of rx buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @rx_size: size of the current rx buffer userspace is reading
+ */
+struct uci_chan {
+ wait_queue_head_t wq;
+
+ /* protects pending and cur_buf members */
+ spinlock_t lock;
+
+ struct list_head pending;
+ struct uci_buf *cur_buf;
+ size_t rx_size;
+};
+
+/**
+ * struct uci_buf - uci buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the uci buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI uci device
+ * @minor: uci device node minor number
+ * @mhi_dev: associated mhi device object
+ * @chan: MHI channel name
+ * @lock: mutex lock
+ * @ul_chan: uplink uci channel object
+ * @dl_chan: downlink uci channel object
+ * @mtu: max tx buffer length
+ * @actual_mtu: maximum size of incoming buffer
+ * @ref_count: uci_dev reference count
+ * @open_count: device node open count
+ * @enabled: uci device probed
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+
Re: [PATCH 1/3] ARM/dma-mapping: move various helpers from dma-mapping.h to dma-direct.h
On Thu, Sep 10, 2020 at 07:02:23PM +0100, Robin Murphy wrote:
> On 2020-09-10 06:40, Christoph Hellwig wrote:
>> Move the helpers to translate to and from direct mapping DMA addresses
>> to dma-direct.h. This not only is the most logical place, but the new
>> placement also avoids dependency loops with pending commits.
>
> For the straightforward move as it should be,
>
> Reviewed-by: Robin Murphy
>
> However I do wonder how much of this could be cleaned up further...
>> +
>> +#ifdef __arch_page_to_dma
>> +#error Please update to __arch_pfn_to_dma
>> +#endif
>
> This must be long, long dead by now.
Yeah. I had a patch to remove this which lead me into the rabbit
hole your described later. A few patches in I decided to give up
and just do the trivial move. But it probably makes sense to pick
up at least the two trivial dead code removal patches..
>> +static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>> +{
>> +unsigned long pfn = __bus_to_pfn(addr);
>> +
>> +if (dev)
>> +pfn += dev->dma_pfn_offset;
>> +
>> +return pfn;
>> +}
>
> These are only overridden for OMAP1510, and it looks like it wouldn't take
> much for the platform code or ohci-omap driver to set up a generic DMA
> offset for the relevant device.
I sent a ping to the omap maintainers earlier this week to ask for that :)
>> +static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>> +{
>> +if (dev)
>> +return pfn_to_dma(dev, virt_to_pfn(addr));
>> +
>> +return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>> +}
>
> And this is only used for some debug prints in dmabounce.
>
> Similarly the __bus_to_*()/__*_to_bus() calls themselves only appear
> significant to mach-footbridge any more, and could probably also be evolved
> into regular DMA offsets now that all API calls must have a non-NULL
> device. I think I might come back and take a closer look at all this at
> some point in future... :)
Yes, pretty much all of this should eventually go away. I just don't
want to bock the ranges work on all kinds of random arm cleanups..
Re: [PATCH v2 01/15] dt-bindings: gpio: convert bindings for NXP PCA953x family to dtschema
On Thu, 10 Sep 2020 at 17:57, Krzysztof Kozlowski wrote:
>
> Convert the NXP PCA953x family of GPIO expanders bindings to device tree
> schema.
>
> Signed-off-by: Krzysztof Kozlowski
> +patternProperties:
> + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
> +type: object
> +properties:
> + gpio-hog: true
> + gpios: true
> + input: true
> + output-high: true
> + output-low: true
> + line-name: true
> +
> +required:
> + - gpio-hog
> + - gpios
> +
> +usb3-sata-sel-hog {
> +gpio-hog;
> +gpios = <4 GPIO_ACTIVE_HIGH>;
> +output-low;
> +line-name = "usb3_sata_sel";
I would prefer we didn't require the addition of hte -hog prefix. It's
mostly just a matter of taste, but I can think of a few more concrete
reasons:
We don't require -high or -low prefixes, so the node name doesn't need
to describe the properties that will be found below.
Changing around node names for existing boards carries with it the
chance of userspace breakage (as sysfs paths change). I would prefer
we avoid that if possible.
Cheers,
Joel
RE: [PATCH] ARM: imx7ulp: enable cpufreq
> From: Peng Fan > Sent: Friday, September 11, 2020 11:32 AM > > > Enable cpufreq for i.MX7ULP when imx cpufreq dt driver enabled. > > Signed-off-by: Peng Fan Reviewed-by: Dong Aisheng Regards Aisheng
Re: [PATCH 00/15] Adding GAUDI NIC code to habanalabs driver
On Thu, Sep 10, 2020 at 10:38:48PM +0200, Andrew Lunn wrote: > On Thu, Sep 10, 2020 at 11:30:33PM +0300, Oded Gabbay wrote: > > On Thu, Sep 10, 2020 at 11:25 PM Andrew Lunn wrote: > > > > > > > Can you please elaborate on how to do this with a single driver that > > > > is already in misc ? > > > > As I mentioned in the cover letter, we are not developing a > > > > stand-alone NIC. We have a deep-learning accelerator with a NIC > > > > interface. > > > > > > This sounds like an MFD. > > > > > > Andrew > > > > Yes and no. There is only one functionality - training of deep > > learning (Accelerating compute operations) :) > > The rdma is just our method of scaling-out - our method of > > intra-connection between GAUDI devices (similar to NVlink or AMD > > crossfire). > > So the H/W exposes a single physical function at the PCI level. And > > thus Linux can call a single driver for it during the PCI probe. > > Yes, it probes the MFD driver. The MFD driver then creates platform > drivers for the sub functions. i.e. it would create an Ethernet > platform driver. That then gets probed in the usual way. The child > device can get access to the parent device, if it needs to share > things, e.g. a device on a bus. This is typically I2C or SPI, but > there is no reason it cannot be a PCI device. > > Go look in drivers/mfd. Why do we keep going down this path each time this comes up... No, mfd doesn't work for this case, but the "virtual bus" that gets posted ever once in a while would solve this issue. Hopefully one day the Intel developers will wake up and post it again here so that we can review it and hopefully merge it to solve this very common problem... thanks, greg k-h
Re: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device driver
On Thu, Sep 10, 2020 at 12:28:38PM +0200, Harald Freudenberger wrote:
> +static inline unsigned long z_copy_from_user(bool userspace,
> + void *to, const void __user *from,
> unsigned long n)
Can you avoid the pointless long lines in the function declaration?
> +{
> + if (likely(userspace))
> + return copy_from_user(to, from, n);
> + memcpy(to, (void __force *) from, n);
> + return 0;
> +}
> +
> +static inline unsigned long z_copy_to_user(bool userspace,
> +void __user *to, const void *from,
> unsigned long n)
> +{
> + if (likely(userspace))
> + return copy_to_user(to, from, n);
> + memcpy((void __force *) to, from, n);
> + return 0;
Otherwise this doesn't look great, but also not horrible and gets rid
of the set_fs while reducing the lines of code, so:
Reviewed-by: Christoph Hellwig
[PATCH v6 1/2] phy: Add new PHY attribute max_link_rate
Add new PHY attribute max_link_rate to struct phy_attrs. This indicates
maximum link rate supported by PHY (in Mbps).
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Acked-by: Kishon Vijay Abraham I
---
include/linux/phy/phy.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index bcee8eba62b3..e435bdb0bab3 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -115,10 +115,12 @@ struct phy_ops {
/**
* struct phy_attrs - represents phy attributes
* @bus_width: Data path width implemented by PHY
+ * @max_link_rate: Maximum link rate supported by PHY (in Mbps)
* @mode: PHY mode
*/
struct phy_attrs {
u32 bus_width;
+ u32 max_link_rate;
enum phy_mode mode;
};
--
2.26.1
arch/powerpc/lib/sstep.c:1172:21: error: variable 'suffix' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 581cb3a26baf846ee9636214afaa5333919875b1
commit: 650b55b707fdfa764e9f2b81314d3eb4216fb962 powerpc: Add prefixed
instructions to instruction data type
date: 4 months ago
config: powerpc-mpc8272_ads_defconfig (attached as .config)
compiler: powerpc-linux-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
git checkout 650b55b707fdfa764e9f2b81314d3eb4216fb962
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/powerpc/lib/sstep.c: In function 'analyse_instr':
>> arch/powerpc/lib/sstep.c:1172:21: error: variable 'suffix' set but not used
>> [-Werror=unused-but-set-variable]
1172 | unsigned int word, suffix;
| ^~
arch/powerpc/lib/sstep.c:1168:31: error: variable 'rc' set but not used
[-Werror=unused-but-set-variable]
1168 | unsigned int opcode, ra, rb, rc, rd, spr, u;
| ^~
cc1: all warnings being treated as errors
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=650b55b707fdfa764e9f2b81314d3eb4216fb962
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 650b55b707fdfa764e9f2b81314d3eb4216fb962
vim +/suffix +1172 arch/powerpc/lib/sstep.c
1153
1154 /*
1155 * Decode an instruction, and return information about it in *op
1156 * without changing *regs.
1157 * Integer arithmetic and logical instructions, branches, and barrier
1158 * instructions can be emulated just using the information in *op.
1159 *
1160 * Return value is 1 if the instruction can be emulated just by
1161 * updating *regs with the information in *op, -1 if we need the
1162 * GPRs but *regs doesn't contain the full register set, or 0
1163 * otherwise.
1164 */
1165 int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
1166struct ppc_inst instr)
1167 {
1168 unsigned int opcode, ra, rb, rc, rd, spr, u;
1169 unsigned long int imm;
1170 unsigned long int val, val2;
1171 unsigned int mb, me, sh;
> 1172 unsigned int word, suffix;
1173 long ival;
1174
1175 word = ppc_inst_val(instr);
1176 suffix = ppc_inst_suffix(instr);
1177
1178 op->type = COMPUTE;
1179
1180 opcode = ppc_inst_primary_opcode(instr);
1181 switch (opcode) {
1182 case 16:/* bc */
1183 op->type = BRANCH;
1184 imm = (signed short)(word & 0xfffc);
1185 if ((word & 2) == 0)
1186 imm += regs->nip;
1187 op->val = truncate_if_32bit(regs->msr, imm);
1188 if (word & 1)
1189 op->type |= SETLK;
1190 if (branch_taken(word, regs, op))
1191 op->type |= BRTAKEN;
1192 return 1;
1193 #ifdef CONFIG_PPC64
1194 case 17:/* sc */
1195 if ((word & 0xfe2) == 2)
1196 op->type = SYSCALL;
1197 else
1198 op->type = UNKNOWN;
1199 return 0;
1200 #endif
1201 case 18:/* b */
1202 op->type = BRANCH | BRTAKEN;
1203 imm = word & 0x03fc;
1204 if (imm & 0x0200)
1205 imm -= 0x0400;
1206 if ((word & 2) == 0)
1207 imm += regs->nip;
1208 op->val = truncate_if_32bit(regs->msr, imm);
1209 if (word & 1)
1210 op->type |= SETLK;
1211 return 1;
1212 case 19:
1213 switch ((word >> 1) & 0x3ff) {
1214 case 0: /* mcrf */
1215 op->type = COMPUTE + SETCC;
1216 rd = 7 - ((word >> 23) & 0x7);
1217 ra = 7 - ((word >> 18) & 0x7);
1218 rd *= 4;
1219 ra *= 4;
1220 val = (regs->ccr >> ra) & 0xf;
1221 op->ccval = (regs->ccr & ~(0xfUL << rd)) | (val
<< rd);
1222 return 1;
1223
1224 case 16:/* bclr */
1225 case 528: /* bcctr */
1226
[PATCH v6 0/2] PHY: Add new PHY attribute max_link_rate
This patch series adds a new PHY attribute max_link_rate. It also updates Cadence Torrent PHY driver to set attributes bus_width, max_link_rate and mode for DisplayPort. It includes following patches: 1. 0001-phy-Add-new-PHY-attribute-max_link_rate.patch This patch adds max_link_rate as a new PHY attribute. 2. 0002-phy-cadence-torrent-Set-Torrent-PHY-attributes.patch This patch sets PHY attributes in Cadence Torrent PHY driver. This will enable drivers using this PHY to read these properties. These attributes will be used in the Cadence MHDP DRM bridge driver [1] which is in the process of upstreaming. [1] https://lkml.org/lkml/2020/8/31/171 Version History: v6: - Remove implementation of new APIs phy_get_attrs/phy_set_attrs - Set attributes manually in Torrent PHY driver v5: - Add kernel-doc comments for phy_get_attrs/phy_set_attrs APIs - Pass second parameter of phy_set_attrs() as const struct * - Add Acked-by: Kishon Vijay Abraham I v4: - Protect phy_get_attrs/phy_set_attrs APIs with mutex v3: - Add comment describing new PHY attribute max_link_rate - Use of memcpy to copy structure members - Change commit log a bit v2: - Implemented single pair of functions to get/set all PHY attributes Swapnil Jakhade (2): phy: Add new PHY attribute max_link_rate phy: cadence-torrent: Set Torrent PHY attributes drivers/phy/cadence/phy-cadence-torrent.c | 4 include/linux/phy/phy.h | 2 ++ 2 files changed, 6 insertions(+) -- 2.26.1
[PATCH v6 2/2] phy: cadence-torrent: Set Torrent PHY attributes
Set Torrent PHY attributes bus_width, max_link_rate and mode
for DisplayPort.
Signed-off-by: Swapnil Jakhade
Acked-by: Kishon Vijay Abraham I
---
drivers/phy/cadence/phy-cadence-torrent.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c
b/drivers/phy/cadence/phy-cadence-torrent.c
index 7116127358ee..116aca36f7dd 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -1852,6 +1852,10 @@ static int cdns_torrent_phy_probe(struct platform_device
*pdev)
cdns_phy->phys[node].num_lanes,
cdns_phy->max_bit_rate / 1000,
cdns_phy->max_bit_rate % 1000);
+
+ gphy->attrs.bus_width = cdns_phy->phys[node].num_lanes;
+ gphy->attrs.max_link_rate = cdns_phy->max_bit_rate;
+ gphy->attrs.mode = PHY_MODE_DP;
} else {
dev_err(dev, "Driver supports only PHY_TYPE_DP\n");
ret = -ENOTSUPP;
--
2.26.1
[PATCH v2 net-next] net: phy: mchp: Add support for LAN8814 QUAD PHY
LAN8814 is a low-power, quad-port triple-speed (10BASE-T/100BASETX/1000BASE-T)
Ethernet physical layer transceiver (PHY). It supports transmission and
reception of data on standard CAT-5, as well as CAT-5e and CAT-6, unshielded
twisted pair (UTP) cables.
LAN8814 supports industry-standard QSGMII (Quad Serial Gigabit Media
Independent Interface) and Q-USGMII (Quad Universal Serial Gigabit Media
Independent Interface) providing chip-to-chip connection to four Gigabit
Ethernet MACs using a single serialized link (differential pair) in each
direction.
The LAN8814 SKU supports high-accuracy timestamping functions to
support IEEE-1588 solutions using Microchip Ethernet switches, as well as
customer solutions based on SoCs and FPGAs.
The LAN8804 SKU has same features as that of LAN8814 SKU except that it does
not support 1588, SyncE, or Q-USGMII with PCH/MCH.
This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T,
QSGMII link with the MAC.
Signed-off-by: Divya Koppera
---
v1 -> v2:
* Removing get_features and config_init as the Errata mentioned and other
functionality related things are not applicable for this phy.
Addressed review comments.
---
drivers/net/phy/micrel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 9f60865587ea..a7f74b3b97af 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1320,8 +1320,6 @@ static struct phy_driver ksphy_driver[] = {
.name = "Microchip INDY Gigabit Quad PHY",
.driver_data= &ksz9021_type,
.probe = kszphy_probe,
- .get_features = ksz9031_get_features,
- .config_init= ksz9031_config_init,
.soft_reset = genphy_soft_reset,
.read_status= ksz9031_read_status,
.get_sset_count = kszphy_get_sset_count,
--
2.17.1
Re: [PATCH v2 12/15] ARM: dts: aspeed: align GPIO hog names with dtschema
On Fri, 11 Sep 2020 at 02:58, Joel Stanley wrote: > > On Thu, 10 Sep 2020 at 17:59, Krzysztof Kozlowski wrote: > > > > dtschema for pca95xx expects GPIO hogs to end with 'hog' prefix. > > This is a bit ugly. Do we have to go down this path? No, but please comment on schema (1/15 in this series). Best regards, Krzysztof
Re: [v4,3/4] reset-controller: ti: introduce a new reset handler
On Fri, 2020-09-11 at 10:52 +0800, Suman Anna wrote:
> On 9/10/20 9:42 PM, Crystal Guo wrote:
> > On Wed, 2020-09-09 at 23:39 +0800, Suman Anna wrote:
> >> On 9/8/20 9:57 PM, Crystal Guo wrote:
> >>> On Thu, 2020-09-03 at 07:40 +0800, Suman Anna wrote:
> Hi Crystal,
>
> On 8/16/20 10:03 PM, Crystal Guo wrote:
> > Introduce ti_syscon_reset() to integrate assert and deassert together.
> > If some modules need do serialized assert and deassert operations
> > to reset itself, reset_control_reset can be called for convenience.
>
> There are multiple changes in this same patch. I think you should split
> this
> functionality away from the change for the regmap_update_bits() to
> regmap_write_bits(), similar to what you have done in your v2 Patch 4.
>
> >>>
> >>> Thanks for your suggestion.
> >>> I will split this patch in the next version.
> >>>
> >
> > Such as reset-qcom-aoss.c, it integrates assert and deassert together
> > by 'reset' method. MTK Socs also need this method to perform reset.
> >
> > Signed-off-by: Crystal Guo
> > ---
> > drivers/reset/reset-ti-syscon.c | 26 --
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/reset/reset-ti-syscon.c
> > b/drivers/reset/reset-ti-syscon.c
> > index a2635c21db7f..08289342f9af 100644
> > --- a/drivers/reset/reset-ti-syscon.c
> > +++ b/drivers/reset/reset-ti-syscon.c
> > @@ -15,6 +15,7 @@
> > * GNU General Public License for more details.
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -56,6 +57,7 @@ struct ti_syscon_reset_data {
> > struct regmap *regmap;
> > struct ti_syscon_reset_control *controls;
> > unsigned int nr_controls;
> > + unsigned int reset_duration_us;
> > };
> >
> > #define to_ti_syscon_reset_data(rcdev) \
> > @@ -89,7 +91,7 @@ static int ti_syscon_reset_assert(struct
> > reset_controller_dev *rcdev,
> > mask = BIT(control->assert_bit);
> > value = (control->flags & ASSERT_SET) ? mask : 0x0;
> >
> > - return regmap_update_bits(data->regmap, control->assert_offset,
> > mask, value);
> > + return regmap_write_bits(data->regmap, control->assert_offset,
> > mask, value);
> > }
> >
> > /**
> > @@ -120,7 +122,7 @@ static int ti_syscon_reset_deassert(struct
> > reset_controller_dev *rcdev,
> > mask = BIT(control->deassert_bit);
> > value = (control->flags & DEASSERT_SET) ? mask : 0x0;
> >
> > - return regmap_update_bits(data->regmap,
> > control->deassert_offset, mask, value);
> > + return regmap_write_bits(data->regmap,
> > control->deassert_offset, mask, value);
> > }
> >
> > /**
> > @@ -158,9 +160,26 @@ static int ti_syscon_reset_status(struct
> > reset_controller_dev *rcdev,
> > !(control->flags & STATUS_SET);
> > }
> >
> > +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> > + unsigned long id)
> > +{
> > + struct ti_syscon_reset_data *data =
> > to_ti_syscon_reset_data(rcdev);
> > + int ret;
> > +
> > + ret = ti_syscon_reset_assert(rcdev, id);
> > + if (ret)
> > + return ret;
> > +
> > + if (data->reset_duration_us)
> > + usleep_range(data->reset_duration_us,
> > data->reset_duration_us * 2);
> > +
> > + return ti_syscon_reset_deassert(rcdev, id);
>
> I echo Philipp's comments [1] from your original v1 series about this.
> We don't
> need a property to distinguish this, but you could add a flag using
> match data
> and Mediatek compatible, and use that within this function, or
> optionally set
> this ops based on compatible (whatever is preferred by Philipp).
>
> regards
> Suman
>
> [1] https://patchwork.kernel.org/comment/23519193/
>
> >>> Hi Suman, Philipp
> >>>
> >>> Which method would you recommend more?
> >>> 1. like v2 patch, but assign the flag "data->assert_deassert_together"
> >>> directly (maybe rename "assert_deassert_together" to
> >>> "reset_op_available")
> >>>
> >>> 2. use Mediatek compatible to decide the reset handler available or not.
> >>
> >> I would go with this option. Anyway, I think you might have to add the
> >> reset SoC
> >> data as well, based on Rob's comment on the binding.
> >>
> >> regards
> >> Suman
> >
> >
> > Thanks for your suggestions
> > I will add the following changes in the next version,
> > please correct me if there is any misunderstanding.
> > 1). revert ti-syscon-reset.txt add a new mediatek reset binding doc.
> > 2). split the patch [v4,3/4] with t
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On Fri, Sep 11, 2020 at 04:54:08AM +0900, Hector Martin wrote: > On 11/09/2020 03.51, James Hilliard wrote: > > I haven't tested this yet but my assumption was that either a kernel driver > > or libusb can issue usb control messages, but both can not be bound to > > a device at the same time. I figured this wouldn't have come up when you > > tested your python script since the script likely predated adding the brick > > PID > > to the ftdi_sio Linux kernel driver. > > Binding to interfaces is exclusive, but global device control messages are > not issued to an interface. I think it should work even if the kernel driver > is bound (this is how lsusb works too, since it issues control requests even > to devices bound to drivers). Even if it is necessary to unbind it, though, > libusb already provides a single function to do that > (libusb_detach_kernel_driver). You really should unbind the device from the driver when doing stuff like this, so the kernel doesn't get confused. thanks, greg k-h
Re: [PATCH v3 0/8] nfc: s3fwrn5: Few cleanups
On Fri, 11 Sep 2020 at 00:22, David Miller wrote: > > From: Krzysztof Kozlowski > Date: Thu, 10 Sep 2020 18:12:11 +0200 > > > Changes since v2: > > 1. Fix dtschema ID after rename (patch 1/8). > > 2. Apply patch 9/9 (defconfig change). > > > > Changes since v1: > > 1. Rename dtschema file and add additionalProperties:false, as Rob > >suggested, > > 2. Add Marek's tested-by, > > 3. New patches: #4, #5, #6, #7 and #9. > > Seires applied to net-next, thanks. Thanks. The DTS should go separate - via samsung-soc/arm-soc tree. However if it is too late, then no problem. Best regards, Krzysztof
[PATCH net-next] net/socket.c: Remove an unused header file
This header file is not actually used in this file. Let's remove it. Information about this header file: This header file comes from the "Frame Relay" module at drivers/net/wan/dlci.c The "Frame Relay" module is used by only one hardware driver, at: drivers/net/wan/sdla.c Note that the "Frame Relay" module is different from and unrelated to the "HDLC Frame Relay" module at: drivers/net/wan/hdlc_fr.c I think maybe we can deprecate the "Frame Relay" module because we already have the (newer) "HDLC Frame Relay" module. Signed-off-by: Xie He --- net/socket.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/socket.c b/net/socket.c index 82262e1922f9..161dd2775e13 100644 --- a/net/socket.c +++ b/net/socket.c @@ -64,7 +64,6 @@ #include #include #include -#include #include #include #include -- 2.25.1
Re: [PATCH v2 3/3] ARM: dts: add Plymovent M2M board
On 20-09-11 07:09, Oleksij Rempel wrote: > Plymovent M2M is a control interface produced for the Plymovent filter > systems. > > Signed-off-by: David Jander > Signed-off-by: Oleksij Rempel > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/imx6dl-plym2m.dts | 394 > 2 files changed, 395 insertions(+) > create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 4572db3fa5ae..3c3811fd8613 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -455,6 +455,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ > imx6dl-pico-hobbit.dtb \ > imx6dl-pico-nymph.dtb \ > imx6dl-pico-pi.dtb \ > + imx6dl-plym2m.dtb \ > imx6dl-prtrvt.dtb \ > imx6dl-prtvt7.dtb \ > imx6dl-rex-basic.dtb \ > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts > b/arch/arm/boot/dts/imx6dl-plym2m.dts > new file mode 100644 > index ..4f96e05aa03f > --- /dev/null > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts > @@ -0,0 +1,394 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > +// SPDX-FileCopyrightText: 2014 Protonic Holland > +// SPDX-FileCopyrightText: 2020 Oleksij Rempel , > Pengutronix ^ @shawn: I saw a few patches adding these tags. Are they used in the near future? Regards, Marco
Re: [PATCH 00/11] mmc: Minor cleanups and compile test
On Fri, 11 Sep 2020 at 00:55, Rob Herring wrote: > > On Thu, Sep 3, 2020 at 2:40 AM Ulf Hansson wrote: > > > > On Wed, 2 Sep 2020 at 21:37, Krzysztof Kozlowski wrote: > > > > > > Hi, > > > > > > Set of minor cleanups. Patches requiring more attention: > > > - 6/11: Testing and review would be appreciated, > > > - 11/11: I build tested multiple architectures but not all and > > >definitely no all possible configs. This one could sit on the lists > > >for few days so 0-day would try it. > > > > > > Best regards, > > > Krzysztof > > > > > > Krzysztof Kozlowski (11): > > > mmc: bcm2835: Simplify with dev_err_probe() > > > mmc: davinci: Simplify with dev_err_probe() > > > mmc: dw_mmc-zx: Simplify with dev_err_probe() > > > mmc: jz4740: Simplify with dev_err_probe() > > > mmc: meson: Simplify with dev_err_probe() > > > mmc: sdhci-brcmstb: Simplify with optional clock and dev_err_probe() > > > mmc: sdhci-of-arasan: Simplify with dev_err_probe() > > > mmc: sdhci-tegra: Simplify with dev_err_probe() > > > mmc: dw_mmc: Simplify with dev_err_probe() > > > mmc: sdhci-of-sparx5: Use proper printk format for dma_addr_t > > > mmc: host: Enable compile testing of multiple drivers > > > > > > drivers/mmc/host/Kconfig | 42 -- > > > drivers/mmc/host/bcm2835.c | 4 +-- > > > drivers/mmc/host/davinci_mmc.c | 5 ++-- > > > drivers/mmc/host/dw_mmc-zx.c | 11 +++- > > > drivers/mmc/host/dw_mmc.c | 9 +++ > > > drivers/mmc/host/jz4740_mmc.c | 5 ++-- > > > drivers/mmc/host/meson-gx-mmc.c| 16 > > > drivers/mmc/host/sdhci-brcmstb.c | 12 - > > > drivers/mmc/host/sdhci-of-arasan.c | 7 +++-- > > > drivers/mmc/host/sdhci-of-sparx5.c | 4 +-- > > > drivers/mmc/host/sdhci-tegra.c | 7 ++--- > > > 11 files changed, 51 insertions(+), 71 deletions(-) > > > > > > -- > > > 2.17.1 > > > > > > > Series applied for next, except 11, thanks! > > I see there's a bunch of these already, but I think we can do better > here than dev_err_probe. We have _optional variants for the case not > getting a resource is not an error. So the called functions like > devm_clk_get can print an error. We already have this for > platform_get_irq along with a coccinelle script to fix cases. I have a > WIP branch[1] doing this. That's quite good idea. Best regards, Krzysztof
[PATCH] kvm/eventfd:do wildcard calculation before list_for_each_entry_safe
There is no need to calculate wildcard in each loop
since wildcard is not changed.
Signed-off-by: Yi Li
---
virt/kvm/eventfd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index d6408bb497dc..c2323c27a28b 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -853,15 +853,17 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus
bus_idx,
struct eventfd_ctx *eventfd;
struct kvm_io_bus*bus;
int ret = -ENOENT;
+ bool wildcard;
eventfd = eventfd_ctx_fdget(args->fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
+ wildcard = !(args->flags & KVM_IOEVENTFD_FLAG_DATAMATCH);
+
mutex_lock(&kvm->slots_lock);
list_for_each_entry_safe(p, tmp, &kvm->ioeventfds, list) {
- bool wildcard = !(args->flags & KVM_IOEVENTFD_FLAG_DATAMATCH);
if (p->bus_idx != bus_idx ||
p->eventfd != eventfd ||
--
2.25.3
Re: [PATCH 0/8] drivers: net: convert tasklets to use new tasklet_setup()
David,
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the net/* drivers to use the new tasklet_setup() API
>
> Allen Pais (8):
> net: dccp: convert tasklets to use new tasklet_setup() API
> net: ipv4: convert tasklets to use new tasklet_setup() API
> net: mac80211: convert tasklets to use new tasklet_setup() API
> net: mac802154: convert tasklets to use new tasklet_setup() API
> net: rds: convert tasklets to use new tasklet_setup() API
> net: sched: convert tasklets to use new tasklet_setup() API
> net: smc: convert tasklets to use new tasklet_setup() API
> net: xfrm: convert tasklets to use new tasklet_setup() API
>
> net/dccp/timer.c | 10 +-
> net/ipv4/tcp_output.c | 8 +++-
> net/mac80211/ieee80211_i.h | 4 ++--
> net/mac80211/main.c| 14 +-
> net/mac80211/tx.c | 5 +++--
> net/mac80211/util.c| 5 +++--
> net/mac802154/main.c | 8 +++-
> net/rds/ib_cm.c| 14 ++
> net/sched/sch_atm.c| 9 +
> net/smc/smc_cdc.c | 6 +++---
> net/smc/smc_wr.c | 14 ++
> net/xfrm/xfrm_input.c | 7 +++
> 12 files changed, 47 insertions(+), 57 deletions(-)
>
> --
> 2.17.1
>
Will you pick these up or should I send these out again when I
have fixed the two patches on the other thread.
Thanks,
--
- Allen
Re: [PATCH 00/30] docs: fix documentation build parsing errors
Em Thu, 10 Sep 2020 10:42:50 -0600 Jonathan Corbet escreveu: > On Wed, 9 Sep 2020 16:10:31 +0200 > Mauro Carvalho Chehab wrote: > > > Currently, there are several warnings/errors produced when building > > the documentation with "make htmldocs". > > > > This series fixes almost all such errors. It is produced against > > linux-next, branch next-20200909. > > > > Some of the patches here were already sent individually, but nobody > > picked them. So, I'm re-sending the full series. > > I'd sure love to just apply the whole series and clean up a lot of this > stuff, but (1) I'm not entirely comfortable taking a few through > docs-next, and (2) some of them don't apply even if I catch up to -rc4. > So I'm going to pass through them individually and snag as many as I can... Yeah. As I commented on the other series, as warnings reach upstream from different trees, the only sane way to fix them is by using linux-next. I'll keep rebase those. This way, if something ends being lost, we could submit upstream by the end of the merge window. Btw, as Andrii gently submitted a fix for the two remaining litmus doc warnings, once everything gets merged, htmldocs should now produce zero doc warnings. I'll keep track on this. Hopefully, we can make 5.10 free of doc warnings, and build robots can start warning about newly introduced ones. Thanks, Mauro
Re: [PATCH] soundwire: bus: add enumerated slave to device list
On 10-09-20, 09:02, Pierre-Louis Bossart wrote: > > > > > May be we could make the enumerated devices discovery bit more verbose! > > > > > > Maybe adding a device number sysfs entry would help, e.g. reporting > > > NotAttched or a value in [0,11] would tell you if the device is actually > > > present. > > > > Agreed, I cooked this patch to report verbose device status, let me know > > if you are okay with this. I think this would be useful regardless of > > current discussion. > > > > On Db845c I see: > > > > root@linaro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:1/status > > Attached > > root@linaro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:2/status > > Attached > > looks like we are all aligned on the idea, I have a similar patch to at > https://github.com/thesofproject/linux/pull/2426 > > The difference is that the sysfs status and device_number is added even > without a driver probe and when there's no firmware description. sysfs is > currently only added after the driver probe, which wouldn't work for the > case Srinivas was trying to deal with. Okay sound fine > but the way you dealt the status below is better than the switch case I > used, so will merge this into my code. Why merge? That patch can remain independent and you can add device_number patch on top and another one for moving sysfs creation without a driver probe, these three sound like three different patches to me. > Srinivas' patch needs a fix for ACPI platforms, won't probe otherwise since > we don't have an of_node. If that's alright with everyone I can submit a > patchset that gathers the 3 contributions. Yes one series should be good, but lets keep one change in a patch please -- ~Vinod
Re: [PATCH 1/2] extcon: ptn5150: Use defines for registers
On Fri, Sep 11, 2020 at 12:14:19PM +0900, Chanwoo Choi wrote:
> On 9/10/20 12:01 AM, Krzysztof Kozlowski wrote:
> > The register addresses are not continuous, so use simple defines for
> > them. This also makes it easier to find the address for register.
> >
> > No functional change.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > drivers/extcon/extcon-ptn5150.c | 22 ++
> > 1 file changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/extcon/extcon-ptn5150.c
> > b/drivers/extcon/extcon-ptn5150.c
> > index dda5b3a3a908..1b68f56d8372 100644
> > --- a/drivers/extcon/extcon-ptn5150.c
> > +++ b/drivers/extcon/extcon-ptn5150.c
> > @@ -19,18 +19,16 @@
> > #include
> >
> > /* PTN5150 registers */
> > -enum ptn5150_reg {
> > - PTN5150_REG_DEVICE_ID = 0x01,
> > - PTN5150_REG_CONTROL,
> > - PTN5150_REG_INT_STATUS,
> > - PTN5150_REG_CC_STATUS,
> > - PTN5150_REG_CON_DET = 0x09,
> > - PTN5150_REG_VCONN_STATUS,
> > - PTN5150_REG_RESET,
> > - PTN5150_REG_INT_MASK = 0x18,
> > - PTN5150_REG_INT_REG_STATUS,
> > - PTN5150_REG_END,
> > -};
> > +#define PTN5150_REG_DEVICE_ID 0x01
> > +#define PTN5150_REG_CONTROL0x02
> > +#define PTN5150_REG_INT_STATUS 0x03
> > +#define PTN5150_REG_CC_STATUS 0x04
> > +#define PTN5150_REG_CON_DET0x09
> > +#define PTN5150_REG_VCONN_STATUS 0x0a
> > +#define PTN5150_REG_RESET 0x0b
> > +#define PTN5150_REG_INT_MASK 0x18
> > +#define PTN5150_REG_INT_REG_STATUS 0x19
> > +#define PTN5150_REG_END
> > PTN5150_REG_INT_REG_STATUS
>
> PTN5150_REG_END should be (PTN5150_REG_INT_REG_STATUS + 1)
> for regmap operation of PTN5150_REG_INT_REG_STATUS.
Why? This goes to regmap's max_register which is the last register
allowed to read:
drivers/base/regmap/regmap-debugfs.c: for (i = 0; i <= map->max_register; i
+= map->reg_stride) {
drivers/base/regmap/regmap.c: if (map->max_register && reg >
map->max_register)
regmap_get_max_register() - Report the max register value
Best regards,
Krzysztof
Re: [PATCH v2 5/9] iomap: Support arbitrarily many blocks per page
On Fri, Sep 11, 2020 at 12:47:03AM +0100, Matthew Wilcox (Oracle) wrote: > Size the uptodate array dynamically to support larger pages in the > page cache. With a 64kB page, we're only saving 8 bytes per page today, > but with a 2MB maximum page size, we'd have to allocate more than 4kB > per page. Add a few debugging assertions. > > Signed-off-by: Matthew Wilcox (Oracle) > Reviewed-by: Dave Chinner Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v2 6/9] iomap: Convert read_count to read_bytes_pending
On Fri, Sep 11, 2020 at 12:47:04AM +0100, Matthew Wilcox (Oracle) wrote: > Instead of counting bio segments, count the number of bytes submitted. > This insulates us from the block layer's definition of what a 'same page' > is, which is not necessarily clear once THPs are involved. > > Signed-off-by: Matthew Wilcox (Oracle) Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v1] ARM: dts: aspeed: Add Mowgli BMC platform
On Wed, 9 Sep 2020 at 09:09, Ben Pai wrote:
>
> The Mowgli BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> Signed-off-by: Ben Pai
This looks good to me. I assume you have all the hardware correctly described.
I notice you don't have any gpio-line-names. If you're using recent
openbmc you will need those descriptions, but I will leave that to
you.
Reviewed-by: Joel Stanley
Cheers,
Joel
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts | 663
> 2 files changed, 664 insertions(+)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4572db3fa5ae..92edb2e12823 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1381,6 +1381,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-microsoft-olympus.dtb \
> aspeed-bmc-opp-lanyang.dtb \
> aspeed-bmc-opp-mihawk.dtb \
> + aspeed-bmc-opp-mowgli.dtb \
> aspeed-bmc-opp-nicole.dtb \
> aspeed-bmc-opp-palmetto.dtb \
> aspeed-bmc-opp-romulus.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
> new file mode 100644
> index ..11fd86980162
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
> @@ -0,0 +1,663 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +#include "aspeed-g5.dtsi"
> +#include
> +#include
> +
> +/ {
> + model = "Mowgli BMC";
> + compatible = "ibm,mowgli-bmc", "aspeed,ast2500";
> +
> +
> + chosen {
> + stdout-path = &uart5;
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> +
> + video_engine_memory: jpegbuffer {
> + size = <0x0200>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + air-water {
> + label = "air-water";
> + gpios = <&gpio ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + checkstop {
> + label = "checkstop";
> + gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps0-presence {
> + label = "ps0-presence";
> + gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps1-presence {
> + label = "ps1-presence";
> + gpios = <&gpio ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + id-button {
> + label = "id-button";
> + gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = <&pca9552 9 GPIO_ACTIVE_LOW>;
> + linux,code = <9>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = <&pca9552 10 GPIO_ACTIVE_LOW>;
> + linux,code = <10>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = <&pca9552 11 GPIO_ACTIVE_LOW>;
> + linux,code = <11>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = <&pca9552 12 GPIO_ACTIVE_LOW>;
> + linux,code = <12>;
> + };
> +
> + fan4-presence {
> +
Re: [PATCH 2/2] watchdog: sp5100_tco: Enable watchdog on Family 17h devices if disabled
On 10.09.20 18:55, Jan Kiszka wrote:
> On 10.09.20 18:53, Guenter Roeck wrote:
>> Hi Jan,
>>
>> On 9/10/20 9:34 AM, Jan Kiszka wrote:
>>> On 10.09.20 18:31, Guenter Roeck wrote:
On Family 17h (Ryzen) devices, the WatchdogTmrEn bit of PmDecodeEn not only
enables watchdog memory decoding at 0xfeb0, it also enables the
watchdog hardware itself. Use this information to enable the watchdog if
it is not already enabled.
Cc: Jan Kiszka
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 85e9664318c9..a730ecbf78cd 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -17,6 +17,12 @@
*AMD Publication 51192 "AMD Bolton FCH Register Reference
Guide"
*AMD Publication 52740 "BIOS and Kernel Developer’s Guide
(BKDG)
*for AMD Family 16h Models 30h-3Fh
Processors"
+ *AMD Publication 55570-B1-PUB "Processor Programming
Reference (PPR)
+ *for AMD Family 17h Model 18h, Revision
B1
+ *Processors (PUB)
+ *AMD Publication 55772-A1-PUB "Processor Programming
Reference (PPR)
+ *for AMD Family 17h Model 20h, Revision
A1
+ *Processors (PUB)
*/
/*
@@ -241,6 +247,18 @@ static int sp5100_tco_setupdevice(struct device *dev,
break;
case efch:
dev_name = SB800_DEVNAME;
+ /*
+ * On Family 17h devices, the EFCH_PM_DECODEEN_WDT_TMREN bit of
+ * EFCH_PM_DECODEEN not only enables the EFCH_PM_WDT_ADDR memory
+ * region, it also enables the watchdog itself.
+ */
+ if (boot_cpu_data.x86 == 0x17) {
+ val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
+ if (!(val & EFCH_PM_DECODEEN_WDT_TMREN)) {
+ sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN,
0xff,
+
EFCH_PM_DECODEEN_WDT_TMREN);
+ }
+ }
val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
if (val & EFCH_PM_DECODEEN_WDT_TMREN)
mmio_addr = EFCH_PM_WDT_ADDR;
>>>
>>> Won't that bring us EFCH_PM_WDT_ADDR as address, rather than
>>> EFCH_PM_ACPI_MMIO_ADDR which worked in my case? Or is one an alias of
>>> the other.
>>>
>>
>> Yes, it does use EFCH_PM_WDT_ADDR. EFCH_PM_ACPI_MMIO_ADDR works as well,
>> but is meant to be a fallback. Both point to the watchdog memory space.
>>
>
> OK, will test, possibly only on the weekend, and confirm this also on my
> board.
>
> Jan
>
Both patches now
Tested-by: Jan Kiszka
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
[tip:x86/fpu] BUILD SUCCESS 0a4bb5e5507a585532cc413125b921c8546fc39f
alldefconfig mips cobalt_defconfig mips rt305x_defconfig sh kfr2r09_defconfig arcnsim_700_defconfig armmvebu_v7_defconfig arm h3600_defconfig powerpc rainier_defconfig shapsh4ad0a_defconfig armmulti_v5_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allyesconfig arc defconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig x86_64 randconfig-a004-20200910 x86_64 randconfig-a006-20200910 x86_64 randconfig-a003-20200910 x86_64 randconfig-a002-20200910 x86_64 randconfig-a005-20200910 x86_64 randconfig-a001-20200910 i386 randconfig-a004-20200909 i386 randconfig-a005-20200909 i386 randconfig-a006-20200909 i386 randconfig-a002-20200909 i386 randconfig-a001-20200909 i386 randconfig-a003-20200909 i386 randconfig-a004-20200911 i386 randconfig-a006-20200911 i386 randconfig-a001-20200911 i386 randconfig-a003-20200911 i386 randconfig-a002-20200911 i386 randconfig-a005-20200911 i386 randconfig-a004-20200910 i386 randconfig-a006-20200910 i386 randconfig-a001-20200910 i386 randconfig-a003-20200910 i386 randconfig-a002-20200910 i386 randconfig-a005-20200910 x86_64 randconfig-a014-20200911 x86_64 randconfig-a011-20200911 x86_64 randconfig-a012-20200911 x86_64 randconfig-a016-20200911 x86_64 randconfig-a015-20200911 x86_64 randconfig-a013-20200911 i386 randconfig-a015-20200911 i386 randconfig-a014-20200911 i386 randconfig-a011-20200911 i386 randconfig-a013-20200911 i386 randconfig-a016-20200911 i386 randconfig-a012-20200911 i386 randconfig-a016-20200909 i386 randconfig-a015-20200909 i386 randconfig-a011-20200909 i386 randconfig-a013-20200909 i386 randconfig-a014-20200909 i386 randconfig-a012-20200909 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20200911 x86_64 randconfig-a006-20200911 x86_64 randconfig-a003-20200911 x86_64 randconfig-a002-20200911 x86_64 randconfig-a005-20200911 x86_64 randconfig-a001-20200911 x86_64 randconfig-a013-20200909 x86_64 randconfig-a016-20200909 x86_64 randconfig-a011-20200909 x86_64 randconfig-a012-20200909 x86_64 randconfig-a015-20200909 x86_64 randconfig-a014-20200909 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v7 07/10] dt-bindings: reset: s700: Add binding constants for mmc
This commit adds device tree binding reset constants for mmc controller present on Actions S700 Soc. Reviewed-by: Manivannan Sadhasivam Acked-by: Rob Herring Signed-off-by: Amit Singh Tomar --- Changes since v6: * No change. Changes since v5: * Added Mani's Reviewed-by: tag. Changes since v4: * No change. Changes since v3: * No change. Changes since v2: * No change. Changes since v1: * No change. Changes since RFC: * added Rob's acked-by tag --- include/dt-bindings/reset/actions,s700-reset.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h index 5e3b16b8ef53..a3118de6d7aa 100644 --- a/include/dt-bindings/reset/actions,s700-reset.h +++ b/include/dt-bindings/reset/actions,s700-reset.h @@ -30,5 +30,8 @@ #define RESET_UART420 #define RESET_UART521 #define RESET_UART622 +#define RESET_SD0 23 +#define RESET_SD1 24 +#define RESET_SD2 25 #endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */ -- 2.7.4
[PATCH v7 08/10] dt-bindings: mmc: owl: add compatible string actions,s700-mmc
The commit adds a new SoC specific compatible string "actions,s700-mmc" in combination with more generic string "actions,owl-mmc". Placement order of these strings should abide by the principle of "from most specific to most general". Reviewed-by: Manivannan Sadhasivam Reviewed-by: Rob Herring Signed-off-by: Amit Singh Tomar --- Changes since v6: * No change. Changes since v5: * Added Mani's Reviewed-by: tag. Changes since v4: * No change. Changes since v3: * No change. Changes since v2: * Added Rob's Reviewed-by tag --- Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml index 1380501fb8f0..5eab25ccf7ae 100644 --- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml @@ -14,7 +14,11 @@ maintainers: properties: compatible: -const: actions,owl-mmc +oneOf: + - const: actions,owl-mmc + - items: + - const: actions,s700-mmc + - const: actions,owl-mmc reg: maxItems: 1 -- 2.7.4
[PATCH] mailbox: sti: fix struct description warnings
Fix formating of struct description to avoid warning highlighted
by W=1 compilation.
warning: cannot understand function prototype: 'struct sti_mbox_device '
warning: cannot understand function prototype: 'struct sti_mbox_pdata '
warning: cannot understand function prototype: 'struct sti_channel '
Signed-off-by: Alain Volmat
Reviewed-by: Lee Jones
---
drivers/mailbox/mailbox-sti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 2baf69a0b81c..0f2bc09c364d 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -36,7 +36,7 @@
#define MBOX_BASE(mdev, inst) ((mdev)->base + ((inst) * 4))
/**
- * STi Mailbox device data
+ * struct sti_mbox_device - STi Mailbox device data
*
* An IP Mailbox is currently composed of 4 instances
* Each instance is currently composed of 32 channels
@@ -60,7 +60,7 @@ struct sti_mbox_device {
};
/**
- * STi Mailbox platform specific configuration
+ * struct sti_mbox_pdata - STi Mailbox platform specific configuration
*
* @num_inst: Maximum number of instances in one HW Mailbox
* @num_chan: Maximum number of channel per instance
@@ -71,7 +71,7 @@ struct sti_mbox_pdata {
};
/**
- * STi Mailbox allocated channel information
+ * struct sti_channel - STi Mailbox allocated channel information
*
* @mdev: Pointer to parent Mailbox device
* @instance: Instance number channel resides in
--
2.17.1
[GIT PULL] FSI changes for 5.10
Hi Greg, Here are some FSI changes for the 5.10 merge window. The following changes since commit 4a851d714eadeabd65c7e321a2e7830f77d945c4: fsi: aspeed: Support CFAM reset GPIO (2020-09-10 12:26:43 +0930) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joel/fsi.git tags/fsi-for-5.10 for you to fetch changes up to 4a851d714eadeabd65c7e321a2e7830f77d945c4: fsi: aspeed: Support CFAM reset GPIO (2020-09-10 12:26:43 +0930) FSI changes for 5.10 - Misc code cleanups. Thanks to Colin, Xu and Rikard - Features for the ASPEED FSI master * Detect connection type and routing for Tacoma * Run at full speed (200MHz) by default * Set bus speed with a parameter * CFAM reset GPIO * 23 bit addressing - Core features * Disable unused links * Set LBUS ownership Colin Ian King (1): fsi: master-ast-cf: fix spelling mistake "firwmare" -> "firmware" Eddie James (5): fsi: aspeed: Enable 23-bit addressing fsi: master: Add boolean parameter to link_enable function fsi: core: Disable link when slave init fails fsi: core: Set slave local bus ownership during init fsi: master: Remove link enable read-back Joel Stanley (5): dt-bindings: fsi: Document gpios fsi: aspeed: Support cabled FSI fsi: aspeed: Run the bus at maximum speed fsi: aspeed: Add module param for bus divisor fsi: aspeed: Support CFAM reset GPIO Rikard Falkeborn (3): fsi: master: Constify hub_master_ids fsi: sbefifo: Constify sbefifo_ids fsi: scom: Constify scom_ids Xu Wang (1): fsi: fsi-occ: fix return value check in occ_probe() Documentation/ABI/testing/sysfs-bus-fsi | 8 + Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt | 12 +++ drivers/fsi/fsi-core.c | 31 +++-- drivers/fsi/fsi-master-aspeed.c | 134 - drivers/fsi/fsi-master-ast-cf.c | 7 ++-- drivers/fsi/fsi-master-gpio.c | 5 +-- drivers/fsi/fsi-master-hub.c| 15 ++--- drivers/fsi/fsi-master.h| 3 +- drivers/fsi/fsi-occ.c | 2 +- drivers/fsi/fsi-sbefifo.c | 2 +- drivers/fsi/fsi-scom.c | 2 +- 11 files changed, 188 insertions(+), 33 deletions(-)
[PATCH v2 0/3] mainline Plymovent M2M board
changes v2: - fsl.yaml: reorder ply,plym2m - imx6dl-plym2m.dts: use hyphen instead of underscore in phy-clock Oleksij Rempel (3): dt-bindings: vendor-prefixes: Add an entry for Plymovent dt-bindings: arm: fsl: add Plymovent M2M board ARM: dts: add Plymovent M2M board .../devicetree/bindings/arm/fsl.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6dl-plym2m.dts | 394 ++ 4 files changed, 398 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts -- 2.28.0
[PATCH v2 3/3] ARM: dts: add Plymovent M2M board
Plymovent M2M is a control interface produced for the Plymovent filter
systems.
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plym2m.dts | 394
2 files changed, 395 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4572db3fa5ae..3c3811fd8613 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -455,6 +455,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts
b/arch/arm/boot/dts/imx6dl-plym2m.dts
new file mode 100644
index ..4f96e05aa03f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+// SPDX-FileCopyrightText: 2014 Protonic Holland
+// SPDX-FileCopyrightText: 2020 Oleksij Rempel ,
Pengutronix
+
+/dts-v1/;
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Plymovent M2M board";
+ compatible = "ply,plym2m", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 50 0>;
+ brightness-levels = <0 1000>;
+ num-interpolated-steps = <20>;
+ default-brightness-level = <19>;
+ power-supply = <®_12v0>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <&pinctrl_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0bdh6";
+ backlight = <&backlight>;
+ power-supply = <®_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+
+ clk50m_phy: phy-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12v0";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+<&clks IMX6QDL_CLK_ENET>,
+<&clk50m_phy>;
+ clock-names = "ipg", "ahb", "ptp";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+
[PATCH v2 2/3] dt-bindings: arm: fsl: add Plymovent M2M board
Add Plymovent Group BV M2M iMX6dl based board Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6da9d734cdb7..e94a455eeab9 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -174,6 +174,7 @@ properties: - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - ply,plym2m# Plymovent M2M board - prt,prtrvt# Protonic RVT board - prt,prtvt7# Protonic VT7 board - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf -- 2.28.0
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add an entry for Plymovent
Add "ply" entry for Plymovent Group BV: https://www.plymovent.com/ Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2baee2c817c1..60b59ca04066 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -818,6 +818,8 @@ patternProperties: description: PLDA "^plx,.*": description: Broadcom Corporation (formerly PLX Technology) + "^ply,.*": +description: Plymovent Group BV "^pni,.*": description: PNI Sensor Corporation "^pocketbook,.*": -- 2.28.0
Re: [PATCH kernel] srcu: Fix static initialization
On 11/09/2020 04:53, Paul E. McKenney wrote:
> On Wed, Sep 09, 2020 at 10:31:03PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/09/2020 21:50, Paul E. McKenney wrote:
>>> On Wed, Sep 09, 2020 at 07:24:11PM +1000, Alexey Kardashevskiy wrote:
On 09/09/2020 00:43, Alexey Kardashevskiy wrote:
> init_srcu_struct_nodes() is called with is_static==true only internally
> and when this happens, the srcu->sda is not initialized in
> init_srcu_struct_fields() and we crash on dereferencing @sdp.
>
> This fixes the crash by moving "if (is_static)" out of the loop which
> only does useful work for is_static=false case anyway.
>
> Found by syzkaller.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> kernel/rcu/srcutree.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index c100acf332ed..49b54a50bde8 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -135,6 +135,9 @@ static void init_srcu_struct_nodes(struct srcu_struct
> *ssp, bool is_static)
> levelspread[level - 1];
> }
>
> + if (is_static)
> + return;
Actually, this is needed here too:
if (!ssp->sda)
return;
as
ssp->sda = alloc_percpu(struct srcu_data)
can fail if the process is killed too soon - it is quite easy to get
this situation with syzkaller (syscalls fuzzer)
Makes sense?
>>>
>>> Just to make sure that I understand, these failures occur when the task
>>> running init_srcu_struct_nodes() is killed, correct?
>>
>> There are multiple user tasks (8) which open /dev/kvm, do 1 ioctl -
>> KVM_CREATE_VM - and terminate, running on 8 vcpus, 8 VMs, crashes every
>> 20min or so, less tasks or vcpus - and the problem does not appear.
>>
>>
>>>
>>> Or has someone managed to invoke (say) synchronize_srcu() on a
>>> dynamically allocated srcu_struct before invoking init_srcu_struct() on
>>> that srcu_struct?
>>
>> Nah, none of that :)
>>
>> init_srcu_struct_nodes() assumes ssp->sda!=NULL but alloc_percpu() fails
>> here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/percpu.c#n1734
>> ===
>> } else if (mutex_lock_killable(&pcpu_alloc_mutex)) {
>> pcpu_memcg_post_alloc_hook(objcg, NULL, 0, size);
>> return NULL;
>> ===
>>
>> I am still up to reading that osr-rcuusage.pdf to provide better
>> analysis :) Thanks,
>
> Ah, got it! Does the following patch help?
>
> There will likely also need to be changes to cleanup_srcu_struct(),
> but first let's see if I understand the problem. ;-)
>
> Thanx, Paul
>
>
>
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index c13348e..6f7880a 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -177,11 +177,13 @@ static int init_srcu_struct_fields(struct srcu_struct
> *ssp, bool is_static)
> INIT_DELAYED_WORK(&ssp->work, process_srcu);
> if (!is_static)
> ssp->sda = alloc_percpu(struct srcu_data);
> + if (!ssp->sda)
> + return -ENOMEM;
> init_srcu_struct_nodes(ssp, is_static);
> ssp->srcu_gp_seq_needed_exp = 0;
> ssp->srcu_last_gp_end = ktime_get_mono_fast_ns();
> smp_store_release(&ssp->srcu_gp_seq_needed, 0); /* Init done. */
The line above confuses me a bit. What you propose returns without
smp_store_release() called which should not matter I suppose.
Otherwise it should work, although I cannot verify right now as my box
went down and since it is across Pacific - it may take time to power
cycle it :) Thanks,
> - return ssp->sda ? 0 : -ENOMEM;
> + return 0;
> }
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
>
--
Alexey
[PATCH] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx
Before the commit identified below, pages tables allocation was
performed after the allocation of final shadow area for linear memory.
But that commit switched the order, leading to page tables being
already allocated at the time 8xx kasan_init_shadow_8M() is called.
Due to this, kasan_init_shadow_8M() doesn't map the needed
shadow entries because there are already page tables.
kasan_init_shadow_8M() installs huge PMD entries instead of page
tables. We could at that time free the page tables, but there is no
point in creating page tables that get freed before being used.
Only book3s/32 hash needs early allocation of page tables. For other
variants, we can keep the initial order and create remaining page
tables after the allocation of final shadow memory for linear mem.
Move back the allocation of shadow page tables for
CONFIG_KASAN_VMALLOC into kasan_init() after the loop which creates
final shadow memory for linear mem.
Fixes: 41ea93cf7ba4 ("powerpc/kasan: Fix shadow pages allocation failure")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/kasan/kasan_init_32.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c
b/arch/powerpc/mm/kasan/kasan_init_32.c
index fb294046e00e..929716ea21e9 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -127,8 +127,7 @@ void __init kasan_mmu_init(void)
{
int ret;
- if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE) ||
- IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE)) {
ret = kasan_init_shadow_page_tables(KASAN_SHADOW_START,
KASAN_SHADOW_END);
if (ret)
@@ -139,11 +138,11 @@ void __init kasan_mmu_init(void)
void __init kasan_init(void)
{
struct memblock_region *reg;
+ int ret;
for_each_memblock(memory, reg) {
phys_addr_t base = reg->base;
phys_addr_t top = min(base + reg->size, total_lowmem);
- int ret;
if (base >= top)
continue;
@@ -153,6 +152,13 @@ void __init kasan_init(void)
panic("kasan: kasan_init_region() failed");
}
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ ret = kasan_init_shadow_page_tables(KASAN_SHADOW_START,
KASAN_SHADOW_END);
+
+ if (ret)
+ panic("kasan: kasan_init_shadow_page_tables() failed");
+ }
+
kasan_remap_early_shadow_ro();
clear_page(kasan_early_shadow_page);
--
2.25.0
[PATCH net-next] net/packet: Fix a comment about hard_header_len and add a warning for it
This patch tries to clarify the difference between hard_header_len and
needed_headroom by fixing an outdated comment and adding a WARN_ON_ONCE
warning for hard_header_len.
The difference between hard_header_len and needed_headroom as understood
by this patch is based on the following reasons:
1.
In af_packet.c, the function packet_snd first reserves a headroom of
length (dev->hard_header_len + dev->needed_headroom).
Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
which calls dev->header_ops->create, to create the link layer header.
If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of
length (dev->hard_header_len), and checks if the user has provided a
header sized between (dev->min_header_len) and (dev->hard_header_len)
(in dev_validate_header).
This shows the developers of af_packet.c expect hard_header_len to
be consistent with header_ops.
2.
In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment.
That comment states that prepending an LL header internally in a driver
is considered a bug. I believe this bug can be fixed by setting
hard_header_len to 0, making the internal header completely invisible
to af_packet.c (and requesting the headroom in needed_headroom instead).
3.
There is a commit for a WiFi driver:
commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len")
According to the discussion about it at:
https://patchwork.kernel.org/patch/11407493/
The author tried to set the WiFi driver's hard_header_len to the Ethernet
header length, and request additional header space internally needed by
setting needed_headroom.
This means this usage is already adopted by driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wang
Signed-off-by: Xie He
---
net/packet/af_packet.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index af6c93ed9fa0..93c89d3b2511 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -93,12 +93,15 @@
/*
Assumptions:
- - if device has no dev->hard_header routine, it adds and removes ll header
- inside itself. In this case ll header is invisible outside of device,
- but higher levels still should reserve dev->hard_header_len.
- Some devices are enough clever to reallocate skb, when header
- will not fit to reserved space (tunnel), another ones are silly
- (PPP).
+ - If the device has no dev->header_ops, there is no LL header visible
+ above the device. In this case, its hard_header_len should be 0.
+ The device may prepend its own header internally. In this case, its
+ needed_headroom should be set to the space needed for it to add its
+ internal header.
+ For example, a WiFi driver pretending to be an Ethernet driver should
+ set its hard_header_len to be the Ethernet header length, and set its
+ needed_headroom to be (the real WiFi header length - the fake Ethernet
+ header length).
- packet socket receives packets with pulled ll header,
so that SOCK_RAW should push it back.
@@ -2936,6 +2939,8 @@ static int packet_snd(struct socket *sock, struct msghdr
*msg, size_t len)
skb_reset_network_header(skb);
err = -EINVAL;
+ if (!dev->header_ops)
+ WARN_ON_ONCE(dev->hard_header_len != 0);
if (sock->type == SOCK_DGRAM) {
offset = dev_hard_header(skb, dev, ntohs(proto), addr, NULL,
len);
if (unlikely(offset < 0))
--
2.25.1
RE: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
Hi Chunfeng,
> From: Chunfeng Yun, Sent: Friday, September 11, 2020 1:13 PM
>
> On Fri, 2020-09-11 at 03:13 +, Yoshihiro Shimoda wrote:
> > Hi Daniel, Chunfeng,
> >
> > > From: Chunfeng Yun, Sent: Friday, September 11, 2020 11:33 AM
> > >
> > > On Thu, 2020-09-10 at 14:12 +0100, Daniel Thompson wrote:
> > > > On Thu, Sep 10, 2020 at 04:21:45PM +0800, Chunfeng Yun wrote:
> > > > > Use readl_poll_timeout_atomic() to simplify code
> > > > >
> > > > > Cc: Mathias Nyman
> > > > > Cc: Yoshihiro Shimoda
> > > > > Signed-off-by: Chunfeng Yun
> > > > > ---
> > > > > v2~v3: no changes
> > > > > ---
> > > > > drivers/usb/host/xhci-rcar.c | 43
> > > > > ---
> > > > > 1 file changed, 12 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/drivers/usb/host/xhci-rcar.c
> > > > > b/drivers/usb/host/xhci-rcar.c
> > > > > index c1025d3..74f836f 100644
> > > > > --- a/drivers/usb/host/xhci-rcar.c
> > > > > +++ b/drivers/usb/host/xhci-rcar.c
> > > > > @@ -6,6 +6,7 @@
> > > > > */
> > > > >
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct
> > > > > usb_hcd *hcd)
> > > > > void __iomem *regs = hcd->regs;
> > > > > struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > > > > const struct firmware *fw;
> > > > > - int retval, index, j, time;
> > > > > - int timeout = 1;
> > > > > + int retval, index, j;
> > > > > u32 data, val, temp;
> > > > > u32 quirks = 0;
> > > > > const struct soc_device_attribute *attr;
> > > > > @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct
> > > > > usb_hcd *hcd)
> > > > > temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> > > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > > >
> > > > > - for (time = 0; time < timeout; time++) {
> > > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > > - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> > > > > - break;
> > > > > - udelay(1);
> > > > > - }
> > > > > - if (time == timeout) {
> > > > > - retval = -ETIMEDOUT;
> > > > > + retval = readl_poll_timeout_atomic(regs +
> > > > > RCAR_USB3_DL_CTRL,
> > > > > + val, !(val &
> > > > > RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> > > > > + 1, 1);
> > > > > + if (retval < 0)
> How about free firmware and return error number here ? instead of break
I think clearing CTRL_ENABLE code below is needed.
And, I think this patch should not change a lot of things...
> > > > > break;
> > > > > - }
> > > > > }
> > > > >
> > > > > temp = readl(regs + RCAR_USB3_DL_CTRL);
> > > > > temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> > > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > > >
> > > > > - for (time = 0; time < timeout; time++) {
> > > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > > - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> > > > > - retval = 0;
> > > > > - break;
> > > > > - }
> > > > > - udelay(1);
> > > > > - }
> > > > > - if (time == timeout)
> > > > > - retval = -ETIMEDOUT;
> > > > > + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> > > > > + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1,
> > > > > 1);
> > > >
> > > > Directly assigning to retval at this point will clobber a previous
> > > > -ETIMEDOUT error.
> > > >
> > > > In other words if there is a timeout waiting for FW_SET_DATA0, but not
> > > > for
> > > > DW_SUCCESS, then we will return the wrong return value.
> >
> > Thank you for your comment! I didn't realized this.
> >
> > > Yes, agree with you, but seems I keep its original logic unchanged.
> > > Hi Yoshihiro,
> > >
> > > What do think about Daniel's suggestion? should I fix it up?
> >
> > I think you should fix it up like below:
> >
> > if (readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> > val, val & RCAR_USB3_DL_CTRL_FW_SUCCESS, 1, 1) < 0)
> > retval = -ETIMEOUT; /* Overwrite retval if timeout occurred */
>
> readl_poll_timeout_atomic() only return -ETIMEOUT error number, so this
> likes what I did, doesn't fix it.
readl_poll_timeout_atomic() returns 0 if timeout doesn't happen.
So, when my suggestion code runs, the retval is not overwritten if
the readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL...) returns 0.
Best regards,
Yoshihiro Shimoda
Re: [PATCH 0/4] Remove LPC register partitioning
On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote: > Hello, > > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang > wrote: > > > > The LPC controller has no concept of the BMC and the Host partitions. > > The incorrect partitioning can impose unnecessary range restrictions > > on register access through the syscon regmap interface. > > > > For instance, HICRB contains the I/O port address configuration > > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access > > HICRB as it is located at the other LPC partition. Thanks for addressing this, I've regretted that choice for a while now. The split was rooted in trying to support pinmux while not being across every detail of the LPC controller, and so I made some poor decisions. > > > > In addition, to be backward compatible, the newly added HW control > > bits could be added at any reserved bits over the LPC addressing space. > > > > Thereby, this patch series aims to remove the LPC partitioning for > > better driver development and maintenance. > > I support this cleanup. The only consideration is to be careful with > breaking the driver/device-tree relationship. We either need to ensure > the drivers remain compatible with both device trees. > > Another solution is to get agreement from all parties that for the LPC > device the device tree is always the one shipped with the kernel, so > it is okay to make incompatible changes. > > While we are doing a cleanup, Andrew suggested we remove the detailed > description of LPC out of the device tree. We would have the one LPC > node, and create a LPC driver that creates all of the sub devices > (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this > plan? I dug up the conversation I had with Rob over a year ago about being unhappy with what I'd cooked up. https://lore.kernel.org/linux-arm-kernel/cal_jsqj+sfdg8ekbv3gvmqvhx+otwbki4dy213apzxgfhbx...@mail.gmail.com/ But I think you covered most of the idea there: We have the LPC driver create the subdevices and that moves the details out of the devicetree. However, I haven't thought about it more than that, and I think there are still problems with that idea. For instance, how we manage configuration of those devices, and how to enable only the devices a given platform actually cares about (i.e. the problems that devicetree solves for us). It may be that the only way to do that is with platform code, and that's not really a direction we should be going either. Andrew
Re: [PATCH -next] media: marvell-ccic: Fix -Wunused-function warnings
On 2020/9/10 22:57, Lubomir Rintel wrote:
> On Thu, Sep 10, 2020 at 05:18:15PM +0800, Yuehaibing wrote:
>> On 2020/9/10 16:22, Lubomir Rintel wrote:
>>> On Thu, Sep 10, 2020 at 04:09:33PM +0800, YueHaibing wrote:
If CONFIG_PM is n, gcc warns:
drivers/media/platform/marvell-ccic/mmp-driver.c:347:12: warning:
‘mmpcam_resume’ defined but not used [-Wunused-function]
static int mmpcam_resume(struct device *dev)
^
drivers/media/platform/marvell-ccic/mmp-driver.c:338:12: warning:
‘mmpcam_suspend’ defined but not used [-Wunused-function]
static int mmpcam_suspend(struct device *dev)
^~
drivers/media/platform/marvell-ccic/mmp-driver.c:324:12: warning:
‘mmpcam_runtime_suspend’ defined but not used [-Wunused-function]
static int mmpcam_runtime_suspend(struct device *dev)
^~
drivers/media/platform/marvell-ccic/mmp-driver.c:310:12: warning:
‘mmpcam_runtime_resume’ defined but not used [-Wunused-function]
static int mmpcam_runtime_resume(struct device *dev)
^
Mark them as __maybe_unused to fix this.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
>>>
>>> Your colleague seems to sent out an equivalent patch:
>>> https://lore.kernel.org/lkml/20200910080933.40684-1-yuehaib...@huawei.com/
>>
>> This is my patch, paste an wrong link?
>
> Indeed, sorry for the confusion.
>
> The original mail only went to linux-media, not lkml, which is why I
> picked the wrong one from the archive. Here's the patch:
>
> https://lore.kernel.org/linux-media/20200909112921.5116-1-weiyongj...@huawei.com/
mmpcam_runtime_suspend/mmpcam_runtime_resume also should be cared, I'll adjust
my patch based on it.
>
> Take care
> Lubo
>
>>
>>>
>>> Cheers
>>> Lubo
>>>
---
drivers/media/platform/marvell-ccic/mmp-driver.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index c4b28a00a3a2..032fdddbbecc 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -307,7 +307,7 @@ static int mmpcam_platform_remove(struct
platform_device *pdev)
* Suspend/resume support.
*/
-static int mmpcam_runtime_resume(struct device *dev)
+static int __maybe_unused mmpcam_runtime_resume(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
struct mcam_camera *mcam = &cam->mcam;
@@ -321,7 +321,7 @@ static int mmpcam_runtime_resume(struct device *dev)
return 0;
}
-static int mmpcam_runtime_suspend(struct device *dev)
+static int __maybe_unused mmpcam_runtime_suspend(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
struct mcam_camera *mcam = &cam->mcam;
@@ -335,7 +335,7 @@ static int mmpcam_runtime_suspend(struct device *dev)
return 0;
}
-static int mmpcam_suspend(struct device *dev)
+static int __maybe_unused mmpcam_suspend(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
@@ -344,7 +344,7 @@ static int mmpcam_suspend(struct device *dev)
return 0;
}
-static int mmpcam_resume(struct device *dev)
+static int __maybe_unused mmpcam_resume(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
--
2.17.1
>>>
>>> .
>>>
>>
>
> .
>
Re: linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
On Wed, 2 Sep 2020 15:12:35 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/scsi/aacraid/aachba.c
>
> between commit:
>
> df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
>
> from Linus' tree and commit:
>
> cfd3d2225aa5 ("scsi: aacraid: Remove erroneous fallthrough annotation")
>
> from the scsi-mkp tree.
>
> I fixed it up (I removed the line removed by the latter - it was rewritten
> by the former to "fallthrough;") and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
This is now a conflict between the scsi tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpj2lDjokB5_.pgp
Description: OpenPGP digital signature
[PATCH 2/3] exfat: remove useless check in exfat_move_file()
In exfat_move_file(), the identity of source and target directory has been checked by the caller. Also, it gets stream.start_clu from file dir-entry, which is an invalid determination. Signed-off-by: Tetsuhiro Kohada --- fs/exfat/namei.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c index 803748946ddb..1c433491f771 100644 --- a/fs/exfat/namei.c +++ b/fs/exfat/namei.c @@ -1095,11 +1095,6 @@ static int exfat_move_file(struct inode *inode, struct exfat_chain *p_olddir, if (!epmov) return -EIO; - /* check if the source and target directory is the same */ - if (exfat_get_entry_type(epmov) == TYPE_DIR && - le32_to_cpu(epmov->dentry.stream.start_clu) == p_newdir->dir) - return -EINVAL; - num_old_entries = exfat_count_ext_entries(sb, p_olddir, oldentry, epmov); if (num_old_entries < 0) -- 2.25.1
[PATCH 3/3] exfat: replace memcpy with structure assignment
Use structure assignment instead of memcpy.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/dir.c | 7 ++-
fs/exfat/inode.c | 2 +-
fs/exfat/namei.c | 15 +++
3 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index fa5bb72aa295..8520decd120c 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -974,11 +974,8 @@ int exfat_find_dir_entry(struct super_block *sb, struct
exfat_inode_info *ei,
if (ei->hint_femp.eidx ==
EXFAT_HINT_NONE ||
candi_empty.eidx <=
-ei->hint_femp.eidx) {
- memcpy(&ei->hint_femp,
- &candi_empty,
- sizeof(candi_empty));
- }
+ei->hint_femp.eidx)
+ ei->hint_femp = candi_empty;
}
brelse(bh);
diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index 70a33d4807c3..687f77653187 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -554,7 +554,7 @@ static int exfat_fill_inode(struct inode *inode, struct
exfat_dir_entry *info)
struct exfat_inode_info *ei = EXFAT_I(inode);
loff_t size = info->size;
- memcpy(&ei->dir, &info->dir, sizeof(struct exfat_chain));
+ ei->dir = info->dir;
ei->entry = info->entry;
ei->attr = info->attr;
ei->start_clu = info->start_clu;
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 1c433491f771..2932b23a3b6c 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -318,8 +318,7 @@ static int exfat_find_empty_entry(struct inode *inode,
hint_femp.eidx = EXFAT_HINT_NONE;
if (ei->hint_femp.eidx != EXFAT_HINT_NONE) {
- memcpy(&hint_femp, &ei->hint_femp,
- sizeof(struct exfat_hint_femp));
+ hint_femp = ei->hint_femp;
ei->hint_femp.eidx = EXFAT_HINT_NONE;
}
@@ -519,7 +518,7 @@ static int exfat_add_entry(struct inode *inode, const char
*path,
if (ret)
goto out;
- memcpy(&info->dir, p_dir, sizeof(struct exfat_chain));
+ info->dir = *p_dir;
info->entry = dentry;
info->flags = ALLOC_NO_FAT_CHAIN;
info->type = type;
@@ -625,7 +624,7 @@ static int exfat_find(struct inode *dir, struct qstr *qname,
if (dentry < 0)
return dentry; /* -error value */
- memcpy(&info->dir, &cdir.dir, sizeof(struct exfat_chain));
+ info->dir = cdir;
info->entry = dentry;
info->num_subdirs = 0;
@@ -1030,7 +1029,7 @@ static int exfat_rename_file(struct inode *inode, struct
exfat_chain *p_dir,
if (!epnew)
return -EIO;
- memcpy(epnew, epold, DENTRY_SIZE);
+ *epnew = *epold;
if (exfat_get_entry_type(epnew) == TYPE_FILE) {
epnew->dentry.file.attr |= cpu_to_le16(ATTR_ARCHIVE);
ei->attr |= ATTR_ARCHIVE;
@@ -1050,7 +1049,7 @@ static int exfat_rename_file(struct inode *inode, struct
exfat_chain *p_dir,
return -EIO;
}
- memcpy(epnew, epold, DENTRY_SIZE);
+ *epnew = *epold;
exfat_update_bh(new_bh, sync);
brelse(old_bh);
brelse(new_bh);
@@ -1113,7 +1112,7 @@ static int exfat_move_file(struct inode *inode, struct
exfat_chain *p_olddir,
if (!epnew)
return -EIO;
- memcpy(epnew, epmov, DENTRY_SIZE);
+ *epnew = *epmov;
if (exfat_get_entry_type(epnew) == TYPE_FILE) {
epnew->dentry.file.attr |= cpu_to_le16(ATTR_ARCHIVE);
ei->attr |= ATTR_ARCHIVE;
@@ -1133,7 +1132,7 @@ static int exfat_move_file(struct inode *inode, struct
exfat_chain *p_olddir,
return -EIO;
}
- memcpy(epnew, epmov, DENTRY_SIZE);
+ *epnew = *epmov;
exfat_update_bh(new_bh, IS_DIRSYNC(inode));
brelse(mov_bh);
brelse(new_bh);
--
2.25.1
[PATCH 1/3] exfat: remove useless directory scan in exfat_add_entry()
There is nothing in directory just created, so there is no need to scan.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/namei.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index b966b9120c9c..803748946ddb 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -530,19 +530,10 @@ static int exfat_add_entry(struct inode *inode, const
char *path,
info->size = 0;
info->num_subdirs = 0;
} else {
- int count;
- struct exfat_chain cdir;
-
info->attr = ATTR_SUBDIR;
info->start_clu = start_clu;
info->size = clu_size;
-
- exfat_chain_set(&cdir, info->start_clu,
- EXFAT_B_TO_CLU(info->size, sbi), info->flags);
- count = exfat_count_dir_entries(sb, &cdir);
- if (count < 0)
- return -EIO;
- info->num_subdirs = count + EXFAT_MIN_SUBDIR;
+ info->num_subdirs = EXFAT_MIN_SUBDIR;
}
memset(&info->crtime, 0, sizeof(info->crtime));
memset(&info->mtime, 0, sizeof(info->mtime));
--
2.25.1
Re: [PATCH v3 3/3] hwrng: xiphera-trng: add support for XIP8001B hwrng
On Wed, Sep 02, 2020 at 01:28:17PM +0300, Atte Tommiska wrote: > Xiphera XIP8001B is an FPGA-based True Random Number Generator > Intellectual Property (IP) Core which can be instantiated in > multiple FPGA families. This driver adds Linux support for it through > the hwrng interface. > > Signed-off-by: Atte Tommiska > Reported-by: kernel test robot This Reported-by appears to be superfluous and I'll remove it when applying. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RFC tip/core/rcu 4/4] rcu-tasks: Shorten per-grace-period sleep for RCU Tasks Trace
On Thu, Sep 10, 2020 at 08:18:01PM -0700, Alexei Starovoitov wrote: > On Thu, Sep 10, 2020 at 1:20 PM wrote: > > > > From: "Paul E. McKenney" > > > > The various RCU tasks flavors currently wait 100 milliseconds between each > > grace period in order to prevent CPU-bound loops and to favor efficiency > > over latency. However, RCU Tasks Trace needs to have a grace-period > > latency of roughly 25 milliseconds, which is completely infeasible given > > the 100-millisecond per-grace-period sleep. This commit therefore reduces > > this sleep duration to 5 milliseconds (or one jiffy, whichever is longer) > > in kernels built with CONFIG_TASKS_TRACE_RCU_READ_MB=y. > > The commit log is either misleading or wrong? > If I read the code correctly in CONFIG_TASKS_TRACE_RCU_READ_MB=y > case the existing HZ/10 "paranoid sleep" is preserved. Yes, for CONFIG_TASKS_TRACE_RCU_READ_MB=y, the previous 100-millisecond "paranoid sleep" is preserved. Preserving previous behavior is of course especially important for rcupdate.rcu_task_ipi_delay, given that real-time applications are degraded by IPIs. And given that we are avoiding IPIs in this case, speeding up the polling is not all that helpful. > It's for the MB=n case it is reduced to HZ/200. Yes, that is, to roughly 5 milliseconds for large HZ or to one jiffy for HZ<200. Here, we send IPIs much more aggressively, so polling more frequently does help a lot. > Also I don't understand why you're talking about milliseconds but > all numbers are HZ based. HZ/10 gives different number of > milliseconds depending on HZ. As long as HZ is 10 or greater, HZ/10 jiffies is roughly 100 milliseconds. In the unlikely event that HZ is less than 10, the code clamps to one jiffy. Since schedule_timeout_idle() sleep time is specified in jiffies, it all works out. Thanx, Paul
Re: [PATCH] crypto: stm32/crc32 - Avoid lock if hardware is already used
On Fri, Sep 04, 2020 at 01:25:27PM +0200, Nicolas Toromanoff wrote:
> If STM32 CRC device is already in use, calculate CRC by software.
>
> This will release CPU constraint for a concurrent access to the
> hardware, and avoid masking irqs during the whole block processing.
>
> Fixes: 7795c0baf5ac ("crypto: stm32/crc32 - protect from concurrent accesses")
>
> Signed-off-by: Nicolas Toromanoff
> ---
> drivers/crypto/stm32/Kconfig | 2 ++
> drivers/crypto/stm32/stm32-crc32.c | 15 ---
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
> index 4ef3eb11361c..8d605b07571f 100644
> --- a/drivers/crypto/stm32/Kconfig
> +++ b/drivers/crypto/stm32/Kconfig
> @@ -3,6 +3,8 @@ config CRYPTO_DEV_STM32_CRC
> tristate "Support for STM32 crc accelerators"
> depends on ARCH_STM32
> select CRYPTO_HASH
> + select CRYPTO_CRC32
> + select CRYPTO_CRC32C
Shouldn't this be "select CRC32"?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v6 0/8] crpyto: introduce OSCCA certificate and SM2 asymmetric algorithm
On Thu, Sep 03, 2020 at 09:12:34PM +0800, Tianjia Zhang wrote: > > --- > v6 changes: > 1. remove mpi_sub_ui function from mpi library. > 2. rebase on mainline. This series is still missing acks for patches 6-8. Without them it cannot proceed. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v3] Documentation: kunit: Add naming guidelines
As discussed in [1], KUnit tests have hitherto not had a particularly consistent naming scheme. This adds documentation outlining how tests and test suites should be named, including how those names should be used in Kconfig entries and filenames. [1]: https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u Signed-off-by: David Gow Reviewed-by: Kees Cook Reviewed-by: Brendan Higgins Reviewed-by: Marco Elver Reviewed-by: Tim Bird --- This is v3 of the KUnit test naming guidelines. It's basically just v2 with some spelling fixes (thanks Marco). Changelog: v3: - Fix a few typos. - Add Marco and Tim's Reviewed-bys. v2: https://lore.kernel.org/linux-kselftest/20200909051631.2960347-1-david...@google.com/ - Rewrote the filename section to use "_test" as a suffix, and focus on module names, not filenames. - Add a motivating introduction, which also calls out existing tests and tests which cause problems when run automatically (long running, flaky tests) as reasons to avoid the guidelines. - Talk about including the type of test in the suite name, but only if theres an actual confict. (And update the example for this). v1: https://lore.kernel.org/linux-kselftest/20200702071416.1780522-1-david...@google.com/ - Fixed a bit of space/tab confusion in the index (Thanks, Randy) - Added some more examples (and some test case examples). - Added some examples of what not to call subsystems and suites. - No longer explicitly require "If unsure, put N" in Kconfig entries. - Minor formatting changes RFC: https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u - Initial version Documentation/dev-tools/kunit/index.rst | 1 + Documentation/dev-tools/kunit/style.rst | 207 2 files changed, 208 insertions(+) create mode 100644 Documentation/dev-tools/kunit/style.rst diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index e93606ecfb01..c234a3ab3c34 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel usage kunit-tool api/index + style faq What is KUnit? diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst new file mode 100644 index ..2352b7292eb5 --- /dev/null +++ b/Documentation/dev-tools/kunit/style.rst @@ -0,0 +1,207 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Test Style and Nomenclature +=== + +To make finding, writing, and using KUnit tests as simple as possible, it's +strongly encouraged that they are named and written according to the guidelines +below. While it's possible to write KUnit tests which do not follow these rules, +they may break some tooling, may conflict with other tests, and may not be run +automatically by testing systems. + +It's recommended that you only deviate from these guidelines when: + +1. Porting tests to KUnit which are already known with an existing name, or +2. Writing tests which would cause serious problems if automatically run (e.g., + non-deterministically producing false positives or negatives, or taking an + extremely long time to run). + +Subsystems, Suites, and Tests += + +In order to make tests as easy to find as possible, they're grouped into suites +and subsystems. A test suite is a group of tests which test a related area of +the kernel, and a subsystem is a set of test suites which test different parts +of the same kernel subsystem or driver. + +Subsystems +-- + +Every test suite must belong to a subsystem. A subsystem is a collection of one +or more KUnit test suites which test the same driver or part of the kernel. A +rule of thumb is that a test subsystem should match a single kernel module. If +the code being tested can't be compiled as a module, in many cases the subsystem +should correspond to a directory in the source tree or an entry in the +MAINTAINERS file. If unsure, follow the conventions set by tests in similar +areas. + +Test subsystems should be named after the code being tested, either after the +module (wherever possible), or after the directory or files being tested. Test +subsystems should be named to avoid ambiguity where necessary. + +If a test subsystem name has multiple components, they should be separated by +underscores. *Do not* include "test" or "kunit" directly in the subsystem name +unless you are actually testing other tests or the kunit framework itself. + +Example subsystems could be: + +``ext4`` + Matches the module and filesystem name. +``apparmor`` + Matches the module name and LSM name. +``kasan`` + Common name for the tool, prominent part of the path ``mm/kasan`` +``snd_hda_codec_hdmi`` + Has several components (``snd``, ``hda``, ``codec``, ``hdmi``) separated by + underscores. Matches the module name. +
[PATCH net-next] net: dsa: b53: Configure VLANs while not filtering
Update the B53 driver to support VLANs while not filtering. This
requires us to enable VLAN globally within the switch upon driver
initial configuration (dev->vlan_enabled).
We also need to remove the code that dealt with PVID re-configuration in
b53_vlan_filtering() since that function worked under the assumption
that it would only be called to make a bridge VLAN filtering, or not
filtering, and we would attempt to move the port's PVID accordingly.
Now that VLANs are programmed all the time, even in the case of a
non-VLAN filtering bridge, we would be programming a default_pvid for
the bridged switch ports.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_common.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 6a5796c32721..46ac8875f870 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1377,23 +1377,6 @@ EXPORT_SYMBOL(b53_phylink_mac_link_up);
int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering)
{
struct b53_device *dev = ds->priv;
- u16 pvid, new_pvid;
-
- b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &pvid);
- if (!vlan_filtering) {
- /* Filtering is currently enabled, use the default PVID since
-* the bridge does not expect tagging anymore
-*/
- dev->ports[port].pvid = pvid;
- new_pvid = b53_default_pvid(dev);
- } else {
- /* Filtering is currently disabled, restore the previous PVID */
- new_pvid = dev->ports[port].pvid;
- }
-
- if (pvid != new_pvid)
- b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
- new_pvid);
b53_enable_vlan(dev, dev->vlan_enabled, vlan_filtering);
@@ -1444,7 +1427,7 @@ void b53_vlan_add(struct dsa_switch *ds, int port,
untagged = true;
vl->members |= BIT(port);
- if (untagged && !dsa_is_cpu_port(ds, port))
+ if (untagged)
vl->untag |= BIT(port);
else
vl->untag &= ~BIT(port);
@@ -1482,7 +1465,7 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
if (pvid == vid)
pvid = b53_default_pvid(dev);
- if (untagged && !dsa_is_cpu_port(ds, port))
+ if (untagged)
vl->untag &= ~(BIT(port));
b53_set_vlan_entry(dev, vid, vl);
@@ -2619,6 +2602,8 @@ struct b53_device *b53_switch_alloc(struct device *base,
dev->priv = priv;
dev->ops = ops;
ds->ops = &b53_switch_ops;
+ ds->configure_vlan_while_not_filtering = true;
+ dev->vlan_enabled = ds->configure_vlan_while_not_filtering;
mutex_init(&dev->reg_mutex);
mutex_init(&dev->stats_mutex);
--
2.25.1
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On Thu, 2020-09-10 at 15:21 +0100, Robin Murphy wrote:
> On 2020-09-09 21:06, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> >
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is case or default and the only statement in the next
> > label block is break;
> >
> > Found using:
> >
> > $ grep-2.5.4 -rP --include=*.[ch] -n
> > "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> >
> > Miscellanea:
> >
> > o Move or coalesce a couple label blocks above a default: block.
> >
> > Signed-off-by: Joe Perches
> > ---
> >
> > Compiled allyesconfig x86-64 only.
> > A few files for other arches were not compiled.
> >
>
> [...]
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index c192544e874b..743db1abec40 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -3777,7 +3777,7 @@ static int arm_smmu_device_hw_probe(struct
> > arm_smmu_device *smmu)
> > switch (FIELD_GET(IDR0_TTF, reg)) {
> > case IDR0_TTF_AARCH32_64:
> > smmu->ias = 40;
> > - fallthrough;
> > + break;
> > case IDR0_TTF_AARCH64:
> > break;
> > default:
>
> I have to say I don't really agree with the readability argument for
> this one - a fallthrough is semantically correct here, since the first
> case is a superset of the second. It just happens that anything we would
> do for the common subset is implicitly assumed (there are other
> potential cases we simply haven't added support for at the moment), thus
> the second case is currently empty.
> This change actively obfuscates that distinction.
Then perhaps comments should be added to usefully
describe the mechanisms.
case IDR0_TTF_AARCH32_64:
smmu->ias = 40;
fallthrough;/* and still do the 64 bit processing */
case IDR0_TTF_AARCH64:
/* Nothing specific yet */
break;
> Robin.
[PATCH 2/4] soc: aspeed: Fix LPC register offsets
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang
---
drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +++---
drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
index 01ed21e8bfee..36faa0618ada 100644
--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
@@ -17,12 +17,12 @@
#define DEVICE_NAME"aspeed-lpc-ctrl"
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_ENL2HBIT(8)
#define HICR5_ENFWHBIT(10)
-#define HICR7 0x8
-#define HICR8 0xc
+#define HICR7 0x88
+#define HICR8 0x8c
struct aspeed_lpc_ctrl {
struct miscdevice miscdev;
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c
b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index f3d8d53ab84d..7ce5c9fcc73c 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -28,26 +28,25 @@
#define NUM_SNOOP_CHANNELS 2
#define SNOOP_FIFO_SIZE 2048
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_EN_SNP0W BIT(0)
#define HICR5_ENINT_SNP0W BIT(1)
#define HICR5_EN_SNP1W BIT(2)
#define HICR5_ENINT_SNP1W BIT(3)
-
-#define HICR6 0x4
+#define HICR6 0x84
#define HICR6_STR_SNP0WBIT(0)
#define HICR6_STR_SNP1WBIT(1)
-#define SNPWADR0x10
+#define SNPWADR0x90
#define SNPWADR_CH0_MASK GENMASK(15, 0)
#define SNPWADR_CH0_SHIFT 0
#define SNPWADR_CH1_MASK GENMASK(31, 16)
#define SNPWADR_CH1_SHIFT 16
-#define SNPWDR 0x14
+#define SNPWDR 0x94
#define SNPWDR_CH0_MASKGENMASK(7, 0)
#define SNPWDR_CH0_SHIFT 0
#define SNPWDR_CH1_MASKGENMASK(15, 8)
#define SNPWDR_CH1_SHIFT 8
-#define HICRB 0x80
+#define HICRB 0x100
#define HICRB_ENSNP0D BIT(14)
#define HICRB_ENSNP1D BIT(15)
--
2.17.1
[PATCH 0/4] Remove LPC register partitioning
The LPC controller has no concept of the BMC and the Host partitions. The incorrect partitioning can impose unnecessary range restrictions on register access through the syscon regmap interface. For instance, HICRB contains the I/O port address configuration of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB as it is located at the other LPC partition. In addition, to be backward compatible, the newly added HW control bits could be added at any reserved bits over the LPC addressing space. Thereby, this patch series aims to remove the LPC partitioning for better driver development and maintenance. Chia-Wei, Wang (4): ARM: dts: Remove LPC BMC and Host partitions soc: aspeed: Fix LPC register offsets ipmi: kcs: aspeed: Fix LPC register offsets pinctrl: aspeed-g5: Fix LPC register offsets arch/arm/boot/dts/aspeed-g4.dtsi | 74 +-- arch/arm/boot/dts/aspeed-g5.dtsi | 135 + arch/arm/boot/dts/aspeed-g6.dtsi | 135 + drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +- drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +- drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +- drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +- 7 files changed, 162 insertions(+), 214 deletions(-) -- 2.17.1
[PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 0cab4c2576e2..98e62333fa54 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -60,7 +60,7 @@
#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
-#define LHCR0 0x20
+#define LHCR0 0xa0
#define GFX064 0x64
#define B14 0
--
2.17.1
[PATCH 3/4] ipmi: kcs: aspeed: Fix LPC register offsets
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang
---
drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c
b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..8843cf867a5d 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
#define KCS_CHANNEL_MAX 4
-/* mapped to lpc-bmc@0 IO space */
#define LPC_HICR00x000
#define LPC_HICR0_LPC3E BIT(7)
#define LPC_HICR0_LPC2E BIT(6)
@@ -52,15 +51,13 @@
#define LPC_STR1 0x03C
#define LPC_STR2 0x040
#define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB0x080
+#define LPC_HICRB0x100
#define LPC_HICRB_IBFIF4 BIT(1)
#define LPC_HICRB_LPC4E BIT(0)
-#define LPC_LADR40x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR40x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
struct aspeed_kcs_bmc {
struct regmap *map;
--
2.17.1
[PATCH 1/4] ARM: dts: Remove LPC BMC and Host partitions
The LPC controller has no concept of the BMC and the Host partitions.
A concrete instance is that the HICRB[5:4] are for the I/O port address
configurtaion of KCS channel 1/2. However, the KCS driver cannot access
HICRB for channel 1/2 initialization via syscon regmap interface due to
the parition boundary. (i.e. offset 80h)
In addition, to be backward compatible, the newly added HW control bits
could be located at any reserved bits over the LPC addressing space.
Thereby, this patch removes the lpc-bmc and lpc-host child node and thus
the LPC partitioning for better driver development and maintenance.
Signed-off-by: Chia-Wei, Wang
---
arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++--
arch/arm/boot/dts/aspeed-g5.dtsi | 135 ++-
arch/arm/boot/dts/aspeed-g6.dtsi | 135 ++-
3 files changed, 148 insertions(+), 196 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 82f0213e3a3c..22996b3c4a00 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -338,58 +338,44 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2400-lpc", "simple-mfd";
+ compatible = "aspeed,ast2400-lpc",
"simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2400-lpc-bmc";
- reg = <0x0 0x80>;
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2400-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2400-lpc-host",
"simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible =
"aspeed,ast2400-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <&syscon
ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible =
"aspeed,ast2400-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible =
"aspeed,ast2400-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible =
"aspeed,ast2400-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible =
"aspeed,ast2400-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2400-lpc-snoop";
+ reg = <0x90 0x8>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2400-lhc";
+
Re: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
On Fri, 2020-09-11 at 03:13 +, Yoshihiro Shimoda wrote:
> Hi Daniel, Chunfeng,
>
> > From: Chunfeng Yun, Sent: Friday, September 11, 2020 11:33 AM
> >
> > On Thu, 2020-09-10 at 14:12 +0100, Daniel Thompson wrote:
> > > On Thu, Sep 10, 2020 at 04:21:45PM +0800, Chunfeng Yun wrote:
> > > > Use readl_poll_timeout_atomic() to simplify code
> > > >
> > > > Cc: Mathias Nyman
> > > > Cc: Yoshihiro Shimoda
> > > > Signed-off-by: Chunfeng Yun
> > > > ---
> > > > v2~v3: no changes
> > > > ---
> > > > drivers/usb/host/xhci-rcar.c | 43
> > > > ---
> > > > 1 file changed, 12 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> > > > index c1025d3..74f836f 100644
> > > > --- a/drivers/usb/host/xhci-rcar.c
> > > > +++ b/drivers/usb/host/xhci-rcar.c
> > > > @@ -6,6 +6,7 @@
> > > > */
> > > >
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct
> > > > usb_hcd *hcd)
> > > > void __iomem *regs = hcd->regs;
> > > > struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > > > const struct firmware *fw;
> > > > - int retval, index, j, time;
> > > > - int timeout = 1;
> > > > + int retval, index, j;
> > > > u32 data, val, temp;
> > > > u32 quirks = 0;
> > > > const struct soc_device_attribute *attr;
> > > > @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct
> > > > usb_hcd *hcd)
> > > > temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > >
> > > > - for (time = 0; time < timeout; time++) {
> > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> > > > - break;
> > > > - udelay(1);
> > > > - }
> > > > - if (time == timeout) {
> > > > - retval = -ETIMEDOUT;
> > > > + retval = readl_poll_timeout_atomic(regs +
> > > > RCAR_USB3_DL_CTRL,
> > > > + val, !(val &
> > > > RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> > > > + 1, 1);
> > > > + if (retval < 0)
How about free firmware and return error number here ? instead of break
> > > > break;
> > > > - }
> > > > }
> > > >
> > > > temp = readl(regs + RCAR_USB3_DL_CTRL);
> > > > temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > >
> > > > - for (time = 0; time < timeout; time++) {
> > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> > > > - retval = 0;
> > > > - break;
> > > > - }
> > > > - udelay(1);
> > > > - }
> > > > - if (time == timeout)
> > > > - retval = -ETIMEDOUT;
> > > > + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> > > > + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1,
> > > > 1);
> > >
> > > Directly assigning to retval at this point will clobber a previous
> > > -ETIMEDOUT error.
> > >
> > > In other words if there is a timeout waiting for FW_SET_DATA0, but not for
> > > DW_SUCCESS, then we will return the wrong return value.
>
> Thank you for your comment! I didn't realized this.
>
> > Yes, agree with you, but seems I keep its original logic unchanged.
> > Hi Yoshihiro,
> >
> > What do think about Daniel's suggestion? should I fix it up?
>
> I think you should fix it up like below:
>
> if (readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> val, val & RCAR_USB3_DL_CTRL_FW_SUCCESS, 1, 1) < 0)
> retval = -ETIMEOUT; /* Overwrite retval if timeout occurred */
readl_poll_timeout_atomic() only return -ETIMEOUT error number, so this
likes what I did, doesn't fix it.
>
> Otherwise, the xhci_rcar_download_firmware() cannot return -ETIMEDOUT if
> timeout happened on the previous poll [1].
>
> [1]
> + retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> + val, !(val & RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> + 1, 1);
>
> Best regards,
> Yoshihiro Shimoda
>
Re: [v2 PATCH] crypto: sun4i-ss - Fix sparse endianness markers
On Thu, Sep 10, 2020 at 02:22:48PM +0200, Corentin Labbe wrote: > > I get some md5 error on both A20+BE: > alg: ahash: md5 test failed (wrong result) on test vector \"random: psize=129 > ksize=0\", cfg=\"random: inplace use_finup nosimd > src_divs=[85.99%@+3999, 5.85%@+30, 0.96%@+25, > 5.9%@+2263, 2.11%@+1950] iv_offset=2 > key_offset=43\" > and A33+BE: > [ 84.469045] alg: ahash: md5 test failed (wrong result) on test vector > \"random: psize=322 ksize=0\", cfg=\"random: inplace may_sleep use_finup > src_divs=[99.1%@+2668, 0.88%@alignmask+3630, 0.11%@+3403] > iv_offset=33\" > +[ 84.469074] need:35966fc8 b31ea266 2bf064e9 f20f40ad > +[ 84.469084] have:e29e4491 f3b6effc fa366691 00e04bd9 > > Thoses errors are random. (1 boot out of 2) Do these really go away without this patch applied? AFAICS the generated code should be identical. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH -next] nfsd: fix comparison to bool warning
Fixes coccicheck warning: fs/nfsd/nfs4proc.c:3234:5-29: WARNING: Comparison to bool Signed-off-by: Zheng Bin --- fs/nfsd/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index eaf50eafa935..63e5a4844d8c 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -3231,7 +3231,7 @@ bool nfsd4_spo_must_allow(struct svc_rqst *rqstp) if (!cstate->minorversion) return false; - if (cstate->spo_must_allowed == true) + if (cstate->spo_must_allowed) return true; opiter = resp->opcnt; -- 2.26.0.106.g9fadedd
Re: [PATCH 0/4] Remove LPC register partitioning
Hello, On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang wrote: > > The LPC controller has no concept of the BMC and the Host partitions. > The incorrect partitioning can impose unnecessary range restrictions > on register access through the syscon regmap interface. > > For instance, HICRB contains the I/O port address configuration > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access > HICRB as it is located at the other LPC partition. > > In addition, to be backward compatible, the newly added HW control > bits could be added at any reserved bits over the LPC addressing space. > > Thereby, this patch series aims to remove the LPC partitioning for > better driver development and maintenance. I support this cleanup. The only consideration is to be careful with breaking the driver/device-tree relationship. We either need to ensure the drivers remain compatible with both device trees. Another solution is to get agreement from all parties that for the LPC device the device tree is always the one shipped with the kernel, so it is okay to make incompatible changes. While we are doing a cleanup, Andrew suggested we remove the detailed description of LPC out of the device tree. We would have the one LPC node, and create a LPC driver that creates all of the sub devices (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this plan? Cheers, Joel > > Chia-Wei, Wang (4): > ARM: dts: Remove LPC BMC and Host partitions > soc: aspeed: Fix LPC register offsets > ipmi: kcs: aspeed: Fix LPC register offsets > pinctrl: aspeed-g5: Fix LPC register offsets > > arch/arm/boot/dts/aspeed-g4.dtsi | 74 +-- > arch/arm/boot/dts/aspeed-g5.dtsi | 135 + > arch/arm/boot/dts/aspeed-g6.dtsi | 135 + > drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +- > drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +- > drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +- > drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +- > 7 files changed, 162 insertions(+), 214 deletions(-) > > -- > 2.17.1 >
[PATCH -next 1/5] cifs: fix comparison to bool warning in cifsacl.c
Fixes coccicheck warning:
fs/cifs/cifsacl.c:371:6-49: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/cifsacl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
index fcff14ef1c70..9447ff1a5b6a 100644
--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -368,7 +368,7 @@ sid_to_id(struct cifs_sb_info *cifs_sb, struct cifs_sid
*psid,
else
is_group = false;
- if (is_well_known_sid(psid, &unix_id, is_group) == false)
+ if (!is_well_known_sid(psid, &unix_id, is_group))
goto try_upcall_to_get_id;
if (is_group) {
--
2.26.0.106.g9fadedd
[PATCH -next 2/5] cifs: fix comparison to bool warning in file.c
Fixes coccicheck warning:
fs/cifs/file.c:780:22-38: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index be46fab4c96d..bad749f606d5 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -777,7 +777,7 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush)
* not dirty locally we could do this.
*/
rc = server->ops->open(xid, &oparms, &oplock, NULL);
- if (rc == -ENOENT && oparms.reconnect == false) {
+ if (rc == -ENOENT && !oparms.reconnect) {
/* durable handle timeout is expired - open the file again */
rc = server->ops->open(xid, &oparms, &oplock, NULL);
/* indicate that we need to relock the file */
--
2.26.0.106.g9fadedd
[PATCH -next 0/5] cifs: fix comparison to bool warning
Zheng Bin (5): cifs: fix comparison to bool warning in cifsacl.c cifs: fix comparison to bool warning in file.c cifs: fix comparison to bool warning in smb2misc.c cifs: fix comparison to bool warning in connect.c cifs: fix comparison to bool warning in smb2ops.c fs/cifs/cifsacl.c | 2 +- fs/cifs/connect.c | 6 +++--- fs/cifs/file.c | 2 +- fs/cifs/smb2misc.c | 2 +- fs/cifs/smb2ops.c | 10 +- 5 files changed, 11 insertions(+), 11 deletions(-) -- 2.26.0.106.g9fadedd
[PATCH net-next] net: stmmac: set get_rx_header_len() as void for it didn't have any error code to return
We found the following warning when using W=1 to build kernel:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3634:6: warning: variable
‘ret’ set but not used [-Wunused-but-set-variable]
int ret, coe = priv->hw->rx_csum;
When digging stmmac_get_rx_header_len(), dwmac4_get_rx_header_len() and
dwxgmac2_get_rx_header_len() return 0 only, without any error code to
report. Therefore, it's better to define get_rx_header_len() as void.
Signed-off-by: Luo Jiaxing
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 3 +--
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 3 +--
drivers/net/ethernet/stmicro/stmmac/hwif.h | 4 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c| 4 ++--
4 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index eff8206..c6540b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -494,10 +494,9 @@ static void dwmac4_set_vlan(struct dma_desc *p, u32 type)
p->des2 |= cpu_to_le32(type & TDES2_VLAN_TAG_MASK);
}
-static int dwmac4_get_rx_header_len(struct dma_desc *p, unsigned int *len)
+static void dwmac4_get_rx_header_len(struct dma_desc *p, unsigned int *len)
{
*len = le32_to_cpu(p->des2) & RDES2_HL;
- return 0;
}
static void dwmac4_set_sec_addr(struct dma_desc *p, dma_addr_t addr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
index c3d654c..0aaf19a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
@@ -286,11 +286,10 @@ static int dwxgmac2_get_rx_hash(struct dma_desc *p, u32
*hash,
return -EINVAL;
}
-static int dwxgmac2_get_rx_header_len(struct dma_desc *p, unsigned int *len)
+static void dwxgmac2_get_rx_header_len(struct dma_desc *p, unsigned int *len)
{
if (le32_to_cpu(p->des3) & XGMAC_RDES3_L34T)
*len = le32_to_cpu(p->des2) & XGMAC_RDES2_HL;
- return 0;
}
static void dwxgmac2_set_sec_addr(struct dma_desc *p, dma_addr_t addr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index ffe2d63..e2dca9b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -90,7 +90,7 @@ struct stmmac_desc_ops {
/* RSS */
int (*get_rx_hash)(struct dma_desc *p, u32 *hash,
enum pkt_hash_types *type);
- int (*get_rx_header_len)(struct dma_desc *p, unsigned int *len);
+ void (*get_rx_header_len)(struct dma_desc *p, unsigned int *len);
void (*set_sec_addr)(struct dma_desc *p, dma_addr_t addr);
void (*set_sarc)(struct dma_desc *p, u32 sarc_type);
void (*set_vlan_tag)(struct dma_desc *p, u16 tag, u16 inner_tag,
@@ -150,7 +150,7 @@ struct stmmac_desc_ops {
#define stmmac_get_rx_hash(__priv, __args...) \
stmmac_do_callback(__priv, desc, get_rx_hash, __args)
#define stmmac_get_rx_header_len(__priv, __args...) \
- stmmac_do_callback(__priv, desc, get_rx_header_len, __args)
+ stmmac_do_void_callback(__priv, desc, get_rx_header_len, __args)
#define stmmac_set_desc_sec_addr(__priv, __args...) \
stmmac_do_void_callback(__priv, desc, set_sec_addr, __args)
#define stmmac_set_desc_sarc(__priv, __args...) \
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 89b2b34..7e95412 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3631,15 +3631,15 @@ static unsigned int stmmac_rx_buf1_len(struct
stmmac_priv *priv,
struct dma_desc *p,
int status, unsigned int len)
{
- int ret, coe = priv->hw->rx_csum;
unsigned int plen = 0, hlen = 0;
+ int coe = priv->hw->rx_csum;
/* Not first descriptor, buffer is always zero */
if (priv->sph && len)
return 0;
/* First descriptor, get split header length */
- ret = stmmac_get_rx_header_len(priv, p, &hlen);
+ stmmac_get_rx_header_len(priv, p, &hlen);
if (priv->sph && hlen) {
priv->xstats.rx_split_hdr_pkt_n++;
return hlen;
--
2.7.4
[PATCH -next 4/5] cifs: fix comparison to bool warning in connect.c
Fixes coccicheck warning:
fs/cifs/connect.c:2478:5-16: WARNING: Comparison to bool
fs/cifs/connect.c:3560:10-35: WARNING: Comparison to bool
fs/cifs/connect.c:4297:6-21: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/connect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index a5731dd6e656..4d2651b9f019 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2475,7 +2475,7 @@ cifs_parse_mount_options(const char *mountdata, const
char *devname,
else if (override_gid == 1)
pr_notice("ignoring forcegid mount option specified with no
gid= option\n");
- if (got_version == false)
+ if (!got_version)
pr_warn_once("No dialect specified on mount. Default has
changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS
(SMB1). To use the less secure SMB1 dialect to access old servers which do not
support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.\n");
kfree(mountdata_copy);
@@ -3557,7 +3557,7 @@ cifs_get_tcon(struct cifs_ses *ses, struct smb_vol
*volume_info)
}
} else if ((tcon->capabilities & SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY)
&& (ses->server->capabilities & SMB2_GLOBAL_CAP_PERSISTENT_HANDLES)
-&& (volume_info->nopersistent == false)) {
+&& !volume_info->nopersistent) {
cifs_dbg(FYI, "enabling persistent handles\n");
tcon->use_persistent = true;
} else if (volume_info->resilient) {
@@ -4294,7 +4294,7 @@ static int mount_get_conns(struct smb_vol *vol, struct
cifs_sb_info *cifs_sb,
*nses = ses;
- if ((vol->persistent == true) && (!(ses->server->capabilities &
+ if (vol->persistent && (!(ses->server->capabilities &
SMB2_GLOBAL_CAP_PERSISTENT_HANDLES))) {
cifs_server_dbg(VFS, "persistent handles not supported by
server\n");
return -EOPNOTSUPP;
--
2.26.0.106.g9fadedd
[PATCH -next 3/5] cifs: fix comparison to bool warning in smb2misc.c
Fixes coccicheck warning: fs/cifs/smb2misc.c:416:5-51: WARNING: Comparison to bool Signed-off-by: Zheng Bin --- fs/cifs/smb2misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c index d88e2683626e..0864cfa87834 100644 --- a/fs/cifs/smb2misc.c +++ b/fs/cifs/smb2misc.c @@ -413,7 +413,7 @@ smb2_calc_size(void *buf, struct TCP_Server_Info *srvr) */ len += le16_to_cpu(pdu->StructureSize2); - if (has_smb2_data_area[le16_to_cpu(shdr->Command)] == false) + if (!has_smb2_data_area[le16_to_cpu(shdr->Command)]) goto calc_size_exit; smb2_get_data_area_len(&offset, &data_length, shdr); -- 2.26.0.106.g9fadedd
[PATCH -next 5/5] cifs: fix comparison to bool warning in smb2ops.c
Fixes coccicheck warning:
fs/cifs/smb2ops.c:3199:6-15: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3223:5-14: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3301:6-15: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3311:6-15: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3341:6-15: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/smb2ops.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 32f90dc82c84..213a0e3d9f76 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -3196,7 +3196,7 @@ static long smb3_zero_range(struct file *file, struct
cifs_tcon *tcon,
/* if file not oplocked can't be sure whether asking to extend size */
if (!CIFS_CACHE_READ(cifsi))
- if (keep_size == false) {
+ if (!keep_size) {
rc = -EOPNOTSUPP;
trace_smb3_zero_err(xid, cfile->fid.persistent_fid,
tcon->tid, ses->Suid, offset, len, rc);
@@ -3220,7 +3220,7 @@ static long smb3_zero_range(struct file *file, struct
cifs_tcon *tcon,
/*
* do we also need to change the size of the file?
*/
- if (keep_size == false && i_size_read(inode) < offset + len) {
+ if (!keep_size && i_size_read(inode) < offset + len) {
eof = cpu_to_le64(offset + len);
rc = SMB2_set_eof(xid, tcon, cfile->fid.persistent_fid,
cfile->fid.volatile_fid, cfile->pid, &eof);
@@ -3298,7 +3298,7 @@ static long smb3_simple_falloc(struct file *file, struct
cifs_tcon *tcon,
tcon->ses->Suid, off, len);
/* if file not oplocked can't be sure whether asking to extend size */
if (!CIFS_CACHE_READ(cifsi))
- if (keep_size == false) {
+ if (!keep_size) {
trace_smb3_falloc_err(xid, cfile->fid.persistent_fid,
tcon->tid, tcon->ses->Suid, off, len, rc);
free_xid(xid);
@@ -3308,7 +3308,7 @@ static long smb3_simple_falloc(struct file *file, struct
cifs_tcon *tcon,
/*
* Extending the file
*/
- if ((keep_size == false) && i_size_read(inode) < off + len) {
+ if (!keep_size && i_size_read(inode) < off + len) {
rc = inode_newsize_ok(inode, off + len);
if (rc)
goto out;
@@ -3338,7 +3338,7 @@ static long smb3_simple_falloc(struct file *file, struct
cifs_tcon *tcon,
goto out;
}
- if ((keep_size == true) || (i_size_read(inode) >= off + len)) {
+ if (keep_size || (i_size_read(inode) >= off + len)) {
/*
* Check if falloc starts within first few pages of file
* and ends within a few pages of the end of file to
--
2.26.0.106.g9fadedd
Re: [PATCH net-next] net: stmmac: Remove unused variable 'ret' at stmmac_rx_buf1_len()
On 2020/9/11 3:29, Jakub Kicinski wrote:
On Thu, 10 Sep 2020 10:42:45 +0800 Luo Jiaxing wrote:
Fixes the following warning when using W=1 to build kernel:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3634:6: warning: variable
‘ret’ set but not used [-Wunused-but-set-variable]
int ret, coe = priv->hw->rx_csum;
When digging stmmac_get_rx_header_len(), dwmac4_get_rx_header_len() and
dwxgmac2_get_rx_header_len() return 0 by default. Therefore, ret do not
need to check the error value and can be directly deleted.
Signed-off-by: Luo Jiaxing
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 89b2b34..7e95412 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3631,15 +3631,15 @@ static unsigned int stmmac_rx_buf1_len(struct
stmmac_priv *priv,
struct dma_desc *p,
int status, unsigned int len)
{
- int ret, coe = priv->hw->rx_csum;
unsigned int plen = 0, hlen = 0;
+ int coe = priv->hw->rx_csum;
/* Not first descriptor, buffer is always zero */
if (priv->sph && len)
return 0;
/* First descriptor, get split header length */
- ret = stmmac_get_rx_header_len(priv, p, &hlen);
+ stmmac_get_rx_header_len(priv, p, &hlen);
This function should return void if there never are any errors to
report.
Yes, you are right. So, if we need to modify the function type , this
patch need to be drop.
And I will send a new patch later to redefine get_rx_header_len() to
void and delete ret there.
Please check "net: stmmac: set get_rx_header_len() as void for it didn't
have any error code to return" later.
Thanks
Jiaxing
if (priv->sph && hlen) {
priv->xstats.rx_split_hdr_pkt_n++;
return hlen;
.
Re: [PATCH v2] i2c: virtio: add a virtio i2c frontend driver
On 9/10/20 8:48 PM, Jie Deng wrote: > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 293e7a0..70c8e30 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -21,6 +21,17 @@ config I2C_ALI1535 > This driver can also be built as a module. If so, the module > will be called i2c-ali1535. > > +config I2C_VIRTIO > + tristate "Virtio I2C Adapter" > + depends on VIRTIO > + help > + If you say yes to this option, support will be included for the virtio > + i2c adapter driver. The hardware can be emulated by any device model I2C preferably > + software according to the virtio protocol. > + > + This driver can also be built as a module. If so, the module > + will be called i2c-virtio. > + > config I2C_ALI1563 > tristate "ALI 1563" > depends on PCI thanks. -- ~Randy
Re: [PATCH 2/3] mmc: sdhci-of-aspeed: Expose data sample phase delay tuning
On Fri, 11 Sep 2020, at 13:03, Joel Stanley wrote:
> On Fri, 11 Sep 2020 at 02:49, Andrew Jeffery wrote:
> >
> >
> >
> > On Fri, 11 Sep 2020, at 11:32, Joel Stanley wrote:
> > > On Thu, 10 Sep 2020 at 10:55, Andrew Jeffery wrote:
> > > >
> > > > Allow sample phase adjustment to deal with layout or tolerance issues.
> > > >
> > > > Signed-off-by: Andrew Jeffery
> > > > ---
> > > > drivers/mmc/host/sdhci-of-aspeed.c | 137 +++--
> > > > 1 file changed, 132 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
> > > > b/drivers/mmc/host/sdhci-of-aspeed.c
> > > > index 4f008ba3280e..641accbfcde4 100644
> > > > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > > > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
>
> > > > +static void
> > > > +aspeed_sdc_configure_phase(struct aspeed_sdc *sdc,
> > > > + const struct aspeed_sdhci_phase_desc *phase,
> > > > + uint8_t value, bool enable)
> > > > +{
> > > > + u32 reg;
> > > > +
> > > > + spin_lock(&sdc->lock);
> > >
> > > What is the lock protecting against?
> > >
> > > We call this in the ->probe, so there should be no concurrent access
> > > going on.
> >
> > Because the register is in the "global" part of the SD/MMC controller
> > address
> > space (it's not part of the SDHCI), and there are multiple slots that may
> > have
> > a driver probed concurrently.
>
> That points to having the property be part of the "global" device tree
> node.
Not really. The settings are slot-specific. The only reason it's in the global
register space is that the settings cannot be part of the SDHCI. That Aspeed
chose to pack them in the same register, and _interleaved_ at that, is
unfortunate.
As the settings are slot-specific they should be associated with each slot's
node. We should concentrate on representing the intent of the controls and
not tie the devicetree representation to the register layout that Aspeed came
up with.
> This would simplify the code; you wouldn't need the locking
> either.
IMO this is a loss for readability, so I'm not convinced it should be changed.
The outcome is some opaque register value that is shoved in the devicetree,
and given the baffling interleaving and choices of field sizes that's not a
place
I want to be.
>
> >
> > >
> > >
> > > > + reg = readl(sdc->regs + ASPEED_SDC_PHASE);
> > > > + reg &= ~phase->enable_mask;
> > > > + if (enable) {
> > > > + reg &= ~phase->value_mask;
> > > > + reg |= value << __ffs(phase->value_mask);
> > > > + reg |= phase->enable_value << __ffs(phase->enable_mask);
> > > > + }
> > > > + writel(reg, sdc->regs + ASPEED_SDC_PHASE);
> > > > + spin_unlock(&sdc->lock);
> > > > +}
> > > > +
> > > > static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned
> > > > int clock)
> > > > {
> > > > struct sdhci_pltfm_host *pltfm_host;
> > > > @@ -155,8 +195,58 @@ static inline int
> > > > aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
> > > > return (delta / 0x100) - 1;
> > > > }
> > > >
> > > > +static int aspeed_sdhci_configure_of(struct platform_device *pdev,
> > > > +struct aspeed_sdhci *sdhci)
> > > > +{
> > > > + u32 iphase, ophase;
> > > > + struct device_node *np;
> > > > + struct device *dev;
> > > > + int ret;
> > > > +
> > > > + if (!sdhci->phase)
> > > > + return 0;
> > > > +
> > > > + dev = &pdev->dev;
> > > > + np = dev->of_node;
> > > > +
> > > > + ret = of_property_read_u32(np, "aspeed,input-phase", &iphase);
> > > > + if (ret < 0) {
> > > > + aspeed_sdc_configure_phase(sdhci->parent,
> > > > &sdhci->phase->in, 0,
> > > > + false);
> > >
> > > Will this clear any value that eg. u-boot writes?
> >
> > No, see the 'enable' test in aspeed_sdc_configure_phase()
>
> OK, so this branch will never cause any change in the register? Best
> to drop it then.
So there are two parts to the phase configuration, the phase adjustment
value, and a switch to turn phase adjustment on or off. Both fields exist
for both in and out phase adjustments for both slots.
So this branch will cause the phase control to be disabled, but it won't
change the phase value that was originally programmed. If we maintain
the original semantics it shouldn't be dropped.
However, below you suggest we maintain the configuration (both
enable and value state) in the absence of the property, so the code
needs to be reworked to uphold suggestion.
>
> >
> > >
> > > The register should be left alone if the kernel doesn't have a
> > > configuration of it's own, otherwise we may end up breaking an
> > > otherwise working system.
> >
> > Right, I can rework that.
>
Re: [External] Re: [PATCH v2] stackleak: Fix a race between stack erasing sysctl handlers
Ping guys. Thanks.
On Mon, Sep 7, 2020 at 9:53 PM Muchun Song wrote:
>
> On Mon, Sep 7, 2020 at 7:24 PM Alexander Popov wrote:
> >
> > On 07.09.2020 05:54, Muchun Song wrote:
> > > Hi all,
> > >
> > > Any comments or suggestions? Thanks.
> > >
> > > On Fri, Aug 28, 2020 at 11:19 AM Muchun Song
> > > wrote:
> > >>
> > >> There is a race between the assignment of `table->data` and write value
> > >> to the pointer of `table->data` in the __do_proc_doulongvec_minmax() on
> > >> the other thread.
> > >>
> > >> CPU0: CPU1:
> > >> proc_sys_write
> > >> stack_erasing_sysctlproc_sys_call_handler
> > >> table->data = &state; stack_erasing_sysctl
> > >> table->data = &state;
> > >> proc_doulongvec_minmax
> > >> do_proc_doulongvec_minmax sysctl_head_finish
> > >> __do_proc_doulongvec_minmax unuse_table
> > >> i = table->data;
> > >> *i = val; // corrupt CPU1's stack
> >
> > Hello everyone!
> >
> > As I remember, I implemented stack_erasing_sysctl() very similar to other
> > sysctl
> > handlers. Is that issue relevant for other handlers as well?
>
> Yeah, it's very similar. But the difference is that others use a
> global variable as the
> `table->data`, but here we use a local variable as the `table->data`.
> The local variable
> is allocated from the stack. So other thread could corrupt the stack
> like the diagram
> above.
>
> >
> > Muchun, could you elaborate how CPU1's stack is corrupted and how you
> > detected
> > that? Thanks!
>
> Why did I find this problem? Because I solve another problem which is
> very similar to
> this issue. You can reference the following fix patch. Thanks.
>
> https://lkml.org/lkml/2020/8/22/105
>
>
>
>
> >
> > Best regards,
> > Alexander
> >
> > >> Fix this by duplicating the `table`, and only update the duplicate of
> > >> it.
> > >>
> > >> Fixes: 964c9dff0091 ("stackleak: Allow runtime disabling of kernel stack
> > >> erasing")
> > >> Signed-off-by: Muchun Song
> > >> ---
> > >> changelogs in v2:
> > >> 1. Add more details about how the race happened to the commit message.
> > >>
> > >> kernel/stackleak.c | 11 ---
> > >> 1 file changed, 8 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> > >> index a8fc9ae1d03d..fd95b87478ff 100644
> > >> --- a/kernel/stackleak.c
> > >> +++ b/kernel/stackleak.c
> > >> @@ -25,10 +25,15 @@ int stack_erasing_sysctl(struct ctl_table *table,
> > >> int write,
> > >> int ret = 0;
> > >> int state = !static_branch_unlikely(&stack_erasing_bypass);
> > >> int prev_state = state;
> > >> + struct ctl_table dup_table = *table;
> > >>
> > >> - table->data = &state;
> > >> - table->maxlen = sizeof(int);
> > >> - ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > >> + /*
> > >> +* In order to avoid races with __do_proc_doulongvec_minmax(), we
> > >> +* can duplicate the @table and alter the duplicate of it.
> > >> +*/
> > >> + dup_table.data = &state;
> > >> + dup_table.maxlen = sizeof(int);
> > >> + ret = proc_dointvec_minmax(&dup_table, write, buffer, lenp,
> > >> ppos);
> > >> state = !!state;
> > >> if (ret || !write || state == prev_state)
> > >> return ret;
> > >> --
> > >> 2.11.0
> > >>
> > >
> > >
> >
>
>
> --
> Yours,
> Muchun
--
Yours,
Muchun
