Re: NFS Caching broken in 4.19.37
On 26.02.2021 16:40, Anton Ivanov wrote: These are two different clients, then what you see is possible on NFS with client side caching. If you have multiple clients reading/writing to the same files you usually need to tune the caching options and/or use locking. I suspect that if you leave it for a while (until the cache expires) it will sort itself out. Yes, letting the client sit for just a few minutes (without interacting with file or directory in question) gets it back in sync with the server. In my test-case it is just one client, it missed a file deletion and nothing short of an unmount and remount fixes that. I have waited for 30 mins+. It does not seem to refresh or expire. I also see the opposite behavior - the bug shows up on 4.x up to at least 5.4. I do not see it on 5.10. Yeah, that's indeed different, though still looks somewhat similar. Makes me wonder if what fixed that issue is what's causing mine. The primarily broken use case here is users starting their SLURM jobs, and then observing them via "tail -f slurm.out", which has worked perfectly fine in the past, prior to the update from 5.4 to 5.10. smime.p7s Description: S/MIME Cryptographic Signature
Re: NFS Caching broken in 4.19.37
I think I can reproduce this, or something that at least looks very similar to this, on 5.10. Namely on 5.10.17 (On both Client and Server). We are running slurm, and since a while now (coincides with updating from 5.4 to 5.10, but a whole bunch of other stuff was updated at the same time, so it took me a while to correlate this) the logs it writes have been truncated, but only while they're being observed on the client, using tail -f or something like that. Looks like this then: On Server: store01 /srv/export/home/users/timo/TestRun # ls -l slurm-41101.out -rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out store01 /srv/export/home/users/timo/TestRun # wc -l slurm-41101.out 61 slurm-41101.out On Client: timo@login01 ~/TestRun $ ls -l slurm-41101.out -rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out timo@login01 ~/TestRun $ wc -l slurm-41101.out 24 slurm-41101.out See https://gist.github.com/BtbN/b9eb4fc08ccc53bb20087bce0bf9f826 for the respective file-contents. If I run the same test job, wait until its done, and then look at its slurm.out file, it matches between NFS Client and Server. If I tail -f the slurm.out on an NFS client, the file stops getting updated on the client, but keeps getting more logs written to it on the NFS server. The slurm.out file is being written to by another NFS client, which is running on one of the compute nodes of the system. It's being reads from a login node. Timo On 21.02.2021 16:53, Anton Ivanov wrote: Client side. This seems to be an entirely client side issue. A variety of kernels on the clients starting from 4.9 and up to 5.10 using 4.19 servers. I have observed it on a 4.9 client versus 4.9 server earlier. 4.9 fails, 4.19 fails, 5.2 fails, 5.4 fails, 5.10 works. At present the server is at 4.19.67 in all tests. Linux jain 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux I can set-up a couple of alternative servers during the week, but so far everything is pointing towards a client fs cache issue, not a server one. Brgds, smime.p7s Description: S/MIME Cryptographic Signature
[PATCH] platform/x86: acer-wmi: add automatic keyboard background light toggle key as KEY_LIGHTS_TOGGLE
Got a dmesg message on my AMD Renoir based Acer laptop:
"acer_wmi: Unknown key number - 0x84" when toggling keyboard
background light
Signed-off-by: Timo Witte
---
drivers/platform/x86/acer-wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 60c18f21588d..87797f785d6a 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -111,6 +111,7 @@ static const struct key_entry acer_wmi_keymap[] __initconst
= {
{KE_KEY, 0x64, {KEY_SWITCHVIDEOMODE} }, /* Display Switch */
{KE_IGNORE, 0x81, {KEY_SLEEP} },
{KE_KEY, 0x82, {KEY_TOUCHPAD_TOGGLE} }, /* Touch Pad Toggle */
+ {KE_IGNORE, 0x84, {KEY_LIGHTS_TOGGLE} }, /* Automatic Keyboard
background light toggle */
{KE_KEY, KEY_TOUCHPAD_ON, {KEY_TOUCHPAD_ON} },
{KE_KEY, KEY_TOUCHPAD_OFF, {KEY_TOUCHPAD_OFF} },
{KE_IGNORE, 0x83, {KEY_TOUCHPAD_TOGGLE} },
--
2.27.0
[PATCH] perf core: apply calculated padding to PERF_SAMPLE_RAW output
Zero the amount of padding bytes determined in perf_prepare_sample().
This prevents garbage being read from the ring buffer after it has wrapped
the page boundary at least once.
Signed-off-by: Timo Beckers
---
kernel/events/core.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 80cf996a7f19..d4e0b003ece0 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6807,8 +6807,16 @@ void perf_output_sample(struct perf_output_handle
*handle,
break;
frag = frag->next;
} while (1);
- if (frag->pad)
- __output_skip(handle, NULL, frag->pad);
+ /*
+* The padding value is determined in
+* perf_prepare_sample() and is not
+* expected to exceed u64.
+*/
+ if (frag->pad) {
+ u64 zero = 0;
+
+ __output_copy(handle, &zero, frag->pad);
+ }
} else {
struct {
u32 size;
--
2.26.2
Re: [ALSA patch] [PATCH] ALSA: pcm: Enable MMAP status and control for ARMv7 and ARMv8
Hello all, it would be great if someone from Renesas or someone else could acknowledge the patch. I think it is a good improvement especially when using ALSA plugins like dmix. Feel free to forward if you know someone who is aware of the cache coherency of ARM architectures. Best regards *Timo Wischer* Engineering Software Multimedia (ADITG/ESM) Tel. +49 5121 49 6938 On 4/17/19 11:40 AM, Takashi Iwai wrote: On Wed, 17 Apr 2019 11:30:10 +0200, Timo Wischer wrote: On 4/17/19 11:21, Takashi Iwai wrote: On Wed, 17 Apr 2019 10:46:11 +0200, wrote: From: Timo Wischer Since ARMv7 hardware cache coherence is supported. "The SCU maintains coherency between the individual data caches in the Cortex-A5 MPCore processor using a variation of the MOESI protocol" [1]. Therefore this patch enables the MMAP access to the status and control structures. This avoids HWSYYNC ioctl calls and therefore lowers the CPU usage. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0434c/ BABJECBF.html Interesting... I thought it would never work properly on ARM. If it really works like that, I'd happily apply the change. But I'd like to hear a confirmation from ARM people before merging such an intensive change. Hi Takashi, do I need to send this patch to any other mailing list or do you think some corresponding guy is already on the lists I have used? Well, maybe we need to ping ARM people if no one on the lists you Cc'ed give comments. Let's see. Takashi thanks, Takashi Signed-off-by: Timo Wischer --- sound/core/pcm_native.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 1d84529..b8019ef 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3225,7 +3225,8 @@ static __poll_t snd_pcm_poll(struct file *file, poll_table *wait) * Only on coherent architectures, we can mmap the status and the control records * for effcient data transfer. On others, we have to use HWSYNC ioctl... */ -#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) +#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) || \ + (defined(CONFIG_ARM) && defined(CONFIG_CPU_V7)) || defined(CONFIG_ARM64) /* * mmap status record */ -- 2.7.4 ___ Patch mailing list pa...@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/patch
Re: [ALSA patch] [PATCH] ALSA: pcm: Enable MMAP status and control for ARMv7 and ARMv8
On 4/17/19 11:21, Takashi Iwai wrote: On Wed, 17 Apr 2019 10:46:11 +0200, wrote: From: Timo Wischer Since ARMv7 hardware cache coherence is supported. "The SCU maintains coherency between the individual data caches in the Cortex-A5 MPCore processor using a variation of the MOESI protocol" [1]. Therefore this patch enables the MMAP access to the status and control structures. This avoids HWSYYNC ioctl calls and therefore lowers the CPU usage. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0434c/ BABJECBF.html Interesting... I thought it would never work properly on ARM. If it really works like that, I'd happily apply the change. But I'd like to hear a confirmation from ARM people before merging such an intensive change. Hi Takashi, do I need to send this patch to any other mailing list or do you think some corresponding guy is already on the lists I have used? thanks, Takashi Signed-off-by: Timo Wischer --- sound/core/pcm_native.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 1d84529..b8019ef 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3225,7 +3225,8 @@ static __poll_t snd_pcm_poll(struct file *file, poll_table *wait) * Only on coherent architectures, we can mmap the status and the control records * for effcient data transfer. On others, we have to use HWSYNC ioctl... */ -#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) +#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) || \ + (defined(CONFIG_ARM) && defined(CONFIG_CPU_V7)) || defined(CONFIG_ARM64) /* * mmap status record */ -- 2.7.4 ___ Patch mailing list pa...@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/patch
Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()
On 3/27/19 10:38, Takashi Iwai wrote: On Wed, 27 Mar 2019 10:26:56 +0100, Timo Wischer wrote: On 3/27/19 10:11, Takashi Iwai wrote: On Wed, 27 Mar 2019 09:34:40 +0100, Timo Wischer wrote: On 3/26/19 17:00, Takashi Iwai wrote: On Tue, 26 Mar 2019 16:16:54 +0100, Timo Wischer wrote: On 3/26/19 15:23, Takashi Iwai wrote: On Tue, 26 Mar 2019 12:25:37 +0100, Timo Wischer wrote: On 3/26/19 09:35, Takashi Iwai wrote: On Tue, 26 Mar 2019 08:49:33 +0100, wrote: From: Timo Wischer snd_pcm_link() can be called by the user as long as the device is not yet started. Therefore currently a driver which wants to iterate over the linked substreams has to do this at the start trigger. But the start trigger should not block for a long time. Therefore there is no callback which can be used to iterate over the linked substreams without delaying the start trigger. This patch introduces a new callback function which will be called after the linked substream list was updated by snd_pcm_link(). This callback function is allowed to block for a longer time without interfering the synchronized start up of linked substreams. Signed-off-by: Timo Wischer Well, the idea appears interesting, but I'm afraid that the implementation is still racy. The place you're calling the new callback isn't protected, hence the stream can be triggered while calling it. That is, even during operating your loopback link_changed callback, another thread is able to start the stream. Hi Takashi, As far as I got you mean the following scenario: * snd_pcm_link() is called for a HW sound card + loopback_snd_timer_link_changed() The start may happen at this point. In this case the last link status will be used and aloop will print a warning "Another sound timer was requested but at least one device is already running...". Without this patch set a similar issue already exists. When calling snd_pcm_start() before snd_pcm_link() was done the additional device linked by the snd_pcm_link() will not be started. Therefore the application has already to take care about the order of the calls. Yes, but it doesn't matter for now, just because other drivers do care the PCM links only for trigger callback. Now you're trying to add something new but in an incomplete manner. + loopback_snd_timer_open() + spin_lock_irqsave(&dpcm->cable->lock, flags); * snd_pcm_start() called for aloop sound card + loopback_trigger() + spin_lock(&cable->lock) -> has to wait till loopback_snd_timer_open() calls spin_unlock_irqrestore() So far snd_pcm_start() has to wait for loopback_snd_timer_open(). * loopback_snd_timer_open() will continue with + dpcm->cable->snd_timer.instance = NULL; + spin_unlock_irqrestore() * loopback_trigger() can enter the lock + loopback_snd_timer_start() will fail with -EINVAL due to (loopback_trigger == NULL) At least this will not result into memory corruption due to race or any other wired behavior. I don't expect the memory corruption, but my point is that dealing with linked streams is still tricky. It was considered for the lightweight coupled start/stop operation, and something intensively depending on the linked status was out of the original design... But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw) is only called by the application calling snd_pcm_start(aloop) because the same aloop device cannot be opened by multiple applications at the same time. Do you see an use case where one application would call snd_pcm_start() in parallel with snd_pcm_link() (somehow configuring the device)? It's not about the actual application usages but rather against the malicious attacks. Especially aloop is a virtual device that is available allover the places, it may be deployed / attacked easily. The attack we are identifying here can only be done by the application opening the aloop device. An application allowed to open the aloop device is anyway able to manipulate the audio streaming. Right, and if it such a racy access may lead to a driver misbehavior, it's a big concern. The proposed callback usage is racy, so some other implementation might be broken easily in future. Or do you see an attack which would influence any other device/stream not opened by this application? May be we should add an additional synchronization mechanism in pcm_native.c to avoid call of snd_pcm_link() in parallel with snd_pcm_start(). If it really matters... Honestly speaking, I'm not fully convinced whether we want to deal with this using the PCM link mechanism. What&#x
Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()
On 3/27/19 10:11, Takashi Iwai wrote: On Wed, 27 Mar 2019 09:34:40 +0100, Timo Wischer wrote: On 3/26/19 17:00, Takashi Iwai wrote: On Tue, 26 Mar 2019 16:16:54 +0100, Timo Wischer wrote: On 3/26/19 15:23, Takashi Iwai wrote: On Tue, 26 Mar 2019 12:25:37 +0100, Timo Wischer wrote: On 3/26/19 09:35, Takashi Iwai wrote: On Tue, 26 Mar 2019 08:49:33 +0100, wrote: From: Timo Wischer snd_pcm_link() can be called by the user as long as the device is not yet started. Therefore currently a driver which wants to iterate over the linked substreams has to do this at the start trigger. But the start trigger should not block for a long time. Therefore there is no callback which can be used to iterate over the linked substreams without delaying the start trigger. This patch introduces a new callback function which will be called after the linked substream list was updated by snd_pcm_link(). This callback function is allowed to block for a longer time without interfering the synchronized start up of linked substreams. Signed-off-by: Timo Wischer Well, the idea appears interesting, but I'm afraid that the implementation is still racy. The place you're calling the new callback isn't protected, hence the stream can be triggered while calling it. That is, even during operating your loopback link_changed callback, another thread is able to start the stream. Hi Takashi, As far as I got you mean the following scenario: * snd_pcm_link() is called for a HW sound card + loopback_snd_timer_link_changed() The start may happen at this point. In this case the last link status will be used and aloop will print a warning "Another sound timer was requested but at least one device is already running...". Without this patch set a similar issue already exists. When calling snd_pcm_start() before snd_pcm_link() was done the additional device linked by the snd_pcm_link() will not be started. Therefore the application has already to take care about the order of the calls. Yes, but it doesn't matter for now, just because other drivers do care the PCM links only for trigger callback. Now you're trying to add something new but in an incomplete manner. + loopback_snd_timer_open() + spin_lock_irqsave(&dpcm->cable->lock, flags); * snd_pcm_start() called for aloop sound card + loopback_trigger() + spin_lock(&cable->lock) -> has to wait till loopback_snd_timer_open() calls spin_unlock_irqrestore() So far snd_pcm_start() has to wait for loopback_snd_timer_open(). * loopback_snd_timer_open() will continue with + dpcm->cable->snd_timer.instance = NULL; + spin_unlock_irqrestore() * loopback_trigger() can enter the lock + loopback_snd_timer_start() will fail with -EINVAL due to (loopback_trigger == NULL) At least this will not result into memory corruption due to race or any other wired behavior. I don't expect the memory corruption, but my point is that dealing with linked streams is still tricky. It was considered for the lightweight coupled start/stop operation, and something intensively depending on the linked status was out of the original design... But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw) is only called by the application calling snd_pcm_start(aloop) because the same aloop device cannot be opened by multiple applications at the same time. Do you see an use case where one application would call snd_pcm_start() in parallel with snd_pcm_link() (somehow configuring the device)? It's not about the actual application usages but rather against the malicious attacks. Especially aloop is a virtual device that is available allover the places, it may be deployed / attacked easily. The attack we are identifying here can only be done by the application opening the aloop device. An application allowed to open the aloop device is anyway able to manipulate the audio streaming. Right, and if it such a racy access may lead to a driver misbehavior, it's a big concern. The proposed callback usage is racy, so some other implementation might be broken easily in future. Or do you see an attack which would influence any other device/stream not opened by this application? May be we should add an additional synchronization mechanism in pcm_native.c to avoid call of snd_pcm_link() in parallel with snd_pcm_start(). If it really matters... Honestly speaking, I'm not fully convinced whether we want to deal with this using the PCM link mechanism. What's the motivation for using the linked streams at the first place? That's one of the biggest missing piece in the whole picture.
Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()
On 3/26/19 17:00, Takashi Iwai wrote: On Tue, 26 Mar 2019 16:16:54 +0100, Timo Wischer wrote: On 3/26/19 15:23, Takashi Iwai wrote: On Tue, 26 Mar 2019 12:25:37 +0100, Timo Wischer wrote: On 3/26/19 09:35, Takashi Iwai wrote: On Tue, 26 Mar 2019 08:49:33 +0100, wrote: From: Timo Wischer snd_pcm_link() can be called by the user as long as the device is not yet started. Therefore currently a driver which wants to iterate over the linked substreams has to do this at the start trigger. But the start trigger should not block for a long time. Therefore there is no callback which can be used to iterate over the linked substreams without delaying the start trigger. This patch introduces a new callback function which will be called after the linked substream list was updated by snd_pcm_link(). This callback function is allowed to block for a longer time without interfering the synchronized start up of linked substreams. Signed-off-by: Timo Wischer Well, the idea appears interesting, but I'm afraid that the implementation is still racy. The place you're calling the new callback isn't protected, hence the stream can be triggered while calling it. That is, even during operating your loopback link_changed callback, another thread is able to start the stream. Hi Takashi, As far as I got you mean the following scenario: * snd_pcm_link() is called for a HW sound card + loopback_snd_timer_link_changed() The start may happen at this point. In this case the last link status will be used and aloop will print a warning "Another sound timer was requested but at least one device is already running...". Without this patch set a similar issue already exists. When calling snd_pcm_start() before snd_pcm_link() was done the additional device linked by the snd_pcm_link() will not be started. Therefore the application has already to take care about the order of the calls. Yes, but it doesn't matter for now, just because other drivers do care the PCM links only for trigger callback. Now you're trying to add something new but in an incomplete manner. + loopback_snd_timer_open() + spin_lock_irqsave(&dpcm->cable->lock, flags); * snd_pcm_start() called for aloop sound card + loopback_trigger() + spin_lock(&cable->lock) -> has to wait till loopback_snd_timer_open() calls spin_unlock_irqrestore() So far snd_pcm_start() has to wait for loopback_snd_timer_open(). * loopback_snd_timer_open() will continue with + dpcm->cable->snd_timer.instance = NULL; + spin_unlock_irqrestore() * loopback_trigger() can enter the lock + loopback_snd_timer_start() will fail with -EINVAL due to (loopback_trigger == NULL) At least this will not result into memory corruption due to race or any other wired behavior. I don't expect the memory corruption, but my point is that dealing with linked streams is still tricky. It was considered for the lightweight coupled start/stop operation, and something intensively depending on the linked status was out of the original design... But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw) is only called by the application calling snd_pcm_start(aloop) because the same aloop device cannot be opened by multiple applications at the same time. Do you see an use case where one application would call snd_pcm_start() in parallel with snd_pcm_link() (somehow configuring the device)? It's not about the actual application usages but rather against the malicious attacks. Especially aloop is a virtual device that is available allover the places, it may be deployed / attacked easily. The attack we are identifying here can only be done by the application opening the aloop device. An application allowed to open the aloop device is anyway able to manipulate the audio streaming. Right, and if it such a racy access may lead to a driver misbehavior, it's a big concern. The proposed callback usage is racy, so some other implementation might be broken easily in future. Or do you see an attack which would influence any other device/stream not opened by this application? May be we should add an additional synchronization mechanism in pcm_native.c to avoid call of snd_pcm_link() in parallel with snd_pcm_start(). If it really matters... Honestly speaking, I'm not fully convinced whether we want to deal with this using the PCM link mechanism. What's the motivation for using the linked streams at the first place? That's one of the biggest missing piece in the whole picture. In general when the user uses snd_pcm_link() it expects that the linked devices are somehow synchronized. Any applications already
Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()
On 3/26/19 15:23, Takashi Iwai wrote: On Tue, 26 Mar 2019 12:25:37 +0100, Timo Wischer wrote: On 3/26/19 09:35, Takashi Iwai wrote: On Tue, 26 Mar 2019 08:49:33 +0100, wrote: From: Timo Wischer snd_pcm_link() can be called by the user as long as the device is not yet started. Therefore currently a driver which wants to iterate over the linked substreams has to do this at the start trigger. But the start trigger should not block for a long time. Therefore there is no callback which can be used to iterate over the linked substreams without delaying the start trigger. This patch introduces a new callback function which will be called after the linked substream list was updated by snd_pcm_link(). This callback function is allowed to block for a longer time without interfering the synchronized start up of linked substreams. Signed-off-by: Timo Wischer Well, the idea appears interesting, but I'm afraid that the implementation is still racy. The place you're calling the new callback isn't protected, hence the stream can be triggered while calling it. That is, even during operating your loopback link_changed callback, another thread is able to start the stream. Hi Takashi, As far as I got you mean the following scenario: * snd_pcm_link() is called for a HW sound card + loopback_snd_timer_link_changed() The start may happen at this point. In this case the last link status will be used and aloop will print a warning "Another sound timer was requested but at least one device is already running...". Without this patch set a similar issue already exists. When calling snd_pcm_start() before snd_pcm_link() was done the additional device linked by the snd_pcm_link() will not be started. Therefore the application has already to take care about the order of the calls. + loopback_snd_timer_open() + spin_lock_irqsave(&dpcm->cable->lock, flags); * snd_pcm_start() called for aloop sound card + loopback_trigger() + spin_lock(&cable->lock) -> has to wait till loopback_snd_timer_open() calls spin_unlock_irqrestore() So far snd_pcm_start() has to wait for loopback_snd_timer_open(). * loopback_snd_timer_open() will continue with + dpcm->cable->snd_timer.instance = NULL; + spin_unlock_irqrestore() * loopback_trigger() can enter the lock + loopback_snd_timer_start() will fail with -EINVAL due to (loopback_trigger == NULL) At least this will not result into memory corruption due to race or any other wired behavior. I don't expect the memory corruption, but my point is that dealing with linked streams is still tricky. It was considered for the lightweight coupled start/stop operation, and something intensively depending on the linked status was out of the original design... But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw) is only called by the application calling snd_pcm_start(aloop) because the same aloop device cannot be opened by multiple applications at the same time. Do you see an use case where one application would call snd_pcm_start() in parallel with snd_pcm_link() (somehow configuring the device)? It's not about the actual application usages but rather against the malicious attacks. Especially aloop is a virtual device that is available allover the places, it may be deployed / attacked easily. The attack we are identifying here can only be done by the application opening the aloop device. An application allowed to open the aloop device is anyway able to manipulate the audio streaming. Or do you see an attack which would influence any other device/stream not opened by this application? May be we should add an additional synchronization mechanism in pcm_native.c to avoid call of snd_pcm_link() in parallel with snd_pcm_start(). If it really matters... Honestly speaking, I'm not fully convinced whether we want to deal with this using the PCM link mechanism. What's the motivation for using the linked streams at the first place? That's one of the biggest missing piece in the whole picture. In general when the user uses snd_pcm_link() it expects that the linked devices are somehow synchronized. Any applications already using snd_pcm_link() do not need to be adapted to use the new feature of aloop (for example JACK or ALSA multi plugin) But when linking a HW sound card and aloop without this patch set, both devices will be started in sync but the snd_pcm_period_eleapsed() calls of the different devices will drift. To avoid this the aloop plugin can automatically use the right timer. If this feature is not implemented the user has to use snd_pcm_link() to trigger snd_pcm_start() in sync but also has to confi
Re: [PATCH 04/10] ALSA: aloop: Use always spin_lock_irqsave() for cable->lock
On 3/25/19 17:58, Takashi Iwai wrote:
On Mon, 25 Mar 2019 17:40:23 +0100,
Timo Wischer wrote:
Best regards
Timo Wischer
Engineering Software Base (ADITG/ESB)
Tel. +49 5121 49 6938
On 3/25/19 17:07, Takashi Iwai wrote:
On Mon, 25 Mar 2019 17:00:38 +0100,
wrote:
From: Timo Wischer
to allow the usage of timer callbacks from interrupt context.
For example the sound timer.
The trigger callback is already irq-disabled. And, open/close must
not be irq-disabled OTOH. So these changes must be superfluous.
Hello Takashi,
could you explain why open/close must not be irq-disabled?
The open/close callbacks get called always in sleepable context where
you can use mutex & co gracefully. The only non-sleepable (atomic)
context is pointer and trigger callbacks. So it's safe to use
spin_lock() without irq in these callbacks.
OTOH, the rest (open, close,hw_params, hw_free, prepare) callbacks are
always sleepable, hence it's safe to use spin_lock_irq() (not
save/restore) variant.
When a driver declares as non-atomic via PCM flag, all callbacks
become sleepable, but this isn't the case for aloop driver.
I see a potential deadlock in case of free_cable() uses only spin_lock()
instead of spin_lock_irqsave().
For example the following will be executed:
loopback_close()
free_cable()
spin_lock(&dpcm->cable->lock)
Which spin_lock() call? The free_cable() calls spin_lock_irq().
Interrupted by jiffies timer IRQ before calling spin_unlock()
loopback_jiffies_timer_function()
spin_lock_irqsave(&dpcm->cable->lock)
DEADLOCK due to dpcm->cable->lock is already locked
Do you also see this deadlock or do you see any reason why this could not
happen?
If spin_lock_irq() is used in free_cable(), it must be OK.
Takashi
Thanks for the detailed explanation.
@all:
Please simple ignore this patch.
Best regards
Timo
Best regards
Timo
thanks,
Takashi
Signed-off-by: Timo Wischer
---
sound/drivers/aloop.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c
index 11e8ed6..c6217c4 100644
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -272,6 +272,7 @@ static int loopback_trigger(struct
snd_pcm_substream *substream, int cmd)
struct loopback_pcm *dpcm = runtime->private_data;
struct loopback_cable *cable = dpcm->cable;
int err = 0, stream = 1 << substream->stream;
+ unsigned long flags;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -281,39 +282,39 @@ static int loopback_trigger(struct
snd_pcm_substream *substream, int cmd)
dpcm->last_jiffies = jiffies;
dpcm->pcm_rate_shift = 0;
dpcm->last_drift = 0;
- spin_lock(&cable->lock);
+ spin_lock_irqsave(&cable->lock, flags);
cable->running |= stream;
cable->pause &= ~stream;
err = loopback_timer_start(dpcm);
- spin_unlock(&cable->lock);
+ spin_unlock_irqrestore(&cable->lock,
flags);
if (substream->stream ==
SNDRV_PCM_STREAM_PLAYBACK)
loopback_active_notify(dpcm);
break;
case SNDRV_PCM_TRIGGER_STOP:
- spin_lock(&cable->lock);
+ spin_lock_irqsave(&cable->lock, flags);
cable->running &= ~stream;
cable->pause &= ~stream;
err = loopback_timer_stop(dpcm);
- spin_unlock(&cable->lock);
+ spin_unlock_irqrestore(&cable->lock,
flags);
if (substream->stream ==
SNDRV_PCM_STREAM_PLAYBACK)
loopback_active_notify(dpcm);
break;
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
case SNDRV_PCM_TRIGGER_SUSPEND:
- spin_lock(&cable->lock);
+ spin_lock_irqsave(&cable->lock, flags);
Re: [RFC PATCH v2 6/7] i2c: tegra-bpmp: convert to use new atomic callbacks
On 2.3.2019 15.47, Wolfram Sang wrote:
The driver did handle this internally, convert it to use the new
callbacks.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-tegra-bpmp.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra-bpmp.c
b/drivers/i2c/busses/i2c-tegra-bpmp.c
index f6cd35d0a2ac..02b78ba5b23b 100644
--- a/drivers/i2c/busses/i2c-tegra-bpmp.c
+++ b/drivers/i2c/busses/i2c-tegra-bpmp.c
@@ -207,7 +207,8 @@ static int tegra_bpmp_i2c_msg_len_check(struct i2c_msg
*msgs, unsigned int num)
static int tegra_bpmp_i2c_msg_xfer(struct tegra_bpmp_i2c *i2c,
struct mrq_i2c_request *request,
- struct mrq_i2c_response *response)
+ struct mrq_i2c_response *response,
+ bool atomic)
{
struct tegra_bpmp_message msg;
int err;
@@ -222,7 +223,7 @@ static int tegra_bpmp_i2c_msg_xfer(struct tegra_bpmp_i2c
*i2c,
msg.rx.data = response;
msg.rx.size = sizeof(*response);
- if (irqs_disabled())
+ if (atomic)
err = tegra_bpmp_transfer_atomic(i2c->bpmp, &msg);
else
err = tegra_bpmp_transfer(i2c->bpmp, &msg);
@@ -230,8 +231,9 @@ static int tegra_bpmp_i2c_msg_xfer(struct tegra_bpmp_i2c
*i2c,
return err;
}
-static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,
- struct i2c_msg *msgs, int num)
+static int tegra_bpmp_i2c_xfer_common(struct i2c_adapter *adapter,
+ struct i2c_msg *msgs, int num,
+ bool atomic)
{
struct tegra_bpmp_i2c *i2c = i2c_get_adapdata(adapter);
struct mrq_i2c_response response;
@@ -253,7 +255,7 @@ static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,
return err;
}
- err = tegra_bpmp_i2c_msg_xfer(i2c, &request, &response);
+ err = tegra_bpmp_i2c_msg_xfer(i2c, &request, &response, atomic);
if (err < 0) {
dev_err(i2c->dev, "failed to transfer message: %d\n", err);
return err;
@@ -268,6 +270,20 @@ static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,
return num;
}
+static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,
+ struct i2c_msg *msgs, int num)
+
+{
+ return tegra_bpmp_i2c_xfer_common(adapter, msgs, num, false);
+}
+
+static int tegra_bpmp_i2c_xfer_atomic(struct i2c_adapter *adapter,
+ struct i2c_msg *msgs, int num)
+
+{
+ return tegra_bpmp_i2c_xfer_common(adapter, msgs, num, true);
+}
+
static u32 tegra_bpmp_i2c_func(struct i2c_adapter *adapter)
{
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
@@ -276,6 +292,7 @@ static u32 tegra_bpmp_i2c_func(struct i2c_adapter *adapter)
static const struct i2c_algorithm tegra_bpmp_i2c_algo = {
.master_xfer = tegra_bpmp_i2c_xfer,
+ .master_xfer_atomic = tegra_bpmp_i2c_xfer_atomic,
.functionality = tegra_bpmp_i2c_func,
};
Looks good to me.
Reviewed-by: Timo Alho
Re: [PATCH] firmware: tegra-bpmp: mark PM function as __maybe_unused
On 03.10.2018 11:26, Jonathan Hunter wrote:
On 02/10/18 22:21, Arnd Bergmann wrote:
The newly added tegra_bpmp_resume function is unused when CONFIG_PM
is disabled:
drivers/firmware/tegra/bpmp.c:847:12: error: 'tegra_bpmp_resume' defined but
not used [-Werror=unused-function]
static int tegra_bpmp_resume(struct device *dev)
Mark it as __maybe_unused to avoid the warning and let the compiler
drop it silently.
Fixes: cd40f6ff124c ("firmware: tegra: bpmp: Implement suspend/resume support")
Signed-off-by: Arnd Bergmann
---
drivers/firmware/tegra/bpmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 41448ba78be9..a3d5b518c10e 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -844,7 +844,7 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
return err;
}
-static int tegra_bpmp_resume(struct device *dev)
+static int __maybe_unused tegra_bpmp_resume(struct device *dev)
{
struct tegra_bpmp *bpmp = dev_get_drvdata(dev);
unsigned int i;
Arnd, is this seen with 32-bit ARM configs?
Timo, does it make sense to make BPMP dependent on ARCH_TEGRA_186_SOC
and ARCH_TEGRA_194_SOC instead of just ARCH_TEGRA? For 64-bit Tegra we
have a dependency on PM so this should not be seen for 64-bit Tegra.
Jon, there will be eventually a BPMP driver for ARCH_TEGRA_210_SOC as
well. So it is probably more appropriate to make BPMP dependent on ARM64
& ARCH_TEGRA.
-Timo
Re: [PATCH V2] firmware: tegra: add BPMP debugfs support
Jon, thanks for reviewing
On 03.10.2017 13:55, Jonathan Hunter wrote:
+static int create_debugfs_mirror(struct tegra_bpmp *bpmp, void *buf,
+size_t bufsize, struct dentry *root)
+{
+ struct seqbuf seqbuf;
+ int err;
+
+ bpmp->debugfs_mirror = debugfs_create_dir("debug", root);
+ if (!bpmp->debugfs_mirror)
+ return -ENOMEM;
Is this extra level needed? Do you plan to have other sub-directories
under the main bpmp directory?
Yes, the downstream driver has few files under main directory (e.g.
'ping' to check that firmware is alive, or 'tag' to read the firmware
version).
BR,
Timo
[PATCH V2] firmware: tegra: add BPMP debugfs support
Tegra power management firmware running on co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).
Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.
Signed-off-by: Timo Alho
---
Changes in v2:
- Address Jonathan's review feedback
* restructure error printing and what error codes passed to higher
layers
* don't use IS_ERR_OR_NULL()
* avoid overwriting last-character of filename in one corner case
(name length = 255)
drivers/firmware/tegra/Makefile | 4 +-
drivers/firmware/tegra/bpmp.c | 4 +
drivers/firmware/tegra/bpmp_debugfs.c | 444 ++
include/soc/tegra/bpmp.h | 14 ++
4 files changed, 465 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/tegra/bpmp_debugfs.c
diff --git a/drivers/firmware/tegra/Makefile b/drivers/firmware/tegra/Makefile
index e34a2f7..0314568 100644
--- a/drivers/firmware/tegra/Makefile
+++ b/drivers/firmware/tegra/Makefile
@@ -1,2 +1,4 @@
-obj-$(CONFIG_TEGRA_BPMP) += bpmp.o
+tegra-bpmp-y = bpmp.o
+tegra-bpmp-$(CONFIG_DEBUG_FS) += bpmp_debugfs.o
+obj-$(CONFIG_TEGRA_BPMP) += tegra-bpmp.o
obj-$(CONFIG_TEGRA_IVC)+= ivc.o
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..d29c593 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -824,6 +824,10 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
+ err = tegra_bpmp_init_debugfs(bpmp);
+ if (err < 0)
+ dev_err(&pdev->dev, "debugfs initialization failed: %d\n", err);
+
return 0;
free_mrq:
diff --git a/drivers/firmware/tegra/bpmp_debugfs.c
b/drivers/firmware/tegra/bpmp_debugfs.c
new file mode 100644
index 000..f7f6a0a
--- /dev/null
+++ b/drivers/firmware/tegra/bpmp_debugfs.c
@@ -0,0 +1,444 @@
+/*
+ * Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+#include
+#include
+#include
+
+#include
+#include
+
+struct seqbuf {
+ char *buf;
+ size_t pos;
+ size_t size;
+};
+
+static void seqbuf_init(struct seqbuf *seqbuf, void *buf, size_t size)
+{
+ seqbuf->buf = buf;
+ seqbuf->size = size;
+ seqbuf->pos = 0;
+}
+
+static size_t seqbuf_avail(struct seqbuf *seqbuf)
+{
+ return seqbuf->pos < seqbuf->size ? seqbuf->size - seqbuf->pos : 0;
+}
+
+static size_t seqbuf_status(struct seqbuf *seqbuf)
+{
+ return seqbuf->pos <= seqbuf->size ? 0 : -EOVERFLOW;
+}
+
+static int seqbuf_eof(struct seqbuf *seqbuf)
+{
+ return seqbuf->pos >= seqbuf->size;
+}
+
+static int seqbuf_read(struct seqbuf *seqbuf, void *buf, size_t nbyte)
+{
+ nbyte = min(nbyte, seqbuf_avail(seqbuf));
+ memcpy(buf, seqbuf->buf + seqbuf->pos, nbyte);
+ seqbuf->pos += nbyte;
+ return seqbuf_status(seqbuf);
+}
+
+static int seqbuf_read_u32(struct seqbuf *seqbuf, uint32_t *v)
+{
+ int err;
+
+ err = seqbuf_read(seqbuf, v, 4);
+ *v = le32_to_cpu(*v);
+ return err;
+}
+
+static int seqbuf_read_str(struct seqbuf *seqbuf, const char **str)
+{
+ *str = seqbuf->buf + seqbuf->pos;
+ seqbuf->pos += strnlen(*str, seqbuf_avail(seqbuf));
+ seqbuf->pos++;
+ return seqbuf_status(seqbuf);
+}
+
+static void seqbuf_seek(struct seqbuf *seqbuf, ssize_t offset)
+{
+ seqbuf->pos += offset;
+}
+
+/* map filename in Linux debugfs to corresponding entry in BPMP */
+static const char *get_filename(struct tegra_bpmp *bpmp,
+ const struct file *file, char *buf, int size)
+{
+ char root_path_buf[512];
+ const char *root_path;
+ const char *filename;
+ size_t root_len;
+
+ root_path = dentry_path(bpmp->debugfs_mirror, root_path_buf,
+ sizeof(root_path_buf));
+ if (IS_ERR(root_path))
+ return NULL;
+
+ root_l
Re: [PATCH 2/4] clk: tegra: check BPMP response return code
On 29.09.2017 17:53, Jonathan Hunter wrote:
On 29/09/17 14:46, Timo Alho wrote:
Hi Jon,
On 21.09.2017 14:21, Jonathan Hunter wrote:
On 07/09/17 10:31, Timo Alho wrote:
Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.
Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.
Signed-off-by: Timo Alho
---
drivers/clk/tegra/clk-bpmp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+ int ret;
} rx;
};
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct
tegra_bpmp *bpmp,
struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = &request;
+ int err;
memset(&request, 0, sizeof(request));
request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct
tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
- return tegra_bpmp_transfer(bpmp, &msg);
+ err = tegra_bpmp_transfer(bpmp, &msg);
+ if (err < 0)
+ return err;
+ else if (msg.rx.ret < 0)
+ return -EINVAL;
I assume that the error codes returned do not correlated to the Linux
error codes here. Is that correct? If not we could just return the
actual error code. Otherwise would it be useful to print a message with
the bpmp error code for debug?
The error codes are not 1:1 match with Linux. Unfortunately, printing
message for debug is not either viable as during clock probing we are
expecting many of the calls to return -BPMP_EINVAL to indicate that
particular clock ID is unused.
OK. Could it return other errors other than BPMP_EINVAL? I am just
wondering if we need to differentiate between unused and an actual
error? Maybe that is not possible here?
Other error codes are possible (though they are not explicitly
documented in abi header). It's not easy to differentiate the error code
at this level: -BPMP_EINVAL is "expected" condition with
CMD_CLK_GET_ALL_INFO, whereas -BPMP_EINVAL is true error on other commands.
Re: [PATCH] firmware: tegra: add BPMP debugfs support
On 29.09.2017 17:58, Jonathan Hunter wrote:
+static int bpmp_populate_dir(struct tegra_bpmp *bpmp, struct seqbuf
*seqbuf,
+ struct dentry *parent, uint32_t depth)
Do we need to use uint32_t here?
+{
+ int err;
+ uint32_t d, t;
And here?
It's part of the BPMP ABI that the data passed is 32 bit unsigned
integer. I wanted to emphasise that with the choice of integer type. Or
did you mean why I did not use u32?
Yes why not just u32?
No other reason than just a personal bias to use standard C99 integer
types. The downstream driver was using a mix of both so wanted to
standardize to just one.
Re: [PATCH 2/4] clk: tegra: check BPMP response return code
Hi Jon,
On 21.09.2017 14:21, Jonathan Hunter wrote:
On 07/09/17 10:31, Timo Alho wrote:
Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.
Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.
Signed-off-by: Timo Alho
---
drivers/clk/tegra/clk-bpmp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+ int ret;
} rx;
};
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = &request;
+ int err;
memset(&request, 0, sizeof(request));
request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
- return tegra_bpmp_transfer(bpmp, &msg);
+ err = tegra_bpmp_transfer(bpmp, &msg);
+ if (err < 0)
+ return err;
+ else if (msg.rx.ret < 0)
+ return -EINVAL;
I assume that the error codes returned do not correlated to the Linux
error codes here. Is that correct? If not we could just return the
actual error code. Otherwise would it be useful to print a message with
the bpmp error code for debug?
The error codes are not 1:1 match with Linux. Unfortunately, printing
message for debug is not either viable as during clock probing we are
expecting many of the calls to return -BPMP_EINVAL to indicate that
particular clock ID is unused.
-Timo
Re: [PATCH] firmware: tegra: add BPMP debugfs support
PTR_ERR(dentry) : -ENOMEM;
+ err = bpmp_populate_dir(bpmp, seqbuf, dentry, depth+1);
+ if (err < 0)
+ return err;
Do we need to remove the directory created here? Or is that handled by
the recursive removal below?
Recursive removal will take care of it.
+static int mrq_is_supported(struct tegra_bpmp *bpmp, unsigned int mrq)
+{
+ struct mrq_query_abi_request req = { .mrq = cpu_to_le32(mrq) };
+ struct mrq_query_abi_response resp;
+ struct tegra_bpmp_message msg = {
+ .mrq = MRQ_QUERY_ABI,
+ .tx = {
+ .data = &req,
+ .size = sizeof(req),
+ },
+ .rx = {
+ .data = &resp,
+ .size = sizeof(resp),
+ },
+ };
+ int ret;
+
+ ret = tegra_bpmp_transfer(bpmp, &msg);
+ /* something went wrong; assume not supported */
+ if (ret < 0)
dev_warn?
Will add.
+
+ virt = dma_alloc_coherent(bpmp->dev, sz, &phys,
+ GFP_KERNEL | GFP_DMA32);
+ if (!virt) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = mrq_debugfs_dumpdir(bpmp, phys, sz, &nbytes);
+ if (ret < 0)
+ goto free;
+
+ ret = create_debugfs_mirror(bpmp, virt, nbytes, root);
+ if (ret < 0)
+ dev_err(bpmp->dev, "create_debugfs_mirror failed (%d)\n", ret);
+
+free:
+ dma_free_coherent(bpmp->dev, sz, virt, phys);
+out:
+ if (ret < 0)
+ debugfs_remove(root);
Should we have a generic warning message here? Looks like it could fail
silently.
I'll add a warning to call site (bpmp.c) if this fails.
-Timo
[PATCH 3/4] reset: tegra: check BPMP response return code
Add checks for return code in BPMP response message. Signed-off-by: Timo Alho --- drivers/reset/tegra/reset-bpmp.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/reset/tegra/reset-bpmp.c b/drivers/reset/tegra/reset-bpmp.c index 5daf2ee..fac2db6 100644 --- a/drivers/reset/tegra/reset-bpmp.c +++ b/drivers/reset/tegra/reset-bpmp.c @@ -23,6 +23,7 @@ static int tegra_bpmp_reset_common(struct reset_controller_dev *rstc, struct tegra_bpmp *bpmp = to_tegra_bpmp(rstc); struct mrq_reset_request request; struct tegra_bpmp_message msg; + int err; memset(&request, 0, sizeof(request)); request.cmd = command; @@ -33,7 +34,13 @@ static int tegra_bpmp_reset_common(struct reset_controller_dev *rstc, msg.tx.data = &request; msg.tx.size = sizeof(request); - return tegra_bpmp_transfer(bpmp, &msg); + err = tegra_bpmp_transfer(bpmp, &msg); + if (err < 0) + return err; + else if (msg.rx.ret < 0) + return -EINVAL; + + return 0; } static int tegra_bpmp_reset_module(struct reset_controller_dev *rstc, -- 2.7.4
[PATCH 1/4] firmware: tegra: propagate error code to caller
Response messages from Tegra BPMP firmware contain an error return
code as the first word of payload. The error code is used to indicate
incorrectly formatted request message or use of non-existing resource
(clk, reset, powergate) identifier. Current implementation of
tegra_bpmp_transfer() ignores this code and does not pass it to
caller. Fix this by adding an extra struct member to
tegra_bpmp_message and populate that with return code.
Signed-off-by: Timo Alho
---
drivers/firmware/tegra/bpmp.c | 22 --
include/soc/tegra/bpmp.h | 1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..33683b5 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -194,16 +194,24 @@ static int tegra_bpmp_wait_master_free(struct
tegra_bpmp_channel *channel)
}
static ssize_t __tegra_bpmp_channel_read(struct tegra_bpmp_channel *channel,
-void *data, size_t size)
+void *data, size_t size, int *ret)
{
+ int err;
+
if (data && size > 0)
memcpy(data, channel->ib->data, size);
- return tegra_ivc_read_advance(channel->ivc);
+ err = tegra_ivc_read_advance(channel->ivc);
+ if (err < 0)
+ return err;
+
+ *ret = channel->ib->code;
+
+ return 0;
}
static ssize_t tegra_bpmp_channel_read(struct tegra_bpmp_channel *channel,
- void *data, size_t size)
+ void *data, size_t size, int *ret)
{
struct tegra_bpmp *bpmp = channel->bpmp;
unsigned long flags;
@@ -217,7 +225,7 @@ static ssize_t tegra_bpmp_channel_read(struct
tegra_bpmp_channel *channel,
}
spin_lock_irqsave(&bpmp->lock, flags);
- err = __tegra_bpmp_channel_read(channel, data, size);
+ err = __tegra_bpmp_channel_read(channel, data, size, ret);
clear_bit(index, bpmp->threaded.allocated);
spin_unlock_irqrestore(&bpmp->lock, flags);
@@ -337,7 +345,8 @@ int tegra_bpmp_transfer_atomic(struct tegra_bpmp *bpmp,
if (err < 0)
return err;
- return __tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size);
+ return __tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size,
+&msg->rx.ret);
}
EXPORT_SYMBOL_GPL(tegra_bpmp_transfer_atomic);
@@ -371,7 +380,8 @@ int tegra_bpmp_transfer(struct tegra_bpmp *bpmp,
if (err == 0)
return -ETIMEDOUT;
- return tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size);
+ return tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size,
+ &msg->rx.ret);
}
EXPORT_SYMBOL_GPL(tegra_bpmp_transfer);
diff --git a/include/soc/tegra/bpmp.h b/include/soc/tegra/bpmp.h
index 9ba6522..57519f4 100644
--- a/include/soc/tegra/bpmp.h
+++ b/include/soc/tegra/bpmp.h
@@ -110,6 +110,7 @@ struct tegra_bpmp_message {
struct {
void *data;
size_t size;
+ int ret;
} rx;
};
--
2.7.4
[PATCH 2/4] clk: tegra: check BPMP response return code
Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.
Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.
Signed-off-by: Timo Alho
---
drivers/clk/tegra/clk-bpmp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+ int ret;
} rx;
};
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = &request;
+ int err;
memset(&request, 0, sizeof(request));
request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
- return tegra_bpmp_transfer(bpmp, &msg);
+ err = tegra_bpmp_transfer(bpmp, &msg);
+ if (err < 0)
+ return err;
+ else if (msg.rx.ret < 0)
+ return -EINVAL;
+
+ return 0;
}
static int tegra_bpmp_clk_prepare(struct clk_hw *hw)
@@ -414,11 +422,8 @@ static int tegra_bpmp_probe_clocks(struct tegra_bpmp *bpmp,
struct tegra_bpmp_clk_info *info = &clocks[count];
err = tegra_bpmp_clk_get_info(bpmp, id, info);
- if (err < 0) {
- dev_err(bpmp->dev, "failed to query clock %u: %d\n",
- id, err);
+ if (err < 0)
continue;
- }
if (info->num_parents >= U8_MAX) {
dev_err(bpmp->dev,
--
2.7.4
[PATCH 0/4] firmware: tegra: add checks for BPMP error return code
Hi Thierry, There is a bug in the BPMP driver as error code in response message is not being checked. Patch 1 adds the error code as part of tegra_bpmp_message struct and propagates that code to callers Patches 2 through 4 add code to client drivers to check the error code appropriately BR, Timo Timo Alho (4): firmware: tegra: propagate error code to caller clk: tegra: check BPMP response return code reset: tegra: check BPMP response return code soc/tegra: bpmp: check BPMP response return code drivers/clk/tegra/clk-bpmp.c | 15 ++- drivers/firmware/tegra/bpmp.c | 22 -- drivers/reset/tegra/reset-bpmp.c | 9 - drivers/soc/tegra/powergate-bpmp.c | 15 +-- include/soc/tegra/bpmp.h | 1 + 5 files changed, 48 insertions(+), 14 deletions(-) -- 2.7.4
[PATCH 4/4] soc/tegra: bpmp: check BPMP response return code
Add checks for return code in BPMP response message.
Signed-off-by: Timo Alho
---
drivers/soc/tegra/powergate-bpmp.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/tegra/powergate-bpmp.c
b/drivers/soc/tegra/powergate-bpmp.c
index 8fc3560..82c7e27 100644
--- a/drivers/soc/tegra/powergate-bpmp.c
+++ b/drivers/soc/tegra/powergate-bpmp.c
@@ -42,6 +42,7 @@ static int tegra_bpmp_powergate_set_state(struct tegra_bpmp
*bpmp,
{
struct mrq_pg_request request;
struct tegra_bpmp_message msg;
+ int err;
memset(&request, 0, sizeof(request));
request.cmd = CMD_PG_SET_STATE;
@@ -53,7 +54,13 @@ static int tegra_bpmp_powergate_set_state(struct tegra_bpmp
*bpmp,
msg.tx.data = &request;
msg.tx.size = sizeof(request);
- return tegra_bpmp_transfer(bpmp, &msg);
+ err = tegra_bpmp_transfer(bpmp, &msg);
+ if (err < 0)
+ return err;
+ else if (msg.rx.ret < 0)
+ return -EINVAL;
+
+ return 0;
}
static int tegra_bpmp_powergate_get_state(struct tegra_bpmp *bpmp,
@@ -80,6 +87,8 @@ static int tegra_bpmp_powergate_get_state(struct tegra_bpmp
*bpmp,
err = tegra_bpmp_transfer(bpmp, &msg);
if (err < 0)
return PG_STATE_OFF;
+ else if (msg.rx.ret < 0)
+ return -EINVAL;
return response.get_state.state;
}
@@ -106,6 +115,8 @@ static int tegra_bpmp_powergate_get_max_id(struct
tegra_bpmp *bpmp)
err = tegra_bpmp_transfer(bpmp, &msg);
if (err < 0)
return err;
+ else if (msg.rx.ret < 0)
+ return -EINVAL;
return response.get_max_id.max_id;
}
@@ -132,7 +143,7 @@ static char *tegra_bpmp_powergate_get_name(struct
tegra_bpmp *bpmp,
msg.rx.size = sizeof(response);
err = tegra_bpmp_transfer(bpmp, &msg);
- if (err < 0)
+ if (err < 0 || msg.rx.ret < 0)
return NULL;
return kstrdup(response.get_name.name, GFP_KERNEL);
--
2.7.4
[PATCH] firmware: tegra: add BPMP debugfs support
Tegra power management firmware running on co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).
Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.
Signed-off-by: Timo Alho
---
drivers/firmware/tegra/Makefile | 4 +-
drivers/firmware/tegra/bpmp.c | 2 +
drivers/firmware/tegra/bpmp_debugfs.c | 446 ++
include/soc/tegra/bpmp.h | 14 ++
4 files changed, 465 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/tegra/bpmp_debugfs.c
diff --git a/drivers/firmware/tegra/Makefile b/drivers/firmware/tegra/Makefile
index e34a2f7..0314568 100644
--- a/drivers/firmware/tegra/Makefile
+++ b/drivers/firmware/tegra/Makefile
@@ -1,2 +1,4 @@
-obj-$(CONFIG_TEGRA_BPMP) += bpmp.o
+tegra-bpmp-y = bpmp.o
+tegra-bpmp-$(CONFIG_DEBUG_FS) += bpmp_debugfs.o
+obj-$(CONFIG_TEGRA_BPMP) += tegra-bpmp.o
obj-$(CONFIG_TEGRA_IVC)+= ivc.o
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..bf2a376 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -824,6 +824,8 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
+ (void)tegra_bpmp_init_debugfs(bpmp);
+
return 0;
free_mrq:
diff --git a/drivers/firmware/tegra/bpmp_debugfs.c
b/drivers/firmware/tegra/bpmp_debugfs.c
new file mode 100644
index 000..4d0279d
--- /dev/null
+++ b/drivers/firmware/tegra/bpmp_debugfs.c
@@ -0,0 +1,446 @@
+/*
+ * Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+#include
+#include
+#include
+
+#include
+#include
+
+struct seqbuf {
+ char *buf;
+ size_t pos;
+ size_t size;
+};
+
+static void seqbuf_init(struct seqbuf *seqbuf, void *buf, size_t size)
+{
+ seqbuf->buf = buf;
+ seqbuf->size = size;
+ seqbuf->pos = 0;
+}
+
+static size_t seqbuf_avail(struct seqbuf *seqbuf)
+{
+ return seqbuf->pos < seqbuf->size ? seqbuf->size - seqbuf->pos : 0;
+}
+
+static size_t seqbuf_status(struct seqbuf *seqbuf)
+{
+ return seqbuf->pos <= seqbuf->size ? 0 : -EOVERFLOW;
+}
+
+static int seqbuf_eof(struct seqbuf *seqbuf)
+{
+ return seqbuf->pos >= seqbuf->size;
+}
+
+static int seqbuf_read(struct seqbuf *seqbuf, void *buf, size_t nbyte)
+{
+ nbyte = min(nbyte, seqbuf_avail(seqbuf));
+ memcpy(buf, seqbuf->buf + seqbuf->pos, nbyte);
+ seqbuf->pos += nbyte;
+ return seqbuf_status(seqbuf);
+}
+
+static int seqbuf_read_u32(struct seqbuf *seqbuf, uint32_t *v)
+{
+ int err;
+
+ err = seqbuf_read(seqbuf, v, 4);
+ *v = le32_to_cpu(*v);
+ return err;
+}
+
+static int seqbuf_read_str(struct seqbuf *seqbuf, const char **str)
+{
+ *str = seqbuf->buf + seqbuf->pos;
+ seqbuf->pos += strnlen(*str, seqbuf_avail(seqbuf));
+ seqbuf->pos++;
+ return seqbuf_status(seqbuf);
+}
+
+static void seqbuf_seek(struct seqbuf *seqbuf, ssize_t offset)
+{
+ seqbuf->pos += offset;
+}
+
+/* map filename in Linux debugfs to corresponding entry in BPMP */
+static const char *get_filename(struct tegra_bpmp *bpmp,
+ const struct file *file, char *buf, int size)
+{
+ char root_path_buf[512];
+ const char *root_path;
+ const char *filename;
+ size_t root_len;
+
+ root_path = dentry_path_raw(bpmp->debugfs_mirror, root_path_buf,
+ sizeof(root_path_buf));
+ if (IS_ERR_OR_NULL(root_path))
+ return NULL;
+
+ root_len = strlen(root_path);
+
+ filename = dentry_path(file->f_path.dentry, buf, size);
+ if (IS_ERR_OR_NULL(filename))
+ return NULL;
+
+ if (strlen(filename) < root_len ||
+ strncmp(filename, root_path, root_len))
+ return NULL;
+
+ filename += root_len;
+
+ return filename;
+}
+
+static int
[PATCH] mmc: tegra: suppress errors when probe is deferred
Don't print error message when clk_get() returns -EPROBE_DEFER. On
recent Tegra chips (t186 onwards), the clocks are provided by
auxiliary microprocessor (bpmp) and until the driver for it is probed
clocks are not available.
While at it, change the real error message more meaningful.
Signed-off-by: Timo Alho
---
drivers/mmc/host/sdhci-tegra.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index f668a6f..cdde9ff 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -501,8 +501,10 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
clk = devm_clk_get(mmc_dev(host->mmc), NULL);
if (IS_ERR(clk)) {
- dev_err(mmc_dev(host->mmc), "clk err\n");
rc = PTR_ERR(clk);
+ if (rc != -EPROBE_DEFER)
+ dev_err(&pdev->dev,
+ "failed to get controller clock: %d\n", rc);
goto err_clk_get;
}
clk_prepare_enable(clk);
--
2.7.4
[PATCH] firmware: tegra: set drvdata earlier
Subdevices of bpmp, such as bpmp-i2c, require the bpmp device's drvdata to be set during their probe. Currently this is not always the case. Fix this by calling platform_set_drvdata() earlier during bpmp's probe. Signed-off-by: Timo Alho --- drivers/firmware/tegra/bpmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c index b251795..73ca55b 100644 --- a/drivers/firmware/tegra/bpmp.c +++ b/drivers/firmware/tegra/bpmp.c @@ -806,6 +806,8 @@ static int tegra_bpmp_probe(struct platform_device *pdev) dev_info(&pdev->dev, "firmware: %s\n", tag); + platform_set_drvdata(pdev, bpmp); + err = of_platform_default_populate(pdev->dev.of_node, NULL, &pdev->dev); if (err < 0) goto free_mrq; @@ -822,8 +824,6 @@ static int tegra_bpmp_probe(struct platform_device *pdev) if (err < 0) goto free_mrq; - platform_set_drvdata(pdev, bpmp); - return 0; free_mrq: -- 2.7.4
[PATCH] staging: wlang-ng: Fix block comments style warnings in prism2sta.h
This patch fixes the following checkpatch.pl warning in prism2sta.h:
WARNING: Block comments should align the * on each line
No more warnings block comments warnings for this file.
Signed-off-by: Timo Schmid
---
drivers/staging/wlan-ng/prism2sta.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2sta.c
b/drivers/staging/wlan-ng/prism2sta.c
index e1b4a94..1a6ea1f 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1859,24 +1859,24 @@ void prism2sta_ev_alloc(struct wlandevice *wlandev)
}
/*
-* create_wlan
-*
-* Called at module init time. This creates the struct wlandevice structure
-* and initializes it with relevant bits.
-*
-* Arguments:
-* none
-*
-* Returns:
-* the created struct wlandevice structure.
-*
-* Side effects:
-* also allocates the priv/hw structures.
-*
-* Call context:
-* process thread
-*
-*/
+ * create_wlan
+ *
+ * Called at module init time. This creates the struct wlandevice structure
+ * and initializes it with relevant bits.
+ *
+ * Arguments:
+ * none
+ *
+ * Returns:
+ * the created struct wlandevice structure.
+ *
+ * Side effects:
+ * also allocates the priv/hw structures.
+ *
+ * Call context:
+ * process thread
+ *
+ */
static struct wlandevice *create_wlan(void)
{
struct wlandevice *wlandev = NULL;
--
2.7.4
Re: [PATCH] builddeb: Update a few outdated and hardcoded strings
Hi, Riku Voipio schrieb am 13.09.2016 10:22: > On 5 September 2016 at 02:43, Timo Sigurdsson > wrote: >> The builddeb script has some hardcoded references to linux version 2.6 >> which is ancient. Use a variable instead in order to keep in sync with >> new releases and avoid the need to manually update this. In addition, >> change the copyright notice to include the year 2016. > > I think we can just drop all the "Provides" lines, the official debian > packages don't provide > anything, and nothing depends on these provided virtual packages either. As far as Debian is concerned, that's true. However, Ubuntu's linux packages have these "Provides" lines. But as I haven't used Ubuntu in a while, I don't know if these are actually required for anything on Ubuntu systems. I'd be fine with any decision (keep or drop), I just don't wanna make the call to drop them as I'm not aware about the implications on other Debian based distributions. Regards, Timo
[PATCH] builddeb: Update a few outdated and hardcoded strings
The builddeb script has some hardcoded references to linux version 2.6
which is ancient. Use a variable instead in order to keep in sync with
new releases and avoid the need to manually update this. In addition,
change the copyright notice to include the year 2016.
Signed-off-by: Timo Sigurdsson
---
scripts/package/builddeb | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..d85120c 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -84,6 +84,7 @@ set_debarch() {
# Some variables and settings used throughout the script
version=$KERNELRELEASE
+majorversion=$VERSION.$PATCHLEVEL
revision=$(cat .version)
if [ -n "$KDEB_PKGVERSION" ]; then
packageversion=$KDEB_PKGVERSION
@@ -265,7 +266,7 @@ This is a packacked upstream version of the Linux kernel.
The sources may be found at most Linux ftp sites, including:
ftp://ftp.kernel.org/pub/linux/kernel
-Copyright: 1991 - 2015 Linus Torvalds and others.
+Copyright: 1991 - 2016 Linus Torvalds and others.
The git repository for mainline kernel development is at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
@@ -296,7 +297,7 @@ if [ "$ARCH" = "um" ]; then
cat <> debian/control
Package: $packagename
-Provides: linux-image, linux-image-2.6, linux-modules-$version
+Provides: linux-image, linux-image-$majorversion, linux-modules-$version
Architecture: any
Description: User Mode Linux kernel, version $version
User-mode Linux is a port of the Linux kernel to its own system call
@@ -313,7 +314,7 @@ else
cat <> debian/control
Package: $packagename
-Provides: linux-image, linux-image-2.6, linux-modules-$version
+Provides: linux-image, linux-image-$majorversion, linux-modules-$version
Suggests: $fwpackagename
Architecture: any
Description: Linux kernel, version $version
@@ -346,7 +347,7 @@ rm -f "$objtree/debian/hdrsrcfiles"
"$objtree/debian/hdrobjfiles"
cat <> debian/control
Package: $kernel_headers_packagename
-Provides: linux-headers, linux-headers-2.6
+Provides: linux-headers, linux-headers-$majorversion
Architecture: any
Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
This package provides kernel header files for $KERNELRELEASE on
\${kernel:debarch}
--
2.1.4
[PATCH for 4.4-rc8] ARM: Fix broken USB support in multi_v7_defconfig for sunxi devices
Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a
new driver for the USB power supply used on various Allwinner based SBCs.
However, the driver was not added to multi_v7_defconfig which breaks USB
support for some boards (e.g. LeMaker BananaPi) as the kernel will now
turn off the USB power supply during boot by default if the driver isn't
present. (This was not the case in linux 4.3 or lower where the USB power
was always left on.)
Hence, add the driver to multi_v7_defconfig in order to keep USB support
working on those boards that require it.
Signed-off-by: Timo Sigurdsson
Tested-by: Timo Sigurdsson
Acked-by: Maxime Ripard
---
Notes:
I chose to add AXP20X_POWER as a module here, since linux-next already
has it this way, see commit 83e9e1f84074 ("ARM: multi_v7_defconfig:
Enable RSB and AXP20X related drivers as modules").
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..cd7b198 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -366,6 +366,7 @@ CONFIG_BATTERY_MAX17042=m
CONFIG_CHARGER_MAX14577=m
CONFIG_CHARGER_MAX77693=m
CONFIG_CHARGER_TPS65090=y
+CONFIG_AXP20X_POWER=m
CONFIG_POWER_RESET_AS3722=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_POWER_RESET_GPIO_RESTART=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig
Hi Arnd, Arnd Bergmann schrieb am 31.12.2015 16:46: > On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote: >> Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this >> could make it into 4.4 in order to avoid unpleasent surprises (and >> subsequent questions) with builds based on sunxi_defconfig. At the moment, >> some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports >> as a newly added driver is required to power them. > > It's a bit confusing to send a patch to so many recipients, that usually > leads to nobody applying it. I can put it into the fixes branch in arm-soc > but need an Ack from the sunxi maintainer(s). Sorry, I didn't know any better. Almost all recipients came from the get-maintainers script (which I thought were mandatory to include). What's the recommended way in such cases? I already prepared and tested a patch for multi_v7_defconfig which I'll send to the same recipients as before just for the sake of not shutting out people that were previously addressed in this conversation. Thanks and Happy New Year, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig
Hi Maxime, Maxime Ripard schrieb am 31.12.2015 17:00: > Hi Arnd, > > On Thu, Dec 31, 2015 at 04:46:01PM +0100, Arnd Bergmann wrote: >> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote: >> > Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this >> > >> > could make it into 4.4 in order to avoid unpleasent surprises (and >> > subsequent questions) with builds based on sunxi_defconfig. At the moment, >> > some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports >> > as a newly added driver is required to power them. >> >> It's a bit confusing to send a patch to so many recipients, that usually >> leads to nobody applying it. I can put it into the fixes branch in arm-soc >> but need an Ack from the sunxi maintainer(s). > > You have mine > > Acked-by: Maxime Ripard > > Timo, don't we need the same thing for multi_v7? Yes, we do. I thought I saw it already in there as a module, but that must have been on linux-next... Anyway, patch will come right away. I take it your question implies an ack for the multi_v7 patch, too. Thanks and Happy New Year, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig
Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this could make it into 4.4 in order to avoid unpleasent surprises (and subsequent questions) with builds based on sunxi_defconfig. At the moment, some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports as a newly added driver is required to power them. Timo Sigurdsson (1): ARM: Fix broken USB support in sunxi_defconfig arch/arm/configs/sunxi_defconfig | 1 + 1 file changed, 1 insertion(+) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig
Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a new
driver for the USB power supply used on various Allwinner based SBCs. However,
the driver was not added to sunxi_defconfig which breaks USB support for some
boards (e.g. LeMaker BananaPi) as the kernel will now turn off the USB power
supply during boot by default if the driver isn't present. (This was not the
case in linux 4.3 or lower where the USB power was always left on.)
Hence, add the driver to sunxi_defconfig in order to keep USB support working
on those boards that require it.
Signed-off-by: Timo Sigurdsson
Reported-by: David Tulloh
Tested-by: David Tulloh
Tested-by: Timo Sigurdsson
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..b503a89 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -84,6 +84,7 @@ CONFIG_SPI_SUN4I=y
CONFIG_SPI_SUN6I=y
CONFIG_GPIO_SYSFS=y
CONFIG_POWER_SUPPLY=y
+CONFIG_AXP20X_POWER=y
CONFIG_THERMAL=y
CONFIG_CPU_THERMAL=y
CONFIG_WATCHDOG=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Sorry, I probably shouldn't send patches at an hour I should rather be
sleeping... As a result, I forgot to add the patch history.
Here it is:
Changes in v2:
- Move the extra cleanup work for sunxi_defconfig to a separate patch
- Add another patch to meet the dependencies of
CONFIG_KEYBOARD_SUN4I_LRADC and not have it removed while cleaning up
Good night,
Timo
Am Freitag, den 20.11.2015, 02:46 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
>
> Signed-off-by: Timo Sigurdsson
> ---
> arch/arm/configs/sunxi_defconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..0bbc2ee 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
> # CONFIG_WIRELESS is not set
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_ATA=y
> CONFIG_AHCI_SUNXI=y
> @@ -123,6 +122,8 @@ CONFIG_PWM=y
> CONFIG_PWM_SUN4I=y
> CONFIG_PHY_SUN4I_USB=y
> CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
> CONFIG_EXT4_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_TMPFS=y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] ARM: sunxi: Really enable LRADC keys in sunxi_defconfig
Commit be8becb81bdc ("ARM: sunxi_defconfig: Enable LRADC keys
(KEYBOARD_SUN4I_LRADC)") added CONFIG_KEYBOARD_SUN4I_LRADC=y to
sunxi_defconfig. However, it depends on CONFIG_KEYBOARD which is
explicitly disabled in sunxi_defconfig. Hence, the LRADC keys were
never actually enabled. Remove the line disabling CONFIG_KEYBOARD in
order to really enable KEYBOARD_SUN4I_LRADC.
Signed-off-by: Timo Sigurdsson
---
arch/arm/configs/sunxi_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 0bbc2ee..90252ca 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -60,7 +60,6 @@ CONFIG_STMMAC_ETH=y
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_WLAN is not set
# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AXP20X_PEK=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM: sunxi: Clean up sunxi_defconfig
Clean up sunxi_defconfig by generating a fresh file via make sunxi_defconfig make savedefconfig While this moves around a few lines and removes unnecessary symbols, it doesn't introduce any functional changes. The resulting .config is identical before and after this patch. Signed-off-by: Timo Sigurdsson --- arch/arm/configs/sunxi_defconfig | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 90252ca..95b51fc 100644 --- a/arch/arm/configs/sunxi_defconfig +++ b/arch/arm/configs/sunxi_defconfig @@ -11,14 +11,12 @@ CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_AEABI=y CONFIG_HIGHMEM=y -CONFIG_HIGHPTE=y CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CPU_FREQ=y CONFIG_CPUFREQ_DT=y CONFIG_VFP=y CONFIG_NEON=y -CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -60,12 +58,12 @@ CONFIG_STMMAC_ETH=y # CONFIG_NET_VENDOR_WIZNET is not set # CONFIG_WLAN is not set # CONFIG_INPUT_MOUSEDEV is not set +CONFIG_KEYBOARD_SUN4I_LRADC=y # CONFIG_INPUT_MOUSE is not set -CONFIG_INPUT_MISC=y -CONFIG_INPUT_AXP20X_PEK=y CONFIG_INPUT_TOUCHSCREEN=y -CONFIG_KEYBOARD_SUN4I_LRADC=y CONFIG_TOUCHSCREEN_SUN4I=y +CONFIG_INPUT_MISC=y +CONFIG_INPUT_AXP20X_PEK=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=8 -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.
Signed-off-by: Timo Sigurdsson
---
arch/arm/configs/sunxi_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..0bbc2ee 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
@@ -123,6 +122,8 @@ CONFIG_PWM=y
CONFIG_PWM_SUN4I=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Sorry, sent out the reply first to Maxime only and forgot to include the
rest of the bunch. So, here we go again...
Hi Maxime,
Am Freitag, den 20.11.2015, 00:43 +0100 schrieb Maxime Ripard:
> Hi,
>
> On Thu, Nov 19, 2015 at 10:48:35PM +0100, Timo Sigurdsson wrote:
> > Hi Maxime,
> > Hi Chen-Yu,
> >
> > Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> > > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the
nvmem
> > > framework") moved the the sunxi SID driver to a new framework, but
left
> > > sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the
driver
> > > in sunxi_defconfig.
> > >
> > > While at it, clean up sunxi_defconfig by generating a fresh file
via
> > > make sunxi_defconfig
> > > make savedefconfig
> > > While this moves around a few lines and removes unnecessary
symbols,
> > > it doesn't introduce any functional changes.
> > >
> > > Signed-off-by: Timo Sigurdsson
> > >
> > > diff --git a/arch/arm/configs/sunxi_defconfig
b/arch/arm/configs/sunxi_defconfig
> > > index 3c36e16..904ea52 100644
> > > --- a/arch/arm/configs/sunxi_defconfig
> > > +++ b/arch/arm/configs/sunxi_defconfig
> > > @@ -11,14 +11,12 @@ CONFIG_SMP=y
> > > CONFIG_NR_CPUS=8
> > > CONFIG_AEABI=y
> > > CONFIG_HIGHMEM=y
> > > -CONFIG_HIGHPTE=y
> > > CONFIG_ARM_APPENDED_DTB=y
> > > CONFIG_ARM_ATAG_DTB_COMPAT=y
> > > CONFIG_CPU_FREQ=y
> > > CONFIG_CPUFREQ_DT=y
> > > CONFIG_VFP=y
> > > CONFIG_NEON=y
> > > -CONFIG_PM=y
> > > CONFIG_NET=y
> > > CONFIG_PACKET=y
> > > CONFIG_UNIX=y
> > > @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
> > > # CONFIG_WIRELESS is not set
> > > CONFIG_DEVTMPFS=y
> > > CONFIG_DEVTMPFS_MOUNT=y
> > > -CONFIG_EEPROM_SUNXI_SID=y
> > > CONFIG_BLK_DEV_SD=y
> > > CONFIG_ATA=y
> > > CONFIG_AHCI_SUNXI=y
> > > @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
> > > # CONFIG_INPUT_MOUSEDEV is not set
> > > # CONFIG_INPUT_KEYBOARD is not set
> > > # CONFIG_INPUT_MOUSE is not set
> > > -CONFIG_INPUT_MISC=y
> > > -CONFIG_INPUT_AXP20X_PEK=y
> > > CONFIG_INPUT_TOUCHSCREEN=y
> > > -CONFIG_KEYBOARD_SUN4I_LRADC=y
> > > CONFIG_TOUCHSCREEN_SUN4I=y
> > > +CONFIG_INPUT_MISC=y
> > > +CONFIG_INPUT_AXP20X_PEK=y
> > > CONFIG_SERIAL_8250=y
> > > CONFIG_SERIAL_8250_CONSOLE=y
> > > CONFIG_SERIAL_8250_NR_UARTS=8
> > > @@ -123,6 +119,8 @@ CONFIG_PWM=y
> > > CONFIG_PWM_SUN4I=y
> > > CONFIG_PHY_SUN4I_USB=y
> > > CONFIG_PHY_SUN9I_USB=y
> > > +CONFIG_NVMEM=y
> > > +CONFIG_NVMEM_SUNXI_SID=y
> > > CONFIG_EXT4_FS=y
> > > CONFIG_VFAT_FS=y
> > > CONFIG_TMPFS=y
> >
> > Would you also prefer to see this patch split up into two patches
(one
> > for re-enabling the SID driver and one for the extra cleanup of
> > sunxi_defconfg) as I was asked to do for my other patch for
> > multi_v7_defconfig?
>
> Yes, please do.
Ok.
>
> Also why CONFIG_PM CONFIG_KEYBOARD_SUN4I_LRADC and CONFIG_HIGHPTE got
> removed ?
CONFIG_HIGHPTE defaults to yes since 4.4-rc1 in arch/arm/Kconfig, so we
don't need it in sunxi_defconfig anymore. CONFIG_PM is already selected
by CONFIG_ARCH_MULTI_V7, so also no need to set that explicitly.
What's interesting is CONFIG_KEYBOARD_SUN4I_LRADC, because that actually
does _NOT_ get enabled by sunxi_defconfig. I didn't notice earlier,
because before and after my patch, the resulting .config was identical.
The problem with CONFIG_KEYBOARD_SUN4I_LRADC is that keyboard support is
explicitly disabled in sunxi_defconfig which is why
CONFIG_KEYBOARD_SUN4I_LRADC is simply ignored.
So, we need to remove the line
# CONFIG_INPUT_KEYBOARD is not set
in order to actually have CONFIG_KEYBOARD_SUN4I_LRADC enabled.
I'll write another patch for it.
Regards,
Timo
>
> Thanks,
> Maxime
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Hi Maxime,
Hi Chen-Yu,
Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
>
> While at it, clean up sunxi_defconfig by generating a fresh file via
> make sunxi_defconfig
> make savedefconfig
> While this moves around a few lines and removes unnecessary symbols,
> it doesn't introduce any functional changes.
>
> Signed-off-by: Timo Sigurdsson
>
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..904ea52 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -11,14 +11,12 @@ CONFIG_SMP=y
> CONFIG_NR_CPUS=8
> CONFIG_AEABI=y
> CONFIG_HIGHMEM=y
> -CONFIG_HIGHPTE=y
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_CPU_FREQ=y
> CONFIG_CPUFREQ_DT=y
> CONFIG_VFP=y
> CONFIG_NEON=y
> -CONFIG_PM=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
> # CONFIG_WIRELESS is not set
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_ATA=y
> CONFIG_AHCI_SUNXI=y
> @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
> # CONFIG_INPUT_MOUSEDEV is not set
> # CONFIG_INPUT_KEYBOARD is not set
> # CONFIG_INPUT_MOUSE is not set
> -CONFIG_INPUT_MISC=y
> -CONFIG_INPUT_AXP20X_PEK=y
> CONFIG_INPUT_TOUCHSCREEN=y
> -CONFIG_KEYBOARD_SUN4I_LRADC=y
> CONFIG_TOUCHSCREEN_SUN4I=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_AXP20X_PEK=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_NR_UARTS=8
> @@ -123,6 +119,8 @@ CONFIG_PWM=y
> CONFIG_PWM_SUN4I=y
> CONFIG_PHY_SUN4I_USB=y
> CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
> CONFIG_EXT4_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_TMPFS=y
Would you also prefer to see this patch split up into two patches (one
for re-enabling the SID driver and one for the extra cleanup of
sunxi_defconfg) as I was asked to do for my other patch for
multi_v7_defconfig?
Thanks,
Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.
Signed-off-by: Timo Sigurdsson
---
Changes in v2:
- Move the extra cleanup work for multi_v7_defconfig to a separate
patch (to be submitted at a later point to avoid conflicts with
another patch waiting to be merged)
---
arch/arm/configs/multi_v7_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index eefcab1..59d3d3a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -188,7 +188,6 @@ CONFIG_ATMEL_SSC=m
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_MULTI_LUN=y
@@ -714,6 +713,8 @@ CONFIG_PHY_STIH407_USB=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_SUN9I_USB=y
CONFIG_PHY_SAMSUNG_USB2=m
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
CONFIG_EXT4_FS=y
CONFIG_AUTOFS4_FS=y
CONFIG_MSDOS_FS=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Hi, Krzysztof Kozlowski schrieb am 17.11.2015 09:21: [...] >>> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y >>> > CONFIG_MEDIA_CONTROLLER=y >>> > CONFIG_VIDEO_V4L2_SUBDEV_API=y >>> > CONFIG_MEDIA_USB_SUPPORT=y >>> > -CONFIG_USB_VIDEO_CLASS=y >>> > -CONFIG_USB_GSPCA=y >>> > +CONFIG_USB_VIDEO_CLASS=m >>> > CONFIG_V4L_PLATFORM_DRIVERS=y >>> > CONFIG_SOC_CAMERA=m >>> > CONFIG_SOC_CAMERA_PLATFORM=m >>> > @@ -465,28 +445,25 @@ CONFIG_DRM=y >>> > CONFIG_DRM_I2C_ADV7511=m >>> > # CONFIG_DRM_I2C_CH7006 is not set >>> > # CONFIG_DRM_I2C_SIL164 is not set >>> > -CONFIG_DRM_NXP_PTN3460=m >>> > -CONFIG_DRM_PARADE_PS8622=m >>> > CONFIG_DRM_NOUVEAU=m >>> > CONFIG_DRM_EXYNOS=m >>> > -CONFIG_DRM_EXYNOS_DSI=y >>> > CONFIG_DRM_EXYNOS_FIMD=y >>> > -CONFIG_DRM_EXYNOS_HDMI=y >>> >>> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled >>> but we are fixing it in: >>> http://www.spinics.net/lists/dri-devel/msg93299.html >> >> I think the problem here is that I don't see this patch in linux-next >> yet. >> > > Indeed... and I don't know when it will go there so actually maybe it > should be removed... but in the same time removing DRM_EXYNOS_HDMI > will probably make some conflicts because mentioned patch will go > through Exynos DRM tree or Samsung SoC. Since you suggested to split my patch into two, I might as well just hold off the "cleanup" patch until Andrzejs patch hits linux-next. Is that ok? Regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Hi,
Lee Jones schrieb am 17.11.2015 09:07:
> On Tue, 17 Nov 2015, Timo Sigurdsson wrote:
>
>> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
>> framework") moved the the sunxi SID driver to a new framework, but left
>> multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
>> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
>> in multi_v7_defconfig.
>>
>> While at it, clean up multi_v7_defconfig by generating a fresh file via
>> make multi_v7_defconfig
>> make savedefconfig
>> While this moves around a few lines and removes unnecessary symbols,
>> it doesn't introduce any functional changes.
>>
>> Signed-off-by: Timo Sigurdsson
>
> Please either use Git to submit your changes, or add a diffstat in
> manually. They *are* helpful.
I do use git. But I guess I messed up the command somehow so the diffstat
wasn't included. Sorry about that. I'll make sure it's there next time.
Thanks,
Timo
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Hi,
Am Dienstag, den 17.11.2015, 11:10 +0900 schrieb Krzysztof Kozlowski:
> On 17.11.2015 10:49, Timo Sigurdsson wrote:
> > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> > framework") moved the the sunxi SID driver to a new framework, but left
> > multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> > in multi_v7_defconfig.
> >
> > While at it, clean up multi_v7_defconfig by generating a fresh file via
> > make multi_v7_defconfig
> > make savedefconfig
> > While this moves around a few lines and removes unnecessary symbols,
> > it doesn't introduce any functional changes.
>
> Split it per change. One change is savedefconfig and second is removing
> or enabling other drivers.
Ok, I can do that.
>
> On which tree you generated the defconfig? There is a minor nit below
> (at least for Exynos platform, I did not checked the others).
The patch was based on torvalds/master (at v4.4-rc1), but I checked
and it applies on linux-next/master just fine.
>
> >
> > Signed-off-by: Timo Sigurdsson
> >
> > diff --git a/arch/arm/configs/multi_v7_defconfig
> > b/arch/arm/configs/multi_v7_defconfig
> > index 69a22fd..f712ea3 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
>
> (...)
>
> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
> > CONFIG_MEDIA_CONTROLLER=y
> > CONFIG_VIDEO_V4L2_SUBDEV_API=y
> > CONFIG_MEDIA_USB_SUPPORT=y
> > -CONFIG_USB_VIDEO_CLASS=y
> > -CONFIG_USB_GSPCA=y
> > +CONFIG_USB_VIDEO_CLASS=m
> > CONFIG_V4L_PLATFORM_DRIVERS=y
> > CONFIG_SOC_CAMERA=m
> > CONFIG_SOC_CAMERA_PLATFORM=m
> > @@ -465,28 +445,25 @@ CONFIG_DRM=y
> > CONFIG_DRM_I2C_ADV7511=m
> > # CONFIG_DRM_I2C_CH7006 is not set
> > # CONFIG_DRM_I2C_SIL164 is not set
> > -CONFIG_DRM_NXP_PTN3460=m
> > -CONFIG_DRM_PARADE_PS8622=m
> > CONFIG_DRM_NOUVEAU=m
> > CONFIG_DRM_EXYNOS=m
> > -CONFIG_DRM_EXYNOS_DSI=y
> > CONFIG_DRM_EXYNOS_FIMD=y
> > -CONFIG_DRM_EXYNOS_HDMI=y
>
> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
> but we are fixing it in:
> http://www.spinics.net/lists/dri-devel/msg93299.html
I think the problem here is that I don't see this patch in linux-next
yet.
Regards,
Timo
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.
While at it, clean up multi_v7_defconfig by generating a fresh file via
make multi_v7_defconfig
make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.
Signed-off-by: Timo Sigurdsson
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..f712ea3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,7 +12,6 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_CMDLINE_PARTITION=y
CONFIG_ARCH_VIRT=y
-CONFIG_ARCH_ALPINE=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_375=y
@@ -20,6 +19,7 @@ CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_39X=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_MACH_DOVE=y
+CONFIG_ARCH_ALPINE=y
CONFIG_ARCH_AT91=y
CONFIG_SOC_SAMA5D2=y
CONFIG_SOC_SAMA5D3=y
@@ -27,9 +27,9 @@ CONFIG_SOC_SAMA5D4=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_CYGNUS=y
CONFIG_ARCH_BCM_NSP=y
-CONFIG_ARCH_BCM_21664=y
-CONFIG_ARCH_BCM_281XX=y
CONFIG_ARCH_BCM_5301X=y
+CONFIG_ARCH_BCM_281XX=y
+CONFIG_ARCH_BCM_21664=y
CONFIG_ARCH_BRCMSTB=y
CONFIG_ARCH_BERLIN=y
CONFIG_MACH_BERLIN_BG2=y
@@ -39,9 +39,9 @@ CONFIG_ARCH_DIGICOLOR=y
CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_HISI=y
CONFIG_ARCH_HI3xxx=y
-CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_HIP01=y
CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_KEYSTONE=y
CONFIG_ARCH_MESON=y
CONFIG_ARCH_MXC=y
@@ -53,8 +53,9 @@ CONFIG_SOC_IMX6SL=y
CONFIG_SOC_IMX6SX=y
CONFIG_SOC_IMX6UL=y
CONFIG_SOC_IMX7D=y
-CONFIG_SOC_VF610=y
CONFIG_SOC_LS1021A=y
+CONFIG_SOC_VF610=y
+CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y
@@ -62,7 +63,6 @@ CONFIG_SOC_AM33XX=y
CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_MSM8X60=y
CONFIG_ARCH_MSM8960=y
CONFIG_ARCH_MSM8974=y
@@ -94,30 +94,22 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
CONFIG_ARCH_TEGRA_3x_SOC=y
CONFIG_ARCH_TEGRA_114_SOC=y
CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
CONFIG_ARCH_UNIPHIER=y
CONFIG_ARCH_U8500=y
CONFIG_MACH_HREFV60=y
CONFIG_MACH_SNOWBALL=y
-CONFIG_MACH_UX500_DT=y
CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_ARCH_VEXPRESS_TC2_PM=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-CONFIG_PCI=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_KEYSTONE=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MVEBU=y
CONFIG_PCI_TEGRA=y
CONFIG_PCI_RCAR_GEN2=y
CONFIG_PCI_RCAR_GEN2_PCIE=y
-CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_KEYSTONE=y
CONFIG_SMP=y
CONFIG_NR_CPUS=16
-CONFIG_HIGHPTE=y
CONFIG_CMA=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -125,12 +117,12 @@ CONFIG_KEXEC=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
-CONFIG_NEON=y
-CONFIG_KERNEL_MODE_NEON=y
CONFIG_ARM_ZYNQ_CPUIDLE=y
CONFIG_ARM_EXYNOS_CPUIDLE=y
+CONFIG_KERNEL_MODE_NEON=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -148,13 +140,10 @@ CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
CONFIG_CAN_AT91=m
+CONFIG_CAN_SUN4I=y
CONFIG_CAN_XILINXCAN=y
CONFIG_CAN_MCP251X=y
-CONFIG_CAN_SUN4I=y
CONFIG_BT=m
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
@@ -188,10 +177,8 @@ CONFIG_ATMEL_SSC=m
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y
@@ -202,10 +189,10 @@ CONFIG_SATA_HIGHBANK=y
CONFIG_SATA_MV=y
CONFIG_SATA_RCAR=y
CONFIG_NETDEVICES=y
-CONFIG_HIX5HD2_GMAC=y
CONFIG_SUN4I_EMAC=y
CONFIG_MACB=y
CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_HIX5HD2_GMAC=y
CONFIG_IGB=y
CONFIG_MV643XX_ETH=y
CONFIG_MVNETA=y
@@ -223,7 +210,6 @@ CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_MICREL_PHY=y
-CONFIG_FIXED_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8152=m
CONFIG_USB_USBNET=y
@@ -239,18 +225,18 @@ CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_CYAPA=m
CONFIG_MOUSE_ELAN_I2C=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=y
+CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_TOUCHSCREEN_ST1232=m
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_TOUCHSCREEN_SUN4I=y
-CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MPU3050=y
CONFIG_INPUT_AXP20X_PEK=y
@@
[PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.
While at it, clean up sunxi_defconfig by generating a fresh file via
make sunxi_defconfig
make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.
Signed-off-by: Timo Sigurdsson
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..904ea52 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
CONFIG_VFP=y
CONFIG_NEON=y
-CONFIG_PM=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
@@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=8
@@ -123,6 +119,8 @@ CONFIG_PWM=y
CONFIG_PWM_SUN4I=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. Also
add board-specific OPP to use slightly higher voltages at lower
frequencies since Kevin Hilman reported that not all BananaPi boards run
stable at the default voltages inherited by sun7i-a20.dtsi.
Signed-off-by: Timo Sigurdsson
---
Changes since v2:
- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 45 +---
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,20 @@
status = "okay";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+ operating-points = <
+ /* kHzuV */
+ 96 140
+ 912000 140
+ 864000 135
+ 72 125
+ 528000 115
+ 312000 110
+ 144000 105
+ >;
+};
+
&ehci0 {
status = "okay";
};
@@ -119,13 +133,9 @@
status = "okay";
axp209: pmic@34 {
- compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
};
};
@@ -182,6 +192,33 @@
};
};
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "avcc";
+};
+
®_usb1_vbus {
status = "okay";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Maxime, Maxime Ripard schrieb am 07.10.2015 19:49: > Hi Timo, > > On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote: >> Hi Kevin, >> Hi Maxime, >> >> Kevin Hilman schrieb am 07.10.2015 16:36: >> >> > "Timo Sigurdsson" writes: >> >> I still think that the lower voltages may be the cause of your problem >> >> with that specific board, so could you please test the attached patch on >> >> top of my patch that you first experienced the problem with? Please let >> >> us know whether this solves your issue or whether we need to dig deeper. >> > >> > Thanks for the patch. Looks like it's the OPPs. >> > >> > I went back to next-20150923 and verified it still fails. Then, I >> > applied your patch and saw that it boots just fine. >> >> Good. Then we can easily fix this, I guess. >> >> @Maxime: How should we handle this? In its current form, the patch applies >> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi. >> In an earlier discussion, it was said that this can be done, even though it >> might not be the most elegant approach. But then again, I think it >> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20 >> boards since this is - to my knowledge - the first and only report that an >> A20 board has stability issues at the lower voltages (although not too many >> boards use voltage scaling yet). > > If you count only the number of boards, indeed, but if you count the > number of devices actually used in the field, we cover already a > significant portion of them. > >> So, would you prefer to keep this as a patch for BananaPi only, or >> change the dtsi for all A20 devices instead? > > Yeah, we probably can keep that for bananapi only at the moment, and > try to generalize that afterwards. Ok. > >> In case we keep it as it is, what is the correct commit to point to as >> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since >> that's where these voltages were defined. But then again, if we don't >> change the dtsi, should I point to my regulator patch instead? > > I don't think it fixes anything at this point. We droped your commit > that was using the A20 OPPs, so in the history so far we don't have > anything to fix, just enable cpufreq again. Ok. I'll send a third version of the regulator patch then with the updated opp included. Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Kevin, Hi Maxime, Kevin Hilman schrieb am 07.10.2015 16:36: > "Timo Sigurdsson" writes: >> I still think that the lower voltages may be the cause of your problem >> with that specific board, so could you please test the attached patch on >> top of my patch that you first experienced the problem with? Please let >> us know whether this solves your issue or whether we need to dig deeper. > > Thanks for the patch. Looks like it's the OPPs. > > I went back to next-20150923 and verified it still fails. Then, I > applied your patch and saw that it boots just fine. Good. Then we can easily fix this, I guess. @Maxime: How should we handle this? In its current form, the patch applies only to the BananaPi dts by overriding the inherited opp from the SoC dtsi. In an earlier discussion, it was said that this can be done, even though it might not be the most elegant approach. But then again, I think it shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20 boards since this is - to my knowledge - the first and only report that an A20 board has stability issues at the lower voltages (although not too many boards use voltage scaling yet). So, would you prefer to keep this as a patch for BananaPi only, or change the dtsi for all A20 devices instead? In case we keep it as it is, what is the correct commit to point to as "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since that's where these voltages were defined. But then again, if we don't change the dtsi, should I point to my regulator patch instead? Thanks and regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Kevin,
Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others. I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi. Reverting that commit on top of next-20150923
> gets my bananapi booting again.
>
> Note it's kind of an interesting boot failure. The kernel boots fully
> to a shell, but panics after running a few commands. In particular
> 'dmesg -n1' seems to trigger it usually[2].
>
> Kevin
>
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
following up on my last email: I'm back from my vacation and I tried to
reproduce your problem, but my board doesn't seem to be affected, so I
cannot trigger it.
I still think that the lower voltages may be the cause of your problem
with that specific board, so could you please test the attached patch on
top of my patch that you first experienced the problem with? Please let
us know whether this solves your issue or whether we need to dig deeper.
Has anybody else been able to reproduce Kevin's issue?
Kind regards,
Timodiff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 74382f3..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -94,6 +94,16 @@
&cpu0 {
cpu-supply = <®_dcdc2>;
+ operating-points = <
+ /* kHz uV */
+ 96 140
+ 912000 140
+ 864000 135
+ 72 125
+ 528000 115
+ 312000 110
+ 144000 105
+ >;
};
&ehci0 {
--
2.1.4
Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Kevin, Kevin Hilman schrieb am 25. Sept 2015 01:57: > On Tue, Aug 18, 2015 at 8:36 AM, Maxime Ripard > wrote: >> On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote: >>> sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 >>> PMU >>> driver, so add them to allow for voltage-scaling with cpufreq-dt. >>> >>> Signed-off-by: Timo Sigurdsson >> >> Queued, thanks! >> Maxime > > kernelci.org started finding boot faiulres[1] on bananapi linux-next > around next-20150918, but it was only failing in some labs and not > others. I finally bisected it down to this patch, which landed in > linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators > for LeMaker BananaPi. Reverting that commit on top of next-20150923 > gets my bananapi booting again. > > Note it's kind of an interesting boot failure. The kernel boots fully > to a shell, but panics after running a few commands. In particular > 'dmesg -n1' seems to trigger it usually[2]. > > Kevin > > [1] > http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f > [2] > http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html > Thanks for your feedback. I'm traveling at the moment, so I can't do any testing but just guess wildly. I know, though, that I used dmesg frequently when I did my own testing before submitting the patch and could not see such behavior. Before this commit, the CPU of your BananaPi runs at 1.4 volts constantly. With this commit applied, the CPU voltage should vary between 1.0-1.4 volts depending on the frequency and defined operating points. Hence, one of my guesses would be that your CPU is not stable at the lower voltages. Could you modify the voltages for the defined frequencies in sun7i-a20.dtsi and test if that solves your issue? Say, raise the voltage by 0.1 volts for each operating point (but no higher than 1.4). I actually had a different patch that applied slightly higher voltages taken from the original fex for by LeMaker, but the feedback was, unless there are actual reports about boards not running stable at the current settings, we just keep them instead. So, I'm curious if you happen to have a board that requires slightly higher voltages to run stable. Regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications
sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise the voltage for the lowest operating point to 1.0 volts in order to stay within the SoC specifications. It is an undervolted setting that isn't stable across all SoCs and boards out there. Signed-off-by: Timo Sigurdsson --- Changes since v1: - Fixed checkpatch warnings - Changed the commit message and title to clarify that this is not a board-specific issue, but rather a limitation by the SoC --- arch/arm/boot/dts/sun7i-a20.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index 6a63f30..f5f384c 100644 --- a/arch/arm/boot/dts/sun7i-a20.dtsi +++ b/arch/arm/boot/dts/sun7i-a20.dtsi @@ -107,7 +107,7 @@ 72 120 528000 110 312000 100 - 144000 90 + 144000 100 >; #cooling-cells = <2>; cooling-min-level = <0>; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Maxime, Maxime Ripard schrieb am 03.08.2015 11:47: > What regulator provides the 3.3V regulator used in the rest of this DT > then (MMC, GMAC) ? For GMAC, there is a reg_gmac_3v3 defined in sun7i-a20-bananapi.dts [1]. MMC uses reg_vcc3v3 included from sunxi-common-regulators.dtsi. Am I missing something? Is this not sufficient? Thanks, Timo [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=v4.2-rc5#n78 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Maxime, Maxime Ripard schrieb am 03.08.2015 11:34: > On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote: >> Julian Calaby schrieb am 03.08.2015 06:22: >> > My only real objection here is are there boards that can go down to >> > 0.9v and if so, won't this change make them less power efficient in >> > the almost-idle case? And are those power savings enough to justify >> > not accepting this patch? >> >> It will probably make those boards less power efficient, yes. On the >> other hand, boards that have their CPU regulator set to min. 1.0V might >> also draw more power because the lowest frequency is not available, >> even though the savings due to frequency are likely to be lower than >> the savings due to voltage. > > Guys, isn't this whole discussion a bit moot? We're not doing any kind > of power management but cpufreq, so maybe there's a lot more to do > before we actually can have these kind of arguments? > > Plus this OPP has never been used anyway, so this patch is not going > to increase the power consumption either. You are right. When I wrote that, I was under the impression that the Olinuxino Lime 2 board at least used this setting since it has has a cpu regulator defined to go as low as 0.7V. But now I checked again and see the regulator is not referenced in the cpu node, so I guess cpufreq doesn't use it. So, this discussion was really hypothetical and more importantly, as you mentioned, it's an out-of-spec opp that shouldn't be supported anyway. Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Maxime, Maxime Ripard schrieb am 03.08.2015 11:13: > On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote: >> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 >> boards >> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise >> the >> voltage for the lowest operating point to 1.0V so all boards can actually use >> it. > > This is not a property of a board, but is the actual limit documented > by Allwinner for the A20. Some individual SoCs might have wider > tolerances, but that's not a property of a board, it's really a > property of a single SoC, and we cannot make any assumption on the > board. Thanks for the clarification. That was a misunderstanding on my side. I can update the commit message in a second version of the patch, but the actual code change can be kept as is then, I guess. > (and please make sure to run checkpatch before sending your patches) Sorry about that. Will do when I post a second version of the patch. Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi again, Julian Calaby schrieb am 03.08.2015 06:22: > My only real objection here is are there boards that can go down to > 0.9v and if so, won't this change make them less power efficient in > the almost-idle case? And are those power savings enough to justify > not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. However, Stefan Monnier (added to CC) mentioned in an earlier discussion that the savings for the lowest opp are rather small and thus the benefit of the 144MHz opp would be questionable. Unfortunately, I don't have measurement equipment precise enough to test this myself and haven't found a way to read power consumption internally via the PMU in mainline yet. Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Julian, Julian Calaby schrieb am 03.08.2015 01:35: >> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 >> boards >> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise >> the >> voltage for the lowest operating point to 1.0V so all boards can actually use >> it. > > Surely it wouldn't be added here if some could supply 0.9v. Maybe. I just know some boards don't (e.g. Cubieboard 2, Cubietruck, BananaPi) and don't know of any that does. But that's not my point. I think that a common minimum operating point, defined on the SOC level, should be defined in a way that works on all boards. > > Is the code that uses this smart enough to sensibly switch between two > operating points with the same frequency and different voltages? If > so, maybe just add a 144MHz @ 1.0v operating point? I never tried and I probably won't have time to test that before the weekend. The current behaviour is this, though: On boards that set their minimum CPU voltage to 1.0V, the lowest operating point will simply not be available to the user. > (Alternatively, would it make sense to modify the code that uses this > to use frequencies with voltages specified that are lower than can be > supplied with the lowest voltage it can?) Considering OPPv2 is in the works, maybe not? Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi Stefan, you didn't include me in your answer, hence the late reply... Stefan Monnier schrieb am 29.07.2015 02:02: >> IMHO for a common maximum opp that's a good approach. But for the lowest >> frequency setting, it would seem more logical to me, to raise the voltage >> to a point where all boards will run fine with them, unless those boards >> cannot handle the frequency regardless of the higher voltage. > I generally agre, tho IIRC some measurements seem to indicate that the > lowest frequency settings did not bring much (if any) reduction in power > consumption, making them rather useless. That's an interesting point. However, that would be a different discussion. I wouldn't mind if the 144MHz would be removed - my point was just that if it's supposed to be a common setting, it should work on all boards. I posted a patch today to fix this. [1] That might be a good place to discuss whether this setting should be removed entirely. Regards, Timo [1] https://groups.google.com/forum/#!topic/linux-sunxi/fIfbdn7mrQA -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Signed-off-by: Timo Sigurdsson --- arch/arm/boot/dts/sun7i-a20.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index 6a63f30..f5f384c 100644 --- a/arch/arm/boot/dts/sun7i-a20.dtsi +++ b/arch/arm/boot/dts/sun7i-a20.dtsi @@ -107,7 +107,7 @@ 72 120 528000 110 312000 100 - 144000 90 + 144000 100 >; #cooling-cells = <2>; cooling-min-level = <0>; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt.
Signed-off-by: Timo Sigurdsson
---
Changes since v1 (RFC):
- Dropped the changes to the cpufreq operating points and renamed the patch
accordingly
- Limited the CPU voltage range so it doesn't exceed the SOC specifications
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 35
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..74382f3 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,10 @@
status = "okay";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci0 {
status = "okay";
};
@@ -119,13 +123,9 @@
status = "okay";
axp209: pmic@34 {
- compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
};
};
@@ -182,6 +182,33 @@
};
};
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "avcc";
+};
+
®_usb1_vbus {
status = "okay";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Hans de Goede schrieb am 28.07.2015 16:24: > I've no problem with Timo submitting a cleaned up version of his > patch and you taking that instead. I just wanted to point out that > I do have a similar patch pending. Ok, I will do that. It might take a couple of days, though, as I will be moving moving in the next few days as well. However, another question first then: What maximum voltage for the dcdc2 regulator should we use then? You used 1.5V, I used 1.45V so far, which is what Cubieboard 2 and Cubietruck use. But after the discussion about overvoltaged settings, I'm wondering whether we should limit the regulartor (and not only the opp) to 1.40V as well? Or is 1.45V ok for everybody here? Thanks and regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:55: >> IMHO for a common maximum opp that's a good approach. But for the lowest >> frequency setting, it would seem more logical to me, to raise the voltage >> to a point where all boards will run fine with them, unless those boards >> cannot handle the frequency regardless of the higher voltage. > > Agreed. Ok, then I will write another patch for this as well, unless Chen-Yu or someone else objects. Regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:55: >> > I plan to submit this for 4.3. >> >> Ok, then I guess we can drop my patch. > > Please don't. Ok. > It was used in mainline, and reverted because it was not stable > enough. Well, the explanation given was, it was not stable because of the missing regulator support. I don't know whether anyboady actually ever reported it wouldn't run fine at 1008MHz with 1.45V. So the actual point should be whether we wan't voltages that are out of the specified range in the official kernel. The consensus seems to be no, with good reasons for that. So, I won't object this. > There's a lot of things we do differently in mainline, it's one of > them. If someone can provide an OPP for 1008MHz that is stable for all > the boards and within the operating limits of the SoC, I'd be totally > fine with that, but we didn't find it so far. > >> For those who don't want to use that setting, it's easier to >> limit the maximum in userspace compared to compiling a new device >> tree blob. > > Except that the kernel should not rely on the userspace to be stable > and harmless for the hardware. It should just work reliably by itself. Same as above. Regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:49: > I don't feel like holding patches that were posted before you did > because you did them some time ago and never submitted them is > reasonnable and / or encouraging for new submitters of patches. > > I'd really like to get more sunxi-people contributing, and that starts > with that kind of trivial stuff. Holding them back because one of the > usual (and experienced) developpers is a bit counter-productive (and > I'm sure you still have a lot of patches to submit anyway ;)). Just for the record: I wouldn't be discouraged by that. The only thing that matters to me here is that regulator support will be added, regardless of who submitted the patch. But anyway, I will rework the patch along the statements made during this discussion. Regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Chen-Yu Tsai schrieb am 27.07.2015 15:14: >> ChenYu (in the CC), since you did most of the original work here, do >> you know why we have an op at 0.9 volt, but none of our boards allow the >> voltage to go that low in the regulator settings ? > > I'm on vacation now, so apologies for the bad formatting. > > The OPPs are from a common subset > of the settings from the fex files available > at the time. Some fex files actually set > min and max voltage thus eliminating > the highest and lowest OPPs. > > At least that is how Maxime and I > interpreted them. IMHO for a common maximum opp that's a good approach. But for the lowest frequency setting, it would seem more logical to me, to raise the voltage to a point where all boards will run fine with them, unless those boards cannot handle the frequency regardless of the higher voltage. Regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Hans de Goede schrieb am 27.07.2015 14:43: >>> I've a simular patch here: >>> >>> https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1 >>> >>> I did not submit this upstream yet as it is part of a series to enable the >>> otg >>> controller on the bananapi which needs axp-usb-power-supply support for >>> which >>> the actual powersupply driver changes are still pending. >> Oops, I see. Are you planning to submit this for 4.3 or later? > > I plan to submit this for 4.3. Ok, then I guess we can drop my patch. >>> IMHO we should just stick with the standard operating points unless we know >>> that there are stability issues with them (such as e.g. on the A10 OlinuxIno >>> Lime). >> I'd be fine with that as I don't have any stability issues with the lower >> voltages. What about the 1008MHz operating point that I "reintroduced"? It >> was >> dropped here [1] because there was no regulator support. > > That is in essence an overclocked setting, the max CPU voltage officially is > 1.4V, I do not think that we should provide any overclocked settings in the > official dts files. If people really want to overclock they will have to > modify there dts themselves IMHO. Personally, I would be fine with that. Even though I think, it might be good to have them in the official files just for convenience and because people who are used to the sunxi-3.4 kernels are used to having the 1008MHz opp (and it was in mainline for a short while, too). For those who don't want to use that setting, it's easier to limit the maximum in userspace compared to compiling a new device tree blob. But I do understand your point, so I guess it's just something that maintainers have to make a decision for. As I said, either way is fine for me. > > Can this be reenabled >> on board level (which means overriding the defaults inherited from >> sun7i-a20.dtsi) or should this be done at SOC level for all boards (which >> means we have to add regulator nodes for all boards in the first place)? > > Technically this is possible, but I do not think that it is a good idea. I guess the same applies here, too. It's something maintainers should have a common understanding on. I don't know how much variation there is among the A20 boards in terms of frequencies and voltages. If there is a lot, I'd say it would be desireable to have board-specific opp. The downside I see in my approach is that it impacts readability of the dts(i) files when settings are overridden further down the tree. Thanks and regards, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. With the
regulators enabled, we can define board-specific operating points. The defined
CPU voltages are more conservative (based on the values used by the vendor),
so they should be more failsafe across all boards of this kind out there.
I'm posting this as RFC as I would like to make a few more remarks and raise
questions along the way (plus, I'm anything but an experienced developer, so a
a critical review might help).
I checked the regulator definitions against the schematics released by LeMaker.
I also compared that to the DT and schematics of Cubiboard 2 and Cubietruck. Of
course, I also tested the patch on the actual hardware and it works fine for me.
The CPU voltages are slightly higher than those set in sun7i-a20.dtsi and even
though they work well for me, I thought it might be safer to use the more
conservative values used by LeMaker in their old fex file. Would you agree?
Besides, it it ok to have this in one patch or should it be splitted in two
(one for the regulators and one for the opp)? Did I miss something important?
Signed-off-by: Timo Sigurdsson
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 47 +---
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..2bcbb0e 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,22 @@
status = "okay";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+ operating-points = <
+ /* kHzuV */
+ 1008000 145
+ 96 1425000
+ 912000 1425000
+ 864000 135
+ 72 125
+ 528000 115
+ 312000 110
+ 144000 105
+ >;
+ cooling-max-level = <7>;
+};
+
&ehci0 {
status = "okay";
};
@@ -119,13 +135,9 @@
status = "okay";
axp209: pmic@34 {
- compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
};
};
@@ -182,6 +194,33 @@
};
};
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <105>;
+ regulator-max-microvolt = <145>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "avcc";
+};
+
®_usb1_vbus {
status = "okay";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/7] Watchdog: introduce "pretimeout" into framework
On 22.05.2015 13:46, Fu Wei wrote: Hi Timo, On 22 May 2015 at 16:59, Timo Kokkonen wrote: On 22.05.2015 11:23, Fu Wei wrote: Hi Timo, On 22 May 2015 at 14:30, Timo Kokkonen wrote: On 21.05.2015 11:32, fu@linaro.org wrote: From: Fu Wei Also update Documentation/watchdog/watchdog-kernel-api.txt to introduce: (1)the new elements in the watchdog_device and watchdog_ops struct; (2)the new API "watchdog_init_timeouts". Reasons: (1)kernel already has two watchdog drivers are using "pretimeout": drivers/char/ipmi/ipmi_watchdog.c drivers/watchdog/kempld_wdt.c(but the definition is different) (2)some other dirvers are going to use this: ARM SBSA Generic Watchdog Hi, As I was proposing some other API changes with my early-timeout-sec work, I can see my work is going to collide with your API change proposal a bit. So maybe I should ask your opinion as well.. Thank you for reminding me of that, I saw "early-timeout-sec", but because I don't get it in kernel API or watchdog_core.c, so I did not pay attention to it. Sorry. Could this pretimeout feature be something that other drivers could benefit too? yes , as you may know, I am making a patch for pretimeout support in watchdog framework I can see that it does not do anything else except call panic() before letting the watchdog expire. This is something that could be emulated easily by the watchdog core for drivers that don't know anything about pretimeouts at all. For SBSA watchdog, there are two stage timeout, and according to kernel doc: -- Pretimeouts: Some watchdog timers can be set to have a trigger go off before the actual time they will reset the system. This can be done with an NMI, interrupt, or other mechanism. This allows Linux to record useful information (like panic information and kernel coredumps) before it resets. -- I think panic() is the right way to do now. but people may also need to config : PANIC_TIMEOUT [!=0] KEXEC KDUMP for debug reason Yes, so basically if we hit pretimeout, we probably have already crashed. yes, for now , I only use panic(), but at the beginning, I offer user some options: https://lists.linaro.org/pipermail/linaro-acpi/2015-April/004350.html The only difference is that we now have some seconds time to dump out useful data and then either reboot or let the actual watchdog reset take care of resetting the device. panic() sounds like a good thing to do. Maybe you could also dump registers on other CPUs too or try to get out some other useful information about the kernel in case it has crashed or something. But I'm just guessing. yes, that is my thought. because there is the kdump support in panic(), so that can give use a chance to figure out why the watchdog wasn't fed. Yes indeed, sounds good! The way I was planning the API change there would need to be a small change with each watchdog driver in order to let the watchdog core take over generic behaviour on behalf of the driver. My goal was to make the change so that each driver that gets converted to the new API extensions gets a support for early-timeout-sec for free, without needing to enable support for it any way. If the API was designed properly, also pretimeouts could be handled easily and maybe even so that other drivers could have that feature even though their hardware does not explicitly give any support for it. could you please point out your patch , then I can learn your idea :-) For now , I am working on a common "Pretimeouts" following the concept in kernel doc. Any thoughts? my thoughts is in my pretimeout patch , would you provide some suggestion ? Here is an archive link to my patch set: http://www.spinics.net/lists/linux-watchdog/msg06473.html Ah , cool, I can see some common in your patch. Thanks :-) See if I can learn something from your patches Your patch set is adding a new call to the core for adjusting the pretimoeut, which is probably a good thing in case the driver needs special handling for it anyway. But if the core had capability to emulate pretimeout for drivers that can't support it in hardware, it would be good if there was a way for the core to support it even though the driver had zero code for it. The core also has watchdog_init_timeout() right now but even that is not called from that many drivers. I would like to fix that too so that drivers would not need to bother so much about it but let core take care of it more. This is why I proposed the watchdog_init_params() call that could dig all the generic parameters from device tree on behalf of the driver. This is where I though timeout and early-timeout-sec parameters would be parsed from device tree, but it could also parse pretimeout parameter as well. Apparently Guenter did not like my approach so we might need some other way to do it. I am using pretimeout, because SBSA watchd
Re: [PATCH v2 5/7] Watchdog: introduce "pretimeout" into framework
On 22.05.2015 11:23, Fu Wei wrote: Hi Timo, On 22 May 2015 at 14:30, Timo Kokkonen wrote: On 21.05.2015 11:32, fu@linaro.org wrote: From: Fu Wei Also update Documentation/watchdog/watchdog-kernel-api.txt to introduce: (1)the new elements in the watchdog_device and watchdog_ops struct; (2)the new API "watchdog_init_timeouts". Reasons: (1)kernel already has two watchdog drivers are using "pretimeout": drivers/char/ipmi/ipmi_watchdog.c drivers/watchdog/kempld_wdt.c(but the definition is different) (2)some other dirvers are going to use this: ARM SBSA Generic Watchdog Hi, As I was proposing some other API changes with my early-timeout-sec work, I can see my work is going to collide with your API change proposal a bit. So maybe I should ask your opinion as well.. Thank you for reminding me of that, I saw "early-timeout-sec", but because I don't get it in kernel API or watchdog_core.c, so I did not pay attention to it. Sorry. Could this pretimeout feature be something that other drivers could benefit too? yes , as you may know, I am making a patch for pretimeout support in watchdog framework I can see that it does not do anything else except call panic() before letting the watchdog expire. This is something that could be emulated easily by the watchdog core for drivers that don't know anything about pretimeouts at all. For SBSA watchdog, there are two stage timeout, and according to kernel doc: -- Pretimeouts: Some watchdog timers can be set to have a trigger go off before the actual time they will reset the system. This can be done with an NMI, interrupt, or other mechanism. This allows Linux to record useful information (like panic information and kernel coredumps) before it resets. -- I think panic() is the right way to do now. but people may also need to config : PANIC_TIMEOUT [!=0] KEXEC KDUMP for debug reason Yes, so basically if we hit pretimeout, we probably have already crashed. The only difference is that we now have some seconds time to dump out useful data and then either reboot or let the actual watchdog reset take care of resetting the device. panic() sounds like a good thing to do. Maybe you could also dump registers on other CPUs too or try to get out some other useful information about the kernel in case it has crashed or something. But I'm just guessing. The way I was planning the API change there would need to be a small change with each watchdog driver in order to let the watchdog core take over generic behaviour on behalf of the driver. My goal was to make the change so that each driver that gets converted to the new API extensions gets a support for early-timeout-sec for free, without needing to enable support for it any way. If the API was designed properly, also pretimeouts could be handled easily and maybe even so that other drivers could have that feature even though their hardware does not explicitly give any support for it. could you please point out your patch , then I can learn your idea :-) For now , I am working on a common "Pretimeouts" following the concept in kernel doc. Any thoughts? my thoughts is in my pretimeout patch , would you provide some suggestion ? Here is an archive link to my patch set: http://www.spinics.net/lists/linux-watchdog/msg06473.html Your patch set is adding a new call to the core for adjusting the pretimoeut, which is probably a good thing in case the driver needs special handling for it anyway. But if the core had capability to emulate pretimeout for drivers that can't support it in hardware, it would be good if there was a way for the core to support it even though the driver had zero code for it. The core also has watchdog_init_timeout() right now but even that is not called from that many drivers. I would like to fix that too so that drivers would not need to bother so much about it but let core take care of it more. This is why I proposed the watchdog_init_params() call that could dig all the generic parameters from device tree on behalf of the driver. This is where I though timeout and early-timeout-sec parameters would be parsed from device tree, but it could also parse pretimeout parameter as well. Apparently Guenter did not like my approach so we might need some other way to do it. I don't get to say how this should be done, I'm just throwing ideas here. But I think the watchdog core would be a lot better place for implementing the generic features than drivers. That way a lot of drivers could enable support the new features for free. Thanks, -Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/7] Watchdog: introduce "pretimeout" into framework
On 21.05.2015 11:32, fu@linaro.org wrote: From: Fu Wei Also update Documentation/watchdog/watchdog-kernel-api.txt to introduce: (1)the new elements in the watchdog_device and watchdog_ops struct; (2)the new API "watchdog_init_timeouts". Reasons: (1)kernel already has two watchdog drivers are using "pretimeout": drivers/char/ipmi/ipmi_watchdog.c drivers/watchdog/kempld_wdt.c(but the definition is different) (2)some other dirvers are going to use this: ARM SBSA Generic Watchdog Hi, As I was proposing some other API changes with my early-timeout-sec work, I can see my work is going to collide with your API change proposal a bit. So maybe I should ask your opinion as well.. Could this pretimeout feature be something that other drivers could benefit too? I can see that it does not do anything else except call panic() before letting the watchdog expire. This is something that could be emulated easily by the watchdog core for drivers that don't know anything about pretimeouts at all. The way I was planning the API change there would need to be a small change with each watchdog driver in order to let the watchdog core take over generic behaviour on behalf of the driver. My goal was to make the change so that each driver that gets converted to the new API extensions gets a support for early-timeout-sec for free, without needing to enable support for it any way. If the API was designed properly, also pretimeouts could be handled easily and maybe even so that other drivers could have that feature even though their hardware does not explicitly give any support for it. Any thoughts? Thanks, -Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Window watchdog driver design
Hi Andy, On 15.05.2015 08:43, Andreas Werner wrote: On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote: On 05/14/2015 07:09 AM, Andreas Werner wrote: On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote: On 05/14/2015 04:56 AM, Andreas Werner wrote: Hi, in the next few weeks I need to write a driver for a window wachtdog implemented in a CPLD. I have some questions about the design of the driver and the best way to write this driver to also be able to submit it. The triggering and configuration of the Watchdog is done by several GPIOs which are connected to the CPLD watchdog device. The correct GPIOs are configurable using the Device Tree. 1. Timeout The timeout values are defined in ms and start from 20ms to 2560ms. The timout is set by 3 GPIOs this means we have only 8 different timout values. It is also possible that a future Watchdog CPLD device does have different timeout values. Is it possible to set ms timeouts? It seems that the WDT API does only support a resolution of 1sec. One idea would be to use the API timeout as something like a timeout index to set the different values. Of course this needs to be documented. e.g. timeout (API) timeout in device 1 20ms 2 100ms 3 500ms ... ... 2. Upper/Lower Window There is currently no support for a windowed watchdog in the wdt core. The lower window can be activated by a gpio and its timeout is defined as "upper windows timeout/4" What is the best way to implement those additional settings? Adding additional ioctl or export these in sysfs? -- Sorry for the maybe dumb question, but what is a window watchdog, and what is the lower window timeout for (assuming the upper window timeout causes the watchdog to expire) ? Guenter Oh sorry forgot to describe it in more detail. If you have a watchdog window you do not have just one timeout where the watchdog can expire. You have a so called "window" to trigger it within. |<trig>| ---lower timeoutupper timeout This means you have to trigger the watchdog not to late and not to early. This kind of watchdog is often used in embedded applications or more often in safety cases to fullfil requirements given e.g. by SIL1-SIL4 certifications. The lower timeout is set by a dedicated GPIO and the value will then "Upper timeout / 4". The upper timeout is set by 3 GPIOs to get different timeout values. Thanks a lot for the explanation. I would suggest to use a module parameter to enable the "lower timeout" functionality. Timeouts have to be specified in seconds. Hope this helps, Guenter Thanks for the answer. The module parameter would be ok for me, but it would be better if i can enable/disable the lower window by the application. I know that the API defines the timout in seconds but what about ms? Is there no watchdog out there which has timout values < seconds?. There are a few. But the user space api specifies the timeout in seconds so you can't really do anything about it as long as you wish to remain compatible with the current watchdog API. I am working on extending the kernel watchdog core api so that the driver would fill in hw_max_timeout parameter that tells the core the maximum supported timeout in HW. I was thinking that millisecond resolution would be good for this. Also there are already at least one watchdog driver (Atmel's at91sam9_wdt.c) that has already concept of "minimum watchdog timeout" in a sense that pinging the watchdog too often is considered to be a failure. This is also something that is not handled with the current watchdog api at all. As I am working on changing the core so that it takes over more of the generic watchdog behaviour and work around watchdog hardware constraints so that user space does not need to know about them, I am interested in hearing opinions about how I should care this kind of constraints. Right now I am not trying to "fix" an user space daemon behaviour where the daemon is pinging more often than what is allowed by the hardware. I don't know if that is something what the watchdog core should be doing or not. I can't think why it would be bad if watchdog daemon pings the hardware too often and why it should be considered as a failure. Therefore I can't think where one should think the failure to be in such case. Right now I am assuming that kernel should not try to be clever about minimum ping interval at all. But as there clearly are hardware that has this kind of window definition, I'm sure there should be some kind of software support for it too. I'm open to hear more about it. -Timo In my case I can only set 2 timou
Re: [PATCH] Btrfs: prevent deletion of mounted subvolumes
Hi,
On 01.04.2015 10:03, Omar Sandoval wrote:
On Tue, Mar 31, 2015 at 10:54:55PM -0500, Eric W. Biederman wrote:
Omar Sandoval writes:
On Mon, Mar 30, 2015 at 02:30:34PM +0200, David Sterba wrote:
On Mon, Mar 30, 2015 at 02:02:17AM -0700, Omar Sandoval wrote:
Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
d_invalidate() could return -EBUSY when a dentry for a directory had
more than one reference to it. This is what prevented a mounted
subvolume from being deleted, as struct vfsmount holds a reference to
the subvolume dentry. However, that commit removed that case, and later
commits in that patch series removed the return code from d_invalidate()
completely, so we don't get that check for free anymore. So, reintroduce
it in btrfs_ioctl_snap_destroy().
This applies to 4.0-rc6. To be honest, I'm not sure that this is the most
correct fix for this bug, but it's equivalent to the pre-3.18 behavior and it's
the best that I could come up with. Thoughts?
+ spin_lock(&dentry->d_lock);
+ err = dentry->d_lockref.count > 1 ? -EBUSY : 0;
+ spin_unlock(&dentry->d_lock);
The fix restores the original behaviour, but I don't think opencoding and
using internals is fine. Either there should be a vfs api for that or
there's an existing one that can be used instead.
I have a problem with restoring the original behavior as is.
In some sense it re-introduces the security issue that the d_invalidate
changes were built to fix.
Any user in the system can create a user namespace, create a mount
namespace and keep any subvolume pinned forever. Which at the very
least could make a very nice DOS attack. I am not familiar enough with
how people use subvolumes and
So let me ask. How can userspace not know that a subvolume that they
want to delete is already mounted?
Currently, the entry in /proc/mounts doesn't tell you which subvolume is
mounted. The fix for that could be as simple as:
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 05fef19..9492d83 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1024,6 +1024,10 @@ static int btrfs_show_options(struct seq_file *seq,
struct dentry *dentry)
struct btrfs_root *root = info->tree_root;
char *compress_type;
+ if (dentry != dentry->d_sb->s_root) {
+ seq_puts(seq, ",subvol=");
+ seq_dentry(seq, dentry, " \t\n\\");
+ }
if (btrfs_test_opt(root, DEGRADED))
seq_puts(seq, ",degraded");
if (btrfs_test_opt(root, NODATASUM))
Then, maybe this policy could be pushed up to userspace. It feels
awkward to do it in the kernel, but users are apparently depending on
this behavior. Timo, do you mind sharing some more details about how
your scripts ran into the bug?
We are choosing the active subvolume via kernel command line parameter, eg:
root=/dev/mmcblk0p3 rw rootwait rootflags=subvol=/foobar
In the user space we run a script that does some upgrades on the root
file system and in the process creates new subvolumes and deletes old
ones. For this to work we mount the root subvolume "eg. /" onto
somewhere so we can take a new snapshot from the currently active
subvolume, eg.
mount /dev/mmcblk0p3 /mnt/root
btrfs subvolume snapshot /mnt/root/foobar /mnt/root/new_foobar
btrfs subvolume delete /mnt/root/old_foobar
and such. But if it happens that user gives faulty names for the
subvolumes to operate with, the script might delete the subvolume that
is the same where the device root file system is mounted from. That is,
there is not anything anymore that prevents user from running this command:
btrfs subvolume delete /mnt/root/foobar
Once you delete the this subvolume, things obviously collapse into halt
pretty soon as the userspace expects "/" to be present on the system.
That is something that is obviously wrong thing for the user to do to
begin with, easily avoidable with more careful scripting. But I can
think this is very bad if the user is doing root file system snapshot
management by hand and might easily delete his mounted root file system
by accident. And I can't think of any reason why kernel should allow
user to do this.
I hope this clears up things a bit.
-Timo
I can see having something like is_local_mount_root and denying the
subvolume destruction if the mount that is pinning it is in your local
mount namespace.
The bug here seems defined up to the point that we're trying to delete a
subvolume that's a mountpoint. My next guess is that a check
if (d_mountpoint(&dentry)) { ... }
could work.
That was my first instinct as well, but d_mountpoint() is true for
dentries that have a filesystem mounted on them (e.g., after mount
/dev/sda1 /mnt, the dentry for "/mnt"), not the dentry that is mounted.
I poked around the mount c
Re: [PATCH] Btrfs: prevent deletion of mounted subvolumes
On 30.03.2015 12:02, Omar Sandoval wrote:
Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
d_invalidate() could return -EBUSY when a dentry for a directory had
more than one reference to it. This is what prevented a mounted
subvolume from being deleted, as struct vfsmount holds a reference to
the subvolume dentry. However, that commit removed that case, and later
commits in that patch series removed the return code from d_invalidate()
completely, so we don't get that check for free anymore. So, reintroduce
it in btrfs_ioctl_snap_destroy().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93021
Reported-by: Timo Kokkonen
Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate")
Signed-off-by: Omar Sandoval
Tested-by: Timo Kokkonen
Thank you
-Timo
---
This applies to 4.0-rc6. To be honest, I'm not sure that this is the most
correct fix for this bug, but it's equivalent to the pre-3.18 behavior and it's
the best that I could come up with. Thoughts?
fs/btrfs/ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 74609b9..39b0538 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2384,6 +2384,12 @@ static noinline int btrfs_ioctl_snap_destroy(struct file
*file,
goto out_dput;
}
+ spin_lock(&dentry->d_lock);
+ err = dentry->d_lockref.count > 1 ? -EBUSY : 0;
+ spin_unlock(&dentry->d_lock);
+ if (err)
+ goto out_dput;
+
mutex_lock(&inode->i_mutex);
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] fs/binfmt_elf: fix memory map for PIE applications
On Thu, 19 Dec 2013 16:02:19 +0100 (CET) Jiri Kosina wrote: > On Thu, 19 Dec 2013, Timo Teras wrote: > > > As you see, the main executable is mapped 5762-57708000 and > > 57708000-5770a000. Heap follow immediately after that > > 5770a000-5770c000 followed by anything mmaped after it (stack or > > some other libraries). Heap can grow only up to 5ffdf000 meaning the > > application is limited to 140 megs or so in this instance. This > > limit can go much lower depending how the randomization went. And > > even 140 megs is very little for big apps. > > So what is the real problem again (i.e. the actual symptoms), please? > Is it that your userspace memory allocator doesn't use mmap() for > allocations at all? Random application failures with uclibc and musl c-libraries. Both seem to use mmap() for large allocations, and brk() for small ones. IIRC, there was also some minor breakage with other applications that use brk() to do some self-accounting / other funny stuff. While this is not strictly a bug, I would still hope that the memory layout is configured for maximum compatibility... or do you see it introducing unwanted side effects? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] fs/binfmt_elf: fix memory map for PIE applications
On Thu, 19 Dec 2013 15:17:03 +0100 (CET) Jiri Kosina wrote: > On Wed, 2 Oct 2013, Timo Teräs wrote: > > > arch/*/include/asm/elf.h comments say: > > ELF_ET_DYN_BASE is the location that an ET_DYN program is loaded > > if exec'ed. Typical use of this is to invoke "./ld.so someprog" > > to test out a new version of the loader. We need to make sure > > that it is out of the way of the program that it will "exec", > > and that there is sufficient room for the brk. > > > > In case we have main application linked as PIE, this can cause > > problems as the main program itself is being loaded to this > > alternate address. And this allows limited heap size. While > > this is inevitable when exec'ing the interpreter directly, > > we should do better for PIE applications. > > could you please provide more specific example of the breakage > scenario you are talking about? It's not completely clear to me from > your commit message. The problem is that if PF_RANDOMIZE is on, the PIE application will be mapped by letting mmap() to randomize the area for the main app (that is used to base heap). Example memory layout from x86, running PIE compiled busybox with randomization enabled: 5756c000-5757 rw-p 00:00 0 5757-575dd000 r-xp 00:0f 2039 /lib/libuClibc-0.9.33.2-git.so 575dd000-575de000 r--p 0006c000 00:0f 2039 /lib/libuClibc-0.9.33.2-git.so 575de000-575df000 rw-p 0006d000 00:0f 2039 /lib/libuClibc-0.9.33.2-git.so 575df000-575e5000 rw-p 00:00 0 575e5000-575f5000 r-xp 00:0f 2038 /lib/libm-0.9.33.2-git.so 575f5000-575f6000 r--p f000 00:0f 2038 /lib/libm-0.9.33.2-git.so 575f6000-575f7000 rw-p 0001 00:0f 2038 /lib/libm-0.9.33.2-git.so 575f7000-575fd000 r-xp 00:0f 2042 /lib/libcrypt-0.9.33.2-git.so 575fd000-575fe000 r--p 5000 00:0f 2042 /lib/libcrypt-0.9.33.2-git.so 575fe000-5761 rw-p 00:00 0 57611000-57613000 rw-p 00:00 0 57613000-57614000 r-xp 00:00 0 [vdso] 57614000-5761e000 r-xp 00:0f 2044 /lib/ld-uClibc-0.9.33.2-git.so 5761e000-5761f000 r--p 9000 00:0f 2044 /lib/ld-uClibc-0.9.33.2-git.so 5761f000-5762 rw-p a000 00:0f 2044 /lib/ld-uClibc-0.9.33.2-git.so 5762-57708000 r-xp 00:0f 234487046 /root/busybox 57708000-5770a000 rw-p 000e8000 00:0f 234487046 /root/busybox 5770a000-5770c000 rw-p 00:00 0 [heap] 5ffdf000-6000 rw-p 00:00 0 [stack] b757-b75dd000 r-xp 00:0f 2039 /lib/libuClibc-0.9.33.2-git.so b75e5000-b75f5000 r-xp 00:0f 2038 /lib/libm-0.9.33.2-git.so b75f7000-b75fd000 r-xp 00:0f 2042 /lib/libcrypt-0.9.33.2-git.so b7613000-b7614000 r-xp 00:00 0 [vdso] b7614000-b761e000 r-xp 00:0f 2044 /lib/ld-uClibc-0.9.33.2-git.so b762-b7708000 r-xp 00:0f 234487046 /root/busybox As you see, the main executable is mapped 5762-57708000 and 57708000-5770a000. Heap follow immediately after that 5770a000-5770c000 followed by anything mmaped after it (stack or some other libraries). Heap can grow only up to 5ffdf000 meaning the application is limited to 140 megs or so in this instance. This limit can go much lower depending how the randomization went. And even 140 megs is very little for big apps. Hope this clarifies the issue. - Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] fs/binfmt_elf: fix memory map for PIE applications
arch/*/include/asm/elf.h comments say: ELF_ET_DYN_BASE is the location that an ET_DYN program is loaded if exec'ed. Typical use of this is to invoke "./ld.so someprog" to test out a new version of the loader. We need to make sure that it is out of the way of the program that it will "exec", and that there is sufficient room for the brk. In case we have main application linked as PIE, this can cause problems as the main program itself is being loaded to this alternate address. And this allows limited heap size. While this is inevitable when exec'ing the interpreter directly, we should do better for PIE applications. This fixes the loader to detect PIE application by checking if elf_interpreter is requested. This images are loaded to beginning of the address space instead of the specially crafted place for elf interpreter. This allows full heap address space for PIE applications and fixes random "out of memory" errors. Signed-off-by: Timo Teräs --- fs/binfmt_elf.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) It might make sense to define ELF_ET_DYN_APP_BASE or similar so that architectures can specify the load address of ET_DYN applications. diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 100edcc..f1508c7 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -802,21 +802,19 @@ static int load_elf_binary(struct linux_binprm *bprm) * default mmap base, as well as whatever program they * might try to exec. This is because the brk will * follow the loader, and is not movable. */ + if (elf_interpreter) + load_bias = 0x0040UL; + else + load_bias = ELF_ET_DYN_BASE; #ifdef CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE /* Memory randomization might have been switched off * in runtime via sysctl or explicit setting of * personality flags. -* If that is the case, retain the original non-zero -* load_bias value in order to establish proper -* non-randomized mappings. */ if (current->flags & PF_RANDOMIZE) - load_bias = 0; - else - load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr); -#else - load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr); + load_bias += (get_random_int() & STACK_RND_MASK) << PAGE_SHIFT; #endif + load_bias = ELF_PAGESTART(vaddr + load_bias); } error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt, -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ASLR creates bad memory layout for PIE
Hi, It seems that ASLR with PIE binaries (linux-3.11.0-vanilla on ARM) seems to create bad memory layout - the programs run out of memory relatively soon, especially if they also mmap() lot of memory. I believe the problem is that fs/binfmt_elf.c:load_elf_binary() sets load_bias to 0 when CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE is set (true for arm). This causes the following elf_map() to get zero addr (vaddr is zero also for the main program PT_LOAD), and we get the main binary mmapped to random position from the regular mmap area. Thus, brk is also in the same area. I believe load_elf_binary() should instead manually randomize load_bias to be within beginning of the user address space (or at least somewhere close to ELF_ET_DYN_BASE). This would avoid the very restricted heap size what we get now. The memory layout I get on my arm board, with PIE executables and randomize_va_space=2 (boot time default): b6db2000-b6df4000 r-xp 00:0f 5682 /usr/lib/libncurses.so.5.9 b6df4000-b6df7000 rw-p 0003a000 00:0f 5682 /usr/lib/libncurses.so.5.9 b6df7000-b6e31000 r-xp 00:0f 7364 /usr/lib/libreadline.so.6.2 b6e31000-b6e35000 rw-p 00032000 00:0f 7364 /usr/lib/libreadline.so.6.2 b6e35000-b6e36000 rw-p 00:00 0 b6e36000-b6eb3000 r-xp 00:0f 3233 /lib/ld-musl-armhf.so.1 b6eb9000-b6eba000 r-xp 00:00 0 [sigpage] b6eba000-b6ebc000 rw-p 0007c000 00:0f 3233 /lib/ld-musl-armhf.so.1 b6ebc000-b6ebd000 rw-p 00:00 0 b6ebd000-b6f6 r-xp 00:0f 7368 /bin/bash b6f68000-b6f6c000 rw-p 000a3000 00:0f 7368 /bin/bash b6f6c000-b6f7 rw-p 00:00 0 b7641000-b764e000 rw-p 00:00 0 [heap] becd2000-becf3000 rw-p 00:00 0 [stack] -1000 r-xp 00:00 0 [vectors] And with randomize_vaspace=0: 2a00-2a0a3000 r-xp 00:0f 7368 /bin/bash 2a0ab000-2a0af000 rw-p 000a3000 00:0f 7368 /bin/bash 2a0af000-2a0bf000 rw-p 00:00 0 [heap] b6ef5000-b6f37000 r-xp 00:0f 5682 /usr/lib/libncurses.so.5.9 b6f37000-b6f3a000 rw-p 0003a000 00:0f 5682 /usr/lib/libncurses.so.5.9 b6f3a000-b6f74000 r-xp 00:0f 7364 /usr/lib/libreadline.so.6.2 b6f74000-b6f78000 rw-p 00032000 00:0f 7364 /usr/lib/libreadline.so.6.2 b6f78000-b6f79000 rw-p 00:00 0 b6f79000-b6ff6000 r-xp 00:0f 3233 /lib/ld-musl-armhf.so.1 b6ffc000-b6ffd000 r-xp 00:00 0 [sigpage] b6ffd000-b6fff000 rw-p 0007c000 00:0f 3233 /lib/ld-musl-armhf.so.1 b6fff000-b700 rw-p 00:00 0 befdf000-bf00 rw-p 00:00 0 [stack] -1000 r-xp 00:00 0 [vectors] Any comments, or suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PANIC at net/xfrm/xfrm_output.c:125 (3.9.4)
On Thu, 06 Jun 2013 08:47:56 +0100 Chris Boot wrote: > On 06/06/13 02:24, Fan Du wrote: > > Hello Chris/Jean > > > > This issue might have already been fixed by this: > > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/net/xfrm/xfrm_output.c?id=497574c72c9922cf20c12aed15313c389f722fa0 > > > > > > Hope it helps. > > Hi Fan, Jean, > > Thanks, that looks like it's the patch for exactly my problem. > Unfortunately I can't test it until next week now. :-/ > > Timo/Dave: are there any plans to push this into 3.10-rc and/or > stable? I seem to be able to hit the issue pretty reliably. It is already present in 3.10-rc3 [1], and Dave has it queued for 3.9-stable [2]. - Timo [1] http://lwn.net/Articles/551922/ [2] http://patchwork.ozlabs.org/patch/245594/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet
On Fri, 31 May 2013 10:08:27 -0300 Mauro Carvalho Chehab wrote: > Em Thu, 30 May 2013 21:00:01 +0200 > Jon Arne Jørgensen escreveu: > > > On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote: > > > I would rather have the platform_data provide the new table. Or > > > if you think bulk of the table will be the same for most users, > > > then perhaps add there an enum saying which table to use - and > > > name the tables according to the chip variant it applies to. > > > > > > > I think the bulk of the table will be the same for all drivers. > > It's one bit here and one bit there that needs changing. > > As the driver didn't support platform data. > > Changing to a new init table for the drivers that implement > > platform_data shouldn't cause any regressions. > > There are several things that are very bad on passing a table via > platform data: Sorry, my wording was self-conflicting. The intention was to suggest providing an enum saying which table to use. Not that the platform data would provide the whole table. > 1) you're adding saa711x-specific data at the bridge driver, > so, the saa711x code is spread on several places at the > long term; > > 2) some part of the saa711x code may override the data there, > as it is not aware about what bits should be preserved from > the new device; > > 3) due (2), latter changes on the code are more likely to > cause regressions; > > 4) also due to (2), some hacks can be needed, in order to warn > saa711x to handle some things differently. Agreed. > That's why it is a way better to add meaningful parameters telling > what bits are needed for the driver to work with the bridge. That's > also why we do this with all other drivers. Based on the latest patch, more of these bits need to be controlled individually than I figured. So yes, individual meaningful bits do make the most sense. Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet
On Thu, 30 May 2013 07:21:36 +0200
Jon Arne Jørgensen wrote:
> On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
> > Mauro Carvalho Chehab wrote:
> >
> > >Em Wed, 29 May 2013 22:41:16 +0200
> > >Jon Arne Jørgensen escreveu:
> > >
> > >> Change all default values in the initial setup table to match the
> > >table
> > >> in the datasheet.
> > >
> > >This is not a good idea, as it can produce undesired side effects
> > >on the existing drivers that depend on it, and can't be easily
> > >tested.
> > >
> > >Please, don't change the current "default". It is, of course, OK
> > >to change them if needed via the information provided inside the
> > >platform data.
> >
> > I was going to make a comment along the same line as Mauro.
> > Please leave the driver defaults alone. It is almost impossible to
> > regression test all the different devices with a SAA7113 chip, to
> > ensure the change doesn't cause someone's device to not work
> > properly.
> >
>
> You guys are totally right.
>
> What if I clone the original saa7113_init table into a new one, and
> make the driver use the new one if the calling driver sets
> platform_data.
>
> Something like this?
>
> switch (state->ident) {
> case V4L2_IDENT_SAA7111:
> case V4L2_IDENT_SAA7111A:
> saa711x_writeregs(sd, saa7111_init);
> break;
> case V4L2_IDENT_GM7113C:
> case V4L2_IDENT_SAA7113:
> - saa711x_writeregs(sd, saa7113_init);
> + if (client->dev.platform_data)
> + saa711x_writeregs(sd, saa7113_new_init);
> + else
> + saa711x_writeregs(sd, saa7113_init);
I would rather have the platform_data provide the new table. Or if you
think bulk of the table will be the same for most users, then perhaps
add there an enum saying which table to use - and name the tables
according to the chip variant it applies to.
- Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] leds: leds-gpio: reserve gpio before using it
This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one) and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one() flags param correctly) which was a fix of the first one. The conversion to devm_gpio_request in commit e3b1d44c (leds: leds-gpio: use devm_gpio_request_one) is not reverted. The problem is that gpio_cansleep() and gpio_get_value_cansleep() calls can crash if the gpio is not first reserved. Incidentally this same bug existed earlier and was fixed similarly in commit d95cbe61 (leds: Fix potential leds-gpio oops). But the OOPS is real. It happens when GPIOs are provided by module which is not yet loaded. So this fixes the following BUG during my ALIX boot (3.9.2-vanilla): BUG: unable to handle kernel NULL pointer dereference at 004c IP: [] __gpio_cansleep+0xe/0x1a *pde = Oops: [#1] SMP Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine EIP: 0060:[] EFLAGS: 00010282 CPU: 0 EIP is at __gpio_cansleep+0xe/0x1a EAX: EBX: cf364018 ECX: c132b8b9 EDX: ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 004c CR3: 0f0c4000 CR4: 0090 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000) Stack: cded9de0 d09471cb c1399260 cf364014 c1399260 c1399254 d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47 c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 Call Trace: [] gpio_led_probe+0xba/0x203 [leds_gpio] [] platform_drv_probe+0x26/0x48 [] driver_probe_device+0x75/0x15c [] __driver_attach+0x47/0x63 [] bus_for_each_dev+0x3c/0x66 [] driver_attach+0x14/0x16 [] ? driver_probe_device+0x15c/0x15c [] bus_add_driver+0xbd/0x1bc [] ? 0xd08b3fff [] ? 0xd08b3fff [] driver_register+0x74/0xec [] ? 0xd08b3fff [] platform_driver_register+0x38/0x3a [] gpio_led_driver_init+0xd/0x1000 [leds_gpio] [] do_one_initcall+0x6b/0x10f [] ? 0xd08b3fff [] load_module+0x1631/0x1907 [] ? insert_vmalloc_vmlist+0x14/0x43 [] ? __vmalloc_node_range+0x13e/0x15f [] sys_init_module+0x62/0x77 [] syscall_call+0x7/0xb EIP: [] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc CR2: 004c ---[ end trace 5308fb20d2514822 ]--- Signed-off-by: Timo Teräs Cc: Jingoo Han Cc: Sachin Kamat Cc: Raphael Assenat Cc: Trent Piepho Cc: Javier Martinez Canillas Cc: Arnaud Patard Cc: Ezequiel Garcia --- drivers/leds/leds-gpio.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index a0d931b..b02b679 100644 --- a/drivers/leds/leds-gpio.c +++ b/drivers/leds/leds-gpio.c @@ -107,6 +107,10 @@ static int create_gpio_led(const struct gpio_led *template, return 0; } + ret = devm_gpio_request(parent, template->gpio, template->name); + if (ret < 0) + return ret; + led_dat->cdev.name = template->name; led_dat->cdev.default_trigger = template->default_trigger; led_dat->gpio = template->gpio; @@ -126,10 +130,7 @@ static int create_gpio_led(const struct gpio_led *template, if (!template->retain_state_suspended) led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME; - ret = devm_gpio_request_one(parent, template->gpio, - (led_dat->active_low ^ state) ? - GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW, - template->name); + ret = gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state); if (ret < 0) return ret; -- 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Regression] Boot failure on ALIX during LED probe
I got the below with Linux 3.8.7-grsec and 3.9.2-grsec. Where as 3.6.11-grsec is a known good. I believe the same would happen on on vanilla kernels too. [ 15.709955] general protection fault: [#1] SMP [ 15.712287] Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat pata_acpi pata_cs5536 pata_amd ata_generic libata ehci_pci ehci_hcd ohci_hcd usbcore usb_common sd_mod scsi_mod squashfs loop [ 15.712287] Pid: 782, comm: modprobe Not tainted 3.8.7-0-grsec #1-Alpine [ 15.712287] EIP: 0060:[] EFLAGS: 00010212 CPU: 0 [ 15.712287] EIP is at __gpio_cansleep+0xd/0x14 [ 15.712287] EAX: EBX: ce3c2818 ECX: c1379bf0 EDX: [ 15.712287] ESI: c142f7a4 EDI: c142f770 EBP: cdd67ddc ESP: cdd67dbc [ 15.712287] DS: 0068 ES: 0068 FS: 00d8 GS: 007b SS: 0068 [ 15.712287] CR0: 8005003b CR2: aaa409b0 CR3: 0dd16000 CR4: 0090 [ 15.712287] DR0: DR1: DR2: DR3: [ 15.712287] DR6: 0ff0 DR7: 0400 [ 15.712287] Process modprobe (pid: 782, ti=ce6d6a90 task=ce6d6700 task.ti=ce6d6a90) [ 15.712287] Stack: [ 15.712287] d0aa91cb c142f660 ce3c2814 c142f660 c142f654 d0aa7014 [ 15.712287] cdd67df0 c11a5efd c142f660 d0aa7014 d0aa7014 cdd67e04 c11a4bf2 c142f660 [ 15.712287] d0aa7014 c142f694 cdd67e18 c11a4d2b cdd67e20 d0aa7014 cdd67e34 [ 15.712287] Call Trace: [ 15.712287] [] ? gpio_led_probe+0xba/0x203 [leds_gpio] [ 15.712287] [] platform_drv_probe+0x26/0x48 [ 15.712287] [] driver_probe_device+0x80/0x172 [ 15.712287] [] __driver_attach+0x47/0x63 [ 15.712287] [] bus_for_each_dev+0x3c/0x66 [ 15.712287] [] driver_attach+0x14/0x16 [ 15.712287] [] ? driver_probe_device+0x172/0x172 [ 15.712287] [] bus_add_driver+0xbd/0x1bc [ 15.712287] [] ? 0xd0aaafff [ 15.712287] [] ? 0xd0aaafff [ 15.712287] [] driver_register+0x74/0xec [ 15.712287] [] ? notifier_call_chain+0x25/0x46 [ 15.712287] [] ? 0xd0aaafff [ 15.712287] [] platform_driver_register+0x38/0x3a [ 15.712287] [] gpio_led_driver_init+0xd/0x5b5 [leds_gpio] [ 15.712287] [] do_one_initcall+0x6a/0xff [ 15.712287] [] load_module+0x15b2/0x18de [ 15.712287] [] ? insert_vmalloc_vmlist+0x14/0x52 [ 15.712287] [] ? __vmalloc_node_range+0x13e/0x15f [ 15.712287] [] sys_init_module+0x113/0x129 [ 15.712287] [] syscall_call+0x7/0xb [ 15.712287] Code: 00 5c 50 c1 75 14 8b 82 04 5c 50 c1 a8 01 74 0a 8b 8a 08 5c 50 c1 eb 02 31 c9 89 c8 5d c3 6b c0 0c 55 89 e5 5d 8b 80 00 5c 50 c1 40 40 83 e0 01 c3 6b d0 0c 55 89 e5 53 8b 8a 00 5c 50 c1 8b [ 15.712287] EIP: [] __gpio_cansleep+0xd/0x14 SS:ESP 0068:cdd67dbc [ 15.714343] ---[ end trace d6fdd52620ab8376 ]--- [ 16.491213] cs5535-gpio cs5535-gpio: reserved resource region [io 0x6100-0x61ff] [ 16.604968] cs5535-mfgpt cs5535-mfgpt: reserved resource region [io 0x6200-0x623f] [ 16.606766] cs5535-mfgpt cs5535-mfgpt: 8 MFGPT timers available This goes away if gpio_cs5535 is downloaded by hand before leds_gpio. To me it seems that recent gpiolib changes do not handle the case that the gpio chip driver is loaded after leds-gpio. Or perhaps leds-gpio should request that platform specific module first if needed. The relevant config is: CONFIG_ALIX=y CONFIG_LEDS_GPIO=m CONFIG_GPIO_CS5535=m Full config available at: http://git.alpinelinux.org/cgit/aports/tree/main/linux-grsec/kernelconfig.x86 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section
Masami Hiramatsu writes: > Thank you for reporting!! Thanks for fixing these! I spent some time trying to automate the process of finding sensitive functions and eventually resorted into booting a kvm instance with a minimal initrd to test every single function in a clean and reproducible environment. I found 7 more cases where calling register_kprobe() leads to an instant kernel panic: __flush_tlb_single native_flush_tlb native_safe_halt native_set_pgd native_set_pmd native_set_pud native_write_cr0 You can see full kernel console output for each function at http://lindi.iki.fi/lindi/linux/kprobes/panics_2013-03-18/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [media] ir: IR_RX51 only works on OMAP2
On 03.14 2013 22:56:44, Arnd Bergmann wrote: > This driver can be enabled on OMAP1 at the moment, which breaks > allyesconfig for that platform. Let's mark it OMAP2PLUS-only > in Kconfig, since that is the only thing it builds on. > Acked-by: Timo Kokkonen Thanks! > Signed-off-by: Arnd Bergmann > Cc: Mauro Carvalho Chehab > Cc: Timo Kokkonen > Cc: Tony Lindgren > Cc: Laurent Pinchart > Cc: linux-me...@vger.kernel.org > --- > Mauro, please apply for 3.9 > > drivers/media/rc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > index 19f3563..5a79c33 100644 > --- a/drivers/media/rc/Kconfig > +++ b/drivers/media/rc/Kconfig > @@ -291,7 +291,7 @@ config IR_TTUSBIR > > config IR_RX51 > tristate "Nokia N900 IR transmitter diode" > - depends on OMAP_DM_TIMER && LIRC && !ARCH_MULTIPLATFORM > + depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC && > !ARCH_MULTIPLATFORM > ---help--- > Say Y or M here if you want to enable support for the IR > transmitter diode built in the Nokia N900 (RX51) device. > -- > 1.8.1.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section
Masami Hiramatsu writes: > OK, then I'll update it to just use __always_inline. I get a similar case of infinite recursion if I try to kprobe "inat_get_opcode_attribute": PID: 3028 TASK: 88003c67e8c0 CPU: 1 COMMAND: "insmod" #0 [88003d60b9b8] __schedule at 813777f8 #1 [88003d60b9d0] inat_get_opcode_attribute at 811c95a9 #2 [88003d60b9e0] notifier_call_chain at 8137b5a3 #3 [88003d60ba20] notify_die at 8137b60c #4 [88003d60ba50] do_int3 at 81378fa0 #5 [88003d60ba70] xen_int3 at 8137887e [exception RIP: inat_get_opcode_attribute+1] RIP: 811c95a9 RSP: 88003d60bb20 RFLAGS: 0006 RAX: 0200 RBX: a00070f0 RCX: RDX: 88003f80dd90 RSI: 88003d60bcc8 RDI: 0040 RBP: a019b000 R8: R9: 81629b10 R10: 66a8 R11: a019b000 R12: 88003f80dd90 R13: 811c95a8 R14: 811c95a9 R15: a019b010 ORIG_RAX: CS: 1e030 SS: e02b #6 [88003d60bb20] skip_prefixes at 81379b6e #7 [88003d60bb30] set_current_kprobe.isra.4 at 81379bb0 #8 [88003d60bb40] kprobe_exceptions_notify at 8137a446 #9 [88003d60bba0] notifier_call_chain at 8137b5a3 #10 [88003d60bbe0] notify_die at 8137b60c #11 [88003d60bc10] do_int3 at 81378fa0 #12 [88003d60bc30] xen_int3 at 8137887e [exception RIP: inat_get_opcode_attribute+1] RIP: 811c95a9 RSP: 88003d60bce0 RFLAGS: 0246 RAX: 0001 RBX: 88003d60bdb0 RCX: RDX: 88003d60be10 RSI: 88003d60be10 RDI: 0040 RBP: R8: 88003d60bdb0 R9: 811c95a8 R10: 66a8 R11: a019b000 R12: 811c9540 R13: 811c95ad R14: R15: a019b010 ORIG_RAX: CS: e030 SS: e02b #13 [88003d60bce0] insn_get_prefixes at 811c9721 #14 [88003d60bd10] insn_get_opcode at 811c9923 #15 [88003d60bd30] insn_get_modrm at 811c9a2e #16 [88003d60bd50] insn_get_sib at 811c9af8 #17 [88003d60bd60] insn_get_displacement at 811c9b5d #18 [88003d60bd70] insn_get_immediate at 811c9c48 #19 [88003d60bd80] insn_get_length at 811c9f97 #20 [88003d60bd90] can_optimize at 8137a96e #21 [88003d60be50] arch_prepare_optimized_kprobe at 8137ab2c #22 [88003d60bea0] alloc_aggr_kprobe.isra.17 at 8137bb9b #23 [88003d60bec0] register_kprobe at 8137cf16 #24 [88003d60bf00] init_module at a001101b [testcase1] #25 [88003d60bf10] do_one_initcall at 810020b6 #26 [88003d60bf40] sys_init_module at 81083c4f #27 [88003d60bf80] system_call_fastpath at 8137d6e9 RIP: 7f0fec23814a RSP: 7fff29328218 RFLAGS: 0206 RAX: 00af RBX: 8137d6e9 RCX: 7f0fec23448a RDX: 7f0fed0b0010 RSI: 0002be0b RDI: 7f0fec8df000 RBP: 7f0fed0b11d0 R8: 0003 R9: R10: 7f0fec23448a R11: 0206 R12: 7f0fed0b0010 R13: 7f0fed0b12a0 R14: 7f0fed0b00c0 R15: ORIG_RAX: 00af CS: e033 SS: e02b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] [media] ir-rx51: fix clock API related build issues
On 03.05 2013 17:09:53, Tony Lindgren wrote:
> * Mauro Carvalho Chehab [130305 16:28]:
> > Em Tue, 5 Mar 2013 23:16:46 +0100
> > Arnd Bergmann escreveu:
> >
> > > OMAP1 no longer provides its own clock interfaces since patch
> > > a135eaae52 "ARM: OMAP: remove plat/clock.h". This is great, but
> > > we now have to convert the ir-rx51 driver to use the generic
> > > interface from linux/clk.h.
> > >
> > > The driver also uses the omap_dm_timer_get_fclk() function,
> > > which is not exported for OMAP1, so we have to move the
> > > definition out of the OMAP2 specific section.
> > >
> > > Signed-off-by: Arnd Bergmann
> > > Cc: Mauro Carvalho Chehab
> >
> > From my side:
> > Acked-by: Mauro Carvalho Chehab
>
> There's just one issue, this driver most likely only needed on
> rx51 board.. So I suggest we just mark the driver depends on
> ARCH_OMAP2PLUS and let's drop this patch.
>
> This driver is already disabled for ARCH_MULTIPLATFORM
> as we need to move dmtimer.c to drivers and have some minimal
> include/linux/timer-omap.h for it.
>
I've also had this cunning plan that if or when the PWM subsystem
starts supporting the PWM output in OMAP3, I could convert this driver
to generate the IR carrier wave through the PWM subsystem and then use
HR timers to generate the pulses. I think that's much better approach
than trying to depend on interfaces that are not easily
available. Should be possible, but I haven't proven yet that it will
work :)
Unfortunately I haven't got into executing on that plan yet. In
addition to the challenge of scheduling some of my free time for doing
this, my RX51 device is not enumerating the USB with the latest kernel
and I haven't figured out that yet. And because of that, I haven't
been able to get my user space running over nfsroot setup I've been
using..
-Timo
> > > --- a/arch/arm/plat-omap/dmtimer.c
> > > +++ b/arch/arm/plat-omap/dmtimer.c
> > > @@ -333,6 +333,14 @@ int omap_dm_timer_get_irq(struct omap_dm_timer
> > > *timer)
> > > }
> > > EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
> > >
> > > +struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > > +{
> > > + if (timer)
> > > + return timer->fclk;
> > > + return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
> > > +
> > > #if defined(CONFIG_ARCH_OMAP1)
> > > #include
> > > /**
> > > @@ -371,14 +379,6 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
> > >
> > > #else
> > >
> > > -struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > > -{
> > > - if (timer)
> > > - return timer->fclk;
> > > - return NULL;
> > > -}
> > > -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
> > > -
> > > __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
> > > {
> > > BUG();
>
> Then omap_dm_timer_get_fclk() won't work on omap1 as there's no
> separate functional clock. We probably should not even export
> this function eventually when things are fixed up.
>
> Regards,
>
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kprobing "hash_64.constprop.26" crashes the system, recursion through get_kprobe?
Masami Hiramatsu writes: >> I am unable to recreate this problem on a fedora system; hash_64 is >> inlined AFAICS. Thanks testing. How does the disassembly of get_kprobes look for you? > I also tried and couldn't recreate hash_64 problem on my ubuntu 12.10. > Could you tell us your kconfig? Sure, see http://lindi.iki.fi/lindi/config-3.7-trunk-amd64_3.7.3-1~experimental.1 Note that I am doing the tests under xen. Should I redo the tests under kvm? >> This is a clear case of recursion. Either of the two options should fix >> the problem. > > I think __kprobes is better if it works, because it causes kprobes > issue (no problem in other parts). > (Again, since I can't reproduce this hash_64.constprop, > I'm not sure that __kprobes can fix that clearly.) Ok. My worry is that hash_64 is not the only function that is called from a __kprobes marked function. For example kprobes_module_callback calls mutex_lock. Should we also mark mutex_lock with __kprobes? Based on the disassembly of code between __kprobes_text_start and __kprobes_text_end I made a function call graph that shows functions that get called from this region: http://lindi.iki.fi/lindi/kprobes/function-call-graph1.png The __kprobes functions are marked with red color. I had to omit mutex_lock, mutex_unlock and printk from the graph to make it readable (I also omited functions that don't call other functions). As you can see, this is quite a minefield :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kprobing "hash_64.constprop.26" crashes the system, recursion through get_kprobe?
There is a long-standing problem in the systemtap community where
accidentally kprobing a delicate function causes the system to crash:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604453
http://sourceware.org/bugzilla/show_bug.cgi?id=2725
https://bugzilla.redhat.com/show_bug.cgi?id=655904
http://sourceware.org/bugzilla/show_bug.cgi?id=13659
The current solution is to mark these functions with __kprobes that
places them to a separate kprobe-free section (from __kprobes_text_start
to __kprobes_text_end). This has the nice side effect that also inlined
copies of innocent functions can not be kprobed when they are called
from functions marked with __kprobes.
Now, hash_64 is marked "inline" but this is only a hint for the
compiler. On my Debian unstable system (Linux 3.7.3-1~experimental.1)
hash_64 actually exists in six different places thanks to the GCC
ipa-cp (interprocedural constant propagation) optimization:
$ grep -E "(__kprobes_text|hash_64|get_kprobe)" /boot/System.map-3.7-trunk-amd64
810075f8 t hash_64.constprop.8
810544a4 t hash_64
81099908 t hash_64.constprop.26
810b8a95 t hash_64.constprop.75
810f70dc t hash_64.constprop.22
811a33cc t hash_64.constprop.16
81378538 T __kprobes_text_start
8137c5b2 T get_kprobe
8137d522 T __kprobes_text_end
Disassembly shows that get_kprobe calls one of these clones:
8137c5b2 :
8137c5b2: 53 push %rbx
8137c5b3: 48 89 fbmov%rdi,%rbx
8137c5b6: e8 4d d3 d1 ff callq 81099908
8137c5bb: 48 8b 04 c5 10 97 7bmov-0x7e8468f0(,%rax,8),%rax
8137c5c2: 81
8137c5c3: eb 03 jmp8137c5c8
8137c5c5: 48 8b 00mov(%rax),%rax
8137c5c8: 48 85 c0test %rax,%rax
8137c5cb: 74 08 je 8137c5d5
8137c5cd: 48 39 58 28 cmp%rbx,0x28(%rax)
8137c5d1: 75 f2 jne8137c5c5
8137c5d3: eb 02 jmp8137c5d7
8137c5d5: 31 c0 xor%eax,%eax
8137c5d7: 5b pop%rbx
8137c5d8: c3 retq
Trying to kprobe "hash_64.constprop.26" using
#include
#include
#include
static int handle_hash_64(struct kprobe *p, struct pt_regs *regs) {
return 0;
}
static struct kprobe probe_hash_64 = {
.symbol_name = "hash_64.constprop.26",
.pre_handler = handle_hash_64,
};
static int __init init_testcase1(void) {
int ret;
ret = register_kprobe(&probe_hash_64);
if (ret < 0) {
printk(KERN_WARNING "register_kprobe failed with %d\n", ret);
return -EINVAL;
}
return 0;
}
static void __exit cleanup_testcase1(void) {
unregister_kprobe(&probe_hash_64);
}
MODULE_LICENSE("GPL");
module_init(init_testcase1);
module_exit(cleanup_testcase1);
crashes the system. I used the "xm dump-core" facility of xen to dump
the memory of the domU and obtained the following bactrace using
"crash vm.img /usr/lib/debug/boot/vmlinux-3.7-trunk-amd64" and
"for bt":
PID: 3007 TASK: 88003b9bb840 CPU: 0 COMMAND: "insmod"
#0 [88003db8] __schedule at 813777f8
#1 [88003db999a8] hash_64.constprop.26 at 81099909
#2 [88003db999d0] get_kprobe at 8137c5bb
#3 [88003db999e0] kprobe_exceptions_notify at 8137a3c1
#4 [88003db99a40] notifier_call_chain at 8137b5a3
#5 [88003db99a80] notify_die at 8137b60c
#6 [88003db99ab0] do_int3 at 81378fa0
#7 [88003db99ad0] xen_int3 at 8137887e
[exception RIP: hash_64.constprop.26+1]
RIP: 81099909 RSP: 88003db99b80 RFLAGS: 0086
RAX: RBX: 81099908 RCX:
RDX: 88003db99c38 RSI: 0002 RDI: 81099908
RBP: 0002 R8: R9: 81629b10
R10: 66a8 R11: a016a000 R12: 88003f80dd90
R13: 81099908 R14: 81099909 R15: a016a010
ORIG_RAX: CS: 1e030 SS: e02b
#8 [88003db99b80] get_kprobe at 8137c5bb
#9 [88003db99b90] kprobe_exceptions_notify at 8137a3c1
#10 [88003db99bf0] notifier_call_chain at 8137b5a3
#11 [88003db99c30] notify_die at 8137b60c
#12 [88003db99c60] do_int3 at 81378fa0
#13 [88003db99c80] xen_int3 at 8137887e
[exception RIP: hash_64.constprop.26+1]
RIP: 81099909 RSP: 88003db99d30 RFLAGS: 0246
RAX: RBX: 81099908 RCX: a521
RDX: 81099908 RSI: 81099908 RDI: 81099908
RBP: 88003db99e10
Re: [PATCH v2] Media: remove incorrect __init/__exit markups
On 02.25 2013 23:17:27, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically disables sysfs bind/unbind
> attributes.
>
> Similarly probe() methods should not be marked __init unless
> platform_driver_probe() is used.
>
> Signed-off-by: Dmitry Torokhov
> ---
>
> v1->v2: removed __init markup on omap1_cam_probe() that was pointed out
> by Guennadi Liakhovetski.
>
> drivers/media/i2c/adp1653.c | 4 ++--
> drivers/media/i2c/smiapp/smiapp-core.c | 4 ++--
> drivers/media/platform/soc_camera/omap1_camera.c | 6 +++---
> drivers/media/radio/radio-si4713.c | 4 ++--
> drivers/media/rc/ir-rx51.c | 4 ++--
> 5 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
> index 8ead492..31b955b 100644
> --- a/drivers/media/rc/ir-rx51.c
> +++ b/drivers/media/rc/ir-rx51.c
> @@ -464,14 +464,14 @@ static int lirc_rx51_probe(struct platform_device *dev)
> return 0;
> }
>
> -static int __exit lirc_rx51_remove(struct platform_device *dev)
> +static int lirc_rx51_remove(struct platform_device *dev)
> {
> return lirc_unregister_driver(lirc_rx51_driver.minor);
> }
>
> struct platform_driver lirc_rx51_platform_driver = {
> .probe = lirc_rx51_probe,
> - .remove = __exit_p(lirc_rx51_remove),
> + .remove = lirc_rx51_remove,
> .suspend= lirc_rx51_suspend,
> .resume = lirc_rx51_resume,
> .driver = {
For ir-rx51:
Acked-by: Timo Kokkonen
Thanks!
-Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Load averages?
On 09.24 2012 22:39:54, Russell King wrote: > I have here a cubox running v3.5, and I've been watching top while it's > playing back an mpeg stream from NFS using vlc. rootfs on SD card, and > it's uniprocessor. > > Top reports the following: > > top - 20:38:35 up 44 min, 3 users, load average: 1.26, 1.10, 1.10 > Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie > Cpu(s): 55.0%us, 3.5%sy, 0.0%ni, 40.8%id, 0.0%wa, 0.7%hi, 0.0%si, 0.0%st > Mem:768892k total, 757900k used,10992k free,37080k buffers > Swap:0k total,0k used,0k free, 505940k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 4270 cubox 20 0 244m 68m 38m S 51.3 9.2 18:33.32 vlc > > 3659 root 20 0 57652 40m 35m S 6.5 5.4 3:06.79 Xorg > > > and it stays fairly constant like that - around 55-60% user ticks > around 2-4% system, 40% idle, 0% wait, and around a total of 1% > interrupt (combined hardware/software). Here's another snapshot: > > top - 20:41:58 up 47 min, 3 users, load average: 0.93, 1.04, 1.07 > Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie > Cpu(s): 59.8%us, 1.0%sy, 0.0%ni, 38.5%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st > Mem:768892k total, 755296k used,13596k free,37080k buffers > Swap:0k total,0k used,0k free, 503856k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 4270 cubox 20 0 243m 68m 38m S 53.6 9.1 20:19.74 vlc > > 3659 root 20 0 57652 40m 35m S 6.5 5.4 3:20.50 Xorg > > > Now, for this capture, I've set top's interval to be 60 seconds: > > top - 20:49:52 up 55 min, 3 users, load average: 0.99, 0.96, 1.01 > Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie > Cpu(s): 60.4%us, 1.6%sy, 0.0%ni, 36.6%id, 0.1%wa, 0.5%hi, 0.8%si, 0.0%st > Mem:768892k total, 759816k used, 9076k free,37076k buffers > Swap:0k total,0k used,0k free, 508340k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 4270 cubox 20 0 244m 68m 38m S 54.7 9.2 24:23.46 vlc > > 3659 root 20 0 57652 40m 35m S 4.6 5.4 4:02.80 Xorg > > > And finally, here's what vmstat 5 looks like: > > procs ---memory-- ---swap-- -io -system-- cpu > r b swpd free buff cache si sobibo in cs us sy id wa > 0 0 0 13788 37164 503380006213 472 444 52 5 33 9 > 0 0 0 13416 37164 50434000 0 0 354 344 62 2 37 0 > 1 0 0 12424 37164 50530000 0 0 356 374 61 3 36 0 > 4 0 0 11556 37164 50626000 0 0 357 360 63 2 35 0 > 1 0 0 10564 37164 50722000 0 1 359 358 56 4 41 0 > 0 0 0 9572 37164 50818000 0 0 349 369 57 3 41 0 > 0 0 0 11628 37164 50536800 0 0 356 350 56 4 41 0 > 2 0 0 11432 37164 50632800 0 0 350 372 57 3 40 0 > 0 0 0 10440 37164 50728800 0 0 351 379 57 3 40 0 > 0 0 0 9448 37164 50824800 0 0 342 348 57 2 41 0 > 0 0 0 12248 37156 50480400 0 0 356 381 60 3 37 0 > 0 0 0 12052 37156 50576400 0 0 354 365 61 3 36 0 > 1 0 0 12052 37156 50576400 0 0 226 326 56 2 42 0 > 0 0 0 11060 37156 50672400 0 0 352 355 54 5 42 0 > 0 0 0 10068 37156 50768400 0 0 357 356 58 3 38 0 > 0 0 0 9076 37156 50864400 0 0 351 356 64 3 33 0 > > Yet, for some reason, the load average sits around 0.9-1.3. I don't > understand this - if processes are only running for around 65% of the > time and there's very little waiting for IO, why should the load > average be saying that the system load is equivalent to 1 process > running for 1minute/5minutes/15minutes? Shouldn't the load average reflect the average length of the run queue? If that is the case, then I could quite easily imagine load pattern where every now and then (when vlc is decompressing frames and X is drawing the contents of the window) there are multiple runnable processes fighting their turn to get CPU time. And once they get their job done, they are all idling and waiting for the next event (decompress and draw frame) to happen. Even though the CPU is i
BUG: soft lockup with kernel 2.6.23.12 (x86-64)
Heip! I did something like "dd if=/dev/sda1 bs=256M of=dump" and the whole system hanged after a while. Netconsole captured following soft lockup: ===cut BUG: soft lockup - CPU#3 stuck for 11s! [metalog:4767] CPU 3: Modules linked in: fglrx(P) cinergyT2 Pid: 4767, comm: metalog Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0x7/0x10 RSP: 0018:810128dd9b00 EFLAGS: 0286 RAX: RBX: 8100c5341b70 RCX: RDX: 81012aa50720 RSI: 8061df23 RDI: 8069bce0 RBP: 8100c5341b70 R08: R09: R10: 1000 R11: 1000 R12: 8100c5341b70 R13: 810108421a00 R14: 0001 R15: 00010b84002c FS: 2b9a1ba83b00() GS:81012fc0f200() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 8900757b0600 CR3: 00012c223000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] __mark_inode_dirty+0x65/0x1b0 [] reiserfs_file_write+0x1b9/0x1b90 [] free_poll_entry+0x11/0x20 [] poll_freewait+0x30/0x90 [] do_sys_poll+0x170/0x3f0 [] __pollwait+0x0/0x130 [] __d_lookup+0x98/0x120 [] do_lookup+0x8f/0x220 [] dput+0xab/0x140 [] __link_path_walk+0xc83/0xe40 [] mntput_no_expire+0x27/0xb0 [] link_path_walk+0x80/0xf0 [] do_path_lookup+0x89/0x1f0 [] getname+0xf5/0x200 [] _atomic_dec_and_lock+0x48/0x70 [] mntput_no_expire+0x27/0xb0 [] cp_new_stat+0xe5/0x100 [] vfs_write+0xc8/0x170 [] sys_write+0x53/0x90 [] system_call+0x7e/0x83 BUG: soft lockup - CPU#0 stuck for 11s! [pdflush:290] CPU 0: Modules linked in: fglrx(P) cinergyT2 Pid: 290, comm: pdflush Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0x7/0x10 RSP: :81012ff5de58 EFLAGS: 0286 RAX: 0001 RBX: 81004c854070 RCX: RDX: 0001 RSI: 0282 RDI: 8069bce0 RBP: 81012fc9 R08: 81012ff5c000 R09: R10: 0080 R11: R12: 81012ff5a000 R13: 8023a590 R14: 000103f4afa4 R15: 00200200 FS: () GS:806ff000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: f6509000 CR3: 0001221ad000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] writeback_inodes+0xa4/0xf0 [] wb_kupdate+0xa6/0x120 [] pdflush+0x0/0x1e0 [] pdflush+0x110/0x1e0 [] wb_kupdate+0x0/0x120 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 BUG: soft lockup - CPU#2 stuck for 11s! [pdflush:289] CPU 2: Modules linked in: fglrx(P) cinergyT2 Pid: 289, comm: pdflush Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0x7/0x10 RSP: :81012ff59e38 EFLAGS: 0286 RAX: 0001 RBX: 81004c854070 RCX: 0001fcc6 RDX: RSI: 0282 RDI: 8069bce0 RBP: 81012fc9 R08: 000c5c60 R09: 81012ff59eb0 R10: 28f5c28f5c28f5c3 R11: R12: 81012ff54720 R13: 8023a590 R14: 000103f4afa3 R15: 00200200 FS: () GS:81012fc0f180() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b1e07aee000 CR3: 4d4a7000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] writeback_inodes+0xa4/0xf0 [] background_writeout+0xa7/0xd0 [] pdflush+0x0/0x1e0 [] pdflush+0x110/0x1e0 [] background_writeout+0x0/0xd0 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 BUG: soft lockup - CPU#1 stuck for 11s! [boinc:5597] CPU 1: Modules linked in: fglrx(P) cinergyT2 Pid: 5597, comm: boinc Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0xa/0x10 RSP: 0018:810127f33b50 EFLAGS: 0286 RAX: 11d0 RBX: 8100056d1680 RCX: 0012 RDX: f095 RSI: 8100056d1680 RDI: 8069bce0 RBP: R08: 000a R09: R10: R11: 802f05e0 R12: 0010 R13: 810127f33de0 R14: 810127f33dd8 R15: 810127f33dd0 FS: () GS:81012fc0f100(0063) knlGS:f7f696c0 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: f654c000 CR3: 000127c2f000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] ifind_fast+0x27/0xa0 [] iget_locked+0x44/0x180 [] proc_get_inode+0x26/0x140 [] proc_lookup+0x95/0x110 [] do_lookup+0x17a/0x220 [] __link_path_walk+0x80d/0xe40 [] dput+0xab/0x140 [] __link_path_
ALSA HDA problem with 64-bit kernels
Heip! I recently moved to 64-bit kernel, but mixed sounds (ie. mpegs played with a media player) don't work with optical S/PDIF connection. AC3/DTS passthrough still works, and I can hear the mixed sounds on analog connector. And yes, I have unmuted the IEC958 mixer setting. Tested kernels: ALSA 1.0.14: 2.6.23.1 32bit: works 2.6.23.1 64bit: broken 2.6.23.12 64bit: broken 2.6.23.12 64bit kernel, 32bit userspace: broken ALSA 1.0.15: 2.6.24-rc6 64bit: broken (and half of the mixer settings are missing) The soundcard is integrated to the motherboard (Abit IP35 Pro) and I can't find any more information on it than it is "7.1 CH HD Audio CODEC". Relevant part of dmesg (it is the same for 32/64 bit versions, expect that the interrput goes to IRQ 18): ===cut dmesg Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). ACPI: PCI Interrupt :00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device :00:1b.0 to 64 hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... usbcore: registered new interface driver snd-usb-audio ALSA device list: #0: HDA Intel at 0xfdff4000 irq 22 ===cut lspci 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) Subsystem: ABIT Computer Corp. Unknown device [147b:1083] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unkillable gdb process gets system unusably slow
Fully reproducible with me. v2.6.23.1 x86-64 SMP kernel, Core 2 CPU, gdb
v6.6.90.20070912-debian.
gdb ./hang
run
fr 1
p (char*)base
p command hangs and the entire system becomes unusably slow. kill -9
doesn't kill gdb.
/* gcc hang.c -o hang -g -Wall */
#include
#include
#include
#include
#include
int main(void)
{
int fd;
char buf[100];
void *base;
fd = open("hang.tmp", O_RDWR | O_CREAT, 0600);
if (fd == -1) perror("open");
base = mmap(NULL, 100, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (base == MAP_FAILED)
perror("mmap");
memcpy(buf, base, sizeof(buf));
return 0;
}
signature.asc
Description: This is a digitally signed message part
[PATCH] Allow changing O_SYNC with fcntl().
Is there a reason why this isn't allowed now?
---
fs/fcntl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 8685263..fc0c92e 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -203,7 +203,7 @@ asmlinkage long sys_dup(unsigned int fildes)
return ret;
}
-#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | FASYNC | O_DIRECT |
O_NOATIME)
+#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | FASYNC | O_DIRECT |
O_NOATIME | O_SYNC)
static int setfl(int fd, struct file * filp, unsigned long arg)
{
signature.asc
Description: This is a digitally signed message part
[PATCH] ip_gre: sendto/recvfrom NBMA address
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
Signed-off-by: Timo Teras <[EMAIL PROTECTED]>
---
This is useful for implementing NHRP over NBMA GRE tunnels.
Sent earlier to netdev list only. Resending to wider audience with
a style issue fixed.
net/ipv4/ip_gre.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index f151900..b1e3816 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1033,7 +1033,6 @@ static int ipgre_tunnel_change_mtu(struct net_device
*dev, int new_mtu)
return 0;
}
-#ifdef CONFIG_NET_IPGRE_BROADCAST
/* Nice toy. Unfortunately, useless in real life :-)
It allows to construct virtual multiprotocol broadcast "LAN"
over the Internet, provided multicast routing is tuned.
@@ -1092,10 +1091,19 @@ static int ipgre_header(struct sk_buff *skb, struct
net_device *dev,
return -t->hlen;
}
+static int ipgre_header_parse(const struct sk_buff *skb, unsigned char *haddr)
+{
+ struct iphdr *iph = (struct iphdr *) skb_mac_header(skb);
+ memcpy(haddr, &iph->saddr, 4);
+ return 4;
+}
+
static const struct header_ops ipgre_header_ops = {
.create = ipgre_header,
+ .parse = ipgre_header_parse,
};
+#ifdef CONFIG_NET_IPGRE_BROADCAST
static int ipgre_open(struct net_device *dev)
{
struct ip_tunnel *t = netdev_priv(dev);
@@ -1197,6 +1205,8 @@ static int ipgre_tunnel_init(struct net_device *dev)
dev->stop = ipgre_close;
}
#endif
+ } else {
+ dev->header_ops = &ipgre_header_ops;
}
if (!tdev && tunnel->parms.link)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
On Mon, 1 Oct 2007, Linus Torvalds wrote:
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
The r8169 nic performance regression is still there.
2.6.22: send 82MB/s, receive 86MB/s
2.6.23-rc9: send 32MB/s, receive 98MB/s
I debugged this with Francois Romieu but haven't heard from him since
testing his fixes.
I attached a patch from him which is a partial revert of commit
6dccd16b7c2703e8bbf8bca62b5cf248332afbe2.
With this patch I get 93MB send and 97MB receive and I have been running it
for a week but I don't know if the patch has any downsides on other
systems.
//T
> Linus
>From 34875931ba2e473e2867d941980131edd609dbe4 Mon Sep 17 00:00:00 2001
From: Francois Romieu <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 23:44:03 +0200
Subject: [PATCH] r8169: more revert
Part of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index cb4c412..6d8611c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1905,7 +1905,11 @@ static void rtl_hw_start_8169(struct net_device *dev)
rtl_set_rx_max_size(ioaddr);
- rtl_set_rx_tx_config_registers(tp);
+ if ((tp->mac_version == RTL_GIGA_MAC_VER_01) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_02) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_03) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_04))
+ rtl_set_rx_tx_config_registers(tp);
tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
@@ -1926,6 +1930,14 @@ static void rtl_hw_start_8169(struct net_device *dev)
rtl_set_rx_tx_desc_registers(tp, ioaddr);
+ if ((tp->mac_version != RTL_GIGA_MAC_VER_01) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_02) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_03) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_04)) {
+ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+ rtl_set_rx_tx_config_registers(tp);
+ }
+
RTL_W8(Cfg9346, Cfg9346_Lock);
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
@@ -1940,8 +1952,6 @@ static void rtl_hw_start_8169(struct net_device *dev)
/* Enable all known interrupts by setting the interrupt mask. */
RTL_W16(IntrMask, tp->intr_event);
-
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
}
static void rtl_hw_start_8168(struct net_device *dev)
--
1.5.3.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: > Apply and try each patch of the attached tarball on top of 2.6.23-git > until the behavior changes (assuming it does). > > Patch #000n applies on top of patch #000(n - 1). I tested the series on top of -rc8 and 0005 did the trick. And if I use 0005 only, I can get 93MB/s send and 97MB/s receive, so there is a nice increase on send too since .22! iperf numbers (send/receive): revert.0001:[ 4] 0.0-10.1 sec234 MBytes194 Mbits/sec revert.0001:[ 5] 0.0-10.0 sec445 MBytes373 Mbits/sec revert.0002:[ 5] 0.0-10.0 sec325 MBytes272 Mbits/sec revert.0002:[ 4] 0.0-10.1 sec969 MBytes802 Mbits/sec revert.0003:[ 4] 0.0-10.1 sec328 MBytes272 Mbits/sec revert.0003:[ 5] 0.0-10.0 sec742 MBytes622 Mbits/sec revert.0004:[ 4] 0.0-10.2 sec329 MBytes271 Mbits/sec revert.0004:[ 5] 0.0-10.0 sec759 MBytes637 Mbits/sec revert.0005:[ 4] 0.0-10.1 sec829 MBytes691 Mbits/sec revert.0005:[ 5] 0.0-10.0 sec772 MBytes647 Mbits/sec revert.0005-only:[ 5] 0.0-10.0 sec933 MBytes780 Mbits/sec revert.0005-only:[ 4] 0.0-10.1 sec970 MBytes806 Mbits/sec //T > Good night. // / ....Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :FIN-02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...::
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Willy Tarreau wrote: > On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote: > > On Wed, 26 Sep 2007, Francois Romieu wrote: > > > The patch below is scheduled for inclusion before 2.6.23. Please try it > > > and > > > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be > > > welcome > > > too). > > Thanks for the quick reply and fix. Unfortunately the fix didn't help in my > > case. > > In another thread on LKML today, there has been some discussion about a > similar problem, which is caused by a locking bug in iperf which makes > it spin at 100% CPU. Ingo has posted a fix for this, please check the list. I noticed the problem originally with another program (playback of 720p video to remote X using mplayer). And in my case the CPU usage is 2-3% systime, <1% userspace so it doesn't seem to be anything to do with the scheduler (I did try that "echo 1 > /proc/sys/kernel/sched_compat_yield" workaround, too.) //T > Regards, > Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: > The patch below is scheduled for inclusion before 2.6.23. Please try it and > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome > too). Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. Iperf readings (send+receive) from 2.6.23-git (just before 6dccd... commit) [ 5] 0.0-10.0 sec830 MBytes694 Mbits/sec [ 4] 0.0-10.0 sec842 MBytes706 Mbits/sec 2.3.23-rc8 (clean) [ 4] 0.0-10.0 sec323 MBytes270 Mbits/sec [ 5] 0.0-10.0 sec961 MBytes802 Mbits/sec 2.3.23-rc8 and your patch [ 5] 0.0-10.1 sec326 MBytes270 Mbits/sec [ 4] 0.0-10.0 sec958 MBytes802 Mbits/sec 2.3.23-rc8 and 6dccd... reverted [ 5] 0.0-10.1 sec830 MBytes692 Mbits/sec [ 4] 0.0-10.0 sec803 MBytes673 Mbits/sec and full dmesg from 2.3.23-rc8+your patch below. Dmesg from other versions differed only by random noise caused by minor variations on bogomips scores, async initializations etc. I can send them to you too, if you think they are useful. ===cut Linux version 2.6.23-rc8-fix ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0 p1.4)) #2 SMP Wed Sep 26 21:24:43 EEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009e400 (usable) BIOS-e820: 0009e400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7fee (usable) BIOS-e820: 7fee - 7fee3000 (ACPI NVS) BIOS-e820: 7fee3000 - 7fef (ACPI data) BIOS-e820: 7fef - 7ff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f3640 NX (Execute Disable) protection: active Entering add_active_range(0, 0, 524000) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 524000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 524000 On node 0 totalpages: 524000 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 2301 pages used for memmap HighMem zone: 292323 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.5 present. ACPI: RSDP 000F77F0, 0014 (r0 IntelR) ACPI: RSDT 7FEE3000, 0034 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: FACP 7FEE3080, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: DSDT 7FEE3100, 4D1C (r1 INTELR AWRDACPI 1000 MSFT 300) ACPI: FACS 7FEE, 0040 ACPI: MCFG 7FEE7F00, 003C (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: APIC 7FEE7E40, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: SSDT 7FEE8860, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled) Processor #3 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:6010) Built 1 zonelists in Zone order. Total pages: 519907 Kernel command line: ro root=/dev/sdb2 [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ video=vesafb:ypan,mtrr:3 vga=0x0376 netconsole: local port 2001 netconsole: local IP 10.0.0.1 netconsole: interface eth0 netconsole: remote port 2001 netconsole: remote IP 10.0.0.254 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2403.193 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2072204k
