* [PATCH V4 2/8] dt-bindings: stm32-dwmac: add support of MPU families
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>
Add description for Ethernet MPU families fields
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/net/stm32-dwmac.txt | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
index 489dbcb..1341012 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -6,14 +6,28 @@ Please see stmmac.txt for the other unchanged properties.
The device node has following properties.
Required properties:
-- compatible: Should be "st,stm32-dwmac" to select glue, and
+- compatible: For MCU family should be "st,stm32-dwmac" to select glue, and
"snps,dwmac-3.50a" to select IP version.
+ For MPU family should be "st,stm32mp1-dwmac" to select
+ glue, and "snps,dwmac-4.20a" to select IP version.
- clocks: Must contain a phandle for each entry in clock-names.
- clock-names: Should be "stmmaceth" for the host clock.
Should be "mac-clk-tx" for the MAC TX clock.
Should be "mac-clk-rx" for the MAC RX clock.
+ For MPU family need to add also "ethstp" for power mode clock and,
+ "syscfg-clk" for SYSCFG clock.
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Should be "macirq" for the main MAC IRQ
+ Should be "eth_wake_irq" for the IT which wake up system
- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
- encompases the glue register, and the offset of the control register.
+ encompases the glue register, and the offset of the control register.
+
+Optional properties:
+- clock-names: For MPU family "mac-clk-ck" for PHY without quartz
+- st,int-phyclk (boolean) : valid only where PHY do not have quartz and need to be clock
+ by RCC
+
Example:
ethernet at 40028000 {
--
1.9.1
^ permalink raw reply related
* [PATCH V4 1/8] net: ethernet: stmmac: add adaptation for stm32mp157c.
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>
Glue codes to support stm32mp157c device and stay
compatible with stm32 mcu family
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 270 ++++++++++++++++++++--
1 file changed, 255 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 9e6db16..f51e327 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -16,49 +16,183 @@
#include <linux/of_net.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/stmmac.h>
#include "stmmac_platform.h"
-#define MII_PHY_SEL_MASK BIT(23)
+#define SYSCFG_MCU_ETH_MASK BIT(23)
+#define SYSCFG_MP1_ETH_MASK GENMASK(23, 16)
+
+#define SYSCFG_PMCR_ETH_CLK_SEL BIT(16)
+#define SYSCFG_PMCR_ETH_REF_CLK_SEL BIT(17)
+#define SYSCFG_PMCR_ETH_SEL_MII BIT(20)
+#define SYSCFG_PMCR_ETH_SEL_RGMII BIT(21)
+#define SYSCFG_PMCR_ETH_SEL_RMII BIT(23)
+#define SYSCFG_PMCR_ETH_SEL_GMII 0
+#define SYSCFG_MCU_ETH_SEL_MII 0
+#define SYSCFG_MCU_ETH_SEL_RMII 1
struct stm32_dwmac {
struct clk *clk_tx;
struct clk *clk_rx;
+ struct clk *clk_eth_ck;
+ struct clk *clk_ethstp;
+ struct clk *syscfg_clk;
+ bool int_phyclk; /* Clock from RCC to drive PHY */
u32 mode_reg; /* MAC glue-logic mode register */
struct regmap *regmap;
u32 speed;
+ const struct stm32_ops *ops;
+ struct device *dev;
+};
+
+struct stm32_ops {
+ int (*set_mode)(struct plat_stmmacenet_data *plat_dat);
+ int (*clk_prepare)(struct stm32_dwmac *dwmac, bool prepare);
+ int (*suspend)(struct stm32_dwmac *dwmac);
+ void (*resume)(struct stm32_dwmac *dwmac);
+ int (*parse_data)(struct stm32_dwmac *dwmac,
+ struct device *dev);
+ u32 syscfg_eth_mask;
};
static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
{
struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
- u32 reg = dwmac->mode_reg;
- u32 val;
int ret;
- val = (plat_dat->interface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
- ret = regmap_update_bits(dwmac->regmap, reg, MII_PHY_SEL_MASK, val);
- if (ret)
- return ret;
+ if (dwmac->ops->set_mode) {
+ ret = dwmac->ops->set_mode(plat_dat);
+ if (ret)
+ return ret;
+ }
ret = clk_prepare_enable(dwmac->clk_tx);
if (ret)
return ret;
- ret = clk_prepare_enable(dwmac->clk_rx);
- if (ret)
- clk_disable_unprepare(dwmac->clk_tx);
+ if (!dwmac->dev->power.is_suspended) {
+ ret = clk_prepare_enable(dwmac->clk_rx);
+ if (ret) {
+ clk_disable_unprepare(dwmac->clk_tx);
+ return ret;
+ }
+ }
+
+ if (dwmac->ops->clk_prepare) {
+ ret = dwmac->ops->clk_prepare(dwmac, true);
+ if (ret) {
+ clk_disable_unprepare(dwmac->clk_rx);
+ clk_disable_unprepare(dwmac->clk_tx);
+ }
+ }
return ret;
}
+static int stm32mp1_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
+{
+ int ret = 0;
+
+ if (prepare) {
+ ret = clk_prepare_enable(dwmac->syscfg_clk);
+ if (ret)
+ return ret;
+
+ if (dwmac->int_phyclk) {
+ ret = clk_prepare_enable(dwmac->clk_eth_ck);
+ if (ret) {
+ clk_disable_unprepare(dwmac->syscfg_clk);
+ return ret;
+ }
+ }
+ } else {
+ clk_disable_unprepare(dwmac->syscfg_clk);
+ if (dwmac->int_phyclk)
+ clk_disable_unprepare(dwmac->clk_eth_ck);
+ }
+ return ret;
+}
+
+static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
+{
+ struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
+ u32 reg = dwmac->mode_reg;
+ int val;
+
+ switch (plat_dat->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ val = SYSCFG_PMCR_ETH_SEL_MII;
+ pr_debug("SYSCFG init : PHY_INTERFACE_MODE_MII\n");
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ val = SYSCFG_PMCR_ETH_SEL_GMII;
+ if (dwmac->int_phyclk)
+ val |= SYSCFG_PMCR_ETH_CLK_SEL;
+ pr_debug("SYSCFG init : PHY_INTERFACE_MODE_GMII\n");
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ val = SYSCFG_PMCR_ETH_SEL_RMII;
+ if (dwmac->int_phyclk)
+ val |= SYSCFG_PMCR_ETH_REF_CLK_SEL;
+ pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ val = SYSCFG_PMCR_ETH_SEL_RGMII;
+ if (dwmac->int_phyclk)
+ val |= SYSCFG_PMCR_ETH_CLK_SEL;
+ pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RGMII\n");
+ break;
+ default:
+ pr_debug("SYSCFG init : Do not manage %d interface\n",
+ plat_dat->interface);
+ /* Do not manage others interfaces */
+ return -EINVAL;
+ }
+
+ return regmap_update_bits(dwmac->regmap, reg,
+ dwmac->ops->syscfg_eth_mask, val);
+}
+
+static int stm32mcu_set_mode(struct plat_stmmacenet_data *plat_dat)
+{
+ struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
+ u32 reg = dwmac->mode_reg;
+ int val;
+
+ switch (plat_dat->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ val = SYSCFG_MCU_ETH_SEL_MII;
+ pr_debug("SYSCFG init : PHY_INTERFACE_MODE_MII\n");
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ val = SYSCFG_MCU_ETH_SEL_RMII;
+ pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
+ break;
+ default:
+ pr_debug("SYSCFG init : Do not manage %d interface\n",
+ plat_dat->interface);
+ /* Do not manage others interfaces */
+ return -EINVAL;
+ }
+
+ return regmap_update_bits(dwmac->regmap, reg,
+ dwmac->ops->syscfg_eth_mask, val);
+}
+
static void stm32_dwmac_clk_disable(struct stm32_dwmac *dwmac)
{
clk_disable_unprepare(dwmac->clk_tx);
clk_disable_unprepare(dwmac->clk_rx);
+
+ if (dwmac->ops->clk_prepare)
+ dwmac->ops->clk_prepare(dwmac, false);
}
static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
@@ -70,15 +204,22 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
/* Get TX/RX clocks */
dwmac->clk_tx = devm_clk_get(dev, "mac-clk-tx");
if (IS_ERR(dwmac->clk_tx)) {
- dev_err(dev, "No tx clock provided...\n");
+ dev_err(dev, "No ETH Tx clock provided...\n");
return PTR_ERR(dwmac->clk_tx);
}
+
dwmac->clk_rx = devm_clk_get(dev, "mac-clk-rx");
if (IS_ERR(dwmac->clk_rx)) {
- dev_err(dev, "No rx clock provided...\n");
+ dev_err(dev, "No ETH Rx clock provided...\n");
return PTR_ERR(dwmac->clk_rx);
}
+ if (dwmac->ops->parse_data) {
+ err = dwmac->ops->parse_data(dwmac, dev);
+ if (err)
+ return err;
+ }
+
/* Get mode register */
dwmac->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
if (IS_ERR(dwmac->regmap))
@@ -91,11 +232,46 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
return err;
}
+static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
+ struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+
+ dwmac->int_phyclk = of_property_read_bool(np, "st,int-phyclk");
+
+ /* Check if internal clk from RCC selected */
+ if (dwmac->int_phyclk) {
+ /* Get ETH_CLK clocks */
+ dwmac->clk_eth_ck = devm_clk_get(dev, "eth-ck");
+ if (IS_ERR(dwmac->clk_eth_ck)) {
+ dev_err(dev, "No ETH CK clock provided...\n");
+ return PTR_ERR(dwmac->clk_eth_ck);
+ }
+ }
+
+ /* Clock used for low power mode */
+ dwmac->clk_ethstp = devm_clk_get(dev, "ethstp");
+ if (IS_ERR(dwmac->clk_ethstp)) {
+ dev_err(dev, "No ETH peripheral clock provided for CStop mode ...\n");
+ return PTR_ERR(dwmac->clk_ethstp);
+ }
+
+ /* Clock for sysconfig */
+ dwmac->syscfg_clk = devm_clk_get(dev, "syscfg-clk");
+ if (IS_ERR(dwmac->syscfg_clk)) {
+ dev_err(dev, "No syscfg clock provided...\n");
+ return PTR_ERR(dwmac->syscfg_clk);
+ }
+
+ return 0;
+}
+
static int stm32_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
struct stm32_dwmac *dwmac;
+ const struct stm32_ops *data;
int ret;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
@@ -112,6 +288,16 @@ static int stm32_dwmac_probe(struct platform_device *pdev)
goto err_remove_config_dt;
}
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data) {
+ dev_err(&pdev->dev, "no of match data provided\n");
+ ret = -EINVAL;
+ goto err_remove_config_dt;
+ }
+
+ dwmac->ops = data;
+ dwmac->dev = &pdev->dev;
+
ret = stm32_dwmac_parse_data(dwmac, &pdev->dev);
if (ret) {
dev_err(&pdev->dev, "Unable to parse OF data\n");
@@ -149,15 +335,48 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
return ret;
}
+static int stm32mp1_suspend(struct stm32_dwmac *dwmac)
+{
+ int ret = 0;
+
+ ret = clk_prepare_enable(dwmac->clk_ethstp);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(dwmac->clk_tx);
+ clk_disable_unprepare(dwmac->syscfg_clk);
+ if (dwmac->int_phyclk)
+ clk_disable_unprepare(dwmac->clk_eth_ck);
+
+ return ret;
+}
+
+static void stm32mp1_resume(struct stm32_dwmac *dwmac)
+{
+ clk_disable_unprepare(dwmac->clk_ethstp);
+}
+
+static int stm32mcu_suspend(struct stm32_dwmac *dwmac)
+{
+ clk_disable_unprepare(dwmac->clk_tx);
+ clk_disable_unprepare(dwmac->clk_rx);
+
+ return 0;
+}
+
#ifdef CONFIG_PM_SLEEP
static int stm32_dwmac_suspend(struct device *dev)
{
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
+ struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
+
int ret;
ret = stmmac_suspend(dev);
- stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+
+ if (dwmac->ops->suspend)
+ ret = dwmac->ops->suspend(dwmac);
return ret;
}
@@ -166,8 +385,12 @@ static int stm32_dwmac_resume(struct device *dev)
{
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
+ struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
int ret;
+ if (dwmac->ops->resume)
+ dwmac->ops->resume(dwmac);
+
ret = stm32_dwmac_init(priv->plat);
if (ret)
return ret;
@@ -181,8 +404,24 @@ static int stm32_dwmac_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
stm32_dwmac_suspend, stm32_dwmac_resume);
+static struct stm32_ops stm32mcu_dwmac_data = {
+ .set_mode = stm32mcu_set_mode,
+ .suspend = stm32mcu_suspend,
+ .syscfg_eth_mask = SYSCFG_MCU_ETH_MASK
+};
+
+static struct stm32_ops stm32mp1_dwmac_data = {
+ .set_mode = stm32mp1_set_mode,
+ .clk_prepare = stm32mp1_clk_prepare,
+ .suspend = stm32mp1_suspend,
+ .resume = stm32mp1_resume,
+ .parse_data = stm32mp1_parse_data,
+ .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK
+};
+
static const struct of_device_id stm32_dwmac_match[] = {
- { .compatible = "st,stm32-dwmac"},
+ { .compatible = "st,stm32-dwmac", .data = &stm32mcu_dwmac_data},
+ { .compatible = "st,stm32mp1-dwmac", .data = &stm32mp1_dwmac_data},
{ }
};
MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
@@ -199,5 +438,6 @@ static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
module_platform_driver(stm32_dwmac_driver);
MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue@gmail.com>");
-MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
+MODULE_AUTHOR("Christophe Roullier <christophe.roullier@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 DWMAC Specific Glue layer");
MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH V4 0/8] net: ethernet: stmmac: add support for stm32mp1
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
To: linux-arm-kernel
Patches to have Ethernet support on stm32mp1
Changelog:
Remark from Rob Herring
Move Documentation/devicetree/bindings/arm/stm32.txt in
Documentation/devicetree/bindings/arm/stm32/stm32.txt and create
Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
Replace also in arch/arm/boot/dts/stm32mp157c.dtsi, syscfg: system-config at 50020000
with syscfg: syscon at 50020000syscfg: system-config at 50020000
Christophe Roullier (8):
net: ethernet: stmmac: add adaptation for stm32mp157c.
dt-bindings: stm32-dwmac: add support of MPU families
ARM: dts: stm32: add ethernet pins to stm32mp157c
ARM: dts: stm32: Add syscfg on stm32mp1
ARM: dts: stm32: Add ethernet dwmac on stm32mp1
net: stmmac: add dwmac-4.20a compatible
ARM: dts: stm32: add support of ethernet on stm32mp157c-ev1
dt-bindings: stm32: add compatible for syscon
Documentation/devicetree/bindings/arm/stm32.txt | 10 -
.../devicetree/bindings/arm/stm32/stm32-syscon.txt | 14 ++
.../devicetree/bindings/arm/stm32/stm32.txt | 10 +
.../devicetree/bindings/net/stm32-dwmac.txt | 18 +-
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 46 ++++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 20 ++
arch/arm/boot/dts/stm32mp157c.dtsi | 35 +++
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 270 +++++++++++++++++++--
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +-
9 files changed, 398 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt
--
1.9.1
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-23 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=XfPkpGD32MfTfcw02wQ+QetpUhY=P299uhpX6pY_iEvg@mail.gmail.com>
On Wed, May 23, 2018 at 08:23:22AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
>
> > It's arguable either way - you could say that the client gets to specify
> > a safe range at all times or you could say that the machine constraints
> > should cover all cases where the hardware is idling. Of course RPMh
> > is missing anything like the machine constraints (as we can see from all
> > the fixing up of undesirable hard coding we have to do) so it's kind of
> > pushed towards the first case.
> OK, fair enough. If others all agree that it's OK to make requests
> about the voltage of a disabled regulator then I won't stand in the
> way. I guess it does call into question the whole idea of caching /
> not sending the voltage until the first enable because it means
> there's no way for the client to use this feature until they've
> enabled / disabled the regulator once. If you think of it as invalid
> to adjust the voltage of a disabled regulator then the caching
> argument is super clean, but once you say that you should normally be
It's got to be valid to think about the voltage of a disabled regulator
since drivers want to be able make sure that the regulator gets enabled
with a sensible config. With most hardware this is really easy since
you can just look at the status reported by the hardware but the RPM
makes this hard since there's so much write only stuff in there.
> able to do it it feels more like a hacky workaround. ...but I suppose
> that's what we've got to live with...
These RPM systems are always going to have problems of some kind
unfortunately unless the interface changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180523/9671d53b/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-23 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523082908.GB4828@sirena.org.uk>
Hi,
On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
> It's arguable either way - you could say that the client gets to specify
> a safe range at all times or you could say that the machine constraints
> should cover all cases where the hardware is idling. Of course RPMh
> is missing anything like the machine constraints (as we can see from all
> the fixing up of undesirable hard coding we have to do) so it's kind of
> pushed towards the first case.
OK, fair enough. If others all agree that it's OK to make requests
about the voltage of a disabled regulator then I won't stand in the
way. I guess it does call into question the whole idea of caching /
not sending the voltage until the first enable because it means
there's no way for the client to use this feature until they've
enabled / disabled the regulator once. If you think of it as invalid
to adjust the voltage of a disabled regulator then the caching
argument is super clean, but once you say that you should normally be
able to do it it feels more like a hacky workaround. ...but I suppose
that's what we've got to live with...
-Doug
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Heiko Stübner @ 2018-05-23 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+_QEBWdxW=J4oVGWeokc-+nMzxzX_pgCayaxg-ehivfQ@mail.gmail.com>
Hi Rob, Levin,
sorry for being late to the party.
Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
> > On 2018-05-23 2:02 AM, Rob Herring wrote:
> >> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
> >>> From: Levin Du <djw@t-chip.com.cn>
> >>>
> >>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> >>> which do not belong to the general pinctrl.
> >>>
> >>> Adding gpio-syscon support makes controlling regulator or
> >>> LED using these special pins very easy by reusing existing
> >>> drivers, such as gpio-regulator and led-gpio.
> >>>
> >>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
> >>>
> >>> ---
> >>>
> >>> Changes in v2:
> >>> - Rename gpio_syscon10 to gpio_mute in doc
> >>>
> >>> Changes in v1:
> >>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> >>> - Add doc rockchip,gpio-syscon.txt
> >>>
> >>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
> >>>
> >>> ++++++++++++++++++++++
> >>>
> >>> drivers/gpio/gpio-syscon.c | 30
> >>>
> >>> ++++++++++++++++
> >>>
> >>> 2 files changed, 71 insertions(+)
> >>> create mode 100644
> >>>
> >>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>> new file mode 100644
> >>> index 0000000..b1b2a67
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>> @@ -0,0 +1,41 @@
> >>> +* Rockchip GPIO support for GRF_SOC_CON registers
> >>> +
> >>> +Required properties:
> >>> +- compatible: Should contain "rockchip,gpio-syscon".
> >>> +- gpio-controller: Marks the device node as a gpio controller.
> >>> +- #gpio-cells: Should be two. The first cell is the pin number and
> >>> + the second cell is used to specify the gpio polarity:
> >>> + 0 = Active high,
> >>> + 1 = Active low.
> >>
> >> There's no need for this child node. Just make the parent node a gpio
> >> controller.
> >>
> >> Rob
> >
> > Hi Rob, it is not clear to me. Do you suggest that the grf node should be
> > a
> > gpio controller,
> > like below?
> >
> > + grf: syscon at ff100000 {
> > + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
> > "syscon", "simple-mfd";
>
> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
I would disagree quite a bit here. The grf are the "general register files",
a bunch of registers used for quite a lot of things, and so it seems
among other users, also a gpio-controller for some more random pins
not controlled through the regular gpio controllers.
For a more fully stocked grf, please see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
So the gpio controller should definitly also be a subnode.
The gpio in question is called "mute", so I'd think the gpio-syscon driver
should just define a "rockchip,rk3328-gpio-mute" compatible and contain
all the register voodoo in the driver itself and not define it in the dt.
So it should probably look like
grf: syscon at ff100000 {
compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
[all the other syscon sub-devices]
gpio_mute: gpio-mute {
compatible = "rockchip,rk3328-gpio-mute";
gpio-controller;
#gpio-cells = <2>;
};
[more other syscon sub-devices]
};
Heiko
> > + //...
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + gpio,syscon-dev = <&grf 0x0428 0>;
>
> And drop this. It may be used in the kernel, but it is not a
> documented property.
>
> > + };
> >
> > or just reserve the following case in the doc?
> >
> > + grf: syscon at ff100000 {
> > + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> > + //...
> > + };
> > +
> > + gpio_mute: gpio-mute {
> > + compatible = "rockchip,gpio-syscon";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + gpio,syscon-dev = <&grf 0x0428 0>;
> > + };
> >
> >
> > Thanks
> > Levin
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v10 07/18] arm64: fpsimd: Eliminate task->mm checks
From: Dave Martin @ 2018-05-23 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523145657.g7b6v2q2vxfqpoc4@armageddon.cambridge.arm.com>
On Wed, May 23, 2018 at 03:56:57PM +0100, Catalin Marinas wrote:
> On Wed, May 23, 2018 at 02:31:59PM +0100, Dave P Martin wrote:
> > On Wed, May 23, 2018 at 01:48:12PM +0200, Christoffer Dall wrote:
> > > On Tue, May 22, 2018 at 05:05:08PM +0100, Dave Martin wrote:
> > > > This is true by construction however: TIF_FOREIGN_FPSTATE is never
> > > > cleared except when returning to userspace or returning from a
> > > > signal: thus, for a true kernel thread no FPSIMD context is ever
> > > > loaded, TIF_FOREIGN_FPSTATE will remain set and no context will
> > > > ever be saved.
> > >
> > > I don't understand this construction proof; from looking at the patch
> > > below it is not obvious to me why fpsimd_thread_switch() can never have
> > > !wrong_task && !wrong_cpu and therefore clear TIF_FOREIGN_FPSTATE for a
> > > kernel thread?
> >
> > Looking at this again, I think it is poorly worded. This patch aims to
> > make it true by construction, but it isn't prior to the patch.
> >
> > I'm tempted to delete the paragraph: the assertion of both untrue and
> > not the best way to justify that this patch works.
> >
> >
> > How about:
> >
> > -8<-
> >
> > The context switch logic already isolates user threads from each other.
> > This, it is sufficient for isolating user threads from the kernel,
> > since the goal either way is to ensure that code executing in userspace
> > cannot see any FPSIMD state except its own. Thus, there is no special
> > property of kernel threads that we care about except that it is
> > pointless to save or load FPSIMD register state for them.
> >
> > At worst, the removal of all the kernel thread special cases by this
> > patch would thus spuriously load and save state for kernel threads when
> > unnecessary.
> >
> > But the context switch logic is already deliberately optimised to defer
> > reloads of the regs until ret_to_user (or sigreturn as a special case),
> > which kernel threads by definition never reach.
> >
> > ->8-
>
> The "at worst" paragraph makes it look like it could happen (at least
> until you reach the last paragraph). Maybe you can just say that
> wrong_task and wrong_cpu (with the fpsimd_cpu = NR_CPUS addition) are
> always true for kernel threads. You should probably mention this in a
> comment in the code as well.
What if I just delete the second paragraph, and remove the "But" from
the start of the third, and append:
"As a result, the wrong_task and wrong_cpu tests in
fpsimd_thread_switch() will always yield false for kernel threads."
...with a similar comment in the code?
Cheers
---Dave
^ permalink raw reply
* [PATCH v10 14/18] KVM: arm64: Save host SVE context as appropriate
From: Catalin Marinas @ 2018-05-23 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-15-git-send-email-Dave.Martin@arm.com>
On Tue, May 22, 2018 at 05:05:15PM +0100, Dave P Martin wrote:
> This patch adds SVE context saving to the hyp FPSIMD context switch
> path. This means that it is no longer necessary to save the host
> SVE state in advance of entering the guest, when in use.
>
> In order to avoid adding pointless complexity to the code, VHE is
> assumed if SVE is in use. VHE is an architectural prerequisite for
> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> kernels that support both SVE and KVM.
>
> Historically, software models exist that can expose the
> architecturally invalid configuration of SVE without VHE, so if
> this situation is detected at kvm_init() time then KVM will be
> disabled.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v10 07/18] arm64: fpsimd: Eliminate task->mm checks
From: Catalin Marinas @ 2018-05-23 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523133158.GJ13470@e103592.cambridge.arm.com>
On Wed, May 23, 2018 at 02:31:59PM +0100, Dave P Martin wrote:
> On Wed, May 23, 2018 at 01:48:12PM +0200, Christoffer Dall wrote:
> > On Tue, May 22, 2018 at 05:05:08PM +0100, Dave Martin wrote:
> > > This is true by construction however: TIF_FOREIGN_FPSTATE is never
> > > cleared except when returning to userspace or returning from a
> > > signal: thus, for a true kernel thread no FPSIMD context is ever
> > > loaded, TIF_FOREIGN_FPSTATE will remain set and no context will
> > > ever be saved.
> >
> > I don't understand this construction proof; from looking at the patch
> > below it is not obvious to me why fpsimd_thread_switch() can never have
> > !wrong_task && !wrong_cpu and therefore clear TIF_FOREIGN_FPSTATE for a
> > kernel thread?
>
> Looking at this again, I think it is poorly worded. This patch aims to
> make it true by construction, but it isn't prior to the patch.
>
> I'm tempted to delete the paragraph: the assertion of both untrue and
> not the best way to justify that this patch works.
>
>
> How about:
>
> -8<-
>
> The context switch logic already isolates user threads from each other.
> This, it is sufficient for isolating user threads from the kernel,
> since the goal either way is to ensure that code executing in userspace
> cannot see any FPSIMD state except its own. Thus, there is no special
> property of kernel threads that we care about except that it is
> pointless to save or load FPSIMD register state for them.
>
> At worst, the removal of all the kernel thread special cases by this
> patch would thus spuriously load and save state for kernel threads when
> unnecessary.
>
> But the context switch logic is already deliberately optimised to defer
> reloads of the regs until ret_to_user (or sigreturn as a special case),
> which kernel threads by definition never reach.
>
> ->8-
The "at worst" paragraph makes it look like it could happen (at least
until you reach the last paragraph). Maybe you can just say that
wrong_task and wrong_cpu (with the fpsimd_cpu = NR_CPUS addition) are
always true for kernel threads. You should probably mention this in a
comment in the code as well.
--
Catalin
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Dave Martin @ 2018-05-23 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523143156.svl7djkm3obrnkvs@linutronix.de>
On Wed, May 23, 2018 at 04:31:56PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-17 19:19:43 [+0100], Dave Martin wrote:
> > On Thu, May 17, 2018 at 02:40:06PM +0200, Sebastian Andrzej Siewior wrote:
> > > In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
> > > code disables BH and expects that it is not preemptible. On -RT the
> > > task remains preemptible but remains the same CPU. This may corrupt the
> >
> > Also, watch out for [1] which adds more of this stuff for KVM. This
> > not merged yet, but likely to land in v4.18.
>
> yay. I will try to keep this in mind while moving forward.
>
> > Anyway:
> >
> > What we're really trying to achieve with the local_bh_disable/enable
> > stuff is exclusive access to the CPU FPSIMD registers and associated
> > metadata that tracks who they belong to.
>
> I assumed this.
Yup, it's a common pattern cross-arch.
> > > The preempt_disable() + local_bh_enable() combo in kernel_neon_begin()
> > > is not working on -RT. We don't use NEON in kernel mode on RT right now
> > > but this still should be addressed.
> >
> > I think we effectively have two levels of locking here.
> >
> > At the outer level, we want exclusive access to the FPSIMD registers.
> > This is what is needed between kernel_neon_begin() and
> > kernel_neon_end(), and maps onto the preempt_disable()/_enable() done
> > by these functions.
> >
> > In context switch critical code, that's insufficient, and we also
> > need exclusive access to the metadata that tracks which task or context
> > owns the FPSIMD registers. This is what the local_bh_disable()/
> > _enable() achieves.
> >
> >
> > So does it make sense to have two locks (I'm assuming local locks are
> > implicitly percpu ?)
> >
> > static inline void local_fpsimd_context_lock(void)
> > {
> > local_bh_disable();
> > local_lock(fpsimd_lock);
> > local_lock(fpsimd_context_lock);
> > }
> >
> > static inline void local_fpsimd_context_unlock(void)
> > {
> > local_unlock(fpsimd_context_lock);
> > local_unlock(fpsimd_lock);
> > local_bh_enable();
> > }
> >
> >
> > kernel_neon_begin() could then do
> >
> > local_fpsimd_context_lock();
> >
> > /* ... */
> >
> > preempt_disable();
> > local_unlock(fpsimd_context_lock);
> >
> > ... with the following in kernel_neon_end():
> >
> > local_unlock(fpsimd_lock);
> > preempt_enable();
> >
> >
> > If kernel-mode NEON was considered harmful to RT due to the context
> > switch overheads, then the above might be overkill. SVE will be worse
> > in that regard, and also needs thinking about at some point -- I've not
> > looked at if from the RT angle at all.
> >
> > In either case, I think abstracting the lock/unlock sequences out to
> > make the purpose clearer may be a good idea, even if we just have a
> > single local lock to manage.
>
> So the two looks you suggested make sense. However I would need to
> replace this preempt_disable() with one such lock. A local_lock() on -RT
> is a per-CPU spin_lock. RT's local_lock gets currently transformed into
> preempt_disable() on !RT configs.
Thinking about this again, I'm guessing it only really makes sense to
have two local locks if there are two independent reasons to inhibit
migration.
There is only one such reason here: preempt_disable() for the purpose
of using the FPSIMD registers, where local_bh_disable() implies this
and also inhibits local softirqs -- which I'm guessing works just
the same with RT.
So maybe there should really be only one local lock as you suggest.
This gives:
static inline void local_fpsimd_context_lock(void)
{
local_lock(fpsimd_lock);
local_bh_disable();
}
static inline void local_fpsimd_context_unlock(void)
{
local_bh_enable();
local_unlock(fpsimd_lock);
}
kernel_neon_begin(...)
{
local_lock(fpsimd_lock);
local_bh_disable();
/* ... */
local_bh_enable();
}
kernel_neon_end(...)
{
/* ... */
local_unlock(fpsimd_lock);
}
If the local_{,un}lock() gets transmuted to preempt_{dis,en}enable()
for !RT, then this seems to map on to what we currently have.
(Still guessing about how RT works here, so a health warning is
implied.)
If you abstract things this way, can you please split the non-RT changes
into a separate patch and Cc me? That would be a nice cleanup for
mainline rather than just having the bare local_bh_ and preempt_ stuff
everywhere.
>
> > There is one place where I mess with the FPSIMD context no lock held
> > because of a need to copy_from_user() straight into the context backing
> > store (we can't copy_from_user() with preemption disabled...)
> > I'm not sure whether RT will have any impact on this, but it probably
> > needs thinking about.
>
> if no locks are held and the task can be preempted then it also might
> happen on PREEMPT config. But copy_from_user() doesn't sounds like
> something that will go straight to HW.
We're just copying to memory, so I guess so long as program order is
respected when the task is migrated (which is ensured via heavy barriers
somewhere in the scheduler and/or arch context switch code IIRC) then I
think there should be no problem). This is a prerequisite for
preemptive migration to work at all, not just on RT. So I suppose
there's no new problem here.
>
> > One more comment below...
> >
> > >
> > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > > ---
> > > arch/arm64/kernel/fpsimd.c | 20 ++++++++++++++++++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > index e7226c4c7493..3a5cd1908874 100644
> > > --- a/arch/arm64/kernel/fpsimd.c
> > > +++ b/arch/arm64/kernel/fpsimd.c
> > > @@ -38,6 +38,7 @@
> > > #include <linux/signal.h>
> > > #include <linux/slab.h>
> > > #include <linux/sysctl.h>
> > > +#include <linux/locallock.h>
> > >
> > > #include <asm/fpsimd.h>
> > > #include <asm/cputype.h>
> > > @@ -235,7 +236,7 @@ static void sve_user_enable(void)
> > > * whether TIF_SVE is clear or set, since these are not vector length
> > > * dependent.
> > > */
> > > -
> > > +static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
> > > /*
> > > * Update current's FPSIMD/SVE registers from thread_struct.
> > > *
> > > @@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
> > > * non-SVE thread.
> > > */
> > > if (task == current) {
> > > + local_lock(fpsimd_lock);
> > > local_bh_disable();
> > >
> > > task_fpsimd_save();
> > > @@ -604,8 +606,10 @@ int sve_set_vector_length(struct task_struct *task,
> > > if (test_and_clear_tsk_thread_flag(task, TIF_SVE))
> > > sve_to_fpsimd(task);
> > >
> > > - if (task == current)
> > > + if (task == current) {
> > > + local_unlock(fpsimd_lock);
> >
> > Is this misordered against local_bh_enable(), or doesn't it matter?
>
> It actually is but it does not matter. On RT local_bh_disable() is
> turned into migrate_disable() what in turn disables the migration of the
> task to another CPU (while it is still preemtible). This
> migrate_disable() is also part of local_lock(). Maybe I will add a
> local_lock_bh() and replace this with this local_bh_disable() so it will
> better :)
Fair enough.
Cheers
---Dave
>
> > > local_bh_enable();
> > > + }
^ permalink raw reply
* [PATCH 0/4] arm64: SMCCC conduit cleanup
From: Will Deacon @ 2018-05-23 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503170330.5591-1-mark.rutland@arm.com>
On Thu, May 03, 2018 at 06:03:26PM +0100, Mark Rutland wrote:
> Currently, the cpu errata code goes digging into PSCI internals to
> discover the SMCCC conduit, using the (arguably misnamed) PSCI_CONDUIT_*
> definitions. This lack of abstraction is somewhat unfortunate.
>
> Further, the SDEI code has an almost identical set of CONDUIT_*
> definitions, and the duplication is rather unfortunate.
>
> Let's unify things behind a common set of SMCCC_CONDUIT_* definitions,
> and expose the SMCCCv1.1 conduit via a new helper that hides the PSCI
> driver internals.
For the series:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [rjarzmik:test/daniel 28/34] arch/arm/plat-pxa/ssp.c:130:23: error: 'info' undeclared; did you mean 'int'?
From: kbuild test robot @ 2018-05-23 14:47 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux test/daniel
head: f495e2dbc482d8f01a1ee20e86284ee9c0c8fa98
commit: 48623336c398bb2f751308c458b1a107e6c13a4a [28/34] ARM: plat-pxa: ssp: add default DMA names for DT
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 48623336c398bb2f751308c458b1a107e6c13a4a
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/plat-pxa/ssp.c: In function 'pxa_ssp_probe':
>> arch/arm/plat-pxa/ssp.c:130:23: error: 'info' undeclared (first use in this function); did you mean 'int'?
if (!dev->of_node && info) {
^~~~
int
arch/arm/plat-pxa/ssp.c:130:23: note: each undeclared identifier is reported only once for each function it appears in
>> arch/arm/plat-pxa/ssp.c:131:6: error: 'struct ssp_device' has no member named 'dma_chan_rx'
ssp->dma_chan_rx = info->dma_chan_rx_name;
^~
>> arch/arm/plat-pxa/ssp.c:132:6: error: 'struct ssp_device' has no member named 'dma_chan_tx'
ssp->dma_chan_tx = info->dma_chan_tx_name;
^~
arch/arm/plat-pxa/ssp.c:134:6: error: 'struct ssp_device' has no member named 'dma_chan_rx'
ssp->dma_chan_rx = "rx";
^~
arch/arm/plat-pxa/ssp.c:135:6: error: 'struct ssp_device' has no member named 'dma_chan_tx'
ssp->dma_chan_tx = "tx";
^~
vim +130 arch/arm/plat-pxa/ssp.c
113
114 static int pxa_ssp_probe(struct platform_device *pdev)
115 {
116 struct resource *res;
117 struct ssp_device *ssp;
118 struct device *dev = &pdev->dev;
119
120 ssp = devm_kzalloc(dev, sizeof(struct ssp_device), GFP_KERNEL);
121 if (ssp == NULL)
122 return -ENOMEM;
123
124 ssp->pdev = pdev;
125
126 ssp->clk = devm_clk_get(dev, NULL);
127 if (IS_ERR(ssp->clk))
128 return PTR_ERR(ssp->clk);
129
> 130 if (!dev->of_node && info) {
> 131 ssp->dma_chan_rx = info->dma_chan_rx_name;
> 132 ssp->dma_chan_tx = info->dma_chan_tx_name;
133 } else {
134 ssp->dma_chan_rx = "rx";
135 ssp->dma_chan_tx = "tx";
136 }
137
138 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
139 if (res == NULL) {
140 dev_err(dev, "no memory resource defined\n");
141 return -ENODEV;
142 }
143
144 res = devm_request_mem_region(dev, res->start, resource_size(res),
145 pdev->name);
146 if (res == NULL) {
147 dev_err(dev, "failed to request memory resource\n");
148 return -EBUSY;
149 }
150
151 ssp->phys_base = res->start;
152
153 ssp->mmio_base = devm_ioremap(dev, res->start, resource_size(res));
154 if (ssp->mmio_base == NULL) {
155 dev_err(dev, "failed to ioremap() registers\n");
156 return -ENODEV;
157 }
158
159 ssp->irq = platform_get_irq(pdev, 0);
160 if (ssp->irq < 0) {
161 dev_err(dev, "no IRQ resource defined\n");
162 return -ENODEV;
163 }
164
165 if (dev->of_node) {
166 const struct of_device_id *id =
167 of_match_device(of_match_ptr(pxa_ssp_of_ids), dev);
168 ssp->type = (int) id->data;
169 } else {
170 const struct platform_device_id *id =
171 platform_get_device_id(pdev);
172 ssp->type = (int) id->driver_data;
173
174 /* PXA2xx/3xx SSP ports starts from 1 and the internal pdev->id
175 * starts from 0, do a translation here
176 */
177 ssp->port_id = pdev->id + 1;
178 }
179
180 ssp->use_count = 0;
181 ssp->of_node = dev->of_node;
182
183 mutex_lock(&ssp_lock);
184 list_add(&ssp->node, &ssp_list);
185 mutex_unlock(&ssp_lock);
186
187 platform_set_drvdata(pdev, ssp);
188
189 return 0;
190 }
191
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 65234 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180523/feb1bdac/attachment-0001.gz>
^ permalink raw reply
* [PATCH V3 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-23 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4f6941a0-4b41-f2db-52b1-d45aa7287fa2@st.com>
On Wed, May 23, 2018 at 4:32 AM, Christophe ROULLIER
<christophe.roullier@st.com> wrote:
> On 05/22/2018 07:22 PM, Rob Herring wrote:
>> On Mon, May 21, 2018 at 10:07:26AM +0200, Christophe Roullier wrote:
>>> This patch describes syscon DT bindings.
>>>
>>> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/stm32.txt | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
>>> index 6808ed9..e46ebad 100644
>>> --- a/Documentation/devicetree/bindings/arm/stm32.txt
>>> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
>>> @@ -8,3 +8,8 @@ using one of the following compatible strings:
>>> st,stm32f746
>>> st,stm32h743
>>> st,stm32mp157
>>> +
>>> +Required nodes:
>>> +- syscon: the soc bus node must have a system controller node pointing to the
>>> + global control registers, with the compatible string
>>> + "st,stm32mp157-syscfg", "syscon";
>>
>> Please don't mix soc/board bindings with other nodes. So perhaps
>> stm32-syscon.txt.
>>
>> Rob
>>
>
> Hi Rob,
>
> Is it ok for you with this tree file:
Yes, one nit below.
>
> Documentation/devicetree/bindings/arm/stm32/stm32.txt
> Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
> With stm32-syscon.txt:
>
> ---------------------------------------------------
> STMicroelectronics STM32 Platforms System Controller
>
> Properties:
> - compatible : should contain two values. First value must be :
> - " st,stm32mp157-syscfg " - for stm32mp157 based SoCs,
> second value must be always "syscon".
> - reg : offset and length of the register set.
>
> Example:
> syscfg: system-config at 50020000 {
syscon at ...
> compatible = "st,stm32mp157-syscfg", "syscon";
> reg = <0x50020000 0x400>;
> };
> ---------------------------------------------------
>
> Do we need to update also all MCU family (stm32f4, stm32h7, stm32f7)
> property to be coherent ?
Yes, if they all have the same or similar syscfg block.
>
> Thanks for your feedback.
>
> Christophe.
>
^ permalink raw reply
* [PATCH v2 1/3] input: touchscreen: edt-ft5x06: don't make device a wakeup source by default
From: Rob Herring @ 2018-05-23 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52c1cd13-3386-8f70-aaf2-e5f4b19fd1e6@zonque.org>
On Wed, May 23, 2018 at 3:27 AM, Daniel Mack <daniel@zonque.org> wrote:
> On Tuesday, May 22, 2018 07:54 PM, Rob Herring wrote:
>>
>> On Thu, May 17, 2018 at 11:05:50AM +0200, Daniel Mack wrote:
>>>
>>> Allow configuring the device as wakeup source through device properties,
>>> as
>>> not all platforms want to wake up on touch screen activity.
>>>
>>> The I2C core automatically reads the "wakeup-source" DT property to
>>> configure a device's wakeup capability, and board supports files can set
>>> I2C_CLIENT_WAKE in the flags.
>>
>>
>> This will break wake-up on working systems. Looks like mostly i.MX, but
>> there's one AM437x board. If that board doesn't care, then it is up to
>> Shawn.
>
>
> I added the property to the dts files, but as Dmitry pointed out, I missed
> some. Sorry for that.
Just adding the property to dts files doesn't fix the compatibility
problem. If a user uses an existing dtb (before this change) with a
new kernel (after this change), then wakeup will stop working.
Rob
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Rob Herring @ 2018-05-23 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ffb43dc-55a5-14eb-eb18-3a731cdaf424@t-chip.com.cn>
On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>
>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>>>
>>> From: Levin Du <djw@t-chip.com.cn>
>>>
>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>> which do not belong to the general pinctrl.
>>>
>>> Adding gpio-syscon support makes controlling regulator or
>>> LED using these special pins very easy by reusing existing
>>> drivers, such as gpio-regulator and led-gpio.
>>>
>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>
>>> Changes in v1:
>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>> - Add doc rockchip,gpio-syscon.txt
>>>
>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>> ++++++++++++++++++++++
>>> drivers/gpio/gpio-syscon.c | 30
>>> ++++++++++++++++
>>> 2 files changed, 71 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>> new file mode 100644
>>> index 0000000..b1b2a67
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>> @@ -0,0 +1,41 @@
>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>> +
>>> +Required properties:
>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>> +- gpio-controller: Marks the device node as a gpio controller.
>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>> + the second cell is used to specify the gpio polarity:
>>> + 0 = Active high,
>>> + 1 = Active low.
>>
>> There's no need for this child node. Just make the parent node a gpio
>> controller.
>>
>> Rob
>
> Hi Rob, it is not clear to me. Do you suggest that the grf node should be a
> gpio controller,
> like below?
>
> + grf: syscon at ff100000 {
> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
> "syscon", "simple-mfd";
Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
> + //...
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <&grf 0x0428 0>;
And drop this. It may be used in the kernel, but it is not a
documented property.
> + };
>
> or just reserve the following case in the doc?
>
> + grf: syscon at ff100000 {
> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> + //...
> + };
> +
> + gpio_mute: gpio-mute {
> + compatible = "rockchip,gpio-syscon";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <&grf 0x0428 0>;
> + };
>
>
> Thanks
> Levin
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v10 04/18] KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
From: Dave Martin @ 2018-05-23 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87muwqtp8z.fsf@linaro.org>
On Wed, May 23, 2018 at 03:34:20PM +0100, Alex Benn?e wrote:
>
> Dave Martin <Dave.Martin@arm.com> writes:
>
> > From: Christoffer Dall <christoffer.dall@linaro.org>
> >
> > KVM/ARM differs from other architectures in having to maintain an
> > additional virtual address space from that of the host and the
> > guest, because we split the execution of KVM across both EL1 and
> > EL2.
> >
> > This results in a need to explicitly map data structures into EL2
> > (hyp) which are accessed from the hyp code. As we are about to be
> > more clever with our FPSIMD handling on arm64, which stores data in
> > the task struct and uses thread_info flags, we will have to map
> > parts of the currently executing task struct into the EL2 virtual
> > address space.
> >
> > However, we don't want to do this on every KVM_RUN, because it is a
> > fairly expensive operation to walk the page tables, and the common
> > execution mode is to map a single thread to a VCPU. By introducing
> > a hook that architectures can select with
> > HAVE_KVM_VCPU_RUN_PID_CHANGE, we do not introduce overhead for
> > other architectures, but have a simple way to only map the data we
> > need when required for arm64.
> >
> > This patch introduces the framework only, and wires it up in the
> > arm/arm64 KVM common code.
> >
> > No functional change.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> > include/linux/kvm_host.h | 9 +++++++++
> > virt/kvm/Kconfig | 3 +++
> > virt/kvm/kvm_main.c | 7 ++++++-
> > 3 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 6930c63..4268ace 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -1276,4 +1276,13 @@ static inline long kvm_arch_vcpu_async_ioctl(struct file *filp,
> > void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> > unsigned long start, unsigned long end);
> >
> > +#ifdef CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE
> > +int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu);
> > +#else
> > +static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > +{
> > + return 0;
> > +}
> > +#endif /* CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE */
> > +
> > #endif
> > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> > index cca7e06..72143cf 100644
> > --- a/virt/kvm/Kconfig
> > +++ b/virt/kvm/Kconfig
> > @@ -54,3 +54,6 @@ config HAVE_KVM_IRQ_BYPASS
> >
> > config HAVE_KVM_VCPU_ASYNC_IOCTL
> > bool
> > +
> > +config HAVE_KVM_VCPU_RUN_PID_CHANGE
> > + bool
>
> This almost threw me as I thought you might be able to enable this and
> break the build, but apparently not:
>
> Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
Without a "help", the option seems non-interactive and cannot be true
unless something selects it. It seems a bit weird to me too, but the
idiom appears widely used...
Christoffer?
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH v10 02/18] thread_info: Add update_thread_flag() helpers
From: Alex Bennée @ 2018-05-23 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523135732.GK13470@e103592.cambridge.arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> On Wed, May 23, 2018 at 02:46:52PM +0100, Alex Benn?e wrote:
>>
>> Dave Martin <Dave.Martin@arm.com> writes:
>>
>> > There are a number of bits of code sprinkled around the kernel to
>> > set a thread flag if a certain condition is true, and clear it
>> > otherwise.
>> >
>> > To help make those call sites terser and less cumbersome, this
>> > patch adds a new family of thread flag manipulators
>> >
>> > update*_thread_flag([...,] flag, cond)
>> >
>> > which do the equivalent of:
>> >
>> > if (cond)
>> > set*_thread_flag([...,] flag);
>> > else
>> > clear*_thread_flag([...,] flag);
>> >
>> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>> > Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>> > Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> > Cc: Ingo Molnar <mingo@redhat.com>
>> > Cc: Peter Zijlstra <peterz@infradead.org>
>> > Cc: Oleg Nesterov <oleg@redhat.com>
>> > ---
>> > include/linux/sched.h | 6 ++++++
>> > include/linux/thread_info.h | 11 +++++++++++
>> > 2 files changed, 17 insertions(+)
>> >
>
> [...]
>
>> > diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
>> > index cf2862b..8d8821b 100644
>> > --- a/include/linux/thread_info.h
>> > +++ b/include/linux/thread_info.h
>> > @@ -60,6 +60,15 @@ static inline void clear_ti_thread_flag(struct thread_info *ti, int flag)
>> > clear_bit(flag, (unsigned long *)&ti->flags);
>> > }
>> >
>> > +static inline void update_ti_thread_flag(struct thread_info *ti, int flag,
>> > + bool value)
>> > +{
>> > + if (value)
>> > + set_ti_thread_flag(ti, flag);
>> > + else
>> > + clear_ti_thread_flag(ti, flag);
>> > +}
>> > +
>>
>> value does seem a bit of vanilla non-informative name for a condition
>> flag but whatever:
>>
>> Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
>
> I guess, though I couldn't some up with an obviously better name.
>
> I support "condition" would have worked, but it's more verbose.
Well as you use cond in the text I think cond would also work as an
abbreviated variable name. But its a minor nit ;-)
>
> Thanks for the review
> ---Dave
--
Alex Benn?e
^ permalink raw reply
* [PATCH v10 04/18] KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
From: Alex Bennée @ 2018-05-23 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-5-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> KVM/ARM differs from other architectures in having to maintain an
> additional virtual address space from that of the host and the
> guest, because we split the execution of KVM across both EL1 and
> EL2.
>
> This results in a need to explicitly map data structures into EL2
> (hyp) which are accessed from the hyp code. As we are about to be
> more clever with our FPSIMD handling on arm64, which stores data in
> the task struct and uses thread_info flags, we will have to map
> parts of the currently executing task struct into the EL2 virtual
> address space.
>
> However, we don't want to do this on every KVM_RUN, because it is a
> fairly expensive operation to walk the page tables, and the common
> execution mode is to map a single thread to a VCPU. By introducing
> a hook that architectures can select with
> HAVE_KVM_VCPU_RUN_PID_CHANGE, we do not introduce overhead for
> other architectures, but have a simple way to only map the data we
> need when required for arm64.
>
> This patch introduces the framework only, and wires it up in the
> arm/arm64 KVM common code.
>
> No functional change.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> include/linux/kvm_host.h | 9 +++++++++
> virt/kvm/Kconfig | 3 +++
> virt/kvm/kvm_main.c | 7 ++++++-
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 6930c63..4268ace 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1276,4 +1276,13 @@ static inline long kvm_arch_vcpu_async_ioctl(struct file *filp,
> void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> unsigned long start, unsigned long end);
>
> +#ifdef CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE
> +int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu);
> +#else
> +static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE */
> +
> #endif
> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> index cca7e06..72143cf 100644
> --- a/virt/kvm/Kconfig
> +++ b/virt/kvm/Kconfig
> @@ -54,3 +54,6 @@ config HAVE_KVM_IRQ_BYPASS
>
> config HAVE_KVM_VCPU_ASYNC_IOCTL
> bool
> +
> +config HAVE_KVM_VCPU_RUN_PID_CHANGE
> + bool
This almost threw me as I thought you might be able to enable this and
break the build, but apparently not:
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index c7b2e92..c32e240 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2550,8 +2550,13 @@ static long kvm_vcpu_ioctl(struct file *filp,
> oldpid = rcu_access_pointer(vcpu->pid);
> if (unlikely(oldpid != current->pids[PIDTYPE_PID].pid)) {
> /* The thread running this VCPU changed. */
> - struct pid *newpid = get_task_pid(current, PIDTYPE_PID);
> + struct pid *newpid;
>
> + r = kvm_arch_vcpu_run_pid_change(vcpu);
> + if (r)
> + break;
> +
> + newpid = get_task_pid(current, PIDTYPE_PID);
> rcu_assign_pointer(vcpu->pid, newpid);
> if (oldpid)
> synchronize_rcu();
--
Alex Benn?e
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Sebastian Andrzej Siewior @ 2018-05-23 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518124605.GA13470@e103592.cambridge.arm.com>
On 2018-05-18 13:46:36 [+0100], Dave Martin wrote:
> On Thu, May 17, 2018 at 07:19:43PM +0100, Dave Martin wrote:
>
> [...]
>
> > kernel_neon_begin() could then do
> >
> > local_fpsimd_context_lock();
> >
> > /* ... */
> >
> > preempt_disable();
> > local_unlock(fpsimd_context_lock);
> >
> > ... with the following in kernel_neon_end():
> >
> > local_unlock(fpsimd_lock);
> > preempt_enable();
> >
> >
> > If kernel-mode NEON was considered harmful to RT due to the context
> > switch overheads, then the above might be overkill. SVE will be worse
> > in that regard, and also needs thinking about at some point -- I've not
> > looked at if from the RT angle at all.
>
> Hmmm, !KERNEL_MODE_NEON breaks EFI, so this probably does want looking
> at. Ard's recent rework to enable voluntary preemption the crypto
> backends for arm64 [1] should reduce the fpsimd_lock blackouts, but it
> still depends on the backends playing nice.
oh. I've seen the series, I more or less asked for this and I am glad
for it. I will try to unbreak this EFI problem then?
I remember the good old days when the boot loader was gone after it
jumped to the kernel?
> Cheers
> ---Dave
Sebastian
^ permalink raw reply
* [PATCH v9 3/4] arm64: Implement page table free interfaces
From: Kani, Toshi @ 2018-05-23 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523140157.GG26965@arm.com>
On Wed, 2018-05-23 at 15:01 +0100, Will Deacon wrote:
> Hi Chintan,
>
> [as a side note: I'm confused on the status of this patch series, as part
> of it was reposted separately by Toshi. Please can you work together?]
I do not know the status of my patch series, either... That being said,
I made my x86 patches based off from Chintan's 1/4 patch (which changes
both x86 and arm) so that my series won't conflict with his.
Chintan,
If you need to update your series before mine's accepted, please make
sure to use the updated 1/4 below. I've updated the descriptions per
review comment.
https://patchwork.kernel.org/patch/10407065/
Thanks,
-Toshi
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Sebastian Andrzej Siewior @ 2018-05-23 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517181932.GW7753@e103592.cambridge.arm.com>
On 2018-05-17 19:19:43 [+0100], Dave Martin wrote:
> On Thu, May 17, 2018 at 02:40:06PM +0200, Sebastian Andrzej Siewior wrote:
> > In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
> > code disables BH and expects that it is not preemptible. On -RT the
> > task remains preemptible but remains the same CPU. This may corrupt the
>
> Also, watch out for [1] which adds more of this stuff for KVM. This
> not merged yet, but likely to land in v4.18.
yay. I will try to keep this in mind while moving forward.
> Anyway:
>
> What we're really trying to achieve with the local_bh_disable/enable
> stuff is exclusive access to the CPU FPSIMD registers and associated
> metadata that tracks who they belong to.
I assumed this.
> > The preempt_disable() + local_bh_enable() combo in kernel_neon_begin()
> > is not working on -RT. We don't use NEON in kernel mode on RT right now
> > but this still should be addressed.
>
> I think we effectively have two levels of locking here.
>
> At the outer level, we want exclusive access to the FPSIMD registers.
> This is what is needed between kernel_neon_begin() and
> kernel_neon_end(), and maps onto the preempt_disable()/_enable() done
> by these functions.
>
> In context switch critical code, that's insufficient, and we also
> need exclusive access to the metadata that tracks which task or context
> owns the FPSIMD registers. This is what the local_bh_disable()/
> _enable() achieves.
>
>
> So does it make sense to have two locks (I'm assuming local locks are
> implicitly percpu ?)
>
> static inline void local_fpsimd_context_lock(void)
> {
> local_bh_disable();
> local_lock(fpsimd_lock);
> local_lock(fpsimd_context_lock);
> }
>
> static inline void local_fpsimd_context_unlock(void)
> {
> local_unlock(fpsimd_context_lock);
> local_unlock(fpsimd_lock);
> local_bh_enable();
> }
>
>
> kernel_neon_begin() could then do
>
> local_fpsimd_context_lock();
>
> /* ... */
>
> preempt_disable();
> local_unlock(fpsimd_context_lock);
>
> ... with the following in kernel_neon_end():
>
> local_unlock(fpsimd_lock);
> preempt_enable();
>
>
> If kernel-mode NEON was considered harmful to RT due to the context
> switch overheads, then the above might be overkill. SVE will be worse
> in that regard, and also needs thinking about at some point -- I've not
> looked at if from the RT angle at all.
>
> In either case, I think abstracting the lock/unlock sequences out to
> make the purpose clearer may be a good idea, even if we just have a
> single local lock to manage.
So the two looks you suggested make sense. However I would need to
replace this preempt_disable() with one such lock. A local_lock() on -RT
is a per-CPU spin_lock. RT's local_lock gets currently transformed into
preempt_disable() on !RT configs.
> There is one place where I mess with the FPSIMD context no lock held
> because of a need to copy_from_user() straight into the context backing
> store (we can't copy_from_user() with preemption disabled...)
> I'm not sure whether RT will have any impact on this, but it probably
> needs thinking about.
if no locks are held and the task can be preempted then it also might
happen on PREEMPT config. But copy_from_user() doesn't sounds like
something that will go straight to HW.
> One more comment below...
>
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> > arch/arm64/kernel/fpsimd.c | 20 ++++++++++++++++++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > index e7226c4c7493..3a5cd1908874 100644
> > --- a/arch/arm64/kernel/fpsimd.c
> > +++ b/arch/arm64/kernel/fpsimd.c
> > @@ -38,6 +38,7 @@
> > #include <linux/signal.h>
> > #include <linux/slab.h>
> > #include <linux/sysctl.h>
> > +#include <linux/locallock.h>
> >
> > #include <asm/fpsimd.h>
> > #include <asm/cputype.h>
> > @@ -235,7 +236,7 @@ static void sve_user_enable(void)
> > * whether TIF_SVE is clear or set, since these are not vector length
> > * dependent.
> > */
> > -
> > +static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
> > /*
> > * Update current's FPSIMD/SVE registers from thread_struct.
> > *
> > @@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
> > * non-SVE thread.
> > */
> > if (task == current) {
> > + local_lock(fpsimd_lock);
> > local_bh_disable();
> >
> > task_fpsimd_save();
> > @@ -604,8 +606,10 @@ int sve_set_vector_length(struct task_struct *task,
> > if (test_and_clear_tsk_thread_flag(task, TIF_SVE))
> > sve_to_fpsimd(task);
> >
> > - if (task == current)
> > + if (task == current) {
> > + local_unlock(fpsimd_lock);
>
> Is this misordered against local_bh_enable(), or doesn't it matter?
It actually is but it does not matter. On RT local_bh_disable() is
turned into migrate_disable() what in turn disables the migration of the
task to another CPU (while it is still preemtible). This
migrate_disable() is also part of local_lock(). Maybe I will add a
local_lock_bh() and replace this with this local_bh_disable() so it will
better :)
> > local_bh_enable();
> > + }
Sebastian
^ permalink raw reply
* [PATCH v2 11/16] irqchip/irq-mvebu-icu: add support for System Error Interrupts (SEI)
From: Marc Zyngier @ 2018-05-23 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522094042.24770-12-miquel.raynal@bootlin.com>
On 22/05/18 10:40, Miquel Raynal wrote:
> An SEI driver provides an MSI domain through which it is possible to
> raise SEIs.
>
> Handle the NSR probe function in a more generic way to support other
> type of interrupts (ie. the SEIs).
>
> For clarity we do not use tree IRQ domains for now but linear ones
> instead, allocating the 207 ICU lines for each interrupt group.
What's the rational for not using trees? Because that's effectively a
100% overhead...
> Reallocating an ICU slot is prevented by the use of an ICU-wide bitmap.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/irqchip/irq-mvebu-icu.c | 126 ++++++++++++++++++++++++++++++++++------
> 1 file changed, 108 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mvebu-icu.c b/drivers/irqchip/irq-mvebu-icu.c
> index 977e47b2716f..6ad6236d6ff1 100644
> --- a/drivers/irqchip/irq-mvebu-icu.c
> +++ b/drivers/irqchip/irq-mvebu-icu.c
> @@ -28,6 +28,10 @@
> #define ICU_SETSPI_NSR_AH 0x14
> #define ICU_CLRSPI_NSR_AL 0x18
> #define ICU_CLRSPI_NSR_AH 0x1c
> +#define ICU_SET_SEI_AL 0x50
> +#define ICU_SET_SEI_AH 0x54
> +#define ICU_CLR_SEI_AL 0x58
> +#define ICU_CLR_SEI_AH 0x5C
> #define ICU_INT_CFG(x) (0x100 + 4 * (x))
> #define ICU_INT_ENABLE BIT(24)
> #define ICU_IS_EDGE BIT(28)
> @@ -38,12 +42,28 @@
> #define ICU_SATA0_ICU_ID 109
> #define ICU_SATA1_ICU_ID 107
>
> +struct mvebu_icu_subset_data {
> + unsigned int icu_group;
> + unsigned int offset_set_ah;
> + unsigned int offset_set_al;
> + unsigned int offset_clr_ah;
> + unsigned int offset_clr_al;
> +};
> +
> struct mvebu_icu {
> struct irq_chip irq_chip;
> struct regmap *regmap;
> struct device *dev;
> - atomic_t initialized;
> bool legacy_bindings;
> + /* Lock on interrupt allocations/releases */
> + spinlock_t msi_lock;
> + DECLARE_BITMAP(msi_bitmap, ICU_MAX_IRQS);
> +};
> +
> +struct mvebu_icu_msi_data {
> + struct mvebu_icu *icu;
> + atomic_t initialized;
> + const struct mvebu_icu_subset_data *subset_data;
> };
>
> struct mvebu_icu_irq_data {
> @@ -76,16 +96,25 @@ static struct mvebu_icu *mvebu_icu_dev_get_drvdata(struct platform_device *pdev)
> return icu;
> }
>
> -static void mvebu_icu_init(struct mvebu_icu *icu, struct msi_msg *msg)
> +static void mvebu_icu_init(struct mvebu_icu *icu, struct irq_domain *d,
> + struct msi_msg *msg)
> {
> - if (atomic_cmpxchg(&icu->initialized, false, true))
> + struct mvebu_icu_msi_data *msi_data = platform_msi_get_host_data(d);
> + const struct mvebu_icu_subset_data *subset = msi_data->subset_data;
> +
> + if (atomic_cmpxchg(&msi_data->initialized, false, true))
> + return;
> +
> + /* Set 'SET' ICU SPI message address in AP */
> + regmap_write(icu->regmap, subset->offset_set_ah, msg[0].address_hi);
> + regmap_write(icu->regmap, subset->offset_set_al, msg[0].address_lo);
> +
> + if (subset->icu_group != ICU_GRP_NSR)
> return;
>
> - /* Set Clear/Set ICU SPI message address in AP */
> - regmap_write(icu->regmap, ICU_SETSPI_NSR_AH, msg[0].address_hi);
> - regmap_write(icu->regmap, ICU_SETSPI_NSR_AL, msg[0].address_lo);
> - regmap_write(icu->regmap, ICU_CLRSPI_NSR_AH, msg[1].address_hi);
> - regmap_write(icu->regmap, ICU_CLRSPI_NSR_AL, msg[1].address_lo);
> + /* Set 'CLEAR' ICU SPI message address in AP (level-MSI only) */
> + regmap_write(icu->regmap, subset->offset_clr_ah, msg[1].address_hi);
> + regmap_write(icu->regmap, subset->offset_clr_al, msg[1].address_lo);
> }
>
> static void mvebu_icu_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> @@ -96,8 +125,8 @@ static void mvebu_icu_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> unsigned int icu_int;
>
> if (msg->address_lo || msg->address_hi) {
> - /* One off initialization */
> - mvebu_icu_init(icu, msg);
> + /* One off initialization per domain */
> + mvebu_icu_init(icu, d->domain, msg);
> /* Configure the ICU with irq number & type */
> icu_int = msg->data | ICU_INT_ENABLE;
> if (icu_irqd->type & IRQ_TYPE_EDGE_RISING)
> @@ -131,7 +160,8 @@ static int
> mvebu_icu_irq_domain_translate(struct irq_domain *d, struct irq_fwspec *fwspec,
> unsigned long *hwirq, unsigned int *type)
> {
> - struct mvebu_icu *icu = platform_msi_get_host_data(d);
> + struct mvebu_icu_msi_data *msi_data = platform_msi_get_host_data(d);
> + struct mvebu_icu *icu = msi_data->icu;
> unsigned int param_count = icu->legacy_bindings ? 3 : 2;
>
> /* Check the count of the parameters in dt */
> @@ -172,7 +202,9 @@ mvebu_icu_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> int err;
> unsigned long hwirq;
> struct irq_fwspec *fwspec = args;
> - struct mvebu_icu *icu = platform_msi_get_host_data(domain);
> + struct mvebu_icu_msi_data *msi_data =
> + platform_msi_get_host_data(domain);
> + struct mvebu_icu *icu = msi_data->icu;
> struct mvebu_icu_irq_data *icu_irqd;
>
> icu_irqd = kmalloc(sizeof(*icu_irqd), GFP_KERNEL);
> @@ -186,16 +218,22 @@ mvebu_icu_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> goto free_irqd;
> }
>
> + spin_lock(&icu->msi_lock);
> + err = bitmap_allocate_region(icu->msi_bitmap, hwirq, 0);
> + spin_unlock(&icu->msi_lock);
This (and the freeing counterpart) could deserve a couple of helpers.
> + if (err < 0)
> + goto free_irqd;
> +
> if (icu->legacy_bindings)
> icu_irqd->icu_group = fwspec->param[0];
> else
> - icu_irqd->icu_group = ICU_GRP_NSR;
> + icu_irqd->icu_group = msi_data->subset_data->icu_group;
> icu_irqd->icu = icu;
>
> err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> if (err) {
> dev_err(icu->dev, "failed to allocate ICU interrupt in parent domain\n");
> - goto free_irqd;
> + goto free_bitmap;
> }
>
> /* Make sure there is no interrupt left pending by the firmware */
> @@ -214,6 +252,10 @@ mvebu_icu_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>
> free_msi:
> platform_msi_domain_free(domain, virq, nr_irqs);
> +free_bitmap:
> + spin_lock(&icu->msi_lock);
> + bitmap_release_region(icu->msi_bitmap, hwirq, 0);
> + spin_unlock(&icu->msi_lock);
> free_irqd:
> kfree(icu_irqd);
> return err;
> @@ -223,12 +265,19 @@ static void
> mvebu_icu_irq_domain_free(struct irq_domain *domain, unsigned int virq,
> unsigned int nr_irqs)
> {
> + struct mvebu_icu_msi_data *msi_data =
> + platform_msi_get_host_data(domain);
> + struct mvebu_icu *icu = msi_data->icu;
> struct irq_data *d = irq_get_irq_data(virq);
> struct mvebu_icu_irq_data *icu_irqd = d->chip_data;
>
> kfree(icu_irqd);
>
> platform_msi_domain_free(domain, virq, nr_irqs);
> +
> + spin_lock(&icu->msi_lock);
> + bitmap_release_region(icu->msi_bitmap, d->hwirq, 0);
> + spin_unlock(&icu->msi_lock);
> }
>
> static const struct irq_domain_ops mvebu_icu_domain_ops = {
> @@ -239,14 +288,29 @@ static const struct irq_domain_ops mvebu_icu_domain_ops = {
>
> static int mvebu_icu_subset_probe(struct platform_device *pdev)
> {
> + const struct mvebu_icu_subset_data *subset;
> + struct mvebu_icu_msi_data *msi_data;
> struct device_node *msi_parent_dn;
> struct irq_domain *irq_domain;
> struct mvebu_icu *icu;
>
> + msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
> + if (!msi_data)
> + return -ENOMEM;
> +
> icu = mvebu_icu_dev_get_drvdata(pdev);
> if (IS_ERR(icu))
> return PTR_ERR(icu);
>
> + subset = of_device_get_match_data(&pdev->dev);
> + if (!subset) {
> + dev_err(&pdev->dev, "Could not retrieve subset data\n");
> + return -EINVAL;
> + }
> +
> + msi_data->icu = icu;
> + msi_data->subset_data = subset;
> +
> pdev->dev.msi_domain = of_msi_get_domain(&pdev->dev, pdev->dev.of_node,
> DOMAIN_BUS_PLATFORM_MSI);
> if (!pdev->dev.msi_domain)
> @@ -259,7 +323,7 @@ static int mvebu_icu_subset_probe(struct platform_device *pdev)
> irq_domain = platform_msi_create_device_domain(&pdev->dev, ICU_MAX_IRQS,
> mvebu_icu_write_msg,
> &mvebu_icu_domain_ops,
> - icu);
> + msi_data);
> if (!irq_domain) {
> dev_err(&pdev->dev, "Failed to create ICU MSI domain\n");
> return -ENOMEM;
> @@ -268,9 +332,30 @@ static int mvebu_icu_subset_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mvebu_icu_subset_data mvebu_icu_nsr_subset_data = {
> + .icu_group = ICU_GRP_NSR,
> + .offset_set_ah = ICU_SETSPI_NSR_AH,
> + .offset_set_al = ICU_SETSPI_NSR_AL,
> + .offset_clr_ah = ICU_CLRSPI_NSR_AH,
> + .offset_clr_al = ICU_CLRSPI_NSR_AL,
> +};
> +
> +static const struct mvebu_icu_subset_data mvebu_icu_sei_subset_data = {
> + .icu_group = ICU_GRP_SEI,
> + .offset_set_ah = ICU_SET_SEI_AH,
> + .offset_set_al = ICU_SET_SEI_AL,
> + .offset_clr_ah = ICU_CLR_SEI_AH,
> + .offset_clr_al = ICU_CLR_SEI_AL,
I thought SEI was edge only, given what you do in mvebu_icu_init.
Confused...
> +};
> +
> static const struct of_device_id mvebu_icu_subset_of_match[] = {
> {
> .compatible = "marvell,cp110-icu-nsr",
> + .data = &mvebu_icu_nsr_subset_data,
> + },
> + {
> + .compatible = "marvell,cp110-icu-sei",
> + .data = &mvebu_icu_sei_subset_data,
> },
> {},
> };
> @@ -317,6 +402,8 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> if (IS_ERR(icu->regmap))
> return PTR_ERR(icu->regmap);
>
> + spin_lock_init(&icu->msi_lock);
> +
> icu->irq_chip.name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
> "ICU.%x",
> (unsigned int)res->start);
> @@ -341,7 +428,7 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> #endif
>
> /*
> - * Clean all ICU interrupts with type SPI_NSR, required to
> + * Clean all ICU interrupts of type NSR and SEI, required to
> * avoid unpredictable SPI assignments done by firmware.
> */
> for (i = 0 ; i < ICU_MAX_IRQS ; i++) {
> @@ -350,7 +437,8 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> regmap_read(icu->regmap, ICU_INT_CFG(i), &icu_int);
> icu_grp = icu_int >> ICU_GROUP_SHIFT;
>
> - if (icu_grp == ICU_GRP_NSR)
> + if (icu_grp == ICU_GRP_NSR ||
> + (icu_grp == ICU_GRP_SEI && !icu->legacy_bindings))
> regmap_write(icu->regmap, ICU_INT_CFG(i), 0);
> }
>
> @@ -363,7 +451,9 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id mvebu_icu_of_match[] = {
> - { .compatible = "marvell,cp110-icu", },
> + {
> + .compatible = "marvell,cp110-icu",
> + },
> {},
> };
>
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Rob Herring @ 2018-05-23 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <243730d3-e7f3-584d-b5dd-491c2700cf11@ti.com>
On Wed, May 23, 2018 at 12:55 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 22/05/18 23:01, Rob Herring wrote:
>>
>> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>>>
>>> On 17/04/18 17:49, Tony Lindgren wrote:
>>>>
>>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>>>
>>>>> In typical setup, you can boot a large number of different configs via:
>>>>>
>>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>>
>>>>> ... assuming the configs were named like that, and assuming they would
>>>>> be
>>>>> compatible with each other. The am57xx-evm example provided is better,
>>>>> as
>>>>> you can chain the different cameras to the available evm configs.
>>>>
>>>>
>>>> Why not just do it in the bootloader to put together the dtb?
>>>>
>>>> Then for external devices, you could just pass info on the
>>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>>> detected over I2C.
>>>
>>>
>>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>>
>>> Ok trying to resurrect this thread a bit. Is there any kind of consensus
>>> how
>>> things like this should be handled? Should we add the DT overlay files to
>>> kernel tree or not?
>>
>>
>> IMO, yes.
>>
>>> Should we add any kind of build infra to kernel tree, and at what level
>>> would this be? Just DT overlay file building support, and drop the FIT
>>> build
>>> support as was proposed in this RFC series or...?
>>
>>
>> I think I mentioned this already, but I expect that this is going to
>> cause a number of conversions of dtsi + dtsi -> dtb into base dts and
>> overlay(s) dts files. In doing so, we still need to be able to build the
>> original, full dtb.
>
>
> So you mean like breaking apart the existing .dts files? Are there any plans
> to get that done (I know the android folks talk about this but I don't like
> their idea.) If we do the split, how are we going to determine which dts +
> overlay files are required to get a specific DTB done? I actually wrote a
> tool for this purpose which parses the FIT image configurations and
> generates plain dtb files out of the info there if needed, but assuming FIT
> is abandoned then what...?
There aren't any plans that I'm aware of. I'm just assuming there are
some cases in the tree. It would just be some additional build rules:
board-kit.dtb: soc-som.dtb expansion-board.dtbo
fdtoverlay -o $@ -i $^
We'd need to come up with some way to express the input and output
files in a kbuild way. Perhaps similar to how multiple module files
are done.
Even if you are adding new platforms, having the above would still be
good. It captures what base the overlays apply to and tests that
applying actually works (rather than leaving that for the user to do
in the bootloader). FIT images also have or need that information, so
perhaps we can define a format that works as input for both kbuild and
FIT images.
>>> U-boot can obviously parse the base DTB + overlay DTB:s into a single
>>> DTB,
>>> but this is somewhat clumsy approach and is relatively error prone to get
>>> it
>>> right.
>>
>>
>> Why? How is the kernel better?
>
>
> I am mostly speaking about runtime applying of the overlays. If done build
> time, it is obviously on same level. If you apply the base DTS + overlays
> from u-boot prompt, it is not too much fun, and if there are any failures it
> just won't work, but don't really tell you why not.
Runtime, but still at boot time, right?
How is the kernel going to have better error handling? Is libfdt error
handling worse than the kernel's overlay code?
I do think we need to standardize how we tell bootloaders what
overlays to apply. I expect that we'll do that as part of EBBR spec[1]
though that is not part of the immediate focus.
Rob
[1] https://github.com/ARM-software/ebbr
^ permalink raw reply
* [rjarzmik:test/daniel 23/34] sound/arm/pxa2xx-ac97.c:27:10: fatal error: mach/regs-ac97.h: No such file or directory
From: Robert Jarzmik @ 2018-05-23 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <831EE4E5E37DCC428EB295A351E662494CB31A1D@shsmsx102.ccr.corp.intel.com>
"Li, Philip" <philip.li@intel.com> writes:
>> On Wednesday, May 23, 2018 10:46 AM, kbuild test robot wrote:
>> > tree: https://github.com/rjarzmik/linux test/daniel
>> > head: f495e2dbc482d8f01a1ee20e86284ee9c0c8fa98
>> > commit: 4cd654b13b9bcc0f206d414497b798ed42df573a [23/34] HACK: select
>> SND_PXA_SOC_SSP for SND_SIMPLE_CARD
>>
>> This patch is just a local hack in one of my scratch-pad branches and is
>> not meant for upstream inclusion. Could you remove the branch or make
>> sure it isn't picked up by test robots?
> thanks for info, we will exclude it from testing.
Hi Li, Philip,
Is it possible to exclude a pattern instead ?
I mean would it be possible to exclude each branch of the form "test/*" ?
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang @ 2018-05-23 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B82BB5F4-E197-4915-A543-C5FF9A5A41F1@holtmann.org>
On Wed, 2018-05-23 at 14:31 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>
> >> [ ... ]
> >>
> >>>> - if (hci_dev_test_flag(hdev, HCI_SETUP)) {
> >>>> + if (hci_dev_test_flag(hdev, HCI_SETUP) ||
> >>>> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
> >>>> hci_sock_dev_event(hdev, HCI_DEV_SETUP);
> >>>
> >>> I am not 100% sure that we want to send the HCI_DEV_SETUP event also multiple times. That is a userspace change that I would need to think about. We need to check create_monitor_event() and see what the btmon trace for this looks like. Can you send me a btmon -w trace.log when this change is active.
> >>>
> >>> Regards
> >>>
> >>> Marcel
> >>>
> >>
> >> Sure, I'll send you the trace.log with the change is active.
> >>
> >> Sean
> >>
> >
> >
> > Attached trace.log was captured when I inputted commands power on and
> > then off in bluetoothctl.
>
> the trace.log is somehow mangled. Something is not fully correct. Can you read it with btmon -r trace.log?
>
> Regards
>
> Marcel
>
Yes, I can read it with btmon -r trace.log.
I post it as plain text as below
Bluetooth monitor ver 5.37
= Note: Linux version 4.16.0-rc1+ (aarch64) 0.641494
= Note: Bluetooth subsystem version 2.22 0.641502
= New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] 0.641505
* Unknown packet (code 14 len 30) 0.641509
01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
* Unknown packet (code 14 len 30) 0.641592
02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
* Unknown packet (code 16 len 7) [hci0] 6.536771
01 00 00 00 05 00 01 .......
= Open Index: 00:00:46:76:22:01 [hci0] 6.717019
= Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.760983
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.761975
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.762963
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.763956
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.764948
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.765941
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.766933
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.767926
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.768919
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.769914
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.770909
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.771908
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.772904
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.773898
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.774892
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.775890
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.776882
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.777877
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.778871
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.779869
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.780864
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.781858
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.782852
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.783850
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.784845
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.785839
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.786833
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.787831
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.788826
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.789820
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.790814
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.791813
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.792809
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.793803
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.794798
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.795797
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.796791
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.797786
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.798779
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.799778
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.800774
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.801769
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.802763
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.803761
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.804755
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.805749
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.806743
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.807741
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.808737
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.809731
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.810725
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.811725
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.812719
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.813714
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
02 01 01 00 00 .....
< HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
01 07 01 00 04 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
02 07 01 00 00 .....
< HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 8.845071
01 06 02 00 00 01 ......
> HCI Event: Unknown (0xe4) plen 5 [hci0] 8.923456
02 06 01 00 00 .....
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 10.861118
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.865763
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Fe.. (0x04|0x0003) plen 0 [hci0] 10.865805
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.865965
Read Local Supported Features (0x04|0x0003) ncmd 1
Status: Success (0x00)
Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
3 slot packets
5 slot packets
Encryption
Slot offset
Timing accuracy
Role switch
Sniff mode
Power control requests
Channel quality driven data rate (CQDDR)
SCO link
HV2 packets
HV3 packets
CVSD synchronous data
Power control
Transparent synchronous data
Broadcast Encryption
Enhanced Data Rate ACL 2 Mbps mode
Enhanced Data Rate ACL 3 Mbps mode
Enhanced inquiry scan
Interlaced inquiry scan
Interlaced page scan
RSSI with inquiry results
Extended SCO link (EV3 packets)
EV4 packets
EV5 packets
AFH capable slave
AFH classification slave
LE Supported (Controller)
3-slot Enhanced Data Rate ACL packets
5-slot Enhanced Data Rate ACL packets
Sniff subrating
Pause encryption
AFH capable master
AFH classification master
Enhanced Data Rate eSCO 2 Mbps mode
Enhanced Data Rate eSCO 3 Mbps mode
3-slot Enhanced Data Rate eSCO packets
Extended Inquiry Response
Simultaneous LE and BR/EDR (Controller)
Secure Simple Pairing
Encapsulated PDU
Erroneous Data Reporting
Non-flushable Packet Boundary Flag
Link Supervision Timeout Changed Event
Inquiry TX Power Level
Enhanced Power Control
Extended features
< HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
29 19 09 17 20 48 07 11 00 )... H...
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
Manufacturer: MediaTek, Inc. (70)
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
Read BD ADDR (0x04|0x0009) ncmd 1
Status: Success (0x00)
Address: 00:00:46:76:22:01 (OLIVETTI NORTH AMERICA)
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0 [hci0] 10.866609
> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.866754
Read Buffer Size (0x04|0x0005) ncmd 1
Status: Success (0x00)
ACL MTU: 1021 ACL max packet: 8
SCO MTU: 184 SCO max packet: 1
< HCI Command: Read Class of Device (0x03|0x0023) plen 0 [hci0] 10.866775
> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.866920
Read Class of Device (0x03|0x0023) ncmd 1
Status: Success (0x00)
Class: 0x001f00
Major class: Uncategorized, specific device code not specified
Minor class: 0x00
< HCI Command: Read Local Name (0x03|0x0014) plen 0 [hci0] 10.866939
> HCI Event: Command Complete (0x0e) plen 252 [hci0] 10.867256
Read Local Name (0x03|0x0014) ncmd 1
Status: Success (0x00)
Name: MTK MT7622 #1
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0 [hci0] 10.867308
> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.867447
Read Voice Setting (0x03|0x0025) ncmd 1
Status: Success (0x00)
Setting: 0x0060
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16-bit
# of bits padding at MSB: 0
Air Coding Format: CVSD
< HCI Command: Read Number of Supporte.. (0x03|0x0038) plen 0 [hci0] 10.867474
> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.867611
Read Number of Supported IAC (0x03|0x0038) ncmd 1
Status: Success (0x00)
Number of IAC: 4
< HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 [hci0] 10.867678
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.867865
Read Current IAC LAP (0x03|0x0039) ncmd 1
Status: Success (0x00)
Number of IAC: 1
Access code: 0x9e8b33 (General Inquiry)
< HCI Command: Set Event Filter (0x03|0x0005) plen 1 [hci0] 10.867890
Type: Clear All Filters (0x00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868033
Set Event Filter (0x03|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: Write Connection Accept.. (0x03|0x0016) plen 2 [hci0] 10.868054
Timeout: 20000.000 msec (0x7d00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868235
Write Connection Accept Timeout (0x03|0x0016) ncmd 1
Status: Success (0x00)
< HCI Command: LE Read Buffer Size (0x08|0x0002) plen 0 [hci0] 10.868262
> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.868392
LE Read Buffer Size (0x08|0x0002) ncmd 1
Status: Success (0x00)
Data packet length: 251
Num data packets: 8
< HCI Command: LE Read Local Supported.. (0x08|0x0003) plen 0 [hci0] 10.868413
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868587
LE Read Local Supported Features (0x08|0x0003) ncmd 1
Status: Success (0x00)
Features: 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
LE Data Packet Length Extension
LL Privacy
Extended Scanner Filter Policies
< HCI Command: LE Read Supported States (0x08|0x001c) plen 0 [hci0] 10.868646
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868787
LE Read Supported States (0x08|0x001c) ncmd 1
Status: Success (0x00)
States: 0x000000001fffffff
Non-connectable Advertising State
Scannable Advertising State
Connectable Advertising State
High Duty Cycle Directed Advertising State
Passive Scanning State
Active Scanning State
Initiating State
and Connection State (Master Role)
Connection State (Slave Role)
Non-connectable Advertising State
and Passive Scanning State
Scannable Advertising State
and Passive Scanning State
Connectable Advertising State
and Passive Scanning State
High Duty Cycle Directed Advertising State
and Passive Scanning State
Non-connectable Advertising State
and Active Scanning State
Scannable Advertising State
and Active Scanning State
Connectable Advertising State
and Active Scanning State
High Duty Cycle Directed Advertising State
and Active Scanning State
Non-connectable Advertising State
and Initiating State
Scannable Advertising State
and Initiating State
Non-connectable Advertising State
and Connection State (Master Role)
Scannable Advertising State
and Connection State (Master Role)
Non-connectable Advertising State
and Connection State (Slave Role)
Scannable Advertising State
and Connection State (Slave Role)
Passive Scanning State
and Initiating State
Active Scanning State
and Initiating State
Passive Scanning State
and Connection State (Master Role)
Active Scanning State
and Connection State (Master Role)
Passive Scanning State
and Connection State (Slave Role)
Active Scanning State
and Connection State (Slave Role)
Initiating State
and Connection State (Master Role)
and Master Role & Master Role
< HCI Command: Read Local Supported Co.. (0x04|0x0002) plen 0 [hci0] 10.868807
> HCI Event: Command Complete (0x0e) plen 68 [hci0] 10.868985
Read Local Supported Commands (0x04|0x0002) ncmd 1
Status: Success (0x00)
Commands: 176 entries
Inquiry (Octet 0 - Bit 0)
Inquiry Cancel (Octet 0 - Bit 1)
Periodic Inquiry Mode (Octet 0 - Bit 2)
Exit Periodic Inquiry Mode (Octet 0 - Bit 3)
Create Connection (Octet 0 - Bit 4)
Disconnect (Octet 0 - Bit 5)
Add SCO Connection (Octet 0 - Bit 6)
Create Connection Cancel (Octet 0 - Bit 7)
Accept Connection Request (Octet 1 - Bit 0)
Reject Connection Request (Octet 1 - Bit 1)
Link Key Request Reply (Octet 1 - Bit 2)
Link Key Request Negative Reply (Octet 1 - Bit 3)
PIN Code Request Reply (Octet 1 - Bit 4)
PIN Code Request Negative Reply (Octet 1 - Bit 5)
Change Connection Packet Type (Octet 1 - Bit 6)
Authentication Requested (Octet 1 - Bit 7)
Set Connection Encryption (Octet 2 - Bit 0)
Change Connection Link Key (Octet 2 - Bit 1)
Master Link Key (Octet 2 - Bit 2)
Remote Name Request (Octet 2 - Bit 3)
Remote Name Request Cancel (Octet 2 - Bit 4)
Read Remote Supported Features (Octet 2 - Bit 5)
Read Remote Extended Features (Octet 2 - Bit 6)
Read Remote Version Information (Octet 2 - Bit 7)
Read Clock Offset (Octet 3 - Bit 0)
Read LMP Handle (Octet 3 - Bit 1)
Sniff Mode (Octet 4 - Bit 2)
Exit Sniff Mode (Octet 4 - Bit 3)
QoS Setup (Octet 4 - Bit 6)
Role Discovery (Octet 4 - Bit 7)
Switch Role (Octet 5 - Bit 0)
Read Link Policy Settings (Octet 5 - Bit 1)
Write Link Policy Settings (Octet 5 - Bit 2)
Read Default Link Policy Settings (Octet 5 - Bit 3)
Write Default Link Policy Settings (Octet 5 - Bit 4)
Flow Specification (Octet 5 - Bit 5)
Set Event Mask (Octet 5 - Bit 6)
Reset (Octet 5 - Bit 7)
Set Event Filter (Octet 6 - Bit 0)
Flush (Octet 6 - Bit 1)
Read PIN Type (Octet 6 - Bit 2)
Write PIN Type (Octet 6 - Bit 3)
Create New Unit Key (Octet 6 - Bit 4)
Read Stored Link Key (Octet 6 - Bit 5)
Write Stored Link Key (Octet 6 - Bit 6)
Delete Stored Link Key (Octet 6 - Bit 7)
Write Local Name (Octet 7 - Bit 0)
Read Local Name (Octet 7 - Bit 1)
Read Connection Accept Timeout (Octet 7 - Bit 2)
Write Connection Accept Timeout (Octet 7 - Bit 3)
Read Page Timeout (Octet 7 - Bit 4)
Write Page Timeout (Octet 7 - Bit 5)
Read Scan Enable (Octet 7 - Bit 6)
Write Scan Enable (Octet 7 - Bit 7)
Read Page Scan Activity (Octet 8 - Bit 0)
Write Page Scan Activity (Octet 8 - Bit 1)
Read Inquiry Scan Activity (Octet 8 - Bit 2)
Write Inquiry Scan Activity (Octet 8 - Bit 3)
Read Authentication Enable (Octet 8 - Bit 4)
Write Authentication Enable (Octet 8 - Bit 5)
Read Encryption Mode (Octet 8 - Bit 6)
Write Encryption Mode (Octet 8 - Bit 7)
Read Class of Device (Octet 9 - Bit 0)
Write Class of Device (Octet 9 - Bit 1)
Read Voice Setting (Octet 9 - Bit 2)
Write Voice Setting (Octet 9 - Bit 3)
Read Automatic Flush Timeout (Octet 9 - Bit 4)
Write Automatic Flush Timeout (Octet 9 - Bit 5)
Read Num Broadcast Retransmissions (Octet 9 - Bit 6)
Write Num Broadcast Retransmissions (Octet 9 - Bit 7)
Read Transmit Power Level (Octet 10 - Bit 2)
Read Sync Flow Control Enable (Octet 10 - Bit 3)
Write Sync Flow Control Enable (Octet 10 - Bit 4)
Set Controller To Host Flow Control (Octet 10 - Bit 5)
Host Buffer Size (Octet 10 - Bit 6)
Host Number of Completed Packets (Octet 10 - Bit 7)
Read Link Supervision Timeout (Octet 11 - Bit 0)
Write Link Supervision Timeout (Octet 11 - Bit 1)
Read Number of Supported IAC (Octet 11 - Bit 2)
Read Current IAC LAP (Octet 11 - Bit 3)
Write Current IAC LAP (Octet 11 - Bit 4)
Read Page Scan Mode (Octet 11 - Bit 7)
Write Page Scan Mode (Octet 12 - Bit 0)
Set AFH Host Channel Classification (Octet 12 - Bit 1)
Read Inquiry Scan Type (Octet 12 - Bit 4)
Write Inquiry Scan Type (Octet 12 - Bit 5)
Read Inquiry Mode (Octet 12 - Bit 6)
Write Inquiry Mode (Octet 12 - Bit 7)
Read Page Scan Type (Octet 13 - Bit 0)
Write Page Scan Type (Octet 13 - Bit 1)
Read AFH Channel Assessment Mode (Octet 13 - Bit 2)
Write AFH Channel Assessment Mode (Octet 13 - Bit 3)
Read Local Version Information (Octet 14 - Bit 3)
Read Local Supported Features (Octet 14 - Bit 5)
Read Local Extended Features (Octet 14 - Bit 6)
Read Buffer Size (Octet 14 - Bit 7)
Read Country Code (Octet 15 - Bit 0)
Read BD ADDR (Octet 15 - Bit 1)
Read Failed Contact Counter (Octet 15 - Bit 2)
Reset Failed Contact Counter (Octet 15 - Bit 3)
Read Link Quality (Octet 15 - Bit 4)
Read RSSI (Octet 15 - Bit 5)
Read AFH Channel Map (Octet 15 - Bit 6)
Read Clock (Octet 15 - Bit 7)
Read Loopback Mode (Octet 16 - Bit 0)
Write Loopback Mode (Octet 16 - Bit 1)
Enable Device Under Test Mode (Octet 16 - Bit 2)
Setup Synchronous Connection (Octet 16 - Bit 3)
Accept Synchronous Connection Request (Octet 16 - Bit 4)
Reject Synchronous Connection Request (Octet 16 - Bit 5)
Read Extended Inquiry Response (Octet 17 - Bit 0)
Write Extended Inquiry Response (Octet 17 - Bit 1)
Refresh Encryption Key (Octet 17 - Bit 2)
Sniff Subrating (Octet 17 - Bit 4)
Read Simple Pairing Mode (Octet 17 - Bit 5)
Write Simple Pairing Mode (Octet 17 - Bit 6)
Read Local OOB Data (Octet 17 - Bit 7)
Read Inquiry Response TX Power Level (Octet 18 - Bit 0)
Write Inquiry Transmit Power Level (Octet 18 - Bit 1)
Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
IO Capability Request Reply (Octet 18 - Bit 7)
User Confirmation Request Reply (Octet 19 - Bit 0)
User Confirmation Request Neg Reply (Octet 19 - Bit 1)
User Passkey Request Reply (Octet 19 - Bit 2)
User Passkey Request Negative Reply (Octet 19 - Bit 3)
Remote OOB Data Request Reply (Octet 19 - Bit 4)
Write Simple Pairing Debug Mode (Octet 19 - Bit 5)
Enhanced Flush (Octet 19 - Bit 6)
Remote OOB Data Request Neg Reply (Octet 19 - Bit 7)
Send Keypress Notification (Octet 20 - Bit 2)
IO Capability Request Negative Reply (Octet 20 - Bit 3)
Read Encryption Key Size (Octet 20 - Bit 4)
Set Event Mask Page 2 (Octet 22 - Bit 2)
Read Enhanced Transmit Power Level (Octet 24 - Bit 0)
Enhanced Setup Synchronous Connection (Octet 29 - Bit 3)
Enhanced Accept Synchronous Connection Request (Octet 29 - Bit 4)
Read Local Supported Codecs (Octet 29 - Bit 5)
Set Triggered Clock Capture (Octet 30 - Bit 5)
Truncated Page (Octet 30 - Bit 6)
Truncated Page Cancel (Octet 30 - Bit 7)
Set Connectionless Slave Broadcast (Octet 31 - Bit 0)
Start Synchronization Train (Octet 31 - Bit 2)
Set Reserved LT_ADDR (Octet 31 - Bit 4)
Delete Reserved LT_ADDR (Octet 31 - Bit 5)
Set Connectionless Slave Broadcast Data (Octet 31 - Bit 6)
Read Synchronization Train Parameters (Octet 31 - Bit 7)
Write Synchronization Train Parameters (Octet 32 - Bit 0)
Remote OOB Extended Data Request Reply (Octet 32 - Bit 1)
Read Authenticated Payload Timeout (Octet 32 - Bit 4)
Write Authenticated Payload Timeout (Octet 32 - Bit 5)
Read Local OOB Extended Data (Octet 32 - Bit 6)
Write Secure Connections Test Mode (Octet 32 - Bit 7)
Read Extended Page Timeout (Octet 33 - Bit 0)
Write Extended Page Timeout (Octet 33 - Bit 1)
Read Extended Inquiry Length (Octet 33 - Bit 2)
Write Extended Inquiry Length (Octet 33 - Bit 3)
LE Set Data Length (Octet 33 - Bit 6)
LE Read Suggested Default Data Length (Octet 33 - Bit 7)
LE Write Suggested Default Data Length (Octet 34 - Bit 0)
LE Read Local P-256 Public Key (Octet 34 - Bit 1)
LE Generate DHKey (Octet 34 - Bit 2)
LE Add Device To Resolving List (Octet 34 - Bit 3)
LE Remove Device From Resolving List (Octet 34 - Bit 4)
LE Clear Resolving List (Octet 34 - Bit 5)
LE Read Resolving List Size (Octet 34 - Bit 6)
LE Read Peer Resolvable Address (Octet 34 - Bit 7)
LE Read Local Resolvable Address (Octet 35 - Bit 0)
LE Set Address Resolution Enable (Octet 35 - Bit 1)
LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
LE Read Maximum Data Length (Octet 35 - Bit 3)
Octet 35 - Bit 4
Octet 35 - Bit 5
Octet 35 - Bit 6
Octet 35 - Bit 7
Octet 36 - Bit 0
< HCI Command: Write Simple Pairing Mode (0x03|0x0056) plen 1 [hci0] 10.869023
Mode: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869185
Write Simple Pairing Mode (0x03|0x0056) ncmd 1
Status: Success (0x00)
< HCI Command: Write Inquiry Mode (0x03|0x0045) plen 1 [hci0] 10.869239
Mode: Inquiry Result with RSSI or Extended Inquiry Result (0x02)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869371
Write Inquiry Mode (0x03|0x0045) ncmd 1
Status: Success (0x00)
< HCI Command: Read Inquiry Response T.. (0x03|0x0058) plen 0 [hci0] 10.869396
> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.869552
Read Inquiry Response TX Power Level (0x03|0x0058) ncmd 1
Status: Success (0x00)
TX power: -1 dBm
< HCI Command: Read Local Extended Fea.. (0x04|0x0004) plen 1 [hci0] 10.869572
Page: 1
> HCI Event: Command Complete (0x0e) plen 14 [hci0] 10.869729
Read Local Extended Features (0x04|0x0004) ncmd 1
Status: Success (0x00)
Page: 1/2
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Secure Simple Pairing (Host Support)
< HCI Command: Set Event Mask (0x03|0x0001) plen 8 [hci0] 10.869783
Mask: 0x3dbff807fffbffff
Inquiry Complete
Inquiry Result
Connection Complete
Connection Request
Disconnection Complete
Authentication Complete
Remote Name Request Complete
Encryption Change
Change Connection Link Key Complete
Master Link Key Complete
Read Remote Supported Features Complete
Read Remote Version Information Complete
QoS Setup Complete
Command Complete
Command Status
Hardware Error
Flush Occurred
Role Change
Mode Change
Return Link Keys
PIN Code Request
Link Key Request
Link Key Notification
Loopback Command
Data Buffer Overflow
Max Slots Change
Read Clock Offset Complete
Connection Packet Type Changed
QoS Violation
Page Scan Mode Change
Page Scan Repetition Mode Change
Flow Specification Complete
Inquiry Result with RSSI
Read Remote Extended Features Complete
Synchronous Connection Complete
Synchronous Connection Changed
Sniff Subrating
Extended Inquiry Result
Encryption Key Refresh Complete
IO Capability Request
IO Capability Request Reply
User Confirmation Request
User Passkey Request
Remote OOB Data Request
Simple Pairing Complete
Link Supervision Timeout Changed
Enhanced Flush Complete
User Passkey Notification
Keypress Notification
Remote Host Supported Features Notification
LE Meta
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869921
Set Event Mask (0x03|0x0001) ncmd 1
Status: Success (0x00)
< HCI Command: Read Stored Link Key (0x03|0x000d) plen 7 [hci0] 10.869947
Address: 00:00:00:00:00:00 (OUI 00-00-00)
Read all: 0x01
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.870129
Read Stored Link Key (0x03|0x000d) ncmd 1
Status: Success (0x00)
Max num keys: 4
Num keys: 0
< HCI Command: Write Default Link Poli.. (0x02|0x000f) plen 2 [hci0] 10.870148
Link policy: 0x0005
Enable Role Switch
Enable Sniff Mode
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.870310
Write Default Link Policy Settings (0x02|0x000f) ncmd 1
Status: Success (0x00)
< HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0 [hci0] 10.870331
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.870485
Read Page Scan Activity (0x03|0x001b) ncmd 1
Status: Success (0x00)
Interval: 1280.000 msec (0x0800)
Window: 11.250 msec (0x0012)
< HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 [hci0] 10.870504
> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.870652
Read Page Scan Type (0x03|0x0046) ncmd 1
Status: Success (0x00)
Type: Standard Scan (0x00)
< HCI Command: LE Set Event Mask (0x08|0x0001) plen 8 [hci0] 10.870671
Mask: 0x0000000000000980
LE Read Local P-256 Public Key Complete
LE Generate DHKey Complete
Unknown mask (0x0000000000000800)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.870839
LE Set Event Mask (0x08|0x0001) ncmd 1
Status: Success (0x00)
< HCI Command: Write LE Host Supported (0x03|0x006d) plen 2 [hci0] 10.870859
Supported: 0x01
Simultaneous: 0x00
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.871028
Write LE Host Supported (0x03|0x006d) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Extended Fea.. (0x04|0x0004) plen 1 [hci0] 10.871059
Page: 2
> HCI Event: Command Complete (0x0e) plen 14 [hci0] 10.871201
Read Local Extended Features (0x04|0x0004) ncmd 1
Status: Success (0x00)
Page: 2/2
Features: 0x25 0x0b 0x00 0x00 0x00 0x00 0x00 0x00
Connectionless Slave Broadcast - Master
Synchronization Train
Generalized interlaced scan
Secure Connections (Controller Support)
Ping
Train nudging
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7 [hci0] 10.871240
Address: 00:00:00:00:00:00 (OUI 00-00-00)
Delete all: 0x01
> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.871384
Delete Stored Link Key (0x03|0x0012) ncmd 1
Status: Success (0x00)
Num keys: 0
< HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8 [hci0] 10.871403
Mask: 0x0000000000b0c000
Triggered Clock Capture
Synchronization Train Complete
Slave Page Response Timeout
Connectionless Slave Broadcast Channel Map Change
Authenticated Payload Timeout Expired
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.871566
Set Event Mask Page 2 (0x03|0x0063) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Co.. (0x04|0x000b) plen 0 [hci0] 10.871599
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.871750
Read Local Supported Codecs (0x04|0x000b) ncmd 1
Status: Success (0x00)
Number of supported codecs: 2
Codec: CVSD (0x02)
Codec: Transparent (0x03)
Number of vendor codecs: 0
< HCI Command: Read Synchronization Tr.. (0x03|0x0077) plen 0 [hci0] 10.871769
> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.871928
Read Synchronization Train Parameters (0x03|0x0077) ncmd 1
Status: Success (0x00)
Interval: 0.000 msec (0x0000)
Timeout: 0.000 msec (0x00000000)
Service data: 0x00
< HCI Command: Write Secure Connection.. (0x03|0x007a) plen 1 [hci0] 10.871947
Support: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872098
Write Secure Connections Host Support (0x03|0x007a) ncmd 1
Status: Success (0x00)
< HCI Command: Unknown (0x08|0x0031) plen 3 [hci0] 10.872156
03 00 00 ...
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872322
Unknown (0x08|0x0031) ncmd 1
Status: Success (0x00)
= Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 10.872361
< HCI Command: LE Set Scan Response D.. (0x08|0x0009) plen 32 [hci0] 10.872431
Length: 10
Name (complete): builder
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872606
LE Set Scan Response Data (0x08|0x0009) ncmd 1
Status: Success (0x00)
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 10.872627
Scan enable: Page Scan (0x02)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872819
Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)
< HCI Command: Write Class of Device (0x03|0x0024) plen 3 [hci0] 10.872841
Class: 0x000000
Major class: Miscellaneous
Minor class: 0x00
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873036
Write Class of Device (0x03|0x0024) ncmd 1
Status: Success (0x00)
* Unknown packet (code 17 len 9) [hci0] 10.873069
02 00 00 00 07 00 00 00 00 .........
* Unknown packet (code 17 len 9) [hci0] 10.873069
01 00 00 00 07 00 00 00 00 .........
< HCI Command: Write Local Name (0x03|0x0013) plen 248 [hci0] 10.873096
Name: builder
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873446
Write Local Name (0x03|0x0013) ncmd 1
Status: Success (0x00)
< HCI Command: Write Extended Inquir.. (0x03|0x0052) plen 241 [hci0] 10.873470
FEC: Not required (0x00)
Name (complete): builder
TX power: -1 dBm
Device ID: USB Implementer's Forum assigned (0x0002)
Vendor: Linux Foundation (0x1d6b)
Product: 0x0246
Version: 5.2.11 (0x052b)
16-bit Service UUIDs (complete): 4 entries
Generic Access Profile (0x1800)
Generic Attribute Profile (0x1801)
A/V Remote Control (0x110e)
A/V Remote Control Target (0x110c)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873857
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)
* Unknown packet (code 17 len 13) [hci0] 10.873903
01 00 00 00 01 00 05 00 00 d1 0a 00 00 .............
* Unknown packet (code 17 len 10) [hci0] 10.873913
02 00 00 00 06 00 d1 0a 00 00 ..........
* Unknown packet (code 16 len 7) [hci0] 17.803939
01 00 00 00 05 00 00 .......
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 17.803983
Scan enable: No Scans (0x00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 17.804233
Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)
< HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 17.804282
01 06 02 00 00 00 ......
> HCI Event: Unknown (0xe4) plen 5 [hci0] 17.804636
02 06 01 00 00 .....
* Unknown packet (code 17 len 13) [hci0] 17.811580
01 00 00 00 01 00 05 00 00 d0 0a 00 00 .............
* Unknown packet (code 17 len 10) [hci0] 17.811596
02 00 00 00 06 00 d0 0a 00 00 ..........
= Close Index: 00:00:46:76:22:01 [hci0] 17.811625
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox