drivers: spi: atmel: Only access available chip-select registers #25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Turn the informative message about no vmmc/vqmmc regulator found in debug one. There is no need to indicate that something optional is missing. Moreover, it can bring confusion, people who doesn't know it is optional may consider these messages as warnings or errors. Signed-off-by: Ludovic Desroches <[email protected]>
The eMMC supports double data rate with a 1.8 voltage. Signed-off-by: Ludovic Desroches <[email protected]>
As the SDHCI controller needs the 1.8V line to be always enabled for some eMMC configurations, set the proper "regulator-always-on" property to the board DTS files. Note that the sdhci classical regulator definitions doesn't suit our controller for this 1.8V purpose. Signed-off-by: Nicolas Ferre <[email protected]>
Signed-off-by: Nicolas Ferre <[email protected]>
Set the gclk's parent clock to audio clock. Signed-off-by: Songjun Wu <[email protected]>
Add code to support the mono channel audio. Signed-off-by: Songjun Wu <[email protected]>
Following changes that appeared in lk 4.0.0, the gadget udc driver for some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families) incorrectly deduced full-speed USB link speed even when the hardware had negotiated a high-speed link. The fix is to make sure that the UDPHS Interrupt Enable Register value does not mask the SPEED bit in the Interrupt Status Register. For a mass storage gadget this problem lead to failures when the host had a USB 3 port with the xhci_hcd driver. If the host was a USB 2 port using the ehci_hcd driver then the mass storage gadget worked (but probably at a lower speed than it should have). Signed-off-by: Douglas Gilbert <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Cc: <[email protected]> linux4sam#4.0+ Fixes: 9870d89 ("usb: atmel_usba_udc: Mask status with enabled irqs") Signed-off-by: Felipe Balbi <[email protected]>
Conflicts: drivers/pinctrl/pinctrl-at91-pio4.c
Add CONFIG_CAN_M_CAN=y to enable Bosch M_CAN devices driver. Signed-off-by: Wenyou Yang <[email protected]>
Due to the CAN Message RAM can be shared by multi M_CAN instances, so the base address of the CAN Message RAM for CAN0 and CAN1 are shared at 0x00210000. The default base address of the CAN Message RAM for CAN0 and CAN1 are configured at 0x200000 in CAN Memories Address-based Register. To avoid conflict with SRAM map for pm, change them to 0x2100000 in the AT91Bootstrap. As said in SAMA5D2 datasheet, the CAN clock is recommended to use frequencies of 20, 40 or 80 MHz, and to select the UPLLCK(480 MHz) as source clock. So, the "assigned-clock-rates" property has three options: 20000000, 40000000, and 80000000. The "assigned-clock-parents" property should be referred to utmi fixedly. Signed-off-by: Wenyou Yang <[email protected]>
The sama5d2_defconfig is about to be removed, align the generic one with sama5d2 support Signed-off-by: Nicolas Ferre <[email protected]>
Signed-off-by: Nicolas Ferre <[email protected]>
dma_addr_t may be defined as 32 or 64 bit depending on configuration,
so it cannot be printed using the normal format strings, as
gcc correctly warns:
drivers/dma/at_xdmac.c: In function 'at_xdmac_interleaved_queue_desc':
drivers/dma/at_xdmac.c:922:51: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
This changes the format strings to use the special "%pad" format
string that prints a dma_addr_t, and changes the arguments so we
pass the address by reference as required.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Fix typo in a macro which was not used until now. It explains why there is no error at compilation time. Signed-off-by: Ludovic Desroches <[email protected]> Fixes: e1f7c9e "dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver" Cc: [email protected] # 3.19 and later
When setting the channel configuration register, the perid field is not set to 0 since it is useless for mem2mem transfers. Unfortunately, a device has 0 as perid. It could cause spurious flags status because the controller could mix some events from the two channels. For that reason, use the highest perid value for mem2mem transfers since it doesn't match the perid of other devices. Signed-off-by: Ludovic Desroches <[email protected]>
The code was not in agreement with the comments. Signed-off-by: Ludovic Desroches <[email protected]>
Add runtime PM support and use runtime_force_suspend|resume() for system PM. Signed-off-by: Ludovic Desroches <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
atmel-mci-regs.h is only included in atmel-mci.c so move its content in the driver and do some cleanup in these definitions to remove checkpatch errors. Signed-off-by: Ludovic Desroches <[email protected]>
Remove atmel-mci-regs.h file since it has been merged in atmel-mci.c. Signed-off-by: Ludovic Desroches <[email protected]>
The atmci_convert_chksize() function is no more valid for controller version 0x600 due to the introduction of '2 data' chunk size. Signed-off-by: Ludovic Desroches <[email protected]>
This reverts commit 9072c49.
This option can be handy for connecting an USB mouse of keyboard. Signed-off-by: Nicolas Ferre <[email protected]>
This SoC is now handled normally by the generic sama5_defconfig, no need to keep a special defconfig. Signed-off-by: Nicolas Ferre <[email protected]>
…nux-4.1-at91 Conflicts: arch/arm/boot/dts/at91-sama5d2_xplained_common.dtsi
This patch prevents the driver from crashing when more than 4 SPI slaves are configured with the cs-gpios DT option.
noglitch
requested changes
Sep 20, 2016
|
|
||
| #define AUTOSUSPEND_TIMEOUT 2000 | ||
|
|
||
| #define SPI_NUM_CSR 4 |
Member
There was a problem hiding this comment.
There is no limit to the number of cs-gpio we can use. So why use this limit?
| if (!atmel_spi_is_v2(as)) | ||
| spi_writel(as, CSR0 + 4 * spi->chip_select, csr); | ||
| spi_writel(as, CSR0 + 4 * spi_chip_select_capped, csr); | ||
|
|
Member
There was a problem hiding this comment.
I do feel that there is a pending issue here. It may be related to the use of internal CS selection. But it's not related to cs-gpio... So we have to find another way to prevent this crash.
There was a problem hiding this comment.
Currently the driver effectively only uses one CSR at a time, therefore we could always use CSR0 instead of selecting the CSR register depending on spi->chip_select.
There was a problem hiding this comment.
According to the bug documented in the comment above "cs_activate", maybe it is better to always use CSR1?
noglitch
pushed a commit
that referenced
this pull request
Mar 23, 2017
[ Upstream commit 45caeaa ] As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)↩ 225 {↩ 226 ▹ const struct inet_connection_sock *icsk = inet_csk(sk);↩ 227 ▹ const struct dst_entry *dst = __sk_dst_get(sk);↩ 228 ↩ 229 ▹ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩ 230 ▹ ▹ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩ 231 }↩ But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <[email protected]> Cc: Hannes Sowa <[email protected]> Signed-off-by: Jon Maxwell <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
noglitch
pushed a commit
that referenced
this pull request
Mar 27, 2017
[ Upstream commit 45caeaa ] As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)↩ 225 {↩ 226 ▹ const struct inet_connection_sock *icsk = inet_csk(sk);↩ 227 ▹ const struct dst_entry *dst = __sk_dst_get(sk);↩ 228 ↩ 229 ▹ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩ 230 ▹ ▹ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩ 231 }↩ But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <[email protected]> Cc: Hannes Sowa <[email protected]> Signed-off-by: Jon Maxwell <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
It is now fixed in mainline with the following series: |
|
I will close this as the patch was accepted in upstream long time ago. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch prevents the driver from crashing when more than 4
SPI slaves are configured with the cs-gpios DT option.
Without this patch, if a 5th SPI slave is configured, "spi_writel(as, CSR0 + 4 * spi_chip_select_capped, asd->csr);" will unintendedly overwrite a register that is not a CSR register and the driver crashes.