From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754032AbeE1IAx (ORCPT ); Mon, 28 May 2018 04:00:53 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:34185 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753886AbeE1IAv (ORCPT ); Mon, 28 May 2018 04:00:51 -0400 X-Google-Smtp-Source: ADUXVKLn9dhdr4q+Uc+FSedYYM6ttEbZD2l2NqRMdO3MaBB6o96g+99ov37tB1JYHFB5nKNVFmY6xLz3W1wdaspdnfA= MIME-Version: 1.0 In-Reply-To: <20180525171941.26766-4-radu.pirea@microchip.com> References: <20180525171941.26766-1-radu.pirea@microchip.com> <20180525171941.26766-4-radu.pirea@microchip.com> From: Andy Shevchenko Date: Mon, 28 May 2018 11:00:49 +0300 Message-ID: Subject: Re: [PATCH v4 3/6] mfd: at91-usart: added mfd driver for usart To: Radu Pirea Cc: Mark Brown , Nicolas Ferre , alexandre.belloni@bootlin.com, Lee Jones , Richard Genoud , Rob Herring , Mark Rutland , Greg Kroah-Hartman , linux-spi , linux-arm Mailing List , Linux Kernel Mailing List , devicetree , "open list:SERIAL DRIVERS" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 25, 2018 at 8:19 PM, Radu Pirea wrote: > This mfd driver is just a wrapper over atmel_serial driver and > spi-at91-usart driver. Selection of one of the drivers is based on a > property from device tree. If the property is not specified, the default > driver is atmel_serial. > + depends on OF What makes this driver OF specific? > +#include > +#include Ditto. > +#include How exactly is this used? > +#include > +#include Ditto. > +#include > +static int at91_usart_mode_probe(struct platform_device *pdev) > +{ > + struct device_node *np = pdev->dev.of_node; > + struct mfd_cell cell; > + u32 opmode; > + int err; > + > + err = of_property_read_u32(np, "atmel,usart-mode", &opmode); Check unified device property API. > + return mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, &cell, 1, > + NULL, 0, NULL); No devm_ and no ->remove(). Why to leak resources? -- With Best Regards, Andy Shevchenko