On Wed, 14 Apr 2021 04:58:03 -0400, Nico Pache wrote:
> There are few instances of KUNIT tests that are not properly defined.
> This commit focuses on correcting these issues to match the standard
> defined in the Documentation.
>
> Issues Fixed:
> - tests should end in KUNIT_TEST, some fixes hav
On Wed, Apr 14, 2021 at 04:58:04AM -0400, Nico Pache wrote:
> Drop 'S' from end of SND_SOC_TOPOLOGY_KUNIT_TESTS inorder to adhear to
> the KUNIT *_KUNIT_TEST config name format.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to id
On Fri, Apr 09, 2021 at 08:14:22PM +0200, Sander Vanheule wrote:
> The kernel has the mii_bus struct to describe the bus master, but like
> you noted the bus is generaly refered to as an MDIO interface. I'm fine
> with naming it MDIO to make it easier to spot.
Either mii_bus or mdio seem like an
On Thu, Apr 08, 2021 at 10:52:34PM +0200, Sander Vanheule wrote:
> Basic support for MIIM bus access. Support only includes clause-22
> register access, with 5-bit addresses, and 16-bit wide registers.
What is "MIIM"? A quick search isn't showing up useful hits for that.
Why not just call this MD
On Tue, Mar 16, 2021 at 01:48:58PM -0600, Rob Herring wrote:
> Users of common properties shouldn't have a type definition as the
> common schemas already have one. Drop all the unnecessary type
> references in the tree.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Jan 28, 2021 at 01:45:15PM -0600, Rob Herring wrote:
> Properties with standard unit suffixes already have a type and don't need
> type definitions. They also default to a single entry, so 'maxItems: 1'
> can be dropped.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Tue, 5 Jan 2021 15:02:45 +0100, Thomas Bogendoerfer wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
>
> I've split up the removal into seperate parts for different
On Tue, 5 Jan 2021 15:02:45 +0100, Thomas Bogendoerfer wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
>
> I've split up the removal into seperate parts for different
On Tue, Jan 05, 2021 at 10:36:27AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 05, 2021 at 01:42:56PM +0000, Mark Brown wrote:
> > You're missing the point there. I2C is enumerated by firmware in
> > exactly the same way as the platform bus is, it's not discoverable f
On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 04, 2021 at 09:19:30PM +0000, Mark Brown wrote:
> > Like I keep saying the same thing applies to all non-enumerable buses -
> > exactly the same considerations exist for all the other buses like I2C
>
On Mon, Jan 04, 2021 at 02:08:31PM -0400, Jason Gunthorpe wrote:
> On Mon, Dec 21, 2020 at 06:51:40PM +0000, Mark Brown wrote:
> > BTW I did have a bit of a scan through some of the ACPI devices and
> > for a good proportion of them it seems fairly clear that they are
> > no
On Fri, Dec 18, 2020 at 04:58:56PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 08:32:11PM +0000, Mark Brown wrote:
>
> > Historically people did try to create custom bus types, as I have
> > pointed out before there was then pushback that these were duplicating
>
On Fri, Dec 18, 2020 at 02:41:50PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 06:03:10PM +0000, Mark Brown wrote:
> > If it's not supposed to use platform devices so I'm assuming that the
> > intention is that it should use aux devices, otherwise presumabl
sn't handle subschema
> identifiers and incorrectly allows JSON pointers to begin without a '/'.
> Let's fix this before it becomes a problem when jsonschema module is
> fixed.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 03:52:04PM +0000, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > > I thought the recent LWN article summed it up nicely, auxillary bus is
&
On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote:
> > As previously discussed this will need the auxilliary bus extending to
> > support at least interrupts and possibly also general resources.
> I
On Thu, Dec 17, 2020 at 06:39:55PM -0800, Dan Williams wrote:
> There is room for documentation improvement here. I realize reading it
> back now that much of the justification for "why not platform bus?"
> happened on the list, but only a small mention made it into the
It wasn't clear from the l
On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote:
> On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
> > There is something I don't get from the documentation and it is what is
> > this introducing that couldn't already be done using platform drivers
> > and platform devic
On Wed, Dec 16, 2020 at 04:05:58PM -0600, Seth Forshee wrote:
> On Thu, Dec 10, 2020 at 06:52:33PM +0000, Mark Brown wrote:
> > as part of the wider kselftest build by specifying SKIP_TARGETS,
> > including setting an empty SKIP_TARGETS to build everything. They can
> > a
On Thu, Dec 10, 2020 at 04:41:33PM -0700, Shuah Khan wrote:
> On 12/10/20 12:11 PM, Alexei Starovoitov wrote:
> > I'm fine with this, but I'd rather make an obvious second step right away
> > and move selftests/bpf into a different directory.
> Why is this an obvious second step? If people want t
is already the case to some extent and it makes it easier for people to
pick up and work with the other selftests which is hopefully a net win.
Signed-off-by: Mark Brown
---
tools/testing/selftests/Makefile | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/te
On Tue, Nov 17, 2020 at 07:30:00AM +0200, Leon Romanovsky wrote:
> On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote:
> > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > It enables drivers to create an auxiliary_device and bind an
> > auxiliary_driver to it.
On Thu, Nov 05, 2020 at 08:37:14PM +, Parav Pandit wrote:
> > > This example describes the mlx5 PCI subfunction use case.
> > > I didn't follow your question about 'explicit example'.
> > > What part is missing to identify it as explicit example?
> > Specifically listing "mlx5" so if someone
On Mon, Oct 26, 2020 at 10:47:35AM +0100, Mauro Carvalho Chehab wrote:
> Hi Mark/Jakub,
>
> As you requested, I'm resending the three -net patches
> from the /56 patch series I sent last Friday:
I was asking for you to do the same for the patches for my subsystems
rather than resend the net patch
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote:
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Wed, Sep 23, 2020 at 05:10:33PM +0200, Rolf Reintjes wrote:
> On 21.09.20 18:58, Mark Brown wrote:
> I do not understand which of the 14 patches you applied. Your mail responds
> to the 00/14 mail.
As the mail you're replying to says:
> > [1/1] spi/topcliff-pch:
On Sun, 20 Sep 2020 13:26:12 +0200, Julia Lawall wrote:
> sg_init_table zeroes its first argument, so the allocation of that argument
> doesn't have to.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi/topcliff-pch: drop double zeroing
On Wed, Aug 26, 2020 at 03:38:15AM -0700, syzbot wrote:
> console output: https://syzkaller.appspot.com/x/log.txt?x=10615b3690
> kernel config: https://syzkaller.appspot.com/x/.config?x=a61d44f28687f508
> dashboard link: https://syzkaller.appspot.com/bug?extid=fbe34b643e462f65e542
> compiler:
On Sun, 26 Jul 2020 12:58:25 +0200, Julia Lawall wrote:
> The various list iterators are able to handle an empty list.
> The only effect of avoiding the loop is not initializing some
> index variables.
> Drop list_empty tests in cases where these variables are not
> used.
>
> The semantic patch th
On Wed, 15 Jul 2020 12:08:50 +0100, Lad Prabhakar wrote:
> This patch series enables support for following on RZ/G2H SoC,
> * CPU OPP
> * THS
> * CMT/TMU
> * I2C/IIC
> * MSIOF
> * RWDT
> * SDHI
> * SCIF/HSCIF
> * CAN/CANFD
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/b
On Fri, Jul 17, 2020 at 01:15:13PM +0100, Lad, Prabhakar wrote:
> On Fri, Jul 17, 2020 at 12:59 PM Mark Brown wrote:
> > On Wed, Jul 15, 2020 at 12:09:04PM +0100, Lad Prabhakar wrote:
> > > Document RZ/G2H (R8A774E1) SoC bindings.
> > Please in future could you split
On Wed, Jul 15, 2020 at 12:09:04PM +0100, Lad Prabhakar wrote:
> Document RZ/G2H (R8A774E1) SoC bindings.
Please in future could you split things like this up into per subsystem
serieses? That's a more normal approach and avoids the huge threads and
CC lists.
signature.asc
Description: PGP sign
On Thu, Jul 02, 2020 at 08:21:40AM -0700, Kees Cook wrote:
> On Wed, Jul 01, 2020 at 09:39:20PM +0100, Mark Brown wrote:
> > Please copy maintainers on patches :(
> Hi! Sorry about that; the CC list was giant, so I had opted for using
> subsystem mailing lists where possible.
If
On Thu, Jul 02, 2020 at 09:11:47AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 02, 2020 at 12:15:22PM +0100, Mark Brown wrote:
> > These are very much physical devices often with distinct IPs in distinct
> > address ranges and so on, it's just that those addresses happen not t
On Wed, Jul 01, 2020 at 08:32:50PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 01, 2020 at 10:50:49AM +0100, Mark Brown wrote:
> > Another part of this is that there's not a clean cut over between MMIO
> > and not using any hardware resources at all - for example a device mi
> simply initialize the variable or make compiler changes. As a precursor
> to removing[2] this[3] macro[4], just remove this variable since it was
> actually unused:
Please copy maintainers on patches :(
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Tue, Jun 30, 2020 at 02:27:10PM -0300, Jason Gunthorpe wrote:
> I wonder if SW_MFD might me more apt though? Based on Mark's remarks
> current MFD is 'hw' MFD where the created platform_devices expect a
> MMIO pass through, while this is a MFD a device-specific SW
> interfacing layer.
Another
On Tue, Jun 30, 2020 at 08:32:45AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> > > > What are we supposed to do with things like PCI attached FPGAs and ASICs
On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> > On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
> > > Ok, that's good to hear. But platform devices should never be showing
>
On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher wrote:
> From: Ranjani Sridharan
>
> A client in the SOF (Sound Open Firmware) context is a
> device that needs to communicate with the DSP via IPC
As please send patches to the maintainers for the code you would like to
change. :(
> +conf
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
> On 5/22/20 9:55 AM, Jason Gunthorpe wrote:
> > Maybe not great, but at least it is consistent with all the lifetime
> > models and the operation of the driver core.
> I agree your comments are valid ones, I just don't have a
On Thu, May 28, 2020 at 12:45:45PM +0200, Greg KH wrote:
> On Wed, May 27, 2020 at 06:40:05PM -0700, Ranjani Sridharan wrote:
> > Is your expectation that with the above changes, we should not be
> > needing the MODULE_ALIAS() in the driver?
> Yes, it should not be needed if you did everything pr
On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
> Ok, that's good to hear. But platform devices should never be showing
> up as a child of a PCI device. In the "near future" when we get the
> virtual bus code merged, we can convert any existing users like this to
> the new code.
What a
On Sat, May 23, 2020 at 08:23:51AM +0200, Greg KH wrote:
> Then fix that problem there. The audio card should not be being created
> as a platform device, as that is not what it is. And even if it was,
> the probe should not complete, it should clean up after itself and error
> out.
To be clear
On Tue, Jun 23, 2020 at 12:49:15PM -0700, Florian Fainelli wrote:
> On 6/22/20 6:51 AM, Mark Brown wrote:
> > If the bus includes power management for the devices on the bus the
> > controller is generally responsible for that rather than the devices,
> > the devices acces
On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote:
> The PHY subsystem cannot be the first to run into this problem, that
> you need a device structure to make use of the regulator API, but you
> need the regulator API to probe the device. How do other subsystems
> work around this?
If
On Tue, 9 Jun 2020 13:45:53 +0100, Kieran Bingham wrote:
> I wouldn't normally go through spelling fixes, but I caught sight of
> this typo twice, and then foolishly grepped the tree for it, and saw how
> pervasive it was.
>
> so here I am ... fixing a typo globally... but with an addition in
> sc
On Mon, Jun 15, 2020 at 01:57:39PM +0200, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > On Mon, Jun 15, 2020 at 08:46:52AM +0200, Mauro Carvalho Chehab wrote:
> > > There are some new broken doc links due to yaml renames
> > > at DT. Developers shoul
On Mon, Jun 15, 2020 at 08:46:52AM +0200, Mauro Carvalho Chehab wrote:
> There are some new broken doc links due to yaml renames
> at DT. Developers should really run:
I also previously acked this one in 20200504100822.ga5...@sirena.org.uk.
Has anything changed here to cause the ack to be dropped?
On Thu, Jun 11, 2020 at 09:19:23AM -0600, Rob Herring wrote:
> The examples template is a 'simple-bus' with a size of 1 cell for
> had between 2 and 4 cells which really only errors on I2C or SPI type
> devices with a single cell.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Mon, Jun 01, 2020 at 11:35:36AM -0700, David Miller wrote:
> > v2 -> v3:
> > - drop unneeded ternary operator
> Series applied to net-next, thank you.
I already applied patch 1 and sent a pull request to Linus for it. As I
said:
| Let me know if you need a pull request for this, given the m
On Mon, Jun 01, 2020 at 01:51:31PM +0200, Alexandre Belloni wrote:
> On 01/06/2020 14:12:38+0300, Vladimir Oltean wrote:
> > In my mind I am not exactly sure what the pull request does to improve
> > the work flow. My simplified idea was that you would send a pull
> > request upstream, then David
gned-off-by: Vladimir Oltean
> Link: https://lore.kernel.org/r/20200527234113.2491988-2-olte...@gmail.com
> Signed-off-by: Mark Brown
Please either just wait till after the merge window or ask for a pull
request like I said when I applied the patch.
signature.asc
Description: PGP signature
On Fri, May 29, 2020 at 08:28:01PM +0300, Vladimir Oltean wrote:
> Thanks a lot for merging this. I plan to resend this series again (on
> the last mile!) during the weekend, with the feedback collected so
> far, so I'm not sure what is the best path to make sure Dave also has
> this patch in his
On Fri, May 29, 2020 at 05:51:52PM +0100, Mark Brown wrote:
> [1/1] regmap: add helper for per-port regfield initialization
> commit: 8baebfc2aca26e3fa67ab28343671b82be42b22c
Let me know if you need a pull request for this, I figured it was too
late to deal with the cross tree issu
On Fri, May 29, 2020 at 05:52:00PM +0100, Mark Brown wrote:
> [1/1] regmap: provide helpers for simple bit operations
> commit: aa2ff9dbaeddabb5ad166db5f9f1a0580a8bbba8
Let me know if you need a pull request for this, given the merge window
is likely to open over the weekend I figure
On Thu, 28 May 2020 17:45:01 +0200, Bartosz Golaszewski wrote:
> I noticed that oftentimes I use regmap_update_bits() for simple bit
> setting or clearing. In this case the fourth argument is superfluous as
> it's always 0 or equal to the mask argument.
>
> This series proposes to add simple bit o
On Thu, 28 May 2020 02:41:02 +0300, Vladimir Oltean wrote:
> Looking at the Felix and Ocelot drivers, Maxim asked if it would be
> possible to use them as a base for a new driver for the switch inside
> NXP T1040. Turns out, it is! The result is a driver eerily similar to
> Felix.
>
> The biggest
On Thu, May 28, 2020 at 04:49:06PM +0200, Bartosz Golaszewski wrote:
> czw., 28 maj 2020 o 16:45 Mark Brown napisał(a):
> > The tenery here is redundant, it's converting a boolean value into a
> > boolean value. Otherwise this looks good.
> Do you mind if I respin it r
On Thu, May 28, 2020 at 04:22:40PM +0200, Bartosz Golaszewski wrote:
> + return (val & bits) == bits ? 1 : 0;
The tenery here is redundant, it's converting a boolean value into a
boolean value. Otherwise this looks good.
signature.asc
Description: PGP signature
On Thu, May 28, 2020 at 03:57:24PM +0200, Bartosz Golaszewski wrote:
> Ok. So I'm seeing there are a lot of macros in regmap.h that could
> become static inlines but given the amount of regmap users: how about
> we do it separately and in the meantime I'll just modify this series
> to use static i
On Thu, May 28, 2020 at 03:32:40PM +0200, Bartosz Golaszewski wrote:
> czw., 28 maj 2020 o 15:29 Mark Brown napisał(a):
> > Why macros and not static inlines?
> The existing regmap_update_bits_*() helpers are macros too, so I tried
> to stay consistent. Any reason why they are
On Thu, May 28, 2020 at 02:34:58PM +0200, Bartosz Golaszewski wrote:
> This adds three new macros for simple bit operations: set_bits,
> clear_bits and test_bits.
Why macros and not static inlines?
signature.asc
Description: PGP signature
On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote:
> There are some new broken doc links due to yaml renames
> at DT. Developers should really run:
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Apr 30, 2020 at 03:23:17PM +0100, Mark Brown wrote:
> [1/2] cxgb4: Add missing annotation for service_ofldq()
> commit: d7f27df50eea54fd00c26c5dda7bc12d2541e5e4
Sorry, I didn't register that this was part of a series when I
downloaded the mailbox - I'll drop th
On Wed, 29 Apr 2020 23:57:21 +0100, Jules Irenge wrote:
> This patchset proposes a solution to functions that regiter context
> imbalance warnin, we add annotations to fix the warnings.
>
> Jules Irenge (2):
> cxgb4: Add missing annotation for service_ofldq()
> spi: atmel: Add missing annotati
On Wed, Apr 29, 2020 at 03:46:04PM +0200, Marek Szyprowski wrote:
> On 22.04.2020 22:32, John Stultz wrote:
> > Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state()
> > logic")
> > Signed-off-by: John Stultz
> Please also revert dca0b44957e5 "regulator: Use
> driver_defer
ements its own queue scheduling).
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20190905010114.26718-3-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 127
include/linux/spi/spi.h | 61 +++
2 files chan
On Tue, Oct 08, 2019 at 03:58:51PM +0300, Vladimir Oltean wrote:
> Dave, do you think you can somehow integrate this patch into net-next
> as well, so that I can send some further patches that depend on the
> newly introduced ptp_sts member of struct spi_transfer without waiting
> for another kern
uld be a contradiction in terms).
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20190905010114.26718-4-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/spi/spi-fsl-dspi.c b/driv
ements its own queue scheduling).
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20190905010114.26718-3-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 127
include/linux/spi/spi.h | 61 +++
y at 600 MHz out of
a max of 1200 MHz.
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20190905010114.26718-5-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-d
On Thu, Sep 05, 2019 at 04:01:10AM +0300, Vladimir Oltean wrote:
> This patchset proposes an interface from the SPI subsystem for
> software timestamping SPI transfers. There is a default implementation
> provided in the core, as well as a mechanism for SPI slave drivers to
> check which byte was
igned-off-by: Mark Brown
---
drivers/spi/spi.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index aef55acb5ccd..b2890923d256 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1265,8 +1265,9 @@ EXPOR
On Sat, Aug 24, 2019 at 03:38:16PM +0300, Vladimir Oltean wrote:
> On Thu, 22 Aug 2019 at 21:19, Mark Brown wrote:
> > On Sun, Aug 18, 2019 at 09:25:57PM +0300, Vladimir Oltean wrote:
> > > + if (!ctlr->ptp_sts_supported) {
> > > + list_for_eac
8-5-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 87 --
1 file changed, 64 insertions(+), 23 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 6d2c7984ab0e..77db43f1290f 100644
--- a/drivers/spi
el.org/r/20190822211514.19288-2-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 79 +++---
1 file changed, 40 insertions(+), 39 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 790cb02fc181..c90db7db4121 1006
printing is dead code and can be removed.
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20190822211514.19288-4-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff -
;spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ")
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20190822211514.19288-3-olte...@gmail.com
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/
On Fri, Aug 23, 2019 at 11:50:44AM +0100, Mark Brown wrote:
> On Fri, Aug 23, 2019 at 01:30:27PM +0300, Vladimir Oltean wrote:
> > Did you see this?
> > https://lkml.org/lkml/2019/8/22/1542
> I'm not online enough to readily follow that link right now, I
> did apply a
On Fri, Aug 23, 2019 at 01:30:27PM +0300, Vladimir Oltean wrote:
> On Fri, 23 Aug 2019 at 13:28, Mark Brown wrote:
> > It would be better to have done this as the first patch before
> > the restructuring, that way we could send this as a fix - the
> > refactoring while go
On Fri, Aug 23, 2019 at 12:15:11AM +0300, Vladimir Oltean wrote:
> The DSPI interrupt can be shared between two controllers at least on the
> LX2160A. In that case, the driver for one controller might misbehave and
> consume the other's interrupt. Fix this by actually checking if any of
> the bits
On Sun, Aug 18, 2019 at 09:25:58PM +0300, Vladimir Oltean wrote:
> On platforms like LS1021A which use TCFQ mode, an interrupt needs to be
> processed after each byte is TXed/RXed. I tried to make the DSPI
> implementation on this SoC operate in other, more efficient modes (EOQ,
> DMA) but it looks
On Sun, Aug 18, 2019 at 09:25:57PM +0300, Vladimir Oltean wrote:
> @@ -1391,6 +1402,13 @@ static void __spi_pump_messages(struct spi_controller
> *ctlr, bool in_kthread)
> goto out;
> }
>
> + if (!ctlr->ptp_sts_supported) {
> + list_for_each_entry(xfer, &mesg
On Tue, Aug 20, 2019 at 10:36:43PM +0300, Vladimir Oltean wrote:
> On Tue, 20 Aug 2019 at 21:21, Mark Brown wrote:
> > On Sun, Aug 18, 2019 at 09:25:56PM +0300, Vladimir Oltean wrote:
> > > /* Extract head of queue */
> > > - ctlr->cur_msg =
> > &g
On Sun, Aug 18, 2019 at 09:25:56PM +0300, Vladimir Oltean wrote:
> /* Extract head of queue */
> - ctlr->cur_msg =
> - list_first_entry(&ctlr->queue, struct spi_message, queue);
> + mesg = list_first_entry(&ctlr->queue, struct spi_message, queue);
> + ctlr->cur_msg =
On Tue, Aug 20, 2019 at 04:48:39PM +0300, Vladimir Oltean wrote:
> On Tue, 20 Aug 2019 at 15:55, Mark Brown wrote:
> > On Fri, Aug 16, 2019 at 05:05:53PM +0300, Vladimir Oltean wrote:
> > > Maybe the SPI master driver should just report what sort of
> > > snapshott
On Fri, Aug 16, 2019 at 05:05:53PM +0300, Vladimir Oltean wrote:
> I'm not sure how to respond to this, because I don't know anything
> about the timing of DMA transfers.
> Maybe snapshotting DMA transfers the same way is not possible (if at
> all). Maybe they are not exactly adequate for this sor
On Fri, Aug 16, 2019 at 03:37:46PM +0300, Vladimir Oltean wrote:
> On Fri, 16 Aug 2019 at 15:21, Mark Brown wrote:
> > This is difficult to review since there's a bunch of largely unrelated
> > changes all munged into one patch. It'd be better to split this up so
>
On Fri, Aug 16, 2019 at 03:35:30PM +0300, Vladimir Oltean wrote:
> On Fri, 16 Aug 2019 at 15:18, Mark Brown wrote:
> > On Fri, Aug 16, 2019 at 03:44:41AM +0300, Vladimir Oltean wrote:
> > > @@ -842,6 +843,9 @@ struct spi_transfer {
> > >
> > >
On Fri, Aug 16, 2019 at 03:44:42AM +0300, Vladimir Oltean wrote:
> This patch addresses some cosmetic issues:
> - Alignment
> - Typos
> - (Non-)use of BIT() and GENMASK() macros
> - Unused definitions
> - Unused includes
> - Abuse of ternary operator in detriment of readability
> - Reduce indentati
On Fri, Aug 16, 2019 at 03:44:41AM +0300, Vladimir Oltean wrote:
> @@ -842,6 +843,9 @@ struct spi_transfer {
>
> u32 effective_speed_hz;
>
> + struct ptp_system_timestamp *ptp_sts;
> + unsigned intptp_sts_word_offset;
> +
You've not documented these fields at all
On Wed, Jul 31, 2019 at 04:07:41AM -0700, kernelci.org bot wrote:
Today's -next fails to build an ARM allmodconfig due to:
> allmodconfig (arm, gcc-8) — FAIL, 1 error, 40 warnings, 0 section mismatches
>
> Errors:
> drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> func
On Tue, Apr 23, 2019 at 07:33:10PM +0200, Heiner Kallweit wrote:
> Except having "switch" in the name this driver is solely a SPI driver
> and it uses no network code at all. And it has no dependency on any
> network driver. Therefore I wouldn't consider it a network driver.
> Else any functionali
On Wed, Jan 02, 2019 at 01:44:40AM +0100, Andreas Färber wrote:
> So, the third invocation of sun6i_transfer_one() calling clk_get_rate()
> hangs at the prepare_lock instead of reference-counting, because it runs
> from a separate kthread, unlike the two previous calls?
If there's any contestatio
On Sun, Dec 30, 2018 at 11:55:46AM +0100, Andreas Färber wrote:
> + linux-spi, LAKML
> Given that observed symptoms were CPU stalls, workqueue hangs and RCU
> problems, requiring a power-cycle to recover, I wonder whether we are
> running into some atomic/locking issue with clk_enable()? Is it val
On Thu, Nov 15, 2018 at 05:00:30PM +, Build bot for Mark Brown wrote:
Today's pending-fixes branch fails to build an arm allmodconfig due to:
> arm-allmodconfig
> ../drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';'
> before '}
On Wed, Oct 10, 2018 at 09:59:29AM +0200, Andreas Färber wrote:
> Am 09.10.18 um 14:52 schrieb Ben Whitten:
> > - return spi_sync_transfer(priv->spi, xfr, 2);
> > + return regmap_raw_write(priv->regmap, reg, val, len);
> ... Which would mean we are lacking a noinc API for write here!
> @Mark
Hi James,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/qedf/qedf.h
between commit:
8673daf4f55bf3b91 ("qedf: Add get_generic_tlv_data handler.")
from the net-next tree and commit:
4b9b7fabb39b3e9d7 ("scsi: qedf: Improve firmware debug dump handling")
from t
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/fib_frontend.c
between commit:
2eabd764cb5512f1338 ("net: ipv4: add missing RTA_TABLE to rtm_ipv4_policy")
from the net tree and commit:
404eb77ea766260c45c ("ipv4: support sport, dport and ip_proto in
RT
1 - 100 of 214 matches
Mail list logo
