* [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
From: Geert Uytterhoeven @ 2017-10-05 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1507193900-23801-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for ETHER pin group and enable the interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -88,3 +110,19 @@
>
> status = "okay";
> };
> +
> +ðer {
> + pinctrl-names = "default";
> + pinctrl-0 = <ðer_pins>;
> +
> + status = "okay";
> +
> + reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> + reset-delay-us = <5>;
I'm afraid the PHY people (not CCed ;-) will want you to move these reset
properties to the phy subnode these days, despite
Documentation/devicetree/bindings/net/mdio.txt...
> +
> + renesas,no-ether-link;
> + phy-handle = <&phy0>;
> + phy0: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
From: Geert Uytterhoeven @ 2017-10-05 9:09 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1507193900-23801-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for ETHER pin group and enable the interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -88,3 +110,19 @@
>
> status = "okay";
> };
> +
> +ðer {
> + pinctrl-names = "default";
> + pinctrl-0 = <ðer_pins>;
> +
> + status = "okay";
> +
> + reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> + reset-delay-us = <5>;
I'm afraid the PHY people (not CCed ;-) will want you to move these reset
properties to the phy subnode these days, despite
Documentation/devicetree/bindings/net/mdio.txt...
> +
> + renesas,no-ether-link;
> + phy-handle = <&phy0>;
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/3] hmp-commands-info: Texinfo fixes
From: Dr. David Alan Gilbert @ 2017-10-05 9:09 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-devel
In-Reply-To: <20171002134538.23332-1-armbru@redhat.com>
* Markus Armbruster (armbru@redhat.com) wrote:
> Markus Armbruster (3):
> hmp-commands-info: Fix "info rocker-FOO" misspellings
> hmp-commands-info: Move Texinfo stanzas to conventional place
> hmp-commands-info: Change "@findex FOO" to "@findex info FOO"
Queued for HMP
> hmp-commands-info.hx | 138 +++++++++++++++++++++++++--------------------------
> 1 file changed, 69 insertions(+), 69 deletions(-)
>
> --
> 2.13.6
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [stable backport] stable-4.4 warning with gcc-7
From: gregkh @ 2017-10-05 9:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: stable
In-Reply-To: <CAK8P3a2eHMyyrRQrHtHBUPf73ovpdrL06ZWOQvNBT-7Oiw78yQ@mail.gmail.com>
On Wed, Oct 04, 2017 at 04:01:10PM +0200, Arnd Bergmann wrote:
> Please backport
>
> 1d2d8de44a6c ("drivers: firmware: psci: drop duplicate const from
> psci_of_match")
>
> to avoid this warning:
>
> drivers/firmware/psci.c:427:34: error: duplicate 'const' declaration
> specifier [-Werror=duplicate-decl-specifier]
Now applied, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: draak: enable PWM channel 0 and 1
From: Simon Horman @ 2017-10-05 9:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Magnus Damm, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdX8+jOYuhMFXoPX93VrRWiBUvwDjaL+4ZaFPenSV8i6vw@mail.gmail.com>
On Wed, Oct 04, 2017 at 04:38:08PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 4, 2017 at 12:27 PM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > This patch enables PWM channel 0 and 1 on the draak. Each channel
> > connects to LTC2644 for brightness control.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: draak: enable PWM channel 0 and 1
From: Simon Horman @ 2017-10-05 9:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdX8+jOYuhMFXoPX93VrRWiBUvwDjaL+4ZaFPenSV8i6vw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Oct 04, 2017 at 04:38:08PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 4, 2017 at 12:27 PM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> > This patch enables PWM channel 0 and 1 on the draak. Each channel
> > connects to LTC2644 for brightness control.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net: qcom/emac: make function emac_isr static
From: Colin King @ 2017-10-05 9:10 UTC (permalink / raw)
To: Timur Tabi, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The function emac_isr is local to the source and does not need to
be in global scope, so make it static.
Cleans up sparse warnings:
symbol 'emac_isr' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qualcomm/emac/emac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 759543512117..f477ba29c569 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -130,7 +130,7 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *netdev)
return emac_mac_tx_buf_send(adpt, &adpt->tx_q, skb);
}
-irqreturn_t emac_isr(int _irq, void *data)
+static irqreturn_t emac_isr(int _irq, void *data)
{
struct emac_irq *irq = data;
struct emac_adapter *adpt --
2.14.1
^ permalink raw reply related
* [PATCH] net: qcom/emac: make function emac_isr static
From: Colin King @ 2017-10-05 9:10 UTC (permalink / raw)
To: Timur Tabi, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The function emac_isr is local to the source and does not need to
be in global scope, so make it static.
Cleans up sparse warnings:
symbol 'emac_isr' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qualcomm/emac/emac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 759543512117..f477ba29c569 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -130,7 +130,7 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *netdev)
return emac_mac_tx_buf_send(adpt, &adpt->tx_q, skb);
}
-irqreturn_t emac_isr(int _irq, void *data)
+static irqreturn_t emac_isr(int _irq, void *data)
{
struct emac_irq *irq = data;
struct emac_adapter *adpt =
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: Add git repository to Renesas clock driver section
From: Simon Horman @ 2017-10-05 9:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-renesas-soc,
linux-kernel
In-Reply-To: <1507116864-17219-1-git-send-email-geert+renesas@glider.be>
On Wed, Oct 04, 2017 at 01:34:24PM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61d77c8037a1faf9..d23f4fba728d091a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11476,6 +11476,7 @@ F: include/linux/rpmsg/
> RENESAS CLOCK DRIVERS
> M: Geert Uytterhoeven <geert+renesas@glider.be>
> L: linux-renesas-soc@vger.kernel.org
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git clk-renesas
> S: Supported
> F: drivers/clk/renesas/
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add git repository to Renesas pinctrl driver section
From: Simon Horman @ 2017-10-05 9:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Laurent Pinchart, linux-gpio, linux-renesas-soc,
linux-kernel
In-Reply-To: <1507116912-17362-1-git-send-email-geert+renesas@glider.be>
On Wed, Oct 04, 2017 at 01:35:12PM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6e018e720152c98c..61d77c8037a1faf9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10675,6 +10675,7 @@ PIN CONTROLLER - RENESAS
> M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> M: Geert Uytterhoeven <geert+renesas@glider.be>
> L: linux-renesas-soc@vger.kernel.org
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git sh-pfc
> S: Maintained
> F: drivers/pinctrl/sh-pfc/
>
> --
> 2.7.4
>
^ permalink raw reply
* couple questions about git "logical variables" and "git var"
From: rpjday @ 2017-10-05 9:11 UTC (permalink / raw)
To: git
i just ran across "git var" for the first time, and it seems a bit weird.
it refers to the (apparently) four git "logical variables":
- GIT_AUTHOR_IDENT
- GIT_COMMITTER_IDENT
- GIT_EDITOR
- GIT_PAGER
first question -- what is it about precisely those four variables that makes
them "logical" variables in git parlance? just those four? no others?
also, the man page "man git-var" seems wrong:
"OPTIONS
-l
Cause the logical variables to be listed. In addition, all the variables
of the Git configuration file .git/config are listed as well."
no, if i run "git var -l", i see not only the logical variables, but i
see *all* of the available config settings (system and global), not just
those in .git/config (unless i'm misreading what that is supposed to mean).
thoughts?
rday
p.s. yes, i realize this command is deprecated in favour of "git config -l",
but as long as it's available, it should work as described in the man page.
^ permalink raw reply
* Re: [PATCH 1/3] iio: adc: rcar-gyroadc: Cast pointer to uintptr_t to fix warning on 64-bit
From: Simon Horman @ 2017-10-05 9:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jonathan Cameron, Marek Vasut, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-renesas-soc
In-Reply-To: <1507118906-8946-2-git-send-email-geert+renesas@glider.be>
On Wed, Oct 04, 2017 at 02:08:24PM +0200, Geert Uytterhoeven wrote:
> On 64-bit:
>
> drivers/iio/adc/rcar-gyroadc.c: In function 'rcar_gyroadc_parse_subdevs':
> drivers/iio/adc/rcar-gyroadc.c:352:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> childmode = (unsigned int)of_id->data;
> ^
>
> Cast the pointer to uintptr_t instead of unsigned int to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: rcar-gyroadc: Enable compile-testing on non-ARM
From: Simon Horman @ 2017-10-05 9:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jonathan Cameron, Marek Vasut, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-renesas-soc
In-Reply-To: <1507118906-8946-3-git-send-email-geert+renesas@glider.be>
On Wed, Oct 04, 2017 at 02:08:25PM +0200, Geert Uytterhoeven wrote:
> The rcar-gyroadc driver compiles fine on other platforms, hence increase
> compile coverage.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 0/9] Add support for AES-CCM
From: Zhang, Roy Fan @ 2017-10-05 9:12 UTC (permalink / raw)
To: De Lara Guarch, Pablo, Doherty, Declan, Trahe, Fiona,
Jain, Deepak K, Griffin, John
Cc: dev@dpdk.org, De Lara Guarch, Pablo
In-Reply-To: <20170921131123.16513-1-pablo.de.lara.guarch@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, September 21, 2017 2:11 PM
> To: Doherty, Declan <declan.doherty@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Jain, Deepak K <deepak.k.jain@intel.com>; Griffin,
> John <john.griffin@intel.com>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH v2 0/9] Add support for AES-CCM
>
> AES-CCM support is added in the OpenSSL and QAT PMDs.
> The PMDs and the test code have been reworked, to avoid duplications with
> AES-GCM code, as both algorithms are quite similar (both are AEAD
> algorithms).
>
> Also, an optimization for AES-GCM (and AES-CCM after the last patch) has
> been introduced, initializing the OpenSSL Context with the key, at session
> creation, instead of for each operation.
>
> Changes in v2:
> - Clarified API for AES-CCM
> - Modified OpenSSL PMD and sample apps to comply with API
> - Added support for AES-CCM in QAT
> - Extended test cases for 192 and 256 bit keys
Series Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply
* [PATCH v2] perf callchain: Compare dsos (as well) for CCKEY_FUNCTION
From: Ravi Bangoria @ 2017-10-05 9:12 UTC (permalink / raw)
To: pozdneyev, acme, linux-kernel, jolsa, namhyung
Cc: linux-perf-users, peterz, mingo, alexander.shishkin, yao.jin, ak,
kjlx, milian.wolff, zhangmengting, Ravi Bangoria
In-Reply-To: <20171005041355.GB1584@danjae.aot.lge.com>
Two functions from different binaries can have same start
address. Thus, comparing only start address in match_chain()
leads to inconsistent callchains. Fix this by adding a check
for dsos as well.
Ex, https://www.spinics.net/lists/linux-perf-users/msg04067.html
Reported-by: Alexander Pozdneev <pozdneyev@gmail.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
---
Changes in v2:
- Remove unnecessary checks for 'map'
tools/perf/util/callchain.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index be09d77..a971caf 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -685,6 +685,8 @@ static enum match_result match_chain(struct callchain_cursor_node *node,
{
struct symbol *sym = node->sym;
u64 left, right;
+ struct dso *left_dso = NULL;
+ struct dso *right_dso = NULL;
if (callchain_param.key == CCKEY_SRCLINE) {
enum match_result match = match_chain_srcline(node, cnode);
@@ -696,12 +698,14 @@ static enum match_result match_chain(struct callchain_cursor_node *node,
if (cnode->ms.sym && sym && callchain_param.key == CCKEY_FUNCTION) {
left = cnode->ms.sym->start;
right = sym->start;
+ left_dso = cnode->ms.map->dso;
+ right_dso = node->map->dso;
} else {
left = cnode->ip;
right = node->ip;
}
- if (left == right) {
+ if (left == right && left_dso == right_dso) {
if (node->branch) {
cnode->branch_count++;
--
1.8.3.1
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device
From: Igor Mammedov @ 2017-10-05 9:12 UTC (permalink / raw)
To: Thomas Huth
Cc: Eduardo Habkost, Paolo Bonzini, qemu-devel,
Dr. David Alan Gilbert, Markus Armbruster
In-Reply-To: <5165bbdd-b36a-ab89-e819-c85a788f8415@redhat.com>
On Thu, 5 Oct 2017 11:00:29 +0200
Thomas Huth <thuth@redhat.com> wrote:
> On 05.10.2017 10:36, Igor Mammedov wrote:
> > On Tue, 3 Oct 2017 15:49:46 -0300
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> >> On Tue, Oct 03, 2017 at 06:46:02PM +0200, Thomas Huth wrote:
> >>> The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
> >>> so QEMU crashes when the user tries to device_add + device_del a device
> >>> that does not have a corresponding hotplug controller. This could be
> >>> provoked for a couple of devices in the past (see commit 4c93950659487c7ad
> >>> or 84ebd3e8c7d4fe955 for example). So devices clearly need a hotplug
> >>> controller when they are suitable for device_add.
> >>> The code in qdev_device_add() already checks whether the bus has a proper
> >>> hotplug controller, but for devices that do not have a corresponding bus,
> >>> there is no appropriate check available. In that case we should check
> >>> whether the machine itself provides a suitable hotplug controller and
> >>> refuse to plug the device if none is available.
> >>>
> >>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >>> ---
> >>> This is the follow-up patch from my earlier try "hw/core/qdev: Do not
> >>> allow hot-plugging without hotplug controller" ... AFAICS the function
> >>> qdev_device_add() is now the right spot to do the check.
> >>>
> >>> hw/core/qdev.c | 28 ++++++++++++++++++++--------
> >>> include/hw/qdev-core.h | 1 +
> >>> qdev-monitor.c | 9 +++++++++
> >>> 3 files changed, 30 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> >>> index 606ab53..a953ec9 100644
> >>> --- a/hw/core/qdev.c
> >>> +++ b/hw/core/qdev.c
> >>> @@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
> >>> dev->alias_required_for_version = required_for_version;
> >>> }
> >>>
> >>> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
> >>> +{
> >>> + MachineState *machine;
> >>> + MachineClass *mc;
> >>> + Object *m_obj = qdev_get_machine();
> >>> +
> >>> + if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
> >>> + machine = MACHINE(m_obj);
> >>> + mc = MACHINE_GET_CLASS(machine);
> >>> + if (mc->get_hotplug_handler) {
> >>> + return mc->get_hotplug_handler(machine, dev);
> >>> + }
> >>> + }
> >>> +
> >>> + return NULL;
> >>> +}
> >>> +
> >>> HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
> >>> {
> >>> - HotplugHandler *hotplug_ctrl = NULL;
> >>> + HotplugHandler *hotplug_ctrl;
> >>>
> >>> if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
> >>> hotplug_ctrl = dev->parent_bus->hotplug_handler;
> >>> - } else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
> >>> - MachineState *machine = MACHINE(qdev_get_machine());
> >>> - MachineClass *mc = MACHINE_GET_CLASS(machine);
> >>> -
> >>> - if (mc->get_hotplug_handler) {
> >>> - hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
> >>> - }
> >>> + } else {
> >>> + hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
> >>> }
> >>> return hotplug_ctrl;
> >>> }
> >>> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> >>> index 0891461..5aa536d 100644
> >>> --- a/include/hw/qdev-core.h
> >>> +++ b/include/hw/qdev-core.h
> >>> @@ -285,6 +285,7 @@ DeviceState *qdev_try_create(BusState *bus, const char *name);
> >>> void qdev_init_nofail(DeviceState *dev);
> >>> void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
> >>> int required_for_version);
> >>> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
> >>> HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
> >>> void qdev_unplug(DeviceState *dev, Error **errp);
> >>> void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
> >>> diff --git a/qdev-monitor.c b/qdev-monitor.c
> >>> index 8fd6df9..2891dde 100644
> >>> --- a/qdev-monitor.c
> >>> +++ b/qdev-monitor.c
> >>> @@ -626,6 +626,15 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
> >>> return NULL;
> >>> }
> >>>
> >>> + /* In case we don't have a bus, there must be a machine hotplug handler */
> >>> + if (qdev_hotplug && !bus && !qdev_get_machine_hotplug_handler(dev)) {
> >>> + error_setg(errp, "Device '%s' can not be hotplugged on this machine",
> >>> + driver);
> >>> + object_unparent(OBJECT(dev));
> >>
> >> Isn't it better to check qdev_get_machine_hotplug_handler()
> >> earlier (before the qdev_set_parent_bus() and qdev_set_id()
> >> lines), so object_unparent() isn't necessary?
> >>
> >> (We probably don't need to call object_unparent() here, already,
> >> because bus is NULL. But moving the check before the "if (bus)
> >> qdev_set_parent_bus()" statement would make this more obvious).
> > it might be bus or bus-less device, so making check before
> > qdev_set_parent_bus() should be simpler.
>
> The check for devices that have a bus is already done earlier in this
> function ("if (qdev_hotplug && bus && !qbus_is_hotpluggable(bus))") ...
> but yes, I'll move the new check for bus-less devices a little bit
> earlier so that the unparent is not necessary anymore.
>
> >> I would prefer to eventually make
> >> MachineClass::get_hotplug_handler() get a typename or
> >> DeviceClass* argument instead of DeviceState*, so we don't even
> >> create the device object. But I don't think it's a requirement
> >> for this bug fix.
> > choice of hotplug handler might theoretically depend on plugged
> > device instance (over-engineered? as far as I recall none does it so far)
>
> Yes, currently we might be able to do it with the typename only ... but
> that seems to be a rather big rework right now, and we might indeed need
> a real device instance later again, so I'd prefer to rather not do that
> rework right now.
it was just remark why it uses 'dev' and a call for an action.
>
> >>> + object_unref(OBJECT(dev));
> >>> + return NULL;
> >>> + }
> > wrt error exit path, I'd rework error path in qdev_device_add() in separate patch first
> > to look like it is in device_set_realized() and then just jump to appropriate label
> > from here.
>
> Ok, I can have a try whether that looks better.
the function already has couple error exit point that
duplicate cleanup steps, so it probably would read better
with cleanup
>
> Thomas
>
^ permalink raw reply
* Re: [PATCH 3/3] iio: adc: rcar-gyroadc: Use of_device_get_match_data() helper
From: Simon Horman @ 2017-10-05 9:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jonathan Cameron, Marek Vasut, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-renesas-soc
In-Reply-To: <1507118906-8946-4-git-send-email-geert+renesas@glider.be>
On Wed, Oct 04, 2017 at 02:08:26PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding.
> Note that the rcar-gyroadc driver is used with DT only, so there's
> always a valid match.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 11/12] crypto/dpaa2_sec: add support for protocol offload ipsec
From: De Lara Guarch, Pablo @ 2017-10-05 9:13 UTC (permalink / raw)
To: Akhil Goyal, dev@dpdk.org
Cc: Doherty, Declan, hemant.agrawal@nxp.com, Nicolau, Radu,
borisp@mellanox.com, aviadye@mellanox.com, thomas@monjalon.net,
sandeep.malik@nxp.com, jerin.jacob@caviumnetworks.com,
Mcnamara, John, olivier.matz@6wind.com
In-Reply-To: <20171003131413.23846-12-akhil.goyal@nxp.com>
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, October 3, 2017 2:14 PM
> To: dev@dpdk.org
> Cc: Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; hemant.agrawal@nxp.com; Nicolau,
> Radu <radu.nicolau@intel.com>; borisp@mellanox.com;
> aviadye@mellanox.com; thomas@monjalon.net; sandeep.malik@nxp.com;
> jerin.jacob@caviumnetworks.com; Mcnamara, John
> <john.mcnamara@intel.com>; olivier.matz@6wind.com
> Subject: [PATCH v2 11/12] crypto/dpaa2_sec: add support for protocol
> offload ipsec
>
> driver implementation to support rte_security APIs
>
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
...
> +/**
> + * Checksum
> + *
> + * @param buffer calculate chksum for buffer
> + * @param len buffer length
> + *
> + * @return checksum value in host cpu order */ static inline uint16_t
Tiny comment. Return type should be in a separate line.
> +calc_chksum(void *buffer, int len) {
^ permalink raw reply
* Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r
From: Jeff King @ 2017-10-05 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Derrick Stolee, git, stolee, git, sbeller
In-Reply-To: <xmqqtvzfcuoy.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 04, 2017 at 03:07:25PM +0900, Junio C Hamano wrote:
> > - exists = has_sha1_file(sha1);
> > - while (len < GIT_SHA1_HEXSZ) {
> > - struct object_id oid_ret;
> > - status = get_short_oid(hex, len, &oid_ret, GET_OID_QUIETLY);
> > - if (exists
> > - ? !status
> > - : status == SHORT_NAME_NOT_FOUND) {
> > - hex[len] = 0;
> > - return len;
> > - }
> > - len++;
> > - }
> > - return len;
>
> The "always_call_fn" thing is a big sledgehammer that overrides
> everything else in update_candidates(). It bypasses the careful
> machinery set up to avoid having to open ambiguous object to learn
> their types as much as possible. One narrow exception when it is OK
> to use is if we never limit our candidates with type.
>
> And it might appear that the conversion is safe (if only because we
> do not see any type limitation in the get_short_oid() call above),
> but I think there is one case where this patch changes the
> behaviour: what happens if core.disambiguate was set to anything
> other than "none"? The new code does not know anything about type
> based filtering, so it can end up reporting longer abbreviation than
> it was asked to produce. It may not be a problem in practice, though.
>
> I am not sure if setting core.disambiguate is generally a good idea
> in the first place, and if it is OK to break find_unique_abbrev()
> with respect to the configuration variable like this patch does.
>
> I'd feel safe if we get extra input from Peff, who introduced the
> feature in 5b33cb1f ("get_short_sha1: make default disambiguation
> configurable", 2016-09-27).
Regarding core.disambiguate, I _do_ think it's reasonable to set it to
"commit" or "committish". And in fact I have meant to revisit the idea
of doing so by default (the reason it was made into config at all was to
let people play around with it and gain experience).
That said, I think it's entirely reasonable for find_unique_abbrev() to
ignore type-based disambiguation entirely.
The type disambiguation is really a property of the context in which we
do a lookup. And that context is not necessarily known to the generating
side. Even core.disambiguate is not universal, as command-specific
context overrides it.
So I think on the generating side we are better off creating a slightly
longer abbreviation that is unambiguous no matter what context it is
used in. I.e., I'd argue that it's actually more _correct_ to ignore
the disambiguation code entirely on the generating side.
And it should also be faster, because it turns the abbreviation search
into a purely textual one that never has to look at extra objects. And
that speed matters a lot more on the generating side, where we tend to
output long lists of abbreviated sha1s in commands like "git log" (as
opposed to the lookup side, where we're asked to find some particular
item of interest).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Michal Hocko @ 2017-10-05 7:57 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, Alan Cox, Christoph Hellwig, linux-mm,
linux-kernel, kernel-team
In-Reply-To: <20171004231821.GA3610@cmpxchg.org>
On Wed 04-10-17 19:18:21, Johannes Weiner wrote:
> On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote:
[...]
> > You don't think they should be backported into -stables?
>
> Good point. For this one, it makes sense to CC stable, for 4.11 and
> up. The second patch is more of a fortification against potential
> future issues, and probably shouldn't go into stable.
I am not against. It is true that the memory reserves depletion fix was
theoretical because I haven't seen any real life bug. I would argue that
the more robust allocation failure behavior is a stable candidate as
well, though, because the allocation can fail regardless of the vmalloc
revert. It is less likely but still possible.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Michal Hocko @ 2017-10-05 7:57 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, Alan Cox, Christoph Hellwig, linux-mm,
linux-kernel, kernel-team
In-Reply-To: <20171004231821.GA3610@cmpxchg.org>
On Wed 04-10-17 19:18:21, Johannes Weiner wrote:
> On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote:
[...]
> > You don't think they should be backported into -stables?
>
> Good point. For this one, it makes sense to CC stable, for 4.11 and
> up. The second patch is more of a fortification against potential
> future issues, and probably shouldn't go into stable.
I am not against. It is true that the memory reserves depletion fix was
theoretical because I haven't seen any real life bug. I would argue that
the more robust allocation failure behavior is a stable candidate as
well, though, because the allocation can fail regardless of the vmalloc
revert. It is less likely but still possible.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
From: Michal Hocko @ 2017-10-05 7:57 UTC (permalink / raw)
To: Yang Shi
Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, linux-mm,
linux-kernel
In-Reply-To: <4b668145-a81d-6f46-0569-b0adb76788d8@alibaba-inc.com>
On Thu 05-10-17 02:08:48, Yang Shi wrote:
>
>
> On 10/4/17 7:27 AM, Michal Hocko wrote:
> > On Wed 04-10-17 02:06:17, Yang Shi wrote:
> > > +static bool is_dump_unreclaim_slabs(void)
> > > +{
> > > + unsigned long nr_lru;
> > > +
> > > + nr_lru = global_node_page_state(NR_ACTIVE_ANON) +
> > > + global_node_page_state(NR_INACTIVE_ANON) +
> > > + global_node_page_state(NR_ACTIVE_FILE) +
> > > + global_node_page_state(NR_INACTIVE_FILE) +
> > > + global_node_page_state(NR_ISOLATED_ANON) +
> > > + global_node_page_state(NR_ISOLATED_FILE) +
> > > + global_node_page_state(NR_UNEVICTABLE);
> > > +
> > > + return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
> > > +}
> >
> > I am sorry I haven't pointed this earlier (I was following only half
> > way) but this should really be memcg aware. You are checking only global
> > counters. I do not think it is an absolute must to provide per-memcg
> > data but you should at least check !is_memcg_oom(oc).
>
> BTW, I saw there is already such check in dump_header that looks like the
> below code:
>
> if (oc->memcg)
> mem_cgroup_print_oom_info(oc->memcg, p);
> else
> show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
>
> I'm supposed it'd better to replace "oc->memcg" to "is_memcg_oom(oc)" since
> they do the same check and "is_memcg_oom" interface sounds preferable.
Yes, is_memcg_oom is better
> Then I'm going to move unreclaimable slabs dump to the "else" block.
makes sense.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug
From: Cédric Le Goater @ 2017-10-05 8:18 UTC (permalink / raw)
To: Nikunj A Dadhania, David Gibson
Cc: linuxppc-dev, Michael Ellerman, Benjamin Herrenschmidt
In-Reply-To: <87infui863.fsf@localhost.localdomain.i-did-not-set--mail-host-address--so-tickle-me>
>>> I haven't yet because I fail to understand why the decrementer is not
>>> interrupting the dying CPU under xics as it is the case under XIVE.
>>
>> Oh.. ok. This sounds very similar to the problem Nikunj hit under TCG
>> with decrementer interrupts waking up a supposedly dead CPU. He had a
>> couple of proposed fixes, but we got bogged down trying to work out
>> why (with TCG at least).
>
> Yeah, I wasnt able to get to the exact reason for that.
Yes. Tracking all the CPU states is a nightmare.
* @running: #true if CPU is currently running (lockless).
* @has_waiter: #true if a CPU is currently waiting for the cpu_exec_end;
* valid under cpu_list_lock.
* @created: Indicates whether the CPU thread has been successfully created.
* @interrupt_request: Indicates a pending interrupt request.
* @halted: Nonzero if the CPU is in suspended state.
* @stop: Indicates a pending stop request.
* @stopped: Indicates the CPU has been artificially stopped.
* @unplug: Indicates a pending CPU unplug request.
I will spend some more time to understand why XICS is not behaving
the same. This is really time consuming ...
C.
^ permalink raw reply
* Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
From: Michal Hocko @ 2017-10-05 7:57 UTC (permalink / raw)
To: Yang Shi
Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, linux-mm,
linux-kernel
In-Reply-To: <4b668145-a81d-6f46-0569-b0adb76788d8@alibaba-inc.com>
On Thu 05-10-17 02:08:48, Yang Shi wrote:
>
>
> On 10/4/17 7:27 AM, Michal Hocko wrote:
> > On Wed 04-10-17 02:06:17, Yang Shi wrote:
> > > +static bool is_dump_unreclaim_slabs(void)
> > > +{
> > > + unsigned long nr_lru;
> > > +
> > > + nr_lru = global_node_page_state(NR_ACTIVE_ANON) +
> > > + global_node_page_state(NR_INACTIVE_ANON) +
> > > + global_node_page_state(NR_ACTIVE_FILE) +
> > > + global_node_page_state(NR_INACTIVE_FILE) +
> > > + global_node_page_state(NR_ISOLATED_ANON) +
> > > + global_node_page_state(NR_ISOLATED_FILE) +
> > > + global_node_page_state(NR_UNEVICTABLE);
> > > +
> > > + return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
> > > +}
> >
> > I am sorry I haven't pointed this earlier (I was following only half
> > way) but this should really be memcg aware. You are checking only global
> > counters. I do not think it is an absolute must to provide per-memcg
> > data but you should at least check !is_memcg_oom(oc).
>
> BTW, I saw there is already such check in dump_header that looks like the
> below code:
>
> if (oc->memcg)
> mem_cgroup_print_oom_info(oc->memcg, p);
> else
> show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
>
> I'm supposed it'd better to replace "oc->memcg" to "is_memcg_oom(oc)" since
> they do the same check and "is_memcg_oom" interface sounds preferable.
Yes, is_memcg_oom is better
> Then I'm going to move unreclaimable slabs dump to the "else" block.
makes sense.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] s390: qdio: Convert timers to use timer_setup()
From: Sebastian Ott @ 2017-10-05 9:13 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Peter Oberparleiter, Martin Schwidefsky,
Heiko Carstens, linux-s390, Thomas Gleixner
In-Reply-To: <20171005005435.GA23979@beast>
On Wed, 4 Oct 2017, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> -void qdio_outbound_timer(unsigned long data)
> +void qdio_outbound_timer(struct timer_list *t)
> {
> - struct qdio_q *q = (struct qdio_q *)data;
> + struct qdio_q *q = from_timer(q, t, o.out.timer);
^
this should be u.out.timer
Will be applied to s390/linux.git
Thanks,
Sebastian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.