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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58DB1C43217 for ; Wed, 12 Oct 2022 20:55:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229791AbiJLUzk (ORCPT ); Wed, 12 Oct 2022 16:55:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229755AbiJLUzi (ORCPT ); Wed, 12 Oct 2022 16:55:38 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6EF1A478; Wed, 12 Oct 2022 13:55:37 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id bn8so22068721ljb.6; Wed, 12 Oct 2022 13:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=t94iU6tiDOrr2Z3ZKXKEtLbEQqYDhthkqiU9i1YH9OE=; b=ninVkB9GUhO57bjgFgbl1StVZevTrq0zFzJBAvW68mWeHoY229TuMBta4JS9Tvwcp3 Bk/SD2031yWLCS//kymgyY65ZKkh2rnOVAdOkVE6+aZG8tUbTy5mKnF/5JV9CrGnYvBj GSS9A6MxVRzvuUX10vRPhcLOYh8nxx4+nm8IR3ofrRlzM3+dfZGqajfsegUTA09h6301 eNeLDoWd+y91Hxur9PEAw2Yvo7avLRxa2G1f9cEvHkZxtQ4+ucT4x1ztE/0Z/Ud3QmDy DTCSdhpH1NtqsrbzXdRJBix0u2FcX8h+/LQ62N2H76HpBJNbXwrUlKW+rONL4MuCBX6a 4ROw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=t94iU6tiDOrr2Z3ZKXKEtLbEQqYDhthkqiU9i1YH9OE=; b=DujCY4IXNgJYqQTi1ijNMNN14j+TVIJKNg/M3nhHccMvB3g6142rifMsnxUnA6a/+9 Hus5T1+MYJ9mWV6SAEoV/jX+2PxHVVmMbnYBJcn6p6PggCCTOLU37lskxTMS39HamVwp mIWUikBd9OA2xlBcu9mkan/4keKENMQNz6y9NP5TOj01eXCy/xHvrgrX1qHvkdW2enQJ 1zLpfoObrCnDNvHIq7qOek625NA2YtcTj/mrvOs9Mknv8Sp1oJLf26K/hhVTlCze8Amq kZsv3+RqDSYI7o+qnVaG1LIRB73LbHcXHxelSfWX2pVB+17ZTIT8czSXyZ25pxBxYOqv wcIg== X-Gm-Message-State: ACrzQf1zZcdPZv6p8XENWNG/qc6UK6ofg7srsYk7njjlo2mQeLjFXzXc MtTcP8YIA8zIPCNv3s9u16YbFE75D5mpyQ== X-Google-Smtp-Source: AMsMyM4+9+bYISlmz2xYMf7b5a3yNjLlkesrHctQO6qJpsGL+rStXibgcJcOtp8/RsiRapDieqUiig== X-Received: by 2002:a05:651c:1509:b0:26f:a762:7139 with SMTP id e9-20020a05651c150900b0026fa7627139mr6179680ljf.416.1665608136181; Wed, 12 Oct 2022 13:55:36 -0700 (PDT) Received: from mobilestation ([95.79.133.202]) by smtp.gmail.com with ESMTPSA id m7-20020a056512114700b0049aa7a56715sm93926lfg.267.2022.10.12.13.55.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 13:55:35 -0700 (PDT) Date: Wed, 12 Oct 2022 23:55:33 +0300 From: Serge Semin To: Borislav Petkov Cc: Serge Semin , Michal Simek , Mauro Carvalho Chehab , Tony Luck , James Morse , Robert Richter , Alexey Malahov , Michail Ivanov , Pavel Parkhomenko , Punnaiah Choudary Kalluri , Manish Narani , Dinh Nguyen , Rob Herring , Krzysztof Kozlowski , Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND v3 14/17] EDAC/synopsys: Detach Zynq DDRC controller support Message-ID: <20221012205533.kp45dht3j5zk4bdx@mobilestation> References: <20220929232712.12202-1-Sergey.Semin@baikalelectronics.ru> <20220929232712.12202-15-Sergey.Semin@baikalelectronics.ru> <20221006121740.ksugoodbagr45fky@mobilestation> <20221008004224.owqbzbdctclua2hb@mobilestation> <20221012192743.ihy4nidkzxweqebj@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Oct 12, 2022 at 09:44:00PM +0200, Borislav Petkov wrote: > On Wed, Oct 12, 2022 at 10:27:43PM +0300, Serge Semin wrote: > > ... inter-device parts of the core. The registration procedure is > > protected by the mutex and RCU. So it seems as the EDAC core developer > > Seems, schmeems. As I said already, EDAC has always had a single > chipset-specific driver. Period. So if one needs to run more than one > chipset-specific driver concurrently, then the whole code needs to be > audited because this hasn't been done before. > > > If it has never needed to, then please explain why did you let the > > Synopsys EDAC driver being accepted like that then? > > I think I already did. Kind of. What you didn't explain was the driver-specific problem in the edac_mc core. What is the difference in the EDAC core handling two devices (including of difference types) on the same platform and handling the same devices each probed by two different drivers? (Consider the drivers are designed thread-safe and we are talking about the EDAC MC core.) > > > In my case it's a single EDAC driver per-chip. There can be several > > DDR-controllers installed on the same SoC, but all of them of the same > > type (Synopsys DW uMCTL2 v2.61a). > > Good. > > I'll look at your patches as time allows. Ok. Thanks in advance. -Sergey > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette