summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-12-10mtd: rawnand: ingenic: remove redundant get_device() in ingenic_ecc_get()Yu Kuai
of_find_device_by_node() already takes a reference to the device, and ingenic_ecc_release() will drop the reference. So, the get_device() in ingenic_ecc_get() is redundand. Fixes: 15de8c6efd0e("mtd: rawnand: ingenic: Separate top-level and SoC specific code") Signed-off-by: Yu Kuai <yukuai3@huawei.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201031105439.2304211-1-yukuai3@huawei.com
2020-12-10mtd: nand: ecc-hamming: Clarify the logic around rp17Miquel Raynal
This code has been written in 2008 and is fine, but in order to keep robots happy, I think it's time to change a little bit this code just to clarify the different possible values of eccsize_mult. Indeed, this variable may only take the value 1 or 2 because step_size, in the case of the software Hamming ECC engine may only be 256 or 512. Depending on the value of eccsize_mult, an extra rp17 variable is set, or not and triggers the following warning: smatch warnings: ecc_sw_hamming_calculate() error: uninitialized symbol 'rp17'. As highlighted by Dan Carpenter, if the only possible values for eccsize_mult are 1 and 2, then the code is fine, but "it's hard to tell just from looking". So instead of shifting step_size, let's use a ternary condition to assign to eccsize_mult the only two possible values and clarify the driver's logic. Now that the situation is clarified for humans, ensure rp17 is initialized to 0 to keep compilers and robots silent as well. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201030172333.28390-1-miquel.raynal@bootlin.com
2020-12-10mtd: rawnand: sunxi: Add MDMA supportManuel Dipolt
This patch enables NAND MDMA (MBUS DMA) mode for the Allwinner SoCs A23/A33/H3. The DMA transfer method gets sets now to MBUS DMA as default for the sun8i-a23-nand-controller (till now DMA transfer was executed via the shared DMA engine). The main advantage is more bandwidth for the users of the shared DMA engine and also that the MBUS DMA setup requires less configuration effort. For example you don't need to define a dedicated DMA channel in the device-tree any more. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Manuel Dipolt <manuel.dipolt@robart.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/154840787.280672.1602517282173.JavaMail.zimbra@robart.cc
2020-12-10mtd: rawnand: meson: fix meson_nfc_dma_buffer_release() argumentsSergei Antonov
Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up. Fixes: 8fae856c53500 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Cc: stable@vger.kernel.org Signed-off-by: Sergei Antonov <saproj@gmail.com> Acked-by: Liang Yang <liang.yang@amlogic.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201028094940.11765-1-saproj@gmail.com
2020-12-10mtd: rawnand: fix a kernel-doc markupMauro Carvalho Chehab
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/9ed47a57d12c40e73a9b01612ee119d39baa6236.1603469755.git.mchehab+huawei@kernel.org
2020-12-10mtd: rawnand: qcom: Support for IPQ6018 QPIC NAND controllerKathiravan T
Add the compatible string for IPQ6018 QPIC NAND controller version 1.5.0. It's properties are same as IPQ8074, so reuse the same. Signed-off-by: Kathiravan T <kathirav@codeaurora.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1602566124-13456-3-git-send-email-kathirav@codeaurora.org
2020-12-10mtd: rawnand: qcom: Fix DMA sync on FLASH_STATUS register readPraveenkumar I
After each codeword NAND_FLASH_STATUS is read for possible operational failures. But there is no DMA sync for CPU operation before reading it and this leads to incorrect or older copy of DMA buffer in reg_read_buf. This patch adds the DMA sync on reg_read_buf for CPU before reading it. Fixes: 5bc36b2bf6e2 ("mtd: rawnand: qcom: check for operation errors in case of raw read") Cc: stable@vger.kernel.org Signed-off-by: Praveenkumar I <ipkumar@codeaurora.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1602230872-25616-1-git-send-email-ipkumar@codeaurora.org
2020-12-10mtd: rawnand: gpmi: cleanup makefileMarco Felsch
The extra gpmi_nand.o object is not needed anymore since commit 3045f8e36963 ("mtd: rawnand: gpmi: move all driver code into single file"). Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201007134533.31390-1-m.felsch@pengutronix.de
2020-12-10mtd: spinand: Remove outdated commentMiquel Raynal
This comment is no longer true so drop it. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-7-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Fix OOB readMiquel Raynal
So far OOB have never been used in SPI-NAND, add the missing memcpy to make it work properly. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-6-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Allow the case where there is no ECC engineMiquel Raynal
Even if this is not supposed to happen, there is no reason to fail the probe if it was explicitly requested to use no ECC engine at all (for instance, during development). This condition is met by just commenting out the error on the OOB free bytes count after the assignation of an ECC engine if none was provided (any other situation would error out much earlier anyway). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-5-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Use the external ECC engine logicMiquel Raynal
Now that all the logic is available in the NAND core, let's use it from the SPI-NAND core. Right now there is no functional change as the default ECC engine for SPI-NANDs is set to 'on-die', but user can now use software correction if they want to by just setting the right properties in the DT. Also note that the OOB layout handling is removed from the SPI-NAND core as each ECC engine is supposed to handle it by it's own; users should not be aware of that. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-4-miquel.raynal@bootlin.com
2020-12-10mtd: nand: Add helpers to manage ECC engines and configurationsMiquel Raynal
Add the logic in the NAND core to find the right ECC engine depending on the NAND chip requirements and the user desires. Right now, the choice may be made between (more will come): * software Hamming * software BCH * on-die (SPI-NAND devices only) Once the ECC engine has been found, the ECC engine must be configured. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-2-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Fill a default ECC provider/algorithmMiquel Raynal
The SPI-NAND layer default is on-die ECC because until now it was the only one supported. New SPI-NAND chip flavors might use something else as ECC engine provider but this will always be the default if the user does not choose explicitly something else. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-6-miquel.raynal@bootlin.com
2020-12-10mtd: nand: Let on-die ECC engines be retrieved from the NAND coreMiquel Raynal
Before making use of the ECC engines, we must retrieve them. Add the necessary boilerplate. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-5-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Instantiate a SPI-NAND on-die ECC engineMiquel Raynal
Make use of the existing functions taken from the SPI-NAND core to instantiate an on-die ECC engine specific to the SPI-NAND core. The next step will be to tweak the core to use this object instead of calling the helpers directly. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-4-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Move ECC related definitions earlier in the driverMiquel Raynal
Prepare the creation of a SPI-NAND on-die ECC engine by gathering the ECC-related code earlier enough in the core to avoid the need for forward declarations. The next step is to actually create that engine by implementing the generic ECC interface. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-3-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Fix typo in commentMiquel Raynal
One comment in the SPI-NAND core is not very clear, fix it to ease the understanding of what the block does. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-2-miquel.raynal@bootlin.com
2020-12-10mtd: nand: Let software ECC engines be retrieved from the NAND coreMiquel Raynal
Before making use of the ECC engines, we must retrieve them. Add the boilerplate for the ones already available: software engines (Hamming and BCH). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-21-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Create the software Hamming engineMiquel Raynal
Let's continue introducing the generic ECC engine abstraction in the NAND subsystem by instantiating a second ECC engine: software Hamming. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-20-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Let the software Hamming ECC engine be unselectedMiquel Raynal
There is no reason to always embed the software Hamming ECC engine implementation. By default it is (with raw NAND), but we can let the user decide. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-19-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Remove useless includesMiquel Raynal
Most of the includes are simply useless, drop them. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-18-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Stop using raw NAND structuresMiquel Raynal
This code is meant to be reused by the SPI-NAND core. Now that the driver has been cleaned and reorganized, use a generic ECC engine object to store the driver's data instead of accessing members of the nand_chip structure. This means adding proper init/cleanup helpers. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-17-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Rename the exported functionsMiquel Raynal
Prefix by ecc_sw_hamming_ the functions which should be internal only but are exported for "raw" operations. Prefix by nand_ecc_sw_hamming_ the other functions which will be used in the context of the declaration of an Hamming proper ECC engine object. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-16-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Cleanup and style fixesMiquel Raynal
Various style fixes. There is not functional change. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-15-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Drop/fix the kernel docMiquel Raynal
Some functions should never have been exported (the ones prefixed by __*), in this case simply drop the documentation, we never want anybody to use this function from the outside. For the other functions, enhance the style. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-14-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Clarify the driver descriptionsMiquel Raynal
The include file pretends being the header for "ECC algorithm", while it is just the header for the Hamming implementation. Make this clear by rewording the sentence. Do the same with the module description. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-13-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-hamming: Move Hamming code to the generic NAND layerMiquel Raynal
Hamming ECC code might be later re-used by the SPI NAND layer. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-12-miquel.raynal@bootlin.com
2020-12-10mtd: rawnand: Get rid of chip->ecc.privMiquel Raynal
nand_ecc_ctrl embeds a private pointer which only has a meaning in the sunxi driver. This structure will soon be deprecated, but as this field is actually not needed, let's just drop it. Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-11-miquel.raynal@bootlin.com
2020-12-10mtd: nand: ecc-bch: Create the software BCH engineMiquel Raynal
Let's continue introducing the generic ECC engine abstraction in the NAND subsystem by instantiating a first ECC engine: the software BCH one. While at it, make a very tidy ecc_sw_bch_init() function and move all the sanity checks and user input management in nand_ecc_sw_bch_init_ctx(). This second helper will be called from the raw RAND core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-10-miquel.raynal@bootlin.com
2020-12-10Revert "macb: support the two tx descriptors on at91rm9200"Willy Tarreau
This reverts commit 0a4e9ce17ba77847e5a9f87eed3c0ba46e3f82eb. The code was developed and tested on an MSC313E SoC, which seems to be half-way between the AT91RM9200 and the AT91SAM9260 in that it supports both the 2-descriptors mode and a Tx ring. It turns out that after the code was merged I could notice that the controller would sometimes lock up, and only when dealing with sustained bidirectional transfers, in which case it would report a Tx overrun condition right after having reported being ready, and will stop sending even after the status is cleared (a down/up cycle fixes it though). After adding lots of traces I couldn't spot a sequence pattern allowing to predict that this situation would happen. The chip comes with no documentation and other bits are often reported with no conclusive pattern either. It is possible that my change is wrong just like it is possible that the controller on the chip is bogus or at least unpredictable based on existing docs from other chips. I do not have an RM9200 at hand to test at the moment and a few tests run on a more recent 9G20 indicate that this code path cannot be used there to test the code on a 3rd platform. Since the MSC313E works fine in the single-descriptor mode, and that people using the old RM9200 very likely favor stability over performance, better revert this patch until we can test it on the original platform this part of the driver was written for. Note that the reverted patch was actually tested on MSC313E. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Palmer <daniel@0x0f.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/netdev/20201206092041.GA10646@1wt.eu/ Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10net: qualcomm: rmnet: Update rmnet device MTU based on real deviceSubash Abhinov Kasiviswanathan
Packets sent by rmnet to the real device have variable MAP header lengths based on the data format configured. This patch adds checks to ensure that the real device MTU is sufficient to transmit the MAP packet comprising of the MAP header and the IP packet. This check is enforced when rmnet devices are created and updated and during MTU updates of both the rmnet and real device. Additionally, rmnet devices now have a default MTU configured which accounts for the real device MTU and the headroom based on the data format. Signed-off-by: Sean Tranchetti <stranche@codeaurora.org> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Tested-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10PCI: Keep both device and resource name for config space remapsAlexander Lobakin
Follow the rule taken in commit 35bd8c07db2c ("devres: keep both device name and resource name in pretty name") and keep both device and resource names while requesting memory regions for PCI config space to prettify e.g. /proc/iomem output: Before (DWC Host Controller): 18b00000-18b01fff : dbi 18b10000-18b11fff : config 18b20000-18b21fff : dbi 18b30000-18b31fff : config After: 18b00000-18b01fff : 18b00000.pci dbi 18b10000-18b11fff : 18b00000.pci config 18b20000-18b21fff : 18b20000.pci dbi 18b30000-18b31fff : 18b20000.pci config Link: https://lore.kernel.org/r/WbKfdybjZ6xNIUjcC5oC8NcuLqrJfkxQAlnO80ag@cp3-web-020.plabs.ch Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10net: lapbether: Consider it successful if (dis)connecting when already ↵Xie He
(dis)connected When the upper layer instruct us to connect (or disconnect), but we have already connected (or disconnected), consider this operation successful rather than failed. This can help the upper layer to correct its record about whether we are connected or not here in layer 2. The upper layer may not have the correct information about whether we are connected or not. This can happen if this driver has already been running for some time when the "x25" module gets loaded. Another X.25 driver (hdlc_x25) is already doing this, so we make this driver do this, too. Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Xie He <xie.he.0141@gmail.com> Acked-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10igc: Add new device IDSasha Neftin
Add new device ID for the next step of the silicon and reflect the I226_K part. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10platform/chrome: cros_ec_typec: Tolerate unrecognized mux flagsPrashant Malani
On occasion, the Chrome Embedded Controller (EC) can send a mux configuration which doesn't map to a particular data mode. For instance, dedicated Type C chargers, when connected, may cause only USB_PD_MUX_POLARITY_INVERTED to be set. This is a valid flag combination and should not lead to a driver abort. Modify the mux configuration handling to not return an error when an unrecognized mux flag combination is encountered. Concordantly, make the ensuing print a debug level print so as to not pollute the kernel logs. Cc: Keith Short <keithshort@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20201106020305.767202-1-pmalani@chromium.org
2020-12-10net: mediatek: simplify the return expression of mtk_gmac_sgmii_path_setup()Zheng Yongjun
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10net/mlx4: simplify the return expression of mlx4_init_srq_table()Zheng Yongjun
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10net: stmmac: simplify the return tc_delete_knode()Zheng Yongjun
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10RDMA/mlx4: Remove bogus dev_base_lock usageVladimir Oltean
It is not clear what this lock protects. If the authors wanted to ensure that "dev" does not disappear, that is impossible, given the following code path: mlx4_ib_netdev_event (under RTNL mutex) -> mlx4_ib_scan_netdevs -> mlx4_ib_update_qps Also, the dev_base_lock does not protect dev->dev_addr either. So it serves no purpose here. Remove it. Link: https://lore.kernel.org/r/20201208193928.1500893-1-vladimir.oltean@nxp.com Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-12-10PCI: xgene: Removed unused ".bus_shift" initialisers from pci-xgene.cKrzysztof Wilczyński
Removed unused ".bus_shift" initialisers from pci-xgene.c as xgene_pcie_map_bus() did not use these. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201129230743.3006978-6-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10PCI: vmd: Update type of the __iomem pointersKrzysztof Wilczyński
Use "void __iomem" instead "char __iomem" pointer type when working with the accessor functions (with names like readb() or writel(), etc.) to better match a given accessor function signature where commonly the address pointing to an I/O memory region would be a "void __iomem" pointer. Related: https://lwn.net/Articles/102232/ Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201129230743.3006978-5-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>
2020-12-10PCI: iproc: Convert to use the new ECAM constantsKrzysztof Wilczyński
Change interface of the function iproc_pcie_map_ep_cfg_reg() so that use of PCI_SLOT() and PCI_FUNC() macros and most of the local ECAM-specific constants can be dropped, and the new PCIE_ECAM_OFFSET() macro can be used instead. Use the ALIGN_DOWN() macro to ensure that PCI Express ECAM offset is always 32 bit aligned. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201129230743.3006978-4-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10PCI: thunder-pem: Add constant for custom ".bus_shift" initialiserKrzysztof Wilczyński
Add a custom constant for the ".bus_shift" initialiser to capture a non-standard platform-specific ECAM bus shift value. Standard values otherwise defined in the PCI Express Specification are available in the include/linux/pci-ecam.h. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201129230743.3006978-3-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10PCI: Unify ECAM constants in native PCI Express driversKrzysztof Wilczyński
Add ECAM-related constants to provide a set of standard constants defining memory address shift values to the byte-level address that can be used to access the PCI Express Configuration Space, and then move native PCI Express controller drivers to use the newly introduced definitions retiring driver-specific ones. Refactor pci_ecam_map_bus() function to use newly added constants so that limits to the bus, device function and offset (now limited to 4K as per the specification) are in place to prevent the defective or malicious caller from supplying incorrect configuration offset and thus targeting the wrong device when accessing extended configuration space. This refactor also allows for the ".bus_shift" initialisers to be dropped when the user is not using a custom value as a default value will be used as per the PCI Express Specification. Thanks to Qian Cai <qcai@redhat.com>, Michael Walle <michael@walle.cc>, and Vladimir Oltean <olteanv@gmail.com> for reporting a pci_ecam_create() issue with .bus_shift and to Vladimir for proposing the fix. [bhelgaas: incorporate Vladimir's fix, update commit log] Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201129230743.3006978-2-kw@linux.com Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jon Derrick <jonathan.derrick@intel.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10clk: tegra: Fix duplicated SE clock entryDmitry Osipenko
The periph_clks[] array contains duplicated entry for Security Engine clock which was meant to be defined for T210, but it wasn't added properly. This patch corrects the T210 SE entry and fixes the following error message on T114/T124: "Tegra clk 127: register failed with -17". Fixes: dc37fec48314 ("clk: tegra: periph: Add new periph clks and muxes for Tegra210") Tested-by Nicolas Chauvet <kwizart@gmail.com> Reported-by Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20201025224212.7790-1-digetx@gmail.com Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-12-10Merge tag 'linux-can-next-for-5.11-20201210' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2020-12-10 here's a pull request of 7 patches for net-next/master. The first patch is by Oliver Hartkopp for the CAN ISOTP, which adds support for functional addressing. A patch by Antonio Quartulli removes an unneeded unlikely() annotation from the rx-offload helper. The next three patches target the m_can driver. Sean Nyekjaers's patch removes a double clearing of clock stop request bit, Patrik Flykt's patch moves the runtime PM enable/disable to m_can_platform and Jarkko Nikula's patch adds a PCI glue code driver. Fabio Estevam's patch converts the flexcan driver to DT only. And Manivannan Sadhasivam's patchd for the mcp251xfd driver adds internal loopback mode support. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10clk: qcom: rpmh: add support for SM8350 rpmh clocksVinod Koul
This adds the RPMH clocks present in SM8350 SoC Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201208064702.3654324-3-vkoul@kernel.org [sboyd@kernel.org: Move sdx55 to the right place] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-12-10PCI: Disable PTM during suspend to save powerDavid E. Box
There are systems (for example, Intel based mobile platforms since Coffee Lake) where the power drawn while suspended can be significantly reduced by disabling Precision Time Measurement (PTM) on PCIe root ports as this allows the port to enter a lower-power PM state and the SoC to reach a lower-power idle state. To save this power, disable the PTM feature on root ports during pci_prepare_to_sleep() and pci_finish_runtime_suspend(). The feature will be returned to its previous state during restore and error recovery. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209361 Link: https://lore.kernel.org/r/20201207223951.19667-2-david.e.box@linux.intel.com Reported-by: Len Brown <len.brown@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resumeDavid E. Box
The PCI subsystem does not currently save and restore the configuration space for the Precision Time Measurement (PTM) Extended Capability leading to the possibility of the feature returning disabled on S3 resume. This has been observed on Intel Coffee Lake desktops. Add save/restore of the PTM control register. This saves the PTM Enable, Root Select, and Effective Granularity bits. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20201207223951.19667-1-david.e.box@linux.intel.com Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
generated by cgit (git 2.34.1) at 2025-09-14 10:05:43 +0000