* [PATCH 1/3] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Chanwoo Choi @ 2017-12-07 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206111008.3079-1-enric.balletbo@collabora.com>
Hi Enric,
On 2017? 12? 06? 20:10, Enric Balletbo i Serra wrote:
> From: Benson Leung <bleung@chromium.org>
>
> Extend the driver to notify host and device type cables and the presence
> of power.
>
> Signed-off-by: Benson Leung <bleung@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
> include/linux/mfd/cros_ec_commands.h | 17 +++++
> 2 files changed, 155 insertions(+), 4 deletions(-)
Looks good to me.
After you uses the BIT() macro as the Lee's comment on v2,
I'll merge this patch.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>
> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c b/drivers/extcon/extcon-usbc-cros-ec.c
> index 6187f73..6721ab0 100644
> --- a/drivers/extcon/extcon-usbc-cros-ec.c
> +++ b/drivers/extcon/extcon-usbc-cros-ec.c
> @@ -34,16 +34,26 @@ struct cros_ec_extcon_info {
>
> struct notifier_block notifier;
>
> + unsigned int dr; /* data role */
> + bool pr; /* power role (true if VBUS enabled) */
> bool dp; /* DisplayPort enabled */
> bool mux; /* SuperSpeed (usb3) enabled */
> unsigned int power_type;
> };
>
> static const unsigned int usb_type_c_cable[] = {
> + EXTCON_USB,
> + EXTCON_USB_HOST,
> EXTCON_DISP_DP,
> EXTCON_NONE,
> };
>
> +enum usb_data_roles {
> + DR_NONE,
> + DR_HOST,
> + DR_DEVICE,
> +};
> +
> /**
> * cros_ec_pd_command() - Send a command to the EC.
> * @info: pointer to struct cros_ec_extcon_info
> @@ -150,6 +160,7 @@ static int cros_ec_usb_get_role(struct cros_ec_extcon_info *info,
> pd_control.port = info->port_id;
> pd_control.role = USB_PD_CTRL_ROLE_NO_CHANGE;
> pd_control.mux = USB_PD_CTRL_MUX_NO_CHANGE;
> + pd_control.swap = USB_PD_CTRL_SWAP_NONE;
> ret = cros_ec_pd_command(info, EC_CMD_USB_PD_CONTROL, 1,
> &pd_control, sizeof(pd_control),
> &resp, sizeof(resp));
> @@ -183,11 +194,72 @@ static int cros_ec_pd_get_num_ports(struct cros_ec_extcon_info *info)
> return resp.num_ports;
> }
>
> +static const char *cros_ec_usb_role_string(unsigned int role)
> +{
> + return role == DR_NONE ? "DISCONNECTED" :
> + (role == DR_HOST ? "DFP" : "UFP");
> +}
> +
> +static const char *cros_ec_usb_power_type_string(unsigned int type)
> +{
> + switch (type) {
> + case USB_CHG_TYPE_NONE:
> + return "USB_CHG_TYPE_NONE";
> + case USB_CHG_TYPE_PD:
> + return "USB_CHG_TYPE_PD";
> + case USB_CHG_TYPE_PROPRIETARY:
> + return "USB_CHG_TYPE_PROPRIETARY";
> + case USB_CHG_TYPE_C:
> + return "USB_CHG_TYPE_C";
> + case USB_CHG_TYPE_BC12_DCP:
> + return "USB_CHG_TYPE_BC12_DCP";
> + case USB_CHG_TYPE_BC12_CDP:
> + return "USB_CHG_TYPE_BC12_CDP";
> + case USB_CHG_TYPE_BC12_SDP:
> + return "USB_CHG_TYPE_BC12_SDP";
> + case USB_CHG_TYPE_OTHER:
> + return "USB_CHG_TYPE_OTHER";
> + case USB_CHG_TYPE_VBUS:
> + return "USB_CHG_TYPE_VBUS";
> + case USB_CHG_TYPE_UNKNOWN:
> + return "USB_CHG_TYPE_UNKNOWN";
> + default:
> + return "USB_CHG_TYPE_UNKNOWN";
> + }
> +}
> +
> +static bool cros_ec_usb_power_type_is_wall_wart(unsigned int type,
> + unsigned int role)
> +{
> + switch (type) {
> + /* FIXME : Guppy, Donnettes, and other chargers will be miscategorized
> + * because they identify with USB_CHG_TYPE_C, but we can't return true
> + * here from that code because that breaks Suzy-Q and other kinds of
> + * USB Type-C cables and peripherals.
> + */
> + case USB_CHG_TYPE_PROPRIETARY:
> + case USB_CHG_TYPE_BC12_DCP:
> + return true;
> + case USB_CHG_TYPE_PD:
> + case USB_CHG_TYPE_C:
> + case USB_CHG_TYPE_BC12_CDP:
> + case USB_CHG_TYPE_BC12_SDP:
> + case USB_CHG_TYPE_OTHER:
> + case USB_CHG_TYPE_VBUS:
> + case USB_CHG_TYPE_UNKNOWN:
> + case USB_CHG_TYPE_NONE:
> + default:
> + return false;
> + }
> +}
> +
> static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> bool force)
> {
> struct device *dev = info->dev;
> int role, power_type;
> + unsigned int dr = DR_NONE;
> + bool pr = false;
> bool polarity = false;
> bool dp = false;
> bool mux = false;
> @@ -206,9 +278,12 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> dev_err(dev, "failed getting role err = %d\n", role);
> return role;
> }
> + dev_dbg(dev, "disconnected\n");
> } else {
> int pd_mux_state;
>
> + dr = (role & PD_CTRL_RESP_ROLE_DATA) ? DR_HOST : DR_DEVICE;
> + pr = (role & PD_CTRL_RESP_ROLE_POWER);
> pd_mux_state = cros_ec_usb_get_pd_mux_state(info);
> if (pd_mux_state < 0)
> pd_mux_state = USB_PD_MUX_USB_ENABLED;
> @@ -216,20 +291,62 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> dp = pd_mux_state & USB_PD_MUX_DP_ENABLED;
> mux = pd_mux_state & USB_PD_MUX_USB_ENABLED;
> hpd = pd_mux_state & USB_PD_MUX_HPD_IRQ;
> - }
>
> - if (force || info->dp != dp || info->mux != mux ||
> - info->power_type != power_type) {
> + dev_dbg(dev,
> + "connected role 0x%x pwr type %d dr %d pr %d pol %d mux %d dp %d hpd %d\n",
> + role, power_type, dr, pr, polarity, mux, dp, hpd);
> + }
>
> + /*
> + * When there is no USB host (e.g. USB PD charger),
> + * we are not really a UFP for the AP.
> + */
> + if (dr == DR_DEVICE &&
> + cros_ec_usb_power_type_is_wall_wart(power_type, role))
> + dr = DR_NONE;
> +
> + if (force || info->dr != dr || info->pr != pr || info->dp != dp ||
> + info->mux != mux || info->power_type != power_type) {
> + bool host_connected = false, device_connected = false;
> +
> + dev_dbg(dev, "Type/Role switch! type = %s role = %s\n",
> + cros_ec_usb_power_type_string(power_type),
> + cros_ec_usb_role_string(dr));
> + info->dr = dr;
> + info->pr = pr;
> info->dp = dp;
> info->mux = mux;
> info->power_type = power_type;
>
> - extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
> + if (dr == DR_DEVICE)
> + device_connected = true;
> + else if (dr == DR_HOST)
> + host_connected = true;
>
> + extcon_set_state(info->edev, EXTCON_USB, device_connected);
> + extcon_set_state(info->edev, EXTCON_USB_HOST, host_connected);
> + extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
> + extcon_set_property(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_VBUS,
> + (union extcon_property_value)(int)pr);
> + extcon_set_property(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_VBUS,
> + (union extcon_property_value)(int)pr);
> + extcon_set_property(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_TYPEC_POLARITY,
> + (union extcon_property_value)(int)polarity);
> + extcon_set_property(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_TYPEC_POLARITY,
> + (union extcon_property_value)(int)polarity);
> extcon_set_property(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_TYPEC_POLARITY,
> (union extcon_property_value)(int)polarity);
> + extcon_set_property(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_SS,
> + (union extcon_property_value)(int)mux);
> + extcon_set_property(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_SS,
> + (union extcon_property_value)(int)mux);
> extcon_set_property(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_SS,
> (union extcon_property_value)(int)mux);
> @@ -237,6 +354,8 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> EXTCON_PROP_DISP_HPD,
> (union extcon_property_value)(int)hpd);
>
> + extcon_sync(info->edev, EXTCON_USB);
> + extcon_sync(info->edev, EXTCON_USB_HOST);
> extcon_sync(info->edev, EXTCON_DISP_DP);
>
> } else if (hpd) {
> @@ -322,13 +441,28 @@ static int extcon_cros_ec_probe(struct platform_device *pdev)
> return ret;
> }
>
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_TYPEC_POLARITY);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_TYPEC_POLARITY);
> extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_TYPEC_POLARITY);
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_SS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_SS);
> extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_SS);
> extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_DISP_HPD);
>
> + info->dr = DR_NONE;
> + info->pr = false;
> +
> platform_set_drvdata(pdev, info);
>
> /* Get PD events from the EC */
> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
> index 2b16e95..c907353 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2904,16 +2904,33 @@ enum usb_pd_control_mux {
> USB_PD_CTRL_MUX_AUTO = 5,
> };
>
> +enum usb_pd_control_swap {
> + USB_PD_CTRL_SWAP_NONE = 0,
> + USB_PD_CTRL_SWAP_DATA = 1,
> + USB_PD_CTRL_SWAP_POWER = 2,
> + USB_PD_CTRL_SWAP_VCONN = 3,
> + USB_PD_CTRL_SWAP_COUNT
> +};
> +
> struct ec_params_usb_pd_control {
> uint8_t port;
> uint8_t role;
> uint8_t mux;
> + uint8_t swap;
> } __packed;
>
> #define PD_CTRL_RESP_ENABLED_COMMS (1 << 0) /* Communication enabled */
> #define PD_CTRL_RESP_ENABLED_CONNECTED (1 << 1) /* Device connected */
> #define PD_CTRL_RESP_ENABLED_PD_CAPABLE (1 << 2) /* Partner is PD capable */
>
> +#define PD_CTRL_RESP_ROLE_POWER (1 << 0) /* 0=SNK/1=SRC */
> +#define PD_CTRL_RESP_ROLE_DATA (1 << 1) /* 0=UFP/1=DFP */
> +#define PD_CTRL_RESP_ROLE_VCONN (1 << 2) /* Vconn status */
> +#define PD_CTRL_RESP_ROLE_DR_POWER (1 << 3) /* Partner is dualrole power */
> +#define PD_CTRL_RESP_ROLE_DR_DATA (1 << 4) /* Partner is dualrole data */
> +#define PD_CTRL_RESP_ROLE_USB_COMM (1 << 5) /* Partner USB comm capable */
> +#define PD_CTRL_RESP_ROLE_EXT_POWERED (1 << 6) /* Partner externally powerd */
> +
> struct ec_response_usb_pd_control_v1 {
> uint8_t enabled;
> uint8_t role;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
From: Gary Lin @ 2017-12-07 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206183734.xmgecyrd5suiurm6@gmail.com>
On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
>
> * Gary Lin <glin@suse.com> wrote:
>
> > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> wrote:
> > > > The series of patches introduce Security Version to EFI stub.
> > > >
> > > > Security Version is a monotonically increasing number and designed to
> > > > prevent the user from loading an insecure kernel accidentally. The
> > > > bootloader maintains a list of security versions corresponding to
> > > > different distributions. After fixing a critical vulnerability, the
> > > > distribution kernel maintainer bumps the "version", and the bootloader
> > > > updates the list automatically. When the user tries to load a kernel
> > > > with a lower security version, the bootloader shows a warning prompt
> > > > to notify the user the potential risk.
> > >
> > > If a distribution releases a kernel with a higher security version and
> > > that it automatically updated on boot, what happens if that kernel
> > > contains a different bug that causes it to fail to boot or break
> > > critical functionality? At that point, the user's machine would be in
> > > a state where the higher security version is enforced but the only
> > > kernel that provides that is broken. Wouldn't that make a bad
> > > situation even worse by now requiring manual acceptance of the older
> > > SV kernel boot physically at the machine?
> > >
> > > I feel like I'm missing a detail here or something.
> > >
> > If the new kernel fails to boot, then the user has to choose the kernel
> > manually anyway, and there will be an option in the warning prompt to
> > lower SV.
>
> And what if the firmware does not support a lowering of the SV?
>
The SV list is manipulated by the bootloader, and the firmware only
provides the interface to the storage, i.e. non-volatile flash.
Cheers,
Gary Lin
^ permalink raw reply
* [kernel-hardening][PATCH v4 0/3] arm: Makes ptdump resuable and add WX page checking
From: Laura Abbott @ 2017-12-07 1:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206102315.GA7012@pjb1027-Latitude-E5410>
On 12/06/2017 02:23 AM, Jinbum Park wrote:
> Hi,
>
> Page table dumping code for arm64-x86 is reusable,
> and they have function for WX page checking.
> But arm doesn't have that.
>
> This path series are to makes ptdump reusable,
> and add WX page checking for arm.
> This is heavily based on arm64 version.
>
> v2 :
> Fix a sender name of mail header, there was an mistake.
> (from "jinb.park" to Jinbum Park)
> Contents of patch-set are perfectly same.
>
> v3 :
> Take advantage of the existing pg_level and bits arrays
> to check ro, nx prot.
>
> v4 :
> Add boolean for ro_bit, nx_bit into prot_bits
> to point ro_bit, nx_bit in pg_level.
> This change is suggested by Laura Abbott.
>
> jinb.park (3):
> arm: mm: dump: make page table dumping reusable
> arm: mm: dump: make the page table dumping seq_file optional
> arm: mm: dump: add checking for writable and executable pages
>
> arch/arm/Kconfig.debug | 33 ++++++++-
> arch/arm/include/asm/ptdump.h | 56 ++++++++++++++++
> arch/arm/mm/Makefile | 3 +-
> arch/arm/mm/dump.c | 151 +++++++++++++++++++++++++++++-------------
> arch/arm/mm/init.c | 2 +
> arch/arm/mm/ptdump_debugfs.c | 34 ++++++++++
> 6 files changed, 232 insertions(+), 47 deletions(-)
> create mode 100644 arch/arm/include/asm/ptdump.h
> create mode 100644 arch/arm/mm/ptdump_debugfs.c
>
You can add
Tested-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Laura Abbott <labbott@redhat.com>
^ permalink raw reply
* [RESEND PATCH v3 2/2] ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
From: Yixun Lan @ 2017-12-07 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7htvx3r4o7.fsf@baylibre.com>
Hi Kevin
On 12/07/17 04:18, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> From: Xingyu Chen <xingyu.chen@amlogic.com>
>>
>> Add new pinctrl DT info for the Amlogic's Meson-AXG SoC.
>>
>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index 5fc33b76b91c..e0fb860e12c5 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -9,6 +9,7 @@
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/clock/axg-clkc.h>
>> #include <dt-bindings/clock/axg-aoclkc.h>
>
> This doesn't apply because this aoclkc.h header does not exist in
> mainline.
>
> Kevin
>
this is due to I create the patch in serial sequence (first clk, then
pinctrl), I probably will fix my work flow next time - to rebase all the
patch separately on the -rc version
but here, the pinctrl DT part has no dependency on DT clk patch..
you could drop the above two #include and just apply the reset
could you amend & apply this? or do you want me to send another updated
version?
>> +#include <dt-bindings/gpio/meson-axg-gpio.h>
>>
>> / {
>> compatible = "amlogic,meson-axg";
>> @@ -173,6 +174,32 @@
>> #mbox-cells = <1>;
>> };
>>
>> + periphs: periphs at ff634000 {
>> + compatible = "simple-bus";
>> + reg = <0x0 0xff634000 0x0 0x2000>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x0 0x0 0x0 0xff634000 0x0 0x2000>;
>> +
>> + pinctrl_periphs: pinctrl at 480 {
>> + compatible = "amlogic,meson-axg-periphs-pinctrl";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + gpio: bank at 480 {
>> + reg = <0x0 0x00480 0x0 0x40>,
>> + <0x0 0x004e8 0x0 0x14>,
>> + <0x0 0x00520 0x0 0x14>,
>> + <0x0 0x00430 0x0 0x3c>;
>> + reg-names = "mux", "pull", "pull-enable", "gpio";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + gpio-ranges = <&pinctrl_periphs 0 0 86>;
>> + };
>> + };
>> + };
>> +
>> sram: sram at fffc0000 {
>> compatible = "amlogic,meson-axg-sram", "mmio-sram";
>> reg = <0x0 0xfffc0000 0x0 0x20000>;
>> @@ -209,6 +236,23 @@
>> };
>> };
>>
>> + pinctrl_aobus: pinctrl at 14 {
>> + compatible = "amlogic,meson-axg-aobus-pinctrl";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + gpio_ao: bank at 14 {
>> + reg = <0x0 0x00014 0x0 0x8>,
>> + <0x0 0x0002c 0x0 0x4>,
>> + <0x0 0x00024 0x0 0x8>;
>> + reg-names = "mux", "pull", "gpio";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + gpio-ranges = <&pinctrl_aobus 0 0 15>;
>> + };
>> + };
>> +
>> uart_AO: serial at 3000 {
>> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
>> reg = <0x0 0x3000 0x0 0x18>;
>
> .
>
^ permalink raw reply
* [PATCH 1/6 v3] mmc: meson-gx-mmc: Fix platform_get_irq's error checking
From: Kevin Hilman @ 2017-12-07 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1c27676e9f141ace1254b40807bf2dc03f072c6.1511066652.git.arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH 1/6] mmc: meson-gx-mmc: Fix platform_get_irq's error checking
From: Kevin Hilman @ 2017-12-07 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510950502-22565-2-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
From: Kevin Hilman @ 2017-12-07 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201012452.27086-5-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Qiufang Dai <qiufang.dai@amlogic.com>
>
> Try to add Hiubus DT info, and also enable clock DT info
> for the Amlogic's Meson-AXG SoC.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Qiufang Dai <qiufang.dai@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index b932a784b02a..36a2e98338a8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
This #include will cause an unnessary dependency from the amlogic tree
to the clock tree even though this patch is not currently using any of
the #defines from that header. It will simplify the dependencies if you
drop this #include from this patch.
In my comment on the cover letter, I suggested adding a patch that also
switches the UART over to the new clock provider. That is the patch
that should add this #include, since it will actually need #defines from
the header.
Doing it in that order means that we could merge this patch
independently of the clock driver, and then merge the UART switch-over
patch only after the driver (and headers) are merged.
Kevin
^ permalink raw reply
* [PATCH v9 3/5] perf utils: use pmu->is_uncore to detect PMU UNCORE devices
From: Jin, Yao @ 2017-12-07 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206134702.GA12234@kernel.org>
On 12/6/2017 9:47 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 06, 2017 at 08:30:37AM +0800, Jin, Yao escreveu:
>>
>>
>> On 12/6/2017 2:42 AM, Arnaldo Carvalho de Melo wrote:
>>> Em Tue, Dec 05, 2017 at 08:35:22PM +0800, Jin, Yao escreveu:
>>>> A quick test with the new patch 'fix_json_v9_2.patch' shows it working.
>>>
>>> I'll take this as a Tested-by: you, ok?
>>
>> Hi Arnaldo,
>>
>> I didn't do a full test for this patch and for the whole patch series.
>>
>> I just do a quick test and it shows that the regression issue which was
>> found in 'perf stat --per-thread' test case is disappear.
>>
>> If you think it's enough for adding Tested-by, that's fine for me. :)
>
> I guess this addresses at least your previous regression report, so I
> think it is warranted, thanks!
>
> - arnaldo
>
That's fine, thanks!
Thanks
Jin Yao
^ permalink raw reply
* [PATCH 3/3] ARM64: dts: meson-axg: add the SPICC controller
From: Kevin Hilman @ 2017-12-07 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hy3mfmmtd.fsf@baylibre.com>
On Wed, Dec 6, 2017 at 3:57 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> From: Sunny Luo <sunny.luo@amlogic.com>
>>
>> Add DT info for the SPICC controller which found in
>> the Amlogic's Meson-AXG SoC.
>>
>> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> This patch looks OK but it doesn't apply cleanly.
>
> A quick glance suggests that it's becuase it has a dependency on the PWM
> series, but that dependency was not described here (or in the cover
> letter.)
>
> If the series does not apply directly on mainline, the cover letter
> should describe the dependencies clearly.
>
> In your case, I understand it's difficult because you have many series
> in parallel at the same time. I would suggest that locally, you keep
> each series as independent branches based on the latest -rc tag.
Correction: while in general it's best to keep things based on the
latest -rc tag, for DT patches, it's even better if you base things on
my current <version>/dt64 branch (currently v4.16/dt64)
Kevin
^ permalink raw reply
* [PATCH 3/3] ARM64: dts: meson-axg: add the SPICC controller
From: Kevin Hilman @ 2017-12-06 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128132926.19051-4-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Sunny Luo <sunny.luo@amlogic.com>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
This patch looks OK but it doesn't apply cleanly.
A quick glance suggests that it's becuase it has a dependency on the PWM
series, but that dependency was not described here (or in the cover
letter.)
If the series does not apply directly on mainline, the cover letter
should describe the dependencies clearly.
In your case, I understand it's difficult because you have many series
in parallel at the same time. I would suggest that locally, you keep
each series as independent branches based on the latest -rc tag. It's
pretty easy for me to resolve simple add-add conflicts when there are
two different series adding to the DT, but it can be more time consuming
when I have to figure out the dependencies myself, so I generally don't
do that and just reject the patches instead so the submitter can work
out (and document) the dependencies.
Also some questions...
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 92 ++++++++++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index fe3878f7718c..021b929d8d6e 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -208,6 +208,28 @@
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
> +
> + spicc_a: spi at 13000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x13000 0x0 0x3c>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC0>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spicc_b: spi at 15000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x15000 0x0 0x3c>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC1>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
Here you use the labels spicc_a and spicc_b, but the datasheet
uses 0 and 1. Why the difference?
Hmm, but after looking at the pin definitions those are using A and B.
Confusing.
Can you clarify which is the right one, and also work with the datasheet
team on consistency? Thanks!
Kevin
> };
>
> gic: interrupt-controller at ffc01000 {
> @@ -470,6 +492,76 @@
> function = "pwm_d";
> };
> };
> +
> + spi_a_pins: spi_a {
> + mux {
> + groups = "spi_miso_a",
> + "spi_mosi_a",
> + "spi_clk_a";
> + function = "spi_a";
> + };
> + };
> +
> + spi_ss0_a_pins: spi_ss0_a {
> + mux {
> + groups = "spi_ss0_a";
> + function = "spi_a";
> + };
> + };
> +
> + spi_ss1_a_pins: spi_ss1_a {
> + mux {
> + groups = "spi_ss1_a";
> + function = "spi_a";
> + };
> + };
> +
> + spi_ss2_a_pins: spi_ss2_a {
> + mux {
> + groups = "spi_ss2_a";
> + function = "spi_a";
> + };
> + };
> +
> +
> + spi_b_a_pins: spi_b_a {
> + mux {
> + groups = "spi_miso_b_a",
> + "spi_mosi_b_a",
> + "spi_clk_b_a";
> + function = "spi_b";
> + };
> + };
> +
> + spi_ss0_b_a_pins: spi_ss0_b_a {
> + mux {
> + groups = "spi_ss0_b_a";
> + function = "spi_b";
> + };
> + };
> +
> + spi_ss1_b_pins: spi_ss1_b {
> + mux {
> + groups = "spi_ss1_b";
> + function = "spi_b";
> + };
> + };
> +
> + spi_b_x_pins: spi_b_x {
> + mux {
> + groups = "spi_miso_b_x",
> + "spi_mosi_b_x",
> + "spi_clk_b_x";
> + function = "spi_b";
> + };
> + };
> +
> + spi_ss0_b_x_pins: spi_ss0_b_x {
> + mux {
> + groups = "spi_ss0_b_x";
> + function = "spi_b";
> + };
> + };
> };
> };
^ permalink raw reply
* [kernel-hardening][PATCH v3 1/3] arm: mm: dump: make page table dumping reusable
From: Kees Cook @ 2017-12-06 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErMHp9BBaJ8iNyjOS3nU+LUWNijL6FSOKSmVAYY_20nfB9nAQ@mail.gmail.com>
On Wed, Dec 6, 2017 at 1:45 AM, Jinbum Park <jinb.park7@gmail.com> wrote:
>>> +#ifndef __ASM_PTDUMP_H
>>> +#define __ASM_PTDUMP_H
>>> +
>>> +#ifdef CONFIG_ARM_PTDUMP_CORE
>>
>> Is this #ifdef needed? I think this file is only included in dump.c
>> and ptdump_debugfs.c, both of which are only built when
>> CONFIG_ARM_PTDUMP_CORE is defined.
>
> Looking at next patch in this patch-set series ([PATCH v3 3/3] arm:
> mm: dump: add checking for writable and executable pages),
> Not only dump.c and ptdump_debugfs.c but also arch/arm/mm/init.c
> include this file (ptdump.h) to call debug_checkwx().
> mm/init.c is not built only when CONFIG_ARM_PTDUMP_CORE is defined.
> So, This #ifdef seems not be needed for this patch, but is needed for
> this patch-set series.
>
>
>>> +static int ptdump_init(void)
>>> +{
>>> + ptdump_initialize();
>>> + return ptdump_debugfs_register(&kernel_ptdump_info,
>>> + "kernel_page_tables");
>>
>> This changes the return value of ptdump_init. This should do similar
>> to what was done before:
>>
>> return ptdump_debugfs_register(&kernel_ptdump_info,
>> "kernel_page_tables") ? 0 : -ENOMEM;
>
>
> ptdump_debugfs_register() already returns what you think.
>
>>> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
>>> +{
>>> + struct dentry *pe;
>>> +
>>> + pe = debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
>>> + return pe ? 0 : -ENOMEM;
>>> +
>>> +}
>
> So "return ptdump_debugfs_register(~~)" is fine.
Ah! Yes, I totally missed the change from create_file to
debugfs_register. Sorry for the noise!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] ACPI / GED: unregister interrupts during shutdown
From: Rafael J. Wysocki @ 2017-12-06 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0iaursWFP_KRoJqT6-QoGkvpTot0oMvs6qdjkaP12p9jQ@mail.gmail.com>
Hi Greg,
On Wed, Dec 6, 2017 at 6:16 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Dec 6, 2017 at 5:55 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 12/6/2017 11:41 AM, Rafael J. Wysocki wrote:
>>> On Wed, Dec 6, 2017 at 5:11 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>>>> On 12/6/2017 9:57 AM, Sinan Kaya wrote:
>>>>>> Yes, it should, so I'm not sure why you need the list in the first place.
>>>>>>
>>>>>> Also it looks like something along the lines of devres_release_all()
>>>>>> should be sufficient.
>>>>> Good suggestion, let me test this.
>>>>>
>>>>
>>>> I tried to pull the code into GED but the API is not public. I also looked
>>>> at how it is used. I was afraid to mess up with the internals of base.c by
>>>> calling devres_release_all() externally first and by the driver framework
>>>> next. I moved away from this approach.
>>>
>>> Are you sure it is called by the core in the shutdown path?
>>
>> Sorry, I was thinking about a general case not the shutdown path. If we open
>> this API and have device drivers call it from arbitrary places; then we could
>> be opening a new can of worms that show up during device driver removal.
[cut]
>
> OK
>
> Anyway, it looks like something is missing in the core.
>
> You shouldn't really need to do all that dance in a driver.
We have a problem with the ACPI GED driver which essentially is a
platform driver requesting a number of interrupts and handling them by
dispatching a specific AML method.
It uses devm_request_threaded_irq() to request the interrupts, so it
doesn't need a ->remove() callback, but it turns out to need a
->shutdown() one to free all of these interrupts at the shutdown time.
While we can add a ->shutdown() callback to it, that essentially needs
to duplicate devres_release_all() somewhat.
Any suggestions what to do with that?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Christoph Hellwig @ 2017-12-06 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206072402.11694-4-o.rempel@pengutronix.de>
> void (*pm_power_off_prepare)(void);
> +EXPORT_SYMBOL(pm_power_off_prepare);
EXPORT_SYMBOL_GPL for something this deeply internal, please.
^ permalink raw reply
* [PATCH] net: ethernet: arc: fix error handling in emac_rockchip_probe
From: Branislav Radocaj @ 2017-12-06 23:07 UTC (permalink / raw)
To: linux-arm-kernel
If clk_set_rate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Branislav Radocaj <branislav@radocaj.org>
---
drivers/net/ethernet/arc/emac_rockchip.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index e278e3d96ee0..c6163874e4e7 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -220,9 +220,11 @@ static int emac_rockchip_probe(struct platform_device *pdev)
/* RMII TX/RX needs always a rate of 25MHz */
err = clk_set_rate(priv->macclk, 25000000);
- if (err)
+ if (err) {
dev_err(dev,
"failed to change mac clock rate (%d)\n", err);
+ goto out_clk_disable_macclk;
+ }
}
err = arc_emac_probe(ndev, interface);
@@ -232,7 +234,8 @@ static int emac_rockchip_probe(struct platform_device *pdev)
}
return 0;
-
+out_clk_disable_macclk:
+ clk_disable_unprepare(priv->macclk);
out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);
--
2.11.0
^ permalink raw reply related
* [PATCH 03/45] drivers: gpio: remove duplicate includes
From: Gregory Fong @ 2017-12-06 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512439104-15507-1-git-send-email-pravin.shedge4linux@gmail.com>
Hi Pravin,
On Mon, Dec 4, 2017 at 5:58 PM, Pravin Shedge
<pravin.shedge4linux@gmail.com> wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
> ---
> drivers/gpio/gpio-brcmstb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> index 545d43a..f40ec39 100644
> --- a/drivers/gpio/gpio-brcmstb.c
> +++ b/drivers/gpio/gpio-brcmstb.c
> @@ -11,7 +11,6 @@
> * GNU General Public License for more details.
> */
>
> -#include <linux/bitops.h>
Please remove the second entry at the end of the include list instead
of this one, since that is the duplicate added accidentally in
d74423687f9d70417bfec68121cbd35f79bb170f "gpio: brcmstb: Do not use
gc->pin2mask()" [1].
> #include <linux/gpio/driver.h>
> #include <linux/of_device.h>
> #include <linux/of_irq.h>
Thanks,
Gregory
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpio/gpio-brcmstb.c?id=d74423687f9d70417bfec68121cbd35f79bb170f
^ permalink raw reply
* [PATCH v2] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
From: Tony Lindgren @ 2017-12-06 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206214916.2856657-1-arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [171206 21:52]:
> In configurations without CONFIG_OMAP3 but with secure RAM support,
> we now run into a link failure:
>
> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
>
> The omap3_save_secure_ram() function is only called from the OMAP34xx
> power management code, so we can simply hide that function in the
> appropriate #ifdef.
>
> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: also check for CONFIG_PM
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
From: Tony Lindgren @ 2017-12-06 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a13Or8OvttqiKo8Qg2q6UJwQPg0E5TGb02LUb+p8nB3kw@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [171206 21:51]:
> On Wed, Dec 6, 2017 at 5:29 PM, Dan Murphy <dmurphy@ti.com> wrote:
> > Arnd
> >
> > On 12/06/2017 09:57 AM, Tony Lindgren wrote:
> >> * Arnd Bergmann <arnd@arndb.de> [171206 14:18]:
> >>> In configurations without CONFIG_OMAP3 but with secure RAM support,
> >>> we now run into a link failure:
> >>>
> >>> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
> >>> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
> >>>
> >>> The omap3_save_secure_ram() function is only called from the OMAP34xx
> >>> power management code, so we can simply hide that function in the
> >>> appropriate #ifdef.
> >>>
> >>> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
> >>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Thanks for fixing it, want to apply directly to ARM SoC fixes
> >> where d09220a887f7 is now? If so:
> >>
> >> Acked-by: Tony Lindgren <tony@atomide.com>
> >
> > Found the same issue in our builds.
> > Compile tested the patch against different TI defconfig configurations.
> >
> > Tested-by: Dan Murphy <dmurphy@ti.com>
>
> Thanks!
>
> Unfortunately, I found another build problem with CONFIG_PM=n,
> sent an updated patch now, and will apply it to the fixes branch
> tomorrow keeping both of your Acked-by/Tested-by tags, unless
> I hear any objections or run into a third problem.
OK thanks works for me.
Tony
^ permalink raw reply
* [PATCH v3 04/15] dt-bindings: display: sun4i-drm: Add A83T pipeline
From: Rob Herring @ 2017-12-06 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3762a8428aaf207e80ae86d4db2e50473576bb6d.1512486553.git-series.maxime.ripard@free-electrons.com>
On Tue, Dec 05, 2017 at 04:10:16PM +0100, Maxime Ripard wrote:
> The A83T has two video pipelines in parallel that looks quite similar to
> the other SoCs.
>
> The video planes are handled through a controller called the mixer, and the
> video signal is then passed to the timing controller (TCON).
>
> And while there is two instances of the mixers and TCONs, they have a
> significant number of differences. The TCONs are quite easy to deal with,
> one is supposed to generate TV (in the broader term, so including things
> like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
> while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
> call them TCON-TV and TCON-LCD, which seems more appropriate.
>
> However, the mixers differ mostly by their capabilities, with some features
> being available only in the first one, or the number of planes they expose,
> but also through their register layout. And while the capabilities could be
> represented as properties, the register layout differences would need to
> express all the registers offsets as properties, which is usually quite
> bad. Especially since documentation on that hardware block is close to
> non-existant and we don't even have the list of all those registers in the
> first place.
>
> So let's call them mixer 0 and 1 in our compatibles, even though the name
> is pretty bad...
>
> At the moment, we only have tested the code on a board that has a single
> display output, so we're leaving the tcon-tv and mixer1 out.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties
From: Rob Herring @ 2017-12-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17851ba6277b69aa9cd81de5eead62bfed271661.1512486553.git-series.maxime.ripard@free-electrons.com>
On Tue, Dec 05, 2017 at 04:10:15PM +0100, Maxime Ripard wrote:
> Some clocks and resets supposed to drive the LVDS logic in the display
> engine have been overlooked when the driver was first introduced.
>
> Add those additional resources to the binding, and we'll deal with the ABI
> stability in the code.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 8 +++++++-
> 1 file changed, 8 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 01/15] dt-bindings: panel: lvds: Document power-supply property
From: Rob Herring @ 2017-12-06 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <97ebf0615821d79e8d7718594fe3a542a743a05f.1512486553.git-series.maxime.ripard@free-electrons.com>
On Tue, Dec 05, 2017 at 04:10:13PM +0100, Maxime Ripard wrote:
> The power-supply property is used by a vast majority of panels, including
> panel-simple. Let's document it as a common property
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++++++
> Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 +
> Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
> 3 files changed, 8 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: Rob Herring @ 2017-12-06 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205140646.30367-2-linux-kernel-dev@beckhoff.com>
On Tue, Dec 05, 2017 at 03:06:42PM +0100, linux-kernel-dev at beckhoff.com wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> Document the binding for i.MX53 SRTC implemented by rtc-mxc_v2
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com><Paste>
>
> ---
>
> To: Alessandro Zummo <a.zummo@towertech.it>
> To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Cc: linux-rtc at vger.kernel.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
> Cc: devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Cc: linux-kernel at vger.kernel.org (open list)
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Juergen Borleis <jbe@pengutronix.de>
> Cc: Noel Vellemans <Noel.Vellemans@visionbms.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
> Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
> Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
>
> Cc: Philippe Ombredanne <pombredanne@nexb.com>
> Cc: Lothar Wa?mann <LW@KARO-electronics.de>
> ---
> Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
> new file mode 100644
> index 000000000000..796e7f4995db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
> @@ -0,0 +1,17 @@
> +* i.MX53 Real Time Clock controller
> +
> +Required properties:
> +- compatible: should be: "fsl,imx53-rtc"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- clocks: should contain the phandle for the rtc clock
Shouldn't there be more than 1 here. From what I remember, the ipg clock
and the 32k clock?
> +- interrupts: rtc alarm interrupt
> +
> +Example:
> +
> +srtc at 53fa4000 {
rtc at ...
> + compatible = "fsl,imx53-rtc";
> + reg = <0x53fa4000 0x4000>;
> + interrupts = <24>;
> + clocks = <&clks IMX5_CLK_SRTC_GATE>;
> +};
> --
> 2.11.0
^ permalink raw reply
* [PATCH V2] ARM: dts: bcm283x: Fix probing of bcm2835-i2s
From: Eric Anholt @ 2017-12-06 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1511717111-6055-1-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
> the bcm2835-i2s requires a clock as DT property. Unfortunately
> the necessary DT change has never been applied. While we are at it
> also fix the first PCM register range to cover the PCM_GRAY register.
>
> This patch also fixes the dt-bindings accordlingly.
>
> Fixes: 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> Tested-by: Matthias Reichl <hias@horus.com>
DT folks, are you happy with the binding change here? It fixes having
the i2s node also map a very separate hardware block (clocks) which has
its own DT node.
The I2S node is disabled in the upstream DT files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/e6d75109/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
From: Arnd Bergmann @ 2017-12-06 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a055eca0-fa24-a04a-7278-f633a12e6bae@ti.com>
On Wed, Dec 6, 2017 at 5:29 PM, Dan Murphy <dmurphy@ti.com> wrote:
> Arnd
>
> On 12/06/2017 09:57 AM, Tony Lindgren wrote:
>> * Arnd Bergmann <arnd@arndb.de> [171206 14:18]:
>>> In configurations without CONFIG_OMAP3 but with secure RAM support,
>>> we now run into a link failure:
>>>
>>> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
>>> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
>>>
>>> The omap3_save_secure_ram() function is only called from the OMAP34xx
>>> power management code, so we can simply hide that function in the
>>> appropriate #ifdef.
>>>
>>> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> Thanks for fixing it, want to apply directly to ARM SoC fixes
>> where d09220a887f7 is now? If so:
>>
>> Acked-by: Tony Lindgren <tony@atomide.com>
>
> Found the same issue in our builds.
> Compile tested the patch against different TI defconfig configurations.
>
> Tested-by: Dan Murphy <dmurphy@ti.com>
Thanks!
Unfortunately, I found another build problem with CONFIG_PM=n,
sent an updated patch now, and will apply it to the fixes branch
tomorrow keeping both of your Acked-by/Tested-by tags, unless
I hear any objections or run into a third problem.
Arnd
^ permalink raw reply
* [PATCH v2] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
From: Arnd Bergmann @ 2017-12-06 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In configurations without CONFIG_OMAP3 but with secure RAM support,
we now run into a link failure:
arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
The omap3_save_secure_ram() function is only called from the OMAP34xx
power management code, so we can simply hide that function in the
appropriate #ifdef.
Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: also check for CONFIG_PM
arch/arm/mach-omap2/omap-secure.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
index f9303dc631e4..55b967758bb3 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -72,6 +72,7 @@ phys_addr_t omap_secure_ram_mempool_base(void)
return omap_secure_memblock_base;
}
+#if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
u32 omap3_save_secure_ram(void __iomem *addr, int size)
{
u32 ret;
@@ -90,6 +91,7 @@ u32 omap3_save_secure_ram(void __iomem *addr, int size)
return ret;
}
+#endif
/**
* rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
--
2.9.0
^ permalink raw reply related
* [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Rob Herring @ 2017-12-06 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512397671-28733-1-git-send-email-awallis@codeaurora.org>
On Mon, Dec 04, 2017 at 09:27:51AM -0500, Adam Wallis wrote:
> The xHCI driver currently has the IMOD set to 160, which
> translates to an IMOD interval of 40,000ns (160 * 250)ns
>
> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
> introduced a QUIRK for the MTK platform to adjust this interval to 20,
> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
> due to the fact that the MTK controller IMOD interval is 8 times
> as much as defined in xHCI spec.
>
> Instead of adding more quirk bits for additional platforms, this patch
> introduces the ability for vendors to set the IMOD_INTERVAL as is
> optimal for their platform. By using device_property_read_u32() on
> "imod-interval-ns", the IMOD INTERVAL can be specified in nano seconds.
> If no interval is specified, the default of 40,000ns (IMOD=160) will be
> used.
>
> No bounds checking has been implemented due to the fact that a vendor
> may have violated the spec and would need to specify a value outside of
> the max 8,000 IRQs/second limit specified in the xHCI spec.
>
> Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> Signed-off-by: Adam Wallis <awallis@codeaurora.org>
> ---
> changes from v3:
> * Changed imod-interval to imod-interval-ns [Rob Herring/Chunfeng]
> * Changed "modulation" to "moderation" throughout patch [Mathias]
> changes from v2:
> * Added PCI default value [Mathias]
> * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
> * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
> * Updated bindings Documentation to use proper units [Rob Herring]
> * Added imod-interval description and example to MTK binding documentation
> changes from v1:
> * Removed device_property_read_u32() per suggestion from greg k-h
> * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
>
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
> drivers/usb/host/xhci-mtk.c | 9 +++++++++
> drivers/usb/host/xhci-pci.c | 3 +++
> drivers/usb/host/xhci-plat.c | 5 +++++
> drivers/usb/host/xhci.c | 7 ++-----
> drivers/usb/host/xhci.h | 2 ++
> 7 files changed, 24 insertions(+), 5 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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