{"id":2219714,"url":"http://patchwork.ozlabs.org/api/covers/2219714/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-arc/cover/20260404000644.522677-1-dianders@chromium.org/","project":{"id":48,"url":"http://patchwork.ozlabs.org/api/projects/48/?format=json","name":"Linux ARC development","link_name":"linux-arc","list_id":"linux-snps-arc.lists.infradead.org","list_email":"linux-snps-arc@lists.infradead.org","web_url":"","scm_url":"","webscm_url":"","list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<20260404000644.522677-1-dianders@chromium.org>","list_archive_url":null,"date":"2026-04-04T00:04:54","name":"[v4,0/9] driver core: Fix some race conditions","submitter":{"id":9763,"url":"http://patchwork.ozlabs.org/api/people/9763/?format=json","name":"Douglas Anderson","email":"dianders@chromium.org"},"mbox":"http://patchwork.ozlabs.org/project/linux-arc/cover/20260404000644.522677-1-dianders@chromium.org/mbox/","series":[{"id":498686,"url":"http://patchwork.ozlabs.org/api/series/498686/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-arc/list/?series=498686","date":"2026-04-04T00:04:54","name":"driver core: Fix some race conditions","version":4,"mbox":"http://patchwork.ozlabs.org/series/498686/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/2219714/comments/","headers":{"Return-Path":"\n <linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=APBoTyMJ;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=nAzCLfc/;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fnbWL4lRQz1yD3\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 04 Apr 2026 11:07:26 +1100 (AEDT)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1w8oXt-00000002kcl-0b79;\n\tSat, 04 Apr 2026 00:07:25 +0000","from mail-dy1-x132e.google.com ([2607:f8b0:4864:20::132e])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1w8oXp-00000002kbf-2Qyx\n\tfor linux-snps-arc@lists.infradead.org;\n\tSat, 04 Apr 2026 00:07:23 +0000","by mail-dy1-x132e.google.com with SMTP id\n 5a478bee46e88-2c1632faeb9so4450975eec.0\n        for <linux-snps-arc@lists.infradead.org>;\n Fri, 03 Apr 2026 17:07:21 -0700 (PDT)","from dianders.sjc.corp.google.com\n ([2a00:79e0:2e7c:8:a8b6:55b2:3eb6:2c0e])\n        by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2ca79e1d93bsm6520716eec.12.2026.04.03.17.07.16\n        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n        Fri, 03 Apr 2026 17:07:19 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:Cc\n\t:To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:\n\tResent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:\n\tList-Owner; bh=Bjp808tY5tPCgLxI6wrAbUrANxFplb7znnXT8GabNgQ=; b=APBoTyMJo7emaj\n\tNlP6JTiuDpnUZk/NvWEofomJhiz8Jg3S3LcJKbwWJR/GvkiOv0XiCw1Y1WzNuXI3H5ovRFRxev96m\n\tEMytopXv1S1Eaj09yYvsJbJjaKUNJscxCEdy8UgmK59sKZgz3DUZpIJMcv1Lp/igm7wufbhjX9sia\n\t7LMZTgAzBqN7lJ2/ue/1eramoBYzqi+WfS6QQIzkFZpubDk0OYKdlgV2vfbwj9Ylebkqc4ZuHNkbV\n\tSe+G4fUzdt1FtsQGEZ5FXzcT4mHgCeKSrS2uvDwll+ipX3HMtTKOWg60h7+a8Y6LyqB4D67VObxoD\n\tF5qKkIPR8jjY5PQqjDuQ==;","v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=chromium.org; s=google; t=1775261240; x=1775866040;\n darn=lists.infradead.org;\n        h=content-transfer-encoding:mime-version:message-id:date:subject:cc\n         :to:from:from:to:cc:subject:date:message-id:reply-to;\n        bh=KGKsMy9vhlN9yvdnOvYy+R4lmavPYuTzTATeThGwgQc=;\n        b=nAzCLfc/SZYVYgd0knvrPUnyS1QtgItVdxVjqjtvjURxhqsJtBO1jSBpuhctShud2u\n         4Rz9PX5l7gixtY30n/+EpD0Isn8XrBaE4NVqcJvpKgvM0iCWgfKUFUeiRrDyJzqbH5YV\n         oHFNDJLhcVU6NtcxM50CLJGPx2PNjVg5zyzg8="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1775261240; x=1775866040;\n        h=content-transfer-encoding:mime-version:message-id:date:subject:cc\n         :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n         :message-id:reply-to;\n        bh=KGKsMy9vhlN9yvdnOvYy+R4lmavPYuTzTATeThGwgQc=;\n        b=h1O7kgvYeTvrdnueVGOj1krgDW0BDysfUfIbKX/jt32UmB/gs1WQXvT1dl7ikFfxfQ\n         g4aNpNYRHfHdgxBW8UuJLUk4EJm4a48y+Di266VzKekFxEXqtbRzMx8/yQW25I2ypzQf\n         il3oPhSfsGhw+n6avW1RZDKkRa1MQBLH4txv7fMPB1KmTs/SkTBEmZ70w5RTe+SVYosv\n         GVxij+YHBzntd2e9hUNi6EvujYSNJDFj8muFl8T65z5pVl3Ez1B7UCMfSrQk2jwgp7R9\n         JSvft1rYDfu12Uq6cjnssF0JFsspB0nzRiOjLmUsh3QNY4oEyKOqfsNNSLRqvc9XggWz\n         GpfA==","X-Forwarded-Encrypted":"i=1;\n AJvYcCVVOJVkeKHMvldrcUMEdYTfWr5+6CWidaIzH2OX4EbLRxFs1IWsKbCCSRKz24Thp18Dethp9w+1T+X3LLLb4Q==@lists.infradead.org","X-Gm-Message-State":"AOJu0YwRiPa/u2qOLRHZT0CmKGoMyOVf9e38/9p8z+hzqK5YZhap0dB5\n\tPafNCNmocU06XDDAvoa8WsX5+R/uf+Hqdw2ekR8kWB4l+xvgISfY5D77ys0pf6JIBQ==","X-Gm-Gg":"AeBDiet9Elrn+TLubH8dkiRlp2MOFfAzPiW9mue2CRo5QA3aC9HaLcgckOc5j7ZAG0H\n\tCr06KUcREtDLLq0D1kGIZwmz8ChmJ9KUrSwr34LdKMpMFcs+NZYdS0Mi1URllGPLiV2pvneehdj\n\ttDmuelDxO4sK94XtFeQVS47WuOdejPM093p89NgJ+LNxQYG7X70h4Y+2auz/Ktue00WQSFpMPEL\n\tIhkocXHQiayBDjb5dqGDjYQPph5TNawvI7zffX8QqzC3t/O4wNP0MnJUwQQ+8tp/1LJUQpN+k0A\n\tJV3B2HBoriAV3MRg1z3n5+fVX5p5whYsEcFV+AVdKWR42/8INTWk44LGGD+4HVdLWLJEyuCzKdi\n\tpLRHrIvc2l172znDmC6n6IOzkSgA+bKTKADCy4PcYJXOtsPFLu42NBT+2zWiRgLWpo+n0SAlcAv\n\t2b9wslOJyvwEhJTMtg6+OYYBhgPoM1W+A8S7+AI4fwzfs2elbf3hjm/P8ZPlMjf7UsyGQ97929+\n\tp9HBCt2qX4=","X-Received":"by 2002:a05:7300:5722:b0:2c7:ea98:da0 with SMTP id\n 5a478bee46e88-2cbfbc8aeb9mr2680118eec.19.1775261240285;\n        Fri, 03 Apr 2026 17:07:20 -0700 (PDT)","From":"Douglas Anderson <dianders@chromium.org>","To":"Greg Kroah-Hartman <gregkh@linuxfoundation.org>,\n\t\"Rafael J . Wysocki\" <rafael@kernel.org>,\n\tDanilo Krummrich <dakr@kernel.org>,\n\tAlan Stern <stern@rowland.harvard.edu>","Cc":"Saravana Kannan <saravanak@kernel.org>,\n\tChristoph Hellwig <hch@lst.de>,\n\tEric Dumazet <edumazet@google.com>,\n\tJohan Hovold <johan@kernel.org>,\n\tLeon Romanovsky <leon@kernel.org>,\n\tAlexander Lobakin <aleksander.lobakin@intel.com>,\n\tAlexey Kardashevskiy <aik@ozlabs.ru>,\n\tRobin Murphy <robin.murphy@arm.com>,\n\tDouglas Anderson <dianders@chromium.org>,\n\tAndrew Morton <akpm@linux-foundation.org>,\n\tFrank.Li@kernel.org,\n\tJason Gunthorpe <jgg@ziepe.ca>,\n\talex@ghiti.fr,\n\talexander.stein@ew.tq-group.com,\n\tandre.przywara@arm.com,\n\tandrew@codeconstruct.com.au,\n\tandrew@lunn.ch,\n\tandriy.shevchenko@linux.intel.com,\n\taou@eecs.berkeley.edu,\n\tardb@kernel.org,\n\tbhelgaas@google.com,\n\tbrgl@kernel.org,\n\tbroonie@kernel.org,\n\tcatalin.marinas@arm.com,\n\tchleroy@kernel.org,\n\tdavem@davemloft.net,\n\tdavid@kernel.org,\n\tdevicetree@vger.kernel.org,\n\tdmaengine@vger.kernel.org,\n\tdriver-core@lists.linux.dev,\n\tgbatra@linux.ibm.com,\n\tgregory.clement@bootlin.com,\n\thkallweit1@gmail.com,\n\tiommu@lists.linux.dev,\n\tjirislaby@kernel.org,\n\tjoel@jms.id.au,\n\tjoro@8bytes.org,\n\tkees@kernel.org,\n\tkevin.brodsky@arm.com,\n\tkuba@kernel.org,\n\tlenb@kernel.org,\n\tlgirdwood@gmail.com,\n\tlinux-acpi@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org,\n\tlinux-aspeed@lists.ozlabs.org,\n\tlinux-cxl@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tlinux-mips@vger.kernel.org,\n\tlinux-mm@kvack.org,\n\tlinux-pci@vger.kernel.org,\n\tlinux-riscv@lists.infradead.org,\n\tlinux-serial@vger.kernel.org,\n\tlinux-snps-arc@lists.infradead.org,\n\tlinux-usb@vger.kernel.org,\n\tlinux@armlinux.org.uk,\n\tlinuxppc-dev@lists.ozlabs.org,\n\tm.szyprowski@samsung.com,\n\tmaddy@linux.ibm.com,\n\tmani@kernel.org,\n\tmaz@kernel.org,\n\tmiko.lenczewski@arm.com,\n\tmpe@ellerman.id.au,\n\tnetdev@vger.kernel.org,\n\tnpiggin@gmail.com,\n\tosalvador@suse.de,\n\toupton@kernel.org,\n\tpabeni@redhat.com,\n\tpalmer@dabbelt.com,\n\tpeter.ujfalusi@gmail.com,\n\tpeterz@infradead.org,\n\tpjw@kernel.org,\n\trobh@kernel.org,\n\tsebastian.hesselbarth@gmail.com,\n\ttglx@kernel.org,\n\ttsbogend@alpha.franken.de,\n\tvgupta@kernel.org,\n\tvkoul@kernel.org,\n\twill@kernel.org,\n\twilly@infradead.org,\n\tyangyicong@hisilicon.com,\n\tyeoreum.yun@arm.com","Subject":"[PATCH v4 0/9] driver core: Fix some race conditions","Date":"Fri,  3 Apr 2026 17:04:54 -0700","Message-ID":"<20260404000644.522677-1-dianders@chromium.org>","X-Mailer":"git-send-email 2.53.0.1213.gd9a14994de-goog","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260403_170721_728893_102F09AF ","X-CRM114-Status":"GOOD (  23.69  )","X-Spam-Score":"-2.6 (--)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam.  The original\n message has been attached to this so you can view it or label\n similar future email.  If you have any questions, see\n the administrator of that system for details.\n Content preview:  The main goal of this series is to fix the observed bug\n talked\n    about in the first patch (\"driver core: Don't let a device probe until\n it's\n    ready\"). That patch fixes a problem that has been observed in [...]\n Content analysis details:   (-2.6 points, 5.0 required)\n  pts rule name              description\n ---- ----------------------\n --------------------------------------------------\n -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/, no\n                             trust\n                             [2607:f8b0:4864:20:0:0:0:132e listed in]\n                             [list.dnswl.org]\n  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record\n -0.0 SPF_PASS               SPF: sender matches SPF record\n  0.1 DKIM_SIGNED            Message has a DKIM or DK signature,\n not necessarily valid\n -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from\n                             envelope-from domain\n -0.1 DKIM_VALID             Message has at least one valid DKIM or DK\n signature\n -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from\n author's\n                             domain\n -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%\n                             [score: 0.0000]\n -0.5 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender","X-BeenThere":"linux-snps-arc@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux on Synopsys ARC Processors <linux-snps-arc.lists.infradead.org>","List-Unsubscribe":"<http://lists.infradead.org/mailman/options/linux-snps-arc>,\n <mailto:linux-snps-arc-request@lists.infradead.org?subject=unsubscribe>","List-Archive":"<http://lists.infradead.org/pipermail/linux-snps-arc/>","List-Post":"<mailto:linux-snps-arc@lists.infradead.org>","List-Help":"<mailto:linux-snps-arc-request@lists.infradead.org?subject=help>","List-Subscribe":"<http://lists.infradead.org/mailman/listinfo/linux-snps-arc>,\n <mailto:linux-snps-arc-request@lists.infradead.org?subject=subscribe>","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-snps-arc\" <linux-snps-arc-bounces@lists.infradead.org>","Errors-To":"\n linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"},"content":"The main goal of this series is to fix the observed bug talked about\nin the first patch (\"driver core: Don't let a device probe until it's\nready\"). That patch fixes a problem that has been observed in the real\nworld and could land even if the rest of the patches are found\nunacceptable or need to be spun.\n\nThat said, during patch review Danilo correctly pointed out that many\nof the bitfield accesses in \"struct device\" are unsafe. I added a\nbunch of patches in the series to address each one.\n\nDanilo said he's most worried about \"can_match\", so I put that one\nfirst. After that, I tried to transition bitfields to flags in reverse\norder to when the bitfield was added.\n\nEven if transitioning from bitfields to flags isn't truly needed for\ncorrectness, it seems silly (and wasteful of space in struct device)\nto have some in bitfields and some as flags. Thus I didn't spend time\nfor each bitfield showing that it's truly needed for correctness.\n\nTransition was done semi manually. Presumably someone skilled at\ncoccinelle could do a better job, but I just used sed in a heavy-\nhanded manner and then reviewed/fixed the results, undoing anything my\nscript got wrong. My terrible/ugly script was:\n\nvar=can_match\ncaps=\"${var^^}\"\nfor f in $(git grep -l \"[>\\.]${var}[^1-9_a-zA-Z\\[]\"); do\n  echo $f\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)->${var} = true/set_bit(DEV_FLAG_${caps}, \\&\\\\1->flags)/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)\\.${var} = true/dev_set_${caps}(\\&\\\\1)/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \\&\\\\1->flags)/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)\\.${var} = false/dev_clear_${caps}(\\&\\\\1)/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)->${var} = \\([^;]*\\)/assign_bit(DEV_FLAG_${caps}, \\&\\\\1->flags, \\\\2)/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)\\.${var} = \\([^;]*\\)/dev_assign_${caps}(\\&\\\\1, \\\\2)/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)->${var}\\([^1-9_a-zA-Z\\[]\\)/test_bit(DEV_FLAG_${caps}, \\&\\\\1->flags)\\\\2/\" \"$f\"\n  sed -i~ -e \"s/\\([a-zA-Z_0-9\\.>()-][a-zA-Z_0-9\\.>()-]*\\)\\.${var}\\([^1-9_a-zA-Z\\[]\\)/dev_${caps}(\\&\\\\1)\\\\2/\" \"$f\"\ndone\n\nFrom v3 to v4, I transitioned to accessor functions with another ugly\nsed script. I had git format the old patches, then transformed them\nwith:\n\nfor f in *.patch; do\n  echo $f\n  sed -i~ -e \"s/test_and_set_bit(DEV_FLAG_\\([^,]*\\), \\&\\(.*\\)->flags)/dev_test_and_set_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/test_and_set_bit(DEV_FLAG_\\([^,]*\\), \\(.*\\)\\.flags)/dev_test_and_set_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/test_bit(DEV_FLAG_\\([^,]*\\), \\&\\(.*\\)->flags)/dev_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/test_bit(DEV_FLAG_\\([^,]*\\), \\(.*\\)\\.flags)/dev_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/set_bit(DEV_FLAG_\\([^,]*\\), \\&\\(.*\\)->flags)/dev_set_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/set_bit(DEV_FLAG_\\([^,]*\\), \\(.*\\)\\.flags)/dev_set_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/clear_bit(DEV_FLAG_\\([^,]*\\), \\&\\(.*\\)->flags)/dev_clear_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/clear_bit(DEV_FLAG_\\([^,]*\\), \\(.*\\)\\.flags)/dev_clear_\\\\L\\\\1(\\\\2)/\" \"$f\"\n  sed -i~ -e \"s/assign_bit(DEV_FLAG_\\([^,]*\\), \\&\\(.*\\)->flags, \\(.*\\))/dev_assign_\\\\L\\\\1(\\\\2, \\\\3)/\" \"$f\"\n  sed -i~ -e \"s/assign_bit(DEV_FLAG_\\([^,]*\\), \\(.*\\)\\.flags, \\(.*\\))/dev_assign_\\\\L\\\\1(\\\\2, \\\\3)/\" \"$f\"\ndone\n\n...and then did a few manual touchups for spacing.\n\nNOTE: one potentially \"controversial\" choice I made in some patches\nwas to always reserve a flag ID even if a flag is only used under\ncertain CONFIG_ settings. This is a change from how things were\nbefore. Keeping the numbering consistent and allowing easy\ncompile-testing of both CONFIG settings seemed worth it, especially\nsince it won't take up any extra space until we've added a lot more\nflags.\n\nI only marked the first patch as a \"Fix\" since it is the only one\nfixing observed problems. Other patches could be considered fixes too\nif folks want.\n\nI tested the first patch in the series backported to kernel 6.6 on the\nPixel phone that was experiencing the race. I added extra printouts to\nmake sure that the problem was hitting / addressed. The rest of the\npatches are tested with allmodconfig with arm32, arm64, ppc, and\nx86. I boot tested on an arm64 Chromebook running mainline.\n\nChanges in v4:\n- Use accessor functions for flags\n\nChanges in v3:\n- Use a new \"flags\" bitfield\n- Add missing \\n in probe error message\n\nChanges in v2:\n- Instead of adjusting the ordering, use \"ready_to_probe\" flag\n\nDouglas Anderson (9):\n  driver core: Don't let a device probe until it's ready\n  driver core: Replace dev->can_match with dev_can_match()\n  driver core: Replace dev->dma_iommu with dev_dma_iommu()\n  driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()\n  driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()\n  driver core: Replace dev->state_synced with dev_state_synced()\n  driver core: Replace dev->dma_coherent with dev_dma_coherent()\n  driver core: Replace dev->of_node_reused with dev_of_node_reused()\n  driver core: Replace dev->offline + ->offline_disabled with accessors\n\n arch/arc/mm/dma.c                             |   4 +-\n arch/arm/mach-highbank/highbank.c             |   2 +-\n arch/arm/mach-mvebu/coherency.c               |   2 +-\n arch/arm/mm/dma-mapping-nommu.c               |   4 +-\n arch/arm/mm/dma-mapping.c                     |  28 ++--\n arch/arm64/kernel/cpufeature.c                |   2 +-\n arch/arm64/mm/dma-mapping.c                   |   2 +-\n arch/mips/mm/dma-noncoherent.c                |   2 +-\n arch/powerpc/kernel/dma-iommu.c               |   8 +-\n .../platforms/pseries/hotplug-memory.c        |   4 +-\n arch/riscv/mm/dma-noncoherent.c               |   2 +-\n drivers/acpi/scan.c                           |   2 +-\n drivers/base/core.c                           |  53 +++++---\n drivers/base/cpu.c                            |   4 +-\n drivers/base/dd.c                             |  28 ++--\n drivers/base/memory.c                         |   2 +-\n drivers/base/pinctrl.c                        |   2 +-\n drivers/base/platform.c                       |   2 +-\n drivers/dma/ti/k3-udma-glue.c                 |   6 +-\n drivers/dma/ti/k3-udma.c                      |   6 +-\n drivers/iommu/dma-iommu.c                     |   9 +-\n drivers/iommu/iommu.c                         |   5 +-\n drivers/net/pcs/pcs-xpcs-plat.c               |   2 +-\n drivers/of/device.c                           |   6 +-\n drivers/pci/of.c                              |   2 +-\n drivers/pci/pwrctrl/core.c                    |   2 +-\n drivers/regulator/bq257xx-regulator.c         |   2 +-\n drivers/regulator/rk808-regulator.c           |   2 +-\n drivers/tty/serial/serial_base_bus.c          |   2 +-\n drivers/usb/gadget/udc/aspeed-vhub/dev.c      |   2 +-\n include/linux/device.h                        | 120 ++++++++++++------\n include/linux/dma-map-ops.h                   |   6 +-\n include/linux/dma-mapping.h                   |   2 +-\n include/linux/iommu-dma.h                     |   3 +-\n kernel/cpu.c                                  |   4 +-\n kernel/dma/mapping.c                          |  12 +-\n mm/hmm.c                                      |   2 +-\n 37 files changed, 206 insertions(+), 142 deletions(-)"}