From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32DDBC4321A for ; Tue, 11 Jun 2019 18:44:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 10EDE217F9 for ; Tue, 11 Jun 2019 18:44:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="myaTjclO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729282AbfFKSoe (ORCPT ); Tue, 11 Jun 2019 14:44:34 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:40808 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728412AbfFKSoe (ORCPT ); Tue, 11 Jun 2019 14:44:34 -0400 Received: by mail-pg1-f194.google.com with SMTP id d30so7447148pgm.7; Tue, 11 Jun 2019 11:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VjXOm39CWa6S4I71CKU5r+mT9fayfeuZ4n9Ko6h04/Q=; b=myaTjclOScSIDrJvBHbz7GqxDxIFK7e7DAfxQEM9oALn9rsTlpKt80fwIgm0KtX6V1 rjsp2quD64X+j4e2krEEBu98c5MfZng1DbASdGyGwJG5NVw2h8ncvSeeiM2/is5mt8Tj Hl7PulNEfKL1iTcOm+BmiLv6YbI73mFN+CKOysg5B0Qajeo+mJ+3lkv/hTsDiLqP1K2X E0uc27fMFfCG5CTgpAOnmzWitO8GemDOyDhaTdzt2sylNoufOgyKKIZsO/0WcWMJBXRF bOI29cs4Pv20llVSyHkYaKW+KY4DlzmN8lJPePgHDnkkKHK19ZK8RN8IcjgGd4Bksfk0 p/6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VjXOm39CWa6S4I71CKU5r+mT9fayfeuZ4n9Ko6h04/Q=; b=DGtfviaZwKHP/jH89Tru0Wsj4ev1KGVjO9XIsD4JvvwONe0/RFvN5kggNUnMZI3XNq 4Y1WDVMZT4yVRug5cYkrBiSxNaGloG2KF9YUjH/oWXIQjuYOFyAx3voCbz66FP2l2ztU YK+pjqflDr55jhycvvnKkjK9wbC4j+MWVL9RfXSy0UoF7MU1EGZbt/D6YNtSx67pD86N LvtuEaYlnb2SDFjiZ0V7l3gxl5y5Iv49E9BxRyyycA0hBeFOJVF6fL+XYS1zfjmnw45V yK0uFYq4enVWefRdbPxpk0cO3tls1YhP4jvuJlxkxqwvTWqhEn3G7eKmuu/kmXZ0F7ch /R9A== X-Gm-Message-State: APjAAAVGuf24ZkeAGJpgq4kGQcBC/vu7HLlnD/bwafbaofG2VEFI6nNO JD1IvZb32aLCEw/IjleITS/bZLlpTvb/yzjvrg8= X-Google-Smtp-Source: APXvYqzkqeep3CqfOFDZoSRrKfSGRdBDWFEoMwtK6OFag6Wk/WDtXaVNa/EripQyuLMKoe63k5dbDPKFUOkVassx774= X-Received: by 2002:a63:d84a:: with SMTP id k10mr6952505pgj.74.1560278673900; Tue, 11 Jun 2019 11:44:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Shevchenko Date: Tue, 11 Jun 2019 21:44:23 +0300 Message-ID: Subject: Re: How to inject fwnode/oftree/acpi data by platform driver ? To: "Enrico Weigelt, metux IT consult" , "Krogerus, Heikki" Cc: LKML , ACPI Devel Maling List , "devicetree@vger.kernel.org" , Platform Driver Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org +Cc: Heikki. Heikki, can you help here with swnodes? On Sat, Jun 1, 2019 at 5:17 PM Enrico Weigelt, metux IT consult wrote: > > Hi folks, > > > I'm looking for a way to inject fwnode data from a platform driver, > in order to initialize generic drivers w/ board specific configuration. > The idea is getting rid of passing driver specific pdata structs > (which, IIRC, seem to be deprecated). > > An example usecase is the APUv2/3 board, which have things like gpios > wired to buttons and LEDs. The board can only be detected via DMI > string, no way to probe the platform devices - have to be initialized > explicitly (that's how I'm already doing it now). > > The nicest way, IMHO, would be if I could just write some piece of DTS > and some fancy magic all the rest under the hood. Such thing doesn't > seem to exist yet. Does it make sense to implement that ? How could > we do it ? > > Which other options do we have ? > > Or should we just leave everything as it is and stick w/ pdata structs ? > > > thx > --mtx > > -- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > info@metux.net -- +49-151-27565287 -- With Best Regards, Andy Shevchenko