From patchwork Mon Aug 6 09:48:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Biju Das X-Patchwork-Id: 953801 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=bp.renesas.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41kXzX0yNwz9ryt for ; Mon, 6 Aug 2018 19:53:59 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728311AbeHFMCQ (ORCPT ); Mon, 6 Aug 2018 08:02:16 -0400 Received: from relmlor3.renesas.com ([210.160.252.173]:1228 "EHLO relmlie2.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726855AbeHFMCQ (ORCPT ); Mon, 6 Aug 2018 08:02:16 -0400 Received: from unknown (HELO relmlir3.idc.renesas.com) ([10.200.68.153]) by relmlie2.idc.renesas.com with ESMTP; 06 Aug 2018 18:53:56 +0900 Received: from relmlii2.idc.renesas.com (relmlii2.idc.renesas.com [10.200.68.66]) by relmlir3.idc.renesas.com (Postfix) with ESMTP id B9BCB7AF0A; Mon, 6 Aug 2018 18:53:56 +0900 (JST) X-IronPort-AV: E=Sophos;i="5.51,452,1526310000"; d="scan'208";a="288964447" Received: from unknown (HELO be1yocto.ree.adwin.renesas.com) ([172.29.43.62]) by relmlii2.idc.renesas.com with ESMTP; 06 Aug 2018 18:53:54 +0900 From: Biju Das To: Linus Walleij Cc: Biju Das , linux-gpio@vger.kernel.org, Simon Horman , Geert Uytterhoeven , Chris Paterson , Fabrizio Castro , linux-renesas-soc@vger.kernel.org Subject: [PATCH] gpiolib: Fix of_node inconsistency Date: Mon, 6 Aug 2018 10:48:01 +0100 Message-Id: <1533548881-35174-1-git-send-email-biju.das@bp.renesas.com> X-Mailer: git-send-email 2.7.4 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Some platforms are not setting of_node in the driver. On these platforms defining gpio-reserved-ranges on device tree leads to kernel crash. It is due to some parts of the gpio core relying on the driver to set up of_node,while other parts do themselves.This inconsistent behaviour leads to a crash. gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node as NULL. of_gpiochip_add() fills "of_node" and calls of_gpiochip_init_valid_mask(). The fix is to move the assignment to chip->of_node from of_gpiochip_add() to gpiochip_add_data_with_key(). Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven --- drivers/gpio/gpiolib-of.c | 3 --- drivers/gpio/gpiolib.c | 2 ++ 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index 28d9680..91174bf 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -620,9 +620,6 @@ int of_gpiochip_add(struct gpio_chip *chip) { int status; - if ((!chip->of_node) && (chip->parent)) - chip->of_node = chip->parent->of_node; - if (!chip->of_node) return 0; diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index e11a3bb..20fe531 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1256,6 +1256,8 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data, /* If the gpiochip has an assigned OF node this takes precedence */ if (chip->of_node) gdev->dev.of_node = chip->of_node; + else + chip->of_node = gdev->dev.of_node; #endif gdev->id = ida_simple_get(&gpio_ida, 0, 0, GFP_KERNEL);