Hi Sergej, thank you for testing this !
On Thu, Feb 11, 2021 at 7:18 PM Sergej Bauer wrote:
>
> although whole set of tests might be an overly extensive, but after applying
> patch v2 [1/5]
> tests are:
I am unfamiliar with the test_ber tool. Does this patch improve things?
Hi Bryan,
On Fri, Feb 12, 2021 at 3:45 PM wrote:
>
> According to the document I have, FRAME_LENGTH is only valid when LS bit is
> set, and reserved otherwise.
> Therefore, I'm not sure you can rely on it being zero when LS is not set,
> even if your experiments say it is.
> Future chip revisio
Philipp, Fabio,
I was able to verify that the PREs do indeed overrun their allocated ocram area.
Section 38.5.1 of the iMX6QuadPlus manual indicates the ocram size
required: width(pixels) x 8 lines x 4 bytes. For 2048 pixels max, this
comes to 64K. This is what the PRE driver allocates. So far, s
Bonjour Nicolas,
On Wed, Feb 10, 2021 at 11:11 AM Nicolas Dufresne wrote:
>
> Are you sure you aren't just running out of CMA ? This is the only things that
> comes to mind at the moment, sorry if it's not that useful.
Thanks for the suggestion! No worries, this is such a strange/weird
problem,
Found it!
The i.MX6QuadPlus has two pairs of PREs, which use the extended
section of the iRAM. The Classic does not have any PREs or extended
iRAM:
pre1: pre@21c8000 {
compatible = "fsl,imx6qp-pre";
fsl,iram = <&ocram2>;
};
pre3: pre@21ca000 {
compatible = "fsl,imx6qp-pre";
Hi Jakub and Bryan,
On Wed, Feb 17, 2021 at 4:43 PM wrote:
>
> Just to let you know, my colleague tested the patches 1 and 2 on x86 PC and
> we are satisfied with the result.
> We confirmed some performance improvements.
> We also confirmed PTP is working.
>
> Thanks for your work on this.
>
> T
From: Sven Van Asbroeck
We have observed that under certain repeatable circumstances, the CODA
mem2mem device consistently generates corrupted frames. This happens only
on an i.MX6qp (Plus) - the classic imx6q is not affected.
This happens when the virtual X screen is wider than 0x900 pixels (1
Thank you Bryan. I will prepare a v2 early next week.
Would Microchip be able to donate some time to test v2? My own tests
are certainly not perfect. Various stress tests across architectures
(intel/arm) would help create confidence in the multi-buffer frame
implementation. Perhaps Microchip has v
On Wed, Feb 3, 2021 at 3:14 PM wrote:
>
> We can test on x86 PC. We will just need about a week after you release your
> next version.
>
That's great. If you have any suggestions on how I can improve testing
on my end, feel free to reach out.
Hi Clemens,
On Fri, Jan 29, 2021 at 11:31 AM Clemens Gruber
wrote:
>
> Ok, so you suggest we extend our get_state logic to deal with cases
> like the following:
Kind of. We can't control how other actors (bootloaders etc) program the
chip. As far as I know, there are many, many different registe
From: Sven Van Asbroeck
The first patch of this series boosts the chip's rx performance by up to 3x
on cpus such as ARM. However it introduces a breaking change: the mtu
can no longer be changed while the network interface is up.
To get around this efficiently, the second patch adds d
From: Sven Van Asbroeck
Multi-buffer packets enable us to use rx ring buffers smaller than
the mtu. This will allow us to change the mtu on-the-fly, without
having to stop the network interface in order to re-size the rx
ring buffers.
This is a big change touching a key driver function
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_allocate_skb(): fail 10
allocations in a row in every 100.
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
46eb3c108fe1
To: Bryan Whitehead
To: unglinuxdri
From: Sven Van Asbroeck
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
46eb3c108fe1
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey Denisov
From: Sven Van Asbroeck
Now that we can use rx ring buffers smaller than the mtu,
we allow users to change the mtu on the fly.
Tested as follows:
Tests with debug logging enabled (add #define DEBUG).
1. Set the chip mtu to 1500, generate lots of network traffic.
Stop all network traffic
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_trim_skb(): fail one allocation
in every 100.
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
46eb3c108fe1
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "
From: Sven Van Asbroeck
The buffers in the lan743x driver's receive ring are always 9K,
even when the largest packet that can be received (the mtu) is
much smaller. This performs particularly badly on cpu archs
without dma cache snooping (such as ARM): each received packet
results in a 9K
Hi Clemens,
On Fri, Jan 29, 2021 at 3:37 PM Clemens Gruber
wrote:
>
> Is the driver really responsible for bootloaders that program the chip
> with invalid values?
No, but it's responsible for correcting invalid values. Otherwise the driver
doesn't work.
> The chip comes out of PoR with sane de
Hi Clemens,
On Fri, Jan 29, 2021 at 4:24 PM Sven Van Asbroeck wrote:
>
> LEN_ON = 409, LED_OFF = 1228 and
> LED_ON = 419, LED_OFF = 1238
> produce the same result. you can't see the difference between the two
> when scoping the channel. there are probably more ways to d
On Fri, Jan 29, 2021 at 5:01 PM Jakub Kicinski wrote:
>
> You may need to rebase to see this:
>
> drivers/net/ethernet/microchip/lan743x_main.c:2123:41: warning: restricted
> __le32 degrades to integer
Good catch. The problem goes away with the next commit in the set.
This is probably because I
Hi Andrew, thank you so much for looking at this patch !
On Fri, Jan 29, 2021 at 3:36 PM Andrew Lunn wrote:
>
> So this patch appears to contain two different changes
> 1) You only allocate a receive buffer as big as the MTU plus overheads
> 2) You change the cache operations to operate on the re
Hoi Willem, thanks a lot for reviewing this patch, much appreciated !!
On Fri, Jan 29, 2021 at 5:11 PM Willem de Bruijn
wrote:
>
> > +static struct sk_buff *
> > +lan743x_rx_trim_skb(struct sk_buff *skb, int frame_length)
> > +{
> > + if (skb_linearize(skb)) {
>
> Is this needed? That will
On Fri, Jan 29, 2021 at 6:08 PM Willem de Bruijn
wrote:
>
> Okay. I found it a bit hard to parse how much true code change was
> mixed in with just reindenting existing code. If a lot, then no need
> to split of the code refactor.
Thank you. The code is quite hard to review in patch format.
Proba
Hi Bryan, thank you so much for reviewing, I really appreciate it.
On Sat, Jan 30, 2021 at 5:11 PM wrote:
>
> > /* unmap from dma */
> > + packet_length = RX_DESC_DATA0_FRAME_LENGTH_GET_
> > + (descriptor->data0);
On Sat, Jan 30, 2021 at 5:11 PM wrote:
>
> It appears you moved this packet_length assignment from just below the
> following if block, however you left out the le32_to_cpu.See next comment
PS this merge snafu is removed completely by the next patch in the set.
So this will not prevent you from
On Sun, Jan 31, 2021 at 2:06 AM wrote:
>
> > static int lan743x_rx_process_packet(struct lan743x_rx *rx) {
> It looks like this function no longer processes a packet, but rather only
> processes a single buffer.
> So perhaps it should be renamed to lan743x_rx_process_buffer, so it is not
> mis
Hi Sergej,
On Fri, Feb 5, 2021 at 7:44 AM Sergej Bauer wrote:
>
> Hi Sven
> I can confirm great stability improvement after your patch
> "lan743x: boost performance on cpu archs w/o dma cache snooping".
>
> Test machine is Intel Pentium G4560 3.50GHz
> lan743x with rejected virtual phy 'inside'
On Wed, Aug 12, 2020 at 9:28 AM Enrico Weigelt, metux IT consult
wrote:
>
> But I've still got another problem: how can I use DT along w/ ACPI ?
>
That's a very good question. I focus on arm, so I'm unfamiliar with ACPI.
Hopefully someone with ACPI knowledge can chime in.
Hello Enrico,
On Fri, Aug 7, 2020 at 7:27 AM Enrico Weigelt, metux IT consult
wrote:
>
> In both cases it would be nice to have the actual device configuration
> written as a DT snippet, which just needs to be loaded.
>
I believe you're asking: "how do I associate device tree nodes to
devices on
On Thu, Dec 10, 2020 at 3:54 PM Clemens Gruber
wrote:
>
> After reading your reasoning in this mail and rethinking the whole
> situation, I do no longer have any objections to the more complex
> solution. (Allowing 0% and 100% duty cycle channels with any period)
>
> I first thought it would be to
Hi Heiner,
On Thu, Dec 10, 2020 at 2:32 AM Heiner Kallweit wrote:
>
>
> In addition you could play with sysfs attributes
> /sys/class/net//gro_flush_timeout
> /sys/class/net//napi_defer_hard_irqs
Interesting, I will look into that.
> > @@ -2407,7 +2409,7 @@ static int lan743x_rx_open(struct lan
On Fri, Dec 11, 2020 at 8:18 AM Mark Brown wrote:
>
> Yeah, it'd definitely be easier to read and clearer what people should
> actually do.
I think it would be beneficial if this consisted of two very clearly
separated parts:
1. the actual recommended binding - so people writing new
devicetrees
From: Sven Van Asbroeck
Even if there is more rx data waiting on the chip, the rx napi poll fn
will never run more than once - it will always read a few buffers, then
bail out and re-arm interrupts. Which results in ping-pong between napi
and interrupt.
This defeats the purpose of napi, and is
Hi Uwe,
On Mon, Dec 7, 2020 at 5:00 PM Uwe Kleine-König
wrote:
>
> This is not acceptable, if you have two PWM outputs and a consumer
> modifies one of them the other must change. So if this chip only
> supports a single period length of all channels, the first consumer
> enabling a channel defin
Hi Clemens, see below.
On Mon, Dec 7, 2020 at 2:37 PM Clemens Gruber
wrote:
>
> The switch to the atomic API goes hand in hand with a few fixes to
> previously experienced issues:
> - The duty cycle is no longer lost after disable/enable (previously the
> OFF registers were cleared in disable a
Uwe, Thierry,
On Tue, Dec 8, 2020 at 4:10 AM Uwe Kleine-König
wrote:
>
> If this is already in the old code, this probably warrants a separate
> fix, and yes, I consider this a severe bug. (Consider one channel
> driving a motor and reconfiguring an LED modifies the motor's speed.)
>
I think you
Andrew, Jakub,
On Sat, Dec 5, 2020 at 10:28 AM Sven Van Asbroeck wrote:
>
> From: Sven Van Asbroeck
>
> On the ksz8795, if the devicetree contains a cpu node,
> devicetree parsing fails and the whole driver errors out.
>
> Fix the devicetree parsing code by making it use th
On Tue, Dec 8, 2020 at 11:57 AM Thierry Reding wrote:
>
> Is this really that complicated? I sounds to me like the only thing that
> you need is to have some sort of usage count for the prescaler. Whenever
> you want to use the prescaler you check that usage count. If it is zero,
> then you can ju
ts/sec0
> >
> > And with both sides set to MTU 9000 bytes:
> > Before:
> > [ ID] Interval Transfer Bandwidth Retr
> > [ 4] 0.00-20.00 sec 1.87 GBytes 803 Mbits/sec 27
> > After:
> > [ ID] Interval Transfer Ban
On Tue, Dec 8, 2020 at 2:50 PM Jakub Kicinski wrote:
>
> >
> > +done:
> > /* update RX_TAIL */
> > lan743x_csr_write(adapter, RX_TAIL(rx->channel_number),
> > rx_tail_flags | rx->last_tail);
> > -done:
> > +
>
> I assume this rings the doorbell to let the device
Hi Andrew,
On Tue, Dec 8, 2020 at 5:51 PM Andrew Lunn wrote:
>
> >
> > So I assumed that it's a PCIe dma bandwidth issue, but I could be wrong -
> > I didn't do any PCIe bandwidth measurements.
>
> Sometimes it is actually cache operations which take all the
> time. This needs to invalidate the c
On Tue, Dec 8, 2020 at 6:50 PM Eric Dumazet wrote:
>
> Driver could be called with an arbitrary budget (of 64),
> and if its ring buffer has been depleted, return @budget instead of skb
> counts,
> and not ream the interrupt
>
Aha, so the decision to re-arm the interrupts is made by looking
at w
On Sun, Jan 3, 2021 at 12:04 PM Clemens Gruber
wrote:
>
> I will continue working on this series in the upcoming weeks.
> Feedback on the .get_state issue would be greatly appreciated.
In absence of specifications, I tend to keep things as simple as possible.
On Mon, Dec 28, 2020 at 12:55 PM Tim Harvey wrote:
>
> I'm happy to test your patches for lan743x.
>
That's awesome ! I'll post them early in the new year, so that test + review can
happen in parallel.
Tim, Anders,
On Wed, Dec 23, 2020 at 5:45 PM Tim Harvey wrote:
>
> - 2x RJ45 GbE (IMX8MM FEC and LAN743x)
I noticed that you are users of the LAN743x PCIe ethernet chip.
On non-cache snooping architectures such as ARM, the receive performance of
this chip's driver is about 1/3 of what it shoul
On Thu, Apr 15, 2021 at 3:11 AM Greg Kroah-Hartman
wrote:
>
> I've been talking with the developers here about doing a "real" driver
Would it be beneficial if the device h/w targeted by the "real" Rust
driver has QEMU emulation? Perhaps in addition to physical silicon.
If developers don't need a
On Sun, Apr 11, 2021 at 9:14 PM tiantao (H) wrote:
>
> What about doing it like this?
>
> -static void host_release(struct device *dev, void *res)
> +static void host_release(void *res)
> {
> - struct anybuss_host **dr = res;
> -
> - anybuss_host_common_remove(*dr);
> + anybuss
Hi Julian,
On Wed, Apr 14, 2021 at 8:53 AM Julian Wiedmann wrote:
>
> On a cursory glance, using __netdev_alloc_skb_ip_align() here should
> allow you to get rid of all the RX_HEAD_PADDING gymnastics.
>
> And also avoid the need for setting RX_CFG_B_RX_PAD_2_, as the
> NET_IP_ALIGN part would no
Hi Julian,
On Wed, Apr 14, 2021 at 9:33 AM Julian Wiedmann wrote:
>
> __netdev_alloc_skb_ip_align() already reserves the NET_IP_ALIGN part.
> So when the NIC stores into the dma-mapped skb->data parts, each
> fragment will automatically have the required alignment - even when
> you only care abou
Hello Tian, thank you for the contribution. See below.
On Fri, Apr 9, 2021 at 4:33 AM Tian Tao wrote:
>
> Use devm_add_action_or_reset() instead of devres_alloc() and
> devres_add(), which works the same. This will simplify the
> code. There is no functional changes.
>
> Signed-off-by: Tian Tao
Hi George,
On Fri, Apr 9, 2021 at 10:12 AM George McCollister
wrote:
>
> I'm glad everyone was able to work together to get this fixed properly
> without any figure pointing or mud slinging! Kudos everyone.
Same, this is what the kernel community is supposed to be all about.
And thank you for t
On Tue, Nov 17, 2020 at 1:47 PM Jakub Kicinski wrote:
>
> On Tue, 17 Nov 2020 03:09:56 +0100 Andrew Lunn wrote:
> > Reviewed-by: Andrew Lunn
> Applied, thanks!
Thank you Andrew and Jakub !
Hi Clemens, thank you so much for this contribution.
I no longer have access to this chip, so I cannot test
the changes.
Some friendly/constructive feedback below.
On Wed, Nov 18, 2020 at 12:44 PM Clemens Gruber
wrote:
>
> This switch to the atomic API goes hand in hand with a few fixes to
> pre
On Tue, Dec 8, 2020 at 6:36 PM Florian Fainelli wrote:
>
> dma_sync_single_for_{cpu,device} is what you would need in order to make
> a partial cache line invalidation. You would still need to unmap the
> same address+length pair that was used for the initial mapping otherwise
> the DMA-API debugg
On Wed, Dec 9, 2020 at 4:57 AM H. Nikolaus Schaller wrote:
>
> +
> + device node | cs-gpio | CS pin state active | Note
> + +===+=+=
> + spi-cs-high | - | H |
> + - | -
On Wed, Dec 9, 2020 at 1:16 PM H. Nikolaus Schaller wrote:
>
> This is also what made me wonder if that is really intended because then
> the whole discussion about the cs-gpio-flags and inversion and the fixes
> would not have been needed. The current code and fixes are all about
> not ignoring t
On Wed, Dec 9, 2020 at 3:08 PM H. Nikolaus Schaller wrote:
>
> But I have tested with
>
> > spi->mode |= SPI_MODE_3;
>
> which should keep the mode intact. Right? That did not work either.
>
- make sure ("spi: fix client driver breakages when using GPIO descriptors")
is in your tree
- your pane
From: Sven Van Asbroeck
Even if there is more rx data waiting on the chip, the rx napi poll fn
will never run more than once - it will always read a few buffers, then
bail out and re-arm interrupts. Which results in ping-pong between napi
and interrupt.
This defeats the purpose of napi, and is
On Thu, Nov 19, 2020 at 5:00 AM Clemens Gruber
wrote:
>
> > You appear to mix cached and uncached uses of prescale,
> > is there a need for this? If not, perhaps pick one and use
> > it consistently?
>
> Yes, sticking to the cached value is probably the way to go.
>
I would suggest going one step
On Thu, Nov 19, 2020 at 11:00 AM Clemens Gruber
wrote:
>
> One thing I noticed: The driver currently assumes that it comes out of
> POR in "active" state (comment at end of probe and PM calls).
> However, the SLEEP bit is set by default / after POR.
Very good point, the comment is probably not co
Hi Nikolaus, thank you for reaching out !
On Mon, Nov 30, 2020 at 2:06 PM H. Nikolaus Schaller wrote:
>
> But reverting your patch brings back the display. So it appears as if it does
> not
> fix a breakage, rather breaks a previously working setup.
The patch in question fixes an important brea
And probably also:
@@ -226,8 +226,7 @@ static int spi_gpio_setup(struct spi_device *spi)
if (spi_gpio->cs_gpios) {
cs = spi_gpio->cs_gpios[spi->chip_select];
if (!spi->controller_state && cs)
- status = gpiod_direction_output(cs,
-
Hi Clemens, some cool changes, thank you !! Constructive feedback below.
On Mon, Nov 23, 2020 at 11:36 AM Clemens Gruber
wrote:
>
> Changes since v1:
> - Fixed a logic error
> - Impoved PM runtime handling and fixed !CONFIG_PM
> - Write default prescale reg value if invalid in probe
> - Reuse ful
From: Sven Van Asbroeck
For no apparent reason, this function reads the INT_STS register, and
checks if the software interrupt bit is set. These things have already
been carried out by this function's only caller.
Clean up by removing the redundant code.
Tested-by: Sven Van Asbroeck # la
From: Sven Van Asbroeck
The driver's ISR sends a 'software interrupt' event to the probe()
thread using the following method:
- probe(): write 0 to flag, enable s/w interrupt
- probe(): poll on flag, relax using usleep_range()
- ISR: write 1 to flag
Repla
On Tue, Nov 24, 2020 at 10:19 AM Clemens Gruber
wrote:
>
> Thanks for your review!
My pleasure ! We are fortunate that you take the time & effort to improve
this code.
On Tue, Nov 24, 2020 at 10:29 AM Sven Van Asbroeck wrote:
>
> My pleasure ! We are fortunate that you take the time & effort to improve
> this code.
By "this code" I meant the pca9685 driver in general. Just making sure
there's no possible misinterpretation :)
On Fri, Dec 4, 2020 at 5:11 AM H. Nikolaus Schaller wrote:
>
> Anyways it is debatable if this is a bug at all. It is just a definition.
I respectfully disagree. Prior to the fix, your panel's active-low chip select
needed to be described in the devicetree with 'spi-cs-high'. That sounds
very muc
On Fri, Dec 4, 2020 at 11:52 AM H. Nikolaus Schaller wrote:
>
> >> Anyways it is debatable if this is a bug at all. It is just a definition.
> >
> > I respectfully disagree. Prior to the fix, your panel's active-low chip
> > select
> > needed to be described in the devicetree with 'spi-cs-high'.
Jakub, Andrew,
On Fri, Dec 4, 2020 at 6:24 PM Jakub Kicinski wrote:
>
> All the port counts here are -1 compared to datasheets, so I'm assuming
> the are not supposed to include the host facing port or something?
>
> Can you describe the exact problem you're trying to solve?
>
The ksz8795 driver
From: Sven Van Asbroeck
On the ksz8795, if the devicetree contains a cpu node,
devicetree parsing fails and the whole driver errors out.
Fix the devicetree parsing code by making it use the
correct number of ports.
Fixes: 912aae27c6af ("net: dsa: microchip: really look for phy-mode in
From: Sven Van Asbroeck
Port counts in microchip dsa drivers can be quite confusing:
on the ksz8795, ksz_chip_data->port_cnt excludes the cpu port,
yet on the ksz9477, it includes the cpu port.
Add comments to document this situation explicitly.
Fixes: 912aae27c6af ("net: dsa: m
From: Sven Van Asbroeck
Even if the rx ring is completely full, and there is more rx data
waiting on the chip, the rx napi poll fn will never run more than
once - it will always immediately bail out and re-enable interrupts.
Which results in ping-pong between napi and interrupt.
This defeats
From: Sven Van Asbroeck
To support jumbo frames, each rx ring dma buffer is 9K in size.
But the chip only stores a single frame per dma buffer.
When the chip is working with the default 1500 byte MTU, a 9K
dma buffer goes from chip -> cpu per 1500 byte frame. This means
that to get 1
Hi Clemens, I checked the patch against the datasheet register definitions.
More constructive feedback below.
On Tue, Nov 24, 2020 at 1:10 PM Clemens Gruber
wrote:
>
> The switch to the atomic API goes hand in hand with a few fixes to
> previously experienced issues:
> - The duty cycle is no long
On Tue, Nov 24, 2020 at 1:10 PM Clemens Gruber
wrote:
>
> The PCA9685 supports staggered LED output ON times to minimize current
> surges and reduce EMI.
> When this new option is enabled, the ON times of each channel are
> delayed by channel number x counter range / 16, which avoids asserting
> a
On Wed, Nov 25, 2020 at 3:35 AM Clemens Gruber
wrote:
>
> >
> > The datasheet I found for this chip indicates that every ALL_LED_XXX
> > register
> > is write-only. Those registers cannot be read back from the chip.
> >
> > Datasheet "Rev. 4 - 16 April 2015"
>
> Thanks, good catch! Would you agre
On Wed, Nov 25, 2020 at 12:28 PM Clemens Gruber
wrote:
>
> What's the lesser evil in your opinion, always returning 0 duty and
> disabled for the ALL channel or caching it?
>
I would definitely suggest returning a pwm_state consisting of all zeroes
for the "all led" channel, instead of caching st
On Wed, Nov 25, 2020 at 2:46 PM Sven Van Asbroeck wrote:
>
> Then if you have time && motivation left, enable regmap cache.
In a follow-up patch, after we arrived at a correctly working driver.
On Tue, Nov 24, 2020 at 7:17 PM Jakub Kicinski wrote:
>
> Applied both, thank you!
Thank you Jakub !
Hi Jakub, Sergej,
On Tue, Nov 3, 2020 at 8:41 PM Jakub Kicinski wrote:
>
> On Mon, 2 Nov 2020 01:35:55 +0300 Sergej Bauer wrote:
> > This is the 3rd revision of the patch fix for potential null pointer
> > dereference
> > with lan743x card.
>
> Applied, thanks!
I noticed that this went into ne
On Thu, Dec 17, 2020 at 11:48 AM Clemens Gruber
wrote:
>
> I can initialize the values to 0 of course and check the file for other
> places with missing initializations.
>
> Or would it be better to check the return codes of regmap_read/write in
> such cases? I'm not sure.
I think that checking t
On Thu, Dec 17, 2020 at 12:43 PM Clemens Gruber
wrote:
> >
> > Conclusion: .get_state() will always return "pwm disabled", so why do we
> > bother reading out the h/w?
>
> If there are no plans for the PWM core to call .get_state more often in
> the future, we could just read out the period and re
On Thu, Dec 17, 2020 at 1:07 PM Clemens Gruber
wrote:
>
> As always, great review! Thank you!
>
My pleasure, it's great to help out.
And thanks, you're the one doing all the hard work :)
On Tue, Dec 1, 2020 at 4:04 AM H. Nikolaus Schaller wrote:
>
> Then it should not have been applied to mainline but fully worked out and
> tested.
>
That would be a reasonable expectation of a product. But Linux
isn't a product, it's a hugely complex, shared system, which may
form the basis of y
On Tue, Dec 1, 2020 at 8:36 AM H. Nikolaus Schaller wrote:
>
> Well I only complain because you wrote that you knew that it may
> break something else. So it is known to induces a regression.
We knew that it would fix an important, common problem, but
we also knew that there is always a possibili
Hi Linus,
On Tue, Dec 1, 2020 at 9:20 AM Linus Walleij wrote:
>
> I don't know if much can be done about it other than
> having better programmers than me at the task. Or
> less tired when they write the patch. etc.
I don't think that we have many programmers that are
better than you :)
IMHO th
Nikolaus,
On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller wrote:
>
> Let's work on a fix for the fix now.
I tested spi-gpio on my system, by converting a built-in or hardware spi,
to a spi-gpio. Interestingly, the patch has the opposite effect on my system:
before the patch, spi-gpio did not
Nikolaus,
On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller wrote:
>
> Let's work on a fix for the fix now.
>
Are you quite sure the chip-select of the tpo,td028ttec1 panel
is active-high? A quick google produced a datasheet which
seems to indicate that XCS is active-low?
See page 17 here:
ht
Hi Nikolaus,
On Tue, Dec 1, 2020 at 11:43 AM H. Nikolaus Schaller wrote:
>
> You are right. It is active low.
>
In that case, we have a very simple solution, just remove the spi-cs-high,
and things will work.
In case of SPI CS gpios, the current kernel ignores all
GPIO_ACTIVE_HIGH/LOW
flags, an
Hi Andreas,
On Tue, Dec 1, 2020 at 11:44 AM Andreas Kemnade wrote:
>
> So if that one is really active-low, why did it ever work?!
Because the spi gpio chipselect was broken (inverted), and
766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
fixes it.
Hi Nikolaus,
On Tue, Dec 1, 2020 at 12:13 PM H. Nikolaus Schaller wrote:
> > Am 01.12.2020 um 17:53 schrieb Sven Van Asbroeck :
> > On Tue, Dec 1, 2020 at 11:43 AM H. Nikolaus Schaller
> > wrote:
> >>
> >> You are right. It is active low.
> >>
From: Sven Van Asbroeck
The ksz8795 has five physical ports, but the driver assumes
it has only four. This prevents the driver from working correctly.
Fix by indicating the correct number of physical ports.
Fixes: e66f840c08a23 ("net: dsa: ksz: Add Microchip KSZ8795 DSA driver")
Hi Sergej,
On Fri, Feb 5, 2021 at 10:09 AM Sergej Bauer wrote:
>
> Tests after applying patches [2/6] and [3/6] are:
> $ ifmtu eth7 500
> $ sudo test_ber -l eth7 -c 1000 -n 100 -f500 --no-conf
Thank you! Is there a way for me to run test_ber myself?
Is this a standard, or a bespoke testing t
Hi Christoph,
On Fri, Feb 5, 2021 at 4:31 AM Christoph Hellwig wrote:
>
> This is a pattern we've seen in a few other net driver, so we should
> be ok. It just is rather hairy and needs a good justification, which
> seems to be given here.
Thank you so much for taking the time to look into this
s address in an
> array of pointers to const struct attribute_group, and the only usage of
> can_power_ops is to assign its address to the 'ops' field in the
> regulator_desc struct, which is a pointer to const struct regulator_ops.
>
> Signed-off-by: Rikard Falkeborn
Reviewed-by: Sven Van Asbroeck
Hi Jakub,
On Fri, Dec 11, 2020 at 9:38 AM Sven Van Asbroeck wrote:
>
> From: Sven Van Asbroeck
>
> Even if there is more rx data waiting on the chip, the rx napi poll fn
> will never run more than once - it will always read a few buffers, then
> bail out and re-arm interrupts
From: Sven Van Asbroeck
Even if there is more rx data waiting on the chip, the rx napi poll fn
will never run more than once - it will always read a few buffers, then
bail out and re-arm interrupts. Which results in ping-pong between napi
and interrupt.
This defeats the purpose of napi, and is
Hi Jakub,
On Wed, Dec 16, 2020 at 12:03 PM Jakub Kicinski wrote:
>
> Applied, thanks Sven.
>
> I'll leave it out of our stable submission, and expect Sasha's
> autoselection bot to pick it up. This should give us more time
> for testing before the patch makes its way to stable trees.
> Let's see
Hi Andrew,
On Wed, Dec 9, 2020 at 9:10 AM Andrew Lunn wrote:
>
> 9K is not a nice number, since for each allocation it probably has to
> find 4 contiguous pages. See what the performance difference is with
> 2K, 4K and 8K. If there is a big difference, you might want to special
> case when the MT
101 - 200 of 526 matches
Mail list logo
