On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
> Can I ask someone with more
> technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about
> the possible challenges of nouveau taking matters into its own hand rather
> than keeping this PCI quirk around?
It sounds to me
On Wed, Mar 17, 2021 at 01:02:07PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> On 3/17/21 12:01 PM, Lukas Wunner wrote:
> > If the events are ignored, the driver of the device in the hotplug slot
> > is not unbound and rebound. So the driver must be able to cope with
> > lo
On Sat, Mar 27, 2021 at 10:49:45PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> On 3/16/21 9:13 PM, Lukas Wunner wrote:
> > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > @@ -707,6 +707,17 @@ static irqreturn_t pciehp_ist(
On Wed, Mar 17, 2021 at 12:22:41PM -0700, Raj, Ashok wrote:
> On Wed, Mar 17, 2021 at 08:09:52PM +0100, Lukas Wunner wrote:
> > On Wed, Mar 17, 2021 at 10:45:21AM -0700, Dan Williams wrote:
> > > Ah, ok, we're missing a flush of the hotplug event handler after the
> > &
On Wed, Mar 17, 2021 at 10:45:21AM -0700, Dan Williams wrote:
> Ah, ok, we're missing a flush of the hotplug event handler after the
> link is up to make sure the hotplug handler does not see the Link Up.
> I'm not immediately seeing how the new proposal ensures that there is
> no Link Up event
On Wed, Mar 17, 2021 at 10:54:09AM -0700, Sathyanarayanan Kuppuswamy Natarajan
wrote:
> Flush of hotplug event after successful recovery, and a simulated
> hotplug link down event after link recovery fails should solve the
> problems raised by Lukas. I assume Lukas' proposal adds this support.
>
On Tue, Mar 16, 2021 at 10:08:31PM -0700, Dan Williams wrote:
> On Tue, Mar 16, 2021 at 9:14 PM Lukas Wunner wrote:
> >
> > On Fri, Mar 12, 2021 at 07:32:08PM -0800,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > + if ((events == PCI_EXP_SLTSTA_DLLS
and submit it properly. Let me know what you think. Thanks!
-- >8 --
Subject: [PATCH] PCI: pciehp: Ignore Link Down/Up caused by DPC
Signed-off-by: Lukas Wunner
---
drivers/pci/hotplug/pciehp_hpc.c | 11 +
drivers/pci/pci.h|
On Fri, Mar 12, 2021 at 11:34:46AM +0100, Alain Volmat wrote:
> --- a/drivers/spi/spi-stm32.c
> +++ b/drivers/spi/spi-stm32.c
> @@ -1960,6 +1960,7 @@ static int stm32_spi_remove(struct platform_device
> *pdev)
> struct spi_master *master = platform_get_drvdata(pdev);
> struct
On Thu, Mar 04, 2021 at 11:28:37AM +0300, Heikki Krogerus wrote:
> The old device property API is going to be removed.
> Replacing the device_add_properties() call with the software
> node API equivalent, device_create_managed_software_node().
>
> Signed-off-by: Heikki Krogerus
On Wed, Feb 03, 2021 at 09:11:03AM +, Gustavo Pimentel wrote:
> On Wed, Feb 3, 2021 at 7:51:3, Lukas Wunner wrote:
> > On Wed, Feb 03, 2021 at 01:54:49AM +, Gustavo Pimentel wrote:
> > > On Tue, Feb 2, 2021 at 18:8:55, Lukas Wunner wrote:
> > > > As th
On Wed, Feb 03, 2021 at 01:54:49AM +, Gustavo Pimentel wrote:
> On Tue, Feb 2, 2021 at 18:8:55, Lukas Wunner wrote:
> > As the name implies, the capability is "vendor-specific", so it is
> > perfectly possible that two vendors use the same VSEC ID for different
>
On Tue, Feb 02, 2021 at 01:40:18PM +0100, Gustavo Pimentel wrote:
> /**
> + * pci_find_vsec_capability - Find a vendor-specific extended capability
> + * @dev: PCI device to query
> + * @cap: vendor-specific capability ID code
> + *
> + * Returns the address of the vendor-specific structure that
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 355845b738e76445c8522802552146d96cb4afa7
Gitweb:
https://git.kernel.org/tip/355845b738e76445c8522802552146d96cb4afa7
Author:Lukas Wunner
AuthorDate:Thu, 31 Dec 2020 06:10:32 +01:00
On Sat, Jan 23, 2021 at 07:26:24PM -0800, Jakub Kicinski wrote:
> On Fri, 22 Jan 2021 09:47:01 +0100 Lukas Wunner wrote:
> > sch_handle_egress() returns either the skb or NULL to signal to its
> > caller __dev_queue_xmit() whether a packet should continue to be
> > proces
On Tue, Jan 12, 2021 at 09:28:32AM -0800, Linus Torvalds wrote:
> On Tue, Jan 12, 2021 at 5:20 AM Lukas Wunner wrote:
> > > Variable declarations in for-loops is the only one I can think of. I
> > > think that would clean up some code (and some macros), but might not
>
On Fri, Jan 08, 2021 at 12:02:53PM -0800, Linus Torvalds wrote:
> I appreciate Arnd pointing out "--std=gnu11", though. What are the
> actual relevant language improvements?
>
> Variable declarations in for-loops is the only one I can think of. I
> think that would clean up some code (and some
On Mon, Jan 11, 2021 at 08:46:48PM +0530, Vinod Koul wrote:
> @@ -328,8 +609,34 @@ static int spi_geni_init(struct spi_geni_master *mas)
> spi_tx_cfg &= ~CS_TOGGLE;
> writel(spi_tx_cfg, se->base + SE_SPI_TRANS_CFG);
>
> + mas->tx = dma_request_slave_channel(mas->dev, "tx");
> +
On Thu, Dec 31, 2020 at 10:38:12AM +0100, Heiner Kallweit wrote:
> On 31.12.2020 05:07, Lukas Wunner wrote:
> > FWIW, if platform_pci_power_manageable() returns true, it can probably
> > be assumed that allowing runtime PM by default is okay. So as a first
> > step,
On Wed, Dec 30, 2020 at 12:19:04AM +0100, Bert Vermeulen wrote:
> +static inline void wait_ready(struct rtspi *rtspi)
> +{
> + while (!(readl(REG(RTL8380_SPI_SFCSR)) & RTL8380_SPI_SFCSR_RDY))
> + ;
> +}
I'd suggest calling cpu_relax() in the loop's body.
> + err =
On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
> u16 status;
> u16 pmc;
>
> - pm_runtime_forbid(>dev);
> + if (pci_acpi_forbid_runtime_pm())
> +
> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
> > With Runtime PM disabled e.g. the PHY on network devices may remain
> > powered up even with no cable plugged in, affecting battery lifetime
> > on mobile devices. Currently we have to rely on the respective distro
> > or user
On Wed, Dec 09, 2020 at 08:57:57AM +0100, Jayshri Pawar wrote:
> + master = spi_alloc_master(dev, sizeof(*cdns_xspi));
> + if (!master) {
> + ret = -ENOMEM;
> + dev_err(dev, "Failed to allocate memory for spi_master\n");
> + goto err_no_mem;
> + }
On Fri, Dec 11, 2020 at 01:15:58PM -0800, Sowjanya Komatineni wrote:
> Tegra SoC has a Quad SPI controller starting from Tegra210.
The probe/remove hooks LGTM now. Just two tiny nits that caught my eye:
> + master = devm_spi_alloc_master(>dev, sizeof(*tqspi));
> + if (!master) {
> +
On Thu, Dec 03, 2020 at 02:51:24PM -0800, Raj, Ashok wrote:
> - Press ATTN,
> - Slot is empty
> - After 5 seconds synthetic PDC arrives.
> but since no presence and no link active, we leave slot in
> BLINKINGON_STATE, and led keeps blinking
>
> if someone were to add a card after the 5
On Mon, Dec 07, 2020 at 04:14:53PM -0800, Sowjanya Komatineni wrote:
> On 12/6/20 10:16 AM, Lukas Wunner wrote:
> > However, be sure to use the devm variant to *allocate* the SPI controller,
> > i.e. use devm_spi_alloc_master() instead of spi_alloc_master().
>
>
On Tue, Dec 01, 2020 at 01:12:44PM -0800, Sowjanya Komatineni wrote:
> + ret = devm_spi_register_master(>dev, master);
[...]
> +static int tegra_qspi_remove(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> + struct tegra_qspi_data *tqspi
porting
issue reported above.
Thanks!
-- >8 --
Subject: [PATCH] spi: Fix controller unregister order harder
Commit c7e41e1caa71 sought to backport upstream commit 84855678add8 to
the 4.9-stable tree but erroneously inserted a line at the wrong place.
Fix it.
Fixes: c7e41e1caa71 ("spi: Fix
On Mon, Nov 30, 2020 at 11:30:05AM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 23, 2020 at 02:45:13PM +0800, Jianjun Wang wrote:
> > On Thu, 2020-11-19 at 14:28 -0600, Bjorn Helgaas wrote:
> > > > +static int mtk_pcie_setup(struct mtk_pcie_port *port)
> > > > +{
[...]
> > > > + /* Try link up
On Mon, Nov 23, 2020 at 05:19:06PM +0800, Qing Zhang wrote:
> +static struct platform_device loongson_spi_device = {
> + .name = "loongson-spi",
> + .id = 0,
> + .num_resources = ARRAY_SIZE(loongson_spi_resources),
> + .resource = loongson_spi_resources,
>
On Sat, Nov 21, 2020 at 05:42:03PM -0800, Ashok Raj wrote:
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32
> events)
> {
> int present, link_active;
> + u8 getstatus = 0;
>
On Thu, Nov 19, 2020 at 02:08:07PM -0800, Raj, Ashok wrote:
> On Thu, Nov 19, 2020 at 08:51:20AM +0100, Lukas Wunner wrote:
> > If an Attention Button is present, the current behavior is to bring up
> > the hotplug slot as soon as presence or link is detected. We don't wait
> &g
Hi Ashok,
my sincere apologies for the delay.
On Fri, Sep 25, 2020 at 04:01:38PM -0700, Ashok Raj wrote:
> When Mechanical Retention Lock (MRL) is present, Linux doesn't process
> those change events.
>
> The following changes need to be enabled when MRL is present.
>
> 1. Subscribe to MRL
On Sun, Nov 15, 2020 at 04:11:43PM +0100, Thomas Gleixner wrote:
> Unfortunately there is no way to tell the APIC "Mask vector X" and the
> dump kernel does neither know which device it comes from nor does it
> have enumerated PCI completely which would reset the device and shutup
> the spew. Due
On Thu, Oct 15, 2020 at 01:53:35PM +0100, Mark Brown wrote:
> On Thu, Oct 15, 2020 at 07:38:29AM +0200, Lukas Wunner wrote:
> > On Wed, Oct 14, 2020 at 09:25:05PM +0100, Mark Brown wrote:
> > How about holding a ref on the controller as long as the SPI driver
> > is boun
On Wed, Oct 14, 2020 at 02:20:16PM -0700, Florian Fainelli wrote:
> In bcm2835_spi_remove(), spi_controller_unregister() will free the ctlr
> reference which will lead to an use after free in bcm2835_release_dma().
>
> To avoid this use after free, allocate the bcm2835_spi structure with a
>
[cc += Sascha]
On Wed, Oct 14, 2020 at 09:25:05PM +0100, Mark Brown wrote:
> > On Wed, Oct 14, 2020 at 04:09:12PM +0200, Lukas Wunner wrote:
> > > Apparently the problem is that spi_unregister_controller() drops the
> > > last ref on the controller, causing it to be
On Tue, Oct 13, 2020 at 04:48:42PM -0700, Florian Fainelli wrote:
> With KASAN now working on ARM 32-bit, I was able to get the following
> trace upon reboot which invokes bcm2835_spi_shutdown() calling
> bcm2835_spi_remove(), the same can be triggered by doing a driver unbind:
Thank you for the
On Thu, Oct 08, 2020 at 12:43:17PM +0530, Sanjay R Mehta wrote:
> On 10/7/2020 1:08 AM, Lukas Wunner wrote:
> > On Tue, Oct 06, 2020 at 01:24:28PM -0500, Sanjay R Mehta wrote:
> I am supposed to use PCI_EXP_LNKSTA_DLLLA bit in my patch but have
> used PCI_EXP_DPC_CAP_DL_ACTIVE.
&
On Tue, Oct 06, 2020 at 01:24:28PM -0500, Sanjay R Mehta wrote:
> if DL_ACTIVE bit is set it means that there is no need to check
> PCI_EXP_LNKSTA_LT bit, as DL_ACTIVE would have set only if the link
> is already trained. Hence adding a check which takes care of this
> scenario.
Sorry for being
On Sat, Oct 03, 2020 at 03:55:12AM -0400, Ethan Zhao wrote:
> When root port has DPC capability and it is enabled, then triggered by
> errors, DPC DLLSC and PDC etc interrupts will be sent to DPC driver, pciehp
> drivers almost at the same time.
Do the DLLSC and PDC events occur as a result of
On Tue, Sep 29, 2020 at 05:46:41PM +0800, Ethan Zhao wrote:
> On Tue, Sep 29, 2020 at 4:29 PM Lukas Wunner wrote:
> > On Sun, Sep 27, 2020 at 11:27:46AM -0400, Sinan Kaya wrote:
> > > On 9/26/2020 11:28 PM, Ethan Zhao wrote:
> > > > --- a/drivers/pci/hotplug/pciehp_h
On Sun, Sep 27, 2020 at 11:27:46AM -0400, Sinan Kaya wrote:
> On 9/26/2020 11:28 PM, Ethan Zhao wrote:
> > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > @@ -710,8 +710,10 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
> > down_read(>reset_lock);
On Tue, Sep 15, 2020 at 04:15:15PM +0200, Jinpu Wang wrote:
> We are testing PCIe nvme SSD hotplug, it works out of box with kernel 5.4.62,
> dmesg during the hotplug:
[...]
> But with kernel 4.19.133, pcieport core doesn't print anything, is
> there known problem with kernel 4.19 support for pcie
On Mon, Sep 14, 2020 at 04:29:10AM +0800, Tiezhu Yang wrote:
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -143,6 +144,28 @@ static void pcie_portdrv_remove(struct pci_dev *dev)
> }
>
> pcie_port_device_remove(dev);
> +
On Tue, Sep 01, 2020 at 05:30:59PM +0200, Krzysztof Kozlowski wrote:
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and the error value gets printed.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lukas Wunner
On Tue, Sep 01, 2020 at 05:31:00PM +0200, Krzysztof Kozlowski wrote:
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and the error value gets printed.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lukas Wunner
On Fri, Jul 31, 2020 at 08:45:05AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 30, 2020 at 11:56:10AM +0200, Lukas Wunner wrote:
> > On Thu, Jul 30, 2020 at 08:53:26AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 08, 2020 at 03:27:02PM +0200, Lukas Wunner wrote:
&
On Thu, Jul 30, 2020 at 08:53:26AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2020 at 03:27:02PM +0200, Lukas Wunner wrote:
> > kill_device() is currently serialized with driver probing by way of the
> > device_lock(). We're about to serialize it with device_add() as well
On Fri, Jul 24, 2020 at 10:29:50PM +0800, kernel test robot wrote:
> commit: e3b1cb5c896ba748d8f848238c8ea1f89520bde3 ("[PATCH 3/3] driver core:
> Avoid adding children below a dead parent")
[...]
> [1.392584] WARNING: possible recursive locking detected
> [1.393350]
On Thu, Jul 23, 2020 at 05:13:06PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-9):
[...]
> commit: 3233e41d3e8ebcd44e92da47ffed97fd49b84278 ("[PATCH] PCI: pciehp: Fix
> AB-BA deadlock between reset_lock and device_lock")
[...]
> caused below changes
On Fri, Jul 17, 2020 at 03:04:10PM -0400, Lyude Paul wrote:
> Isn't it possible to tell whether a PCI device is connected through
> thunderbolt or not? We could probably get away with just defaulting
> to 100ms for thunderbolt devices without DLL Link Active specified,
> and then default to the
On Fri, Jul 10, 2020 at 02:00:34PM +0300, Kirill A. Shutemov wrote:
> On Fri, Jul 10, 2020 at 12:09:36PM +0200, Arnd Bergmann wrote:
> > I forgot why we care though -- is there any behavior of gnu11
> > that we prefer over the gnu99 behavior, or is it just going with
> > the times because it's the
deadlocks occurring
with the new use case (patch [2/3]).
Add a missing check for the "dead" flag upon driver binding
(patch [1/3]).
Lukas Wunner (3):
driver core: Avoid binding drivers to dead devices
driver core: Use rwsem for kill_device() serialization
driver core: Avoid addin
of an
SPI controller and teach the driver core to refuse device addition below
a killed parent. To make this race-free, device_add() needs to take the
parent's dead_sem before checking its "dead" flag and until the child
device has been added to the parent's klist_children.
Signed-off-by: L
nstead of a mutex).
Signed-off-by: Lukas Wunner
Cc: Dan Williams
Cc: Geert Uytterhoeven
Cc: Pantelis Antoniou
Cc: Alexander Duyck
---
drivers/base/base.h | 2 ++
drivers/base/core.c | 33 +++--
drivers/base/dd.c| 8
drivers/nvdimm/bus.c | 8 +---
4
deadlocks occurring
with the new use case (patch [2/3]).
Add a missing check for the "dead" flag upon driver binding
(patch [1/3]).
Lukas Wunner (3):
driver core: Avoid binding drivers to dead devices
driver core: Use rwsem for kill_device() serialization
driver core: Avoid addin
5ef24 ("driver core: Establish order of operations for device_add
and device_del via bitflag")
Signed-off-by: Lukas Wunner
Cc: sta...@vger.kernel.org # v5.1+
Cc: Alexander Duyck
---
drivers/base/dd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dd.c
15 years ago, commit 6eded061b126 ("Fix up bus code and remove use of
rwsem") removed the bus rwsem, but left over a reference to it in a
kernel-doc comment. Drop it.
Signed-off-by: Lukas Wunner
---
drivers/base/dd.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
On Thu, Jul 02, 2020 at 01:37:13AM +0300, Serge Semin wrote:
> 1) Add a new capability like UART_CAP_NO16DIV and take it into account
>in the serial8250_get_baud_rate() method.
>
> I don't have a documentation for the Mediatek UART port, but it seems to me
> that that controller calculates
On Tue, Jun 30, 2020 at 04:42:11PM -0700, Daniel Winkler wrote:
> This reverts commit 0eeaf62981ecc79e8395ca8caa1570eaf3a12257.
That is not an upstream commit. You probably mean:
commit 7b668c064ec33f3d687c3a413d05e355172e6c92
Author: Serge Semin
Date: Thu May 7 02:31:32 2020
On Fri, Jun 19, 2020 at 10:12:19PM +0200, refactormys...@gmail.com wrote:
> On failure, pcie_capabiility_read_*() will set the status value,
> its last parameter to 0 and not ~0.
> This bug fix checks for the proper value.
If a config space read times out, the PCIe controller fabricates
an "all
[cc += Heiko]
On Wed, Jun 10, 2020 at 05:51:21PM +0200, Johan Hovold wrote:
> Drop the recently added gpio include from the serial-core header in
> favour of a forward declaration and instead include the gpio header only
> where needed.
Hm, but why? Are there adverse effects if this is included
On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
> And all in code that has at least one obvious inefficiency left on
> the table either way.
Care to submit a patch to overcome that inefficiency?
> This thread truly epitomises Knuth's "premature optimisation" quote... ;)
The
On Thu, Jun 04, 2020 at 01:24:54PM -0700, Florian Fainelli wrote:
> So we do need to know for the first time we install the interrupt
> handler whether we will be in a shared situation or not, I cannot think
> of any solution other than counting the number of available DT nodes
> with the
and both bcm2835_spi_interrupt() as well
> as bcm2835_spi_shared_interrupt() make use of it.
>
> During probe, we determine if there is at least another instance of this
> SPI controller, and if there is, then we install a shared interrupt
> handler.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Lukas Wunner
On Thu, Jun 04, 2020 at 12:13:25PM +0100, Mark Brown wrote:
> On Thu, Jun 04, 2020 at 06:20:38AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> > > The BCM2711 SoC features 5 SPI controllers which all share the same
> > &
On Wed, Jun 03, 2020 at 08:46:53PM -0700, Florian Fainelli wrote:
> The BCM2711 and BCM7211 chips use the BCM2835 SPI controller, but there
> are severl instances of those in the system and they all share the same
^^
Nit: "several"
And apparently they do not *all* share the interrupt,
On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> The BCM2711 SoC features 5 SPI controllers which all share the same
> interrupt line, the SPI driver needs to support interrupt sharing,
> therefore use the chip specific compatible string to help with that.
You're saying above
On Wed, Jun 03, 2020 at 08:46:55PM -0700, Florian Fainelli wrote:
> +static const struct of_device_id bcm2835_spi_match[] = {
> + { .compatible = "brcm,bcm2835-spi", .data = _spi_interrupt },
> + { .compatible = "brcm,bcm2711-spi", .data = _spi_sh_interrupt },
> + { .compatible =
On Fri, May 29, 2020 at 11:03:48AM -0700, Florian Fainelli wrote:
> On 5/29/20 10:53 AM, Lukas Wunner wrote:
> > On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
> >> On 5/29/20 10:43 AM, Lukas Wunner wrote:
> >>> Finally, it would be nice if the chec
On Fri, May 29, 2020 at 10:48:11AM -0700, Florian Fainelli wrote:
> On 5/29/20 10:47 AM, Lukas Wunner wrote:
> > On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
> >> Make sure we clear the FIFOs, stop the block, disable the clock and
> >> release the DM
On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
> On 5/29/20 10:43 AM, Lukas Wunner wrote:
> > On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
> >> --- a/drivers/spi/spi-bcm2835.c
> >> +++ b/drivers/spi/spi-bcm2835.c
>
On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
> Make sure we clear the FIFOs, stop the block, disable the clock and
> release the DMA channel.
To what end? Why is this change necessary? Sorry but this seems like
an awfully terse commit message.
Thanks,
Lukas
>
>
On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
> --- a/drivers/spi/spi-bcm2835.c
> +++ b/drivers/spi/spi-bcm2835.c
> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void
> *dev_id)
> if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>
On Mon, May 18, 2020 at 05:22:47PM +0200, Lukas Wunner wrote:
> And for longer cables, users may have to disable it using the
> TIOCSRS485 ioctl.
Sorry, I meant *enable* here. %-/
On Mon, May 18, 2020 at 06:12:41PM +0300, Andy Shevchenko wrote:
> On Sun, May 17, 2020 at 11:56:08PM +0200, Heiko Stuebner wrote:
> > From: Heiko Stuebner
> >
> > The RE signal is used to control the duplex mode of transmissions,
> > aka receiving data while sending in full duplex mode, while
On Mon, May 18, 2020 at 10:04:05AM +0200, Heiko Stübner wrote:
> Am Montag, 18. Mai 2020, 06:50:06 CEST schrieb Lukas Wunner:
> > On Sun, May 17, 2020 at 11:56:08PM +0200, Heiko Stuebner wrote:
> > > @@ -1457,6 +1458,7 @@ void serial8250_em485_stop_tx(struct uart_8
On Sun, May 17, 2020 at 11:56:08PM +0200, Heiko Stuebner wrote:
> @@ -1457,6 +1458,7 @@ void serial8250_em485_stop_tx(struct uart_8250_port *p)
>* Enable previously disabled RX interrupts.
>*/
> if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
> +
On Thu, Mar 26, 2020 at 12:14:21AM +0100, Heiko Stuebner wrote:
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3356,6 +3356,18 @@ int uart_get_rs485_mode(struct uart_port *port)
> rs485conf->flags |= SER_RS485_TERMINATE_BUS;
> }
On Thu, Mar 26, 2020 at 12:14:20AM +0100, Heiko Stuebner wrote:
> --- a/Documentation/devicetree/bindings/serial/rs485.yaml
> +++ b/Documentation/devicetree/bindings/serial/rs485.yaml
> @@ -44,6 +44,10 @@ properties:
> description: enables the receiving of data even while sending data.
>
On Thu, Mar 26, 2020 at 12:14:19AM +0100, Heiko Stuebner wrote:
> Some 8250 ports have a TEMT interrupt but it's not a part of the 8250
> standard, instead only available on some implementations.
>
> The current em485 implementation does not work on ports without it.
> The only chance to make it
On Sat, May 02, 2020 at 09:11:58AM +0200, Takashi Iwai wrote:
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -673,6 +673,12 @@ static int amdgpu_dm_audio_component_bind(struct device
> *kdev,
> struct amdgpu_device
On Wed, Oct 02, 2019 at 05:28:59PM +0300, Mika Westerberg wrote:
> On Wed, Oct 02, 2019 at 04:17:54PM +0200, Oliver Neukum wrote:
> > Am Dienstag, den 01.10.2019, 14:38 +0300 schrieb Mika Westerberg:
> > > @@ -1975,10 +1972,8 @@ void tb_switch_suspend(struct tb_switch *sw)
> > > if (err)
>
On Wed, Oct 02, 2019 at 05:13:58PM -0500, Alex G. wrote:
> On 10/1/19 11:13 PM, Lukas Wunner wrote:
> > On Tue, Oct 01, 2019 at 05:14:16PM -0400, Stuart Hayes wrote:
> > > This patch set is based on a patch set [1] submitted many months ago by
> > > Alexandru Gagniu
On Tue, Oct 01, 2019 at 05:14:16PM -0400, Stuart Hayes wrote:
> This patch set is based on a patch set [1] submitted many months ago by
> Alexandru Gagniuc, who is no longer working on it.
>
> [1] https://patchwork.kernel.org/cover/10909167/
> [v3,0/4] PCI: pciehp: Do not turn off slot if
On Mon, Sep 23, 2019 at 11:12:37AM +0300, Mika Westerberg wrote:
> Regarding suggestion of unbinding PCI drivers without
> pci_lock_rescan_remove() hold, I haven't looked it too closely but I
> think we need to take that lock anyway because when we are unbinding a
> hotplug driver it is supposed
On Mon, Aug 12, 2019 at 05:31:33PM +0300, Mika Westerberg wrote:
> If there are more than one PCIe switch with hotplug downstream ports
> hot-removing them leads to a following deadlock:
For the record, I think my comments on v1 of this patch still apply:
On Thu, Sep 05, 2019 at 04:01:02PM -0500, Bjorn Helgaas wrote:
> void pciehp_set_indicators(struct controller *ctrl, int pwr, int attn)
> {
> u16 cmd = 0, mask = 0;
>
> - if (PWR_LED(ctrl) && pwr > 0) {
> - cmd |= pwr;
> + if (PWR_LED(ctrl) && pwr != INDICATOR_NOOP) {
On Tue, Sep 03, 2019 at 10:36:35PM -0600, Kelsey Skunberg wrote:
> Change pci_dev_is_disconnected() call inside pci_dev_is_inaccessible() to:
>
> pdev->error_state == pci_channel_io_perm_failure
>
> Change remaining pci_dev_is_disconnected() calls to
> pci_dev_is_inaccessible() calls.
I
On Tue, Aug 27, 2019 at 05:53:19PM -0500, Bjorn Helgaas wrote:
> Unrelated, but if anybody is looking at pciehp, is there value in
> having pciehp split across five files?
>
> drivers/pci/hotplug/pciehp.h
> drivers/pci/hotplug/pciehp_core.c
> drivers/pci/hotplug/pciehp_ctrl.c
>
On Mon, Aug 19, 2019 at 04:29:35PM +, mario.limoncie...@dell.com wrote:
> I've run into a problem when using
> a WD19TB that after unplugging it will cause the following to spew in dmesg:
>
> [ 2198.017003]
> [ 2198.017005] WARNING: possible
On Mon, Aug 12, 2019 at 03:38:46PM +0300, Mika Westerberg wrote:
> +static void icm_veto_begin(struct tb *tb)
> +{
> + struct icm *icm = tb_priv(tb);
> +
> + if (!icm->veto) {
> + icm->veto = true;
> + /* Keep the domain powered while veto is in effect */
> +
On Mon, Aug 12, 2019 at 11:49:23AM -0700, sathyanarayanan kuppuswamy wrote:
> > On 8/11/19 12:59 PM, Denis Efremov wrote:
> > > +if ((!PWR_LED(ctrl) || pwr == PWR_NONE) &&
> > > +(!ATTN_LED(ctrl) || attn == ATTN_NONE))
> > > +return;
>
> Also I think this condition needs to
On Sun, Aug 11, 2019 at 10:59:43PM +0300, Denis Efremov wrote:
> +#define pciehp_set_attention_status(ctrl, status) \
> + pciehp_set_indicators(ctrl, PWR_NONE, (status == 0 ? ATTN_OFF : status))
Reviewed-by: Lukas Wunner
Good catch regarding the translation of the "off" val
statuses.
>
> Signed-off-by: Denis Efremov
Reviewed-by: Lukas Wunner
On Sun, Aug 11, 2019 at 06:07:55PM +0200, Lukas Wunner wrote:
> if (!PWR_LED(ctrl) || pwr == PWR_NONE) &&
> !ATTN_LED(ctrl) || attn == ATTN_NONE))
> return;
Forgot an opening brace in two spots here, sorry.
On Sun, Aug 11, 2019 at 04:29:45PM +0300, Denis Efremov wrote:
> This patch replaces pciehp_green_led_{on,off,blink}() with
> pciehp_set_indicators().
>
> Signed-off-by: Denis Efremov
Reviewed-by: Lukas Wunner
On Sun, Aug 11, 2019 at 04:29:44PM +0300, Denis Efremov wrote:
> +#define pciehp_set_attention_status(crtl, status) \
> + pciehp_set_indicators(ctrl, PWR_NONE, status)
> +
There's a typo here, s/crtl/ctrl/.
With that addressed,
Reviewed-by: Lukas Wunner
On Sun, Aug 11, 2019 at 04:29:43PM +0300, Denis Efremov wrote:
> This patch replaces all consecutive switches of power and attention
> indicators with pciehp_set_indicators() call. Thus, performing only
> single write to a register.
>
> Signed-off-by: Denis Efremov
Reviewed-by: Lukas Wunner
1 - 100 of 1025 matches
Mail list logo
