Re: [patch v3]DM: dm-insitu-comp: a compressed DM target for SSD
ping! On Tue, Feb 18, 2014 at 06:13:04PM +0800, Shaohua Li wrote: > > This is a simple DM target supporting compression for SSD only. Under layer > SSD > must support 512B sector size, the target only supports 4k sector size. > > Disk layout: > |super|...meta...|..data...| > > Store unit is 4k (a block). Super is 1 block, which stores meta and data size > and compression algorithm. Meta is a bitmap. For each data block, there are 5 > bits meta. > > Data: > Data of a block is compressed. Compressed data is round up to 512B, which is > the payload. In disk, payload is stored at the begining of logical sector of > the block. Let's look at an example. Say we store data to block A, which is in > sector B(A*8), its orginal size is 4k, compressed size is 1500. Compressed > data > (CD) will use 3 sectors (512B). The 3 sectors are the payload. Payload will be > stored at sector B. > > --- > ... | CD1 | CD2 | CD3 | | | | || ... > --- > ^B^B+1 ^B+2 ^B+7 ^B+8 > > For this block, we will not use sector B+3 to B+7 (a hole). We use 4 meta bits > to present payload size. The compressed size (1500) isn't stored in meta > directly. Instead, we store it at the last 32bits of payload. In this example, > we store it at the end of sector B+2. If compressed size + sizeof(32bits) > crosses a sector, payload size will increase one sector. If payload uses 8 > sectors, we store uncompressed data directly. > > If IO size is bigger than one block, we can store the data as an extent. Data > of the whole extent will compressed and stored in the similar way like above. > The first block of the extent is the head, all others are the tail. If extent > is 1 block, the block is head. We have 1 bit of meta to present if a block is > head or tail. If 4 meta bits of head block can't store extent payload size, we > will borrow tail block meta bits to store payload size. Max allowd extent size > is 128k, so we don't compress/decompress too big size data. > > Meta: > Modifying data will modify meta too. Meta will be written(flush) to disk > depending on meta write policy. We support writeback and writethrough mode. In > writeback mode, meta will be written to disk in an interval or a FLUSH > request. > In writethrough mode, data and meta data will be written to disk together. > > Advantages: > 1. simple. Since we store compressed data in-place, we don't need complicated > disk data management. > 2. efficient. For each 4k, we only need 5 bits meta. 1T data will use less > than > 200M meta, so we can load all meta into memory. And actual compression size is > in payload. So if IO doesn't need RMW and we use writeback meta flush, we > don't > need extra IO for meta. > > Disadvantages: > 1. hole. Since we store compressed data in-place, there are a lot of holes (in > above example, B+3 - B+7) Hole can impact IO, because we can't do IO merge. > 2. 1:1 size. Compression doesn't change disk size. If disk is 1T, we can only > store > 1T data even we do compression. > > But this is for SSD only. Generally SSD firmware has a FTL layer to map disk > sectors to flash nand. High end SSD firmware has filesystem-like FTL. > 1. hole. Disk has a lot of holes, but SSD FTL can still store data continuous > in nand. Even we can't do IO merge in OS layer, SSD firmware can do it. > 2. 1:1 size. On one side, we write compressed data to SSD, which means less > data is written to SSD. This will be very helpful to improve SSD garbage > collection, and so write speed and life cycle. So even this is a problem, the > target is still helpful. On the other side, advanced SSD FTL can easily do > thin > provision. For example, if nand is 1T and we let SSD report it as 2T, and use > the SSD as compressed target. In such SSD, we don't have the 1:1 size issue. > > So if SSD FTL can map non-continuous disk sectors to continuous nand and > support thin provision, the compressed target will work very well. > > V2->V3: > Updated with new bio iter API > > V1->V2: > 1. Change name to insitu_comp, cleanup code, add comments and doc > 2. Improve performance (extent locking, dedicated workqueue) > > Signed-off-by: Shaohua Li > --- > Documentation/device-mapper/insitu-comp.txt | 50 > drivers/md/Kconfig |6 > drivers/md/Makefile |1 > drivers/md/dm-insitu-comp.c | 1480 > > drivers/md/dm-insitu-comp.h | 158 ++ > 5 files changed, 1695 insertions(+) > > Index: linux/drivers/md/Kconfig > === > --- linux.orig/drivers/md/Kconfig 2014-02-17 17:34:45.431464714 +0800 > +++ linux/drivers/md/Kconfig 2014-02-17 17:34:45.423464815 +0800 > @@ -295,6 +295,12 @@ config DM_CACHE_CLEANER > A simple cache policy that writes back all data to the >
Re: [PATCH] checkpatch: net and drivers/net: Warn on missing blank line after variable declaration
How many warnings does this generate does this generate when you run it across the whole tree? regards, dan carpenter -- 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] drm: add kernel-log renderer
Hi David, On Fri, 7 Mar 2014 00:41:05 +0100 David Herrmann wrote: > On Thu, Mar 6, 2014 at 10:56 PM, Bruno Prémont wrote: > > On Thu, 06 March 2014 David Herrmann wrote: > >> On modern linux user-space, the VT subsystem is no longer needed for > >> system consoles. Although most DEs will fail if VTs are disabled, there > >> are several gfx-systems that support this mode. Especially the lower > >> system stack has been extended to work without VTs. > >> > >> However, there is one major drawback if VTs are disabled: You don't get > >> oops/panic-screens nor early boot-debugging. The VT subsystem registers a > >> console-driver, thus displays the kernel log and oops/panic screens in > >> those situations. This patch introduces a fallback for CONFIG_VT=n. > >> > >> A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer > >> of kernel-log messages. It registers a console-driver and pushes new > >> messages into this buffer whenever they appear. The size of the log-buffer > >> can be changed via drm_log_ensure_size(). Initially, a suitable buffer is > >> chosen, but whenever drivers register high-res CRTCs, they ought to > >> increase that buffer to guarantee there's always enough data to render the > >> whole screen. > >> This log-buffer is managed at the character-level, not pixel-level. It is > >> shared across all users, supports parallel, atomic readers and writers and > >> supports seamless resizing. > > > > Does it make sense to express drm_log_ensure_size() with pixel arguments > > and have the buffer below operated in characters? Shouldn't the pixel->char > > calculation be done at a higher level? (see also below regarding high-DPI) > > I don't want to expose "character" sizes. Any external API should be > dealing with pixels and only pixels. There is no reason to let them > deal with glyphs and text.. Regarding DPI, see below. > > >> Additionally to the log-buffer handling, a generic software renderer is > >> introduced. drm_log_draw() renders the current log-buffer into any > >> memory-mapped framebuffer you want. Note that it supports splitting lines > >> in case your framebuffer is smaller than the log-buffer, but also merging > >> continuation lines in case your framebuffer is wider. This allows > >> rendering an 80x25 log-buffer in full-width on high-res displays. On the > >> other hand, 800x250 log-buffers can be rendered without information loss > >> (apart from a shorter backlog) on low-res displays. > > > > Would it be possible to pass the dlog_font to drm_log_draw() so that > > DRM driver or high-level code could choose a larger font on high-DPI > > monitors (think retina-like)? > > > > Without that option kernel would need to be built specifically for a > > given DPI range and not be able to provide readable debug output on > > multiple CRTCs with (very) different DPIs. > > First of all, I won't support any fancy high-DPI features, that's just > wrong for debugging stuff. What I can do (and what we do in fallback > consoles in user-space) is to add an "dpi" or "scale" argument to > drm_log_draw() which does _integer_ scaling of glyphs. This allows you > to render glyphs 2x or 3x .. as big as usual. Integer scaling would do as well. Just some way to avoid tiny glyphs on high-DPI monitors (so that it can be applied per-CRTC) is needed. > I don't think it makes sense to modify drm_log_ensure_size(). I mean, > the worst that can happen is that the *text*-backlog is twice as big > as required. But if you have a high-dpi display, you already require > like 10x as much space for each framebuffer than for the entire > log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer > requires at least 8*16*4=512 bytes per char. That's fair, especially as drm_log_ensure_size() is grow-only. > Anyhow, integer-scaling should be fairly easy to get done. I thought providing the font to drm_log_draw() and express drm_log_ensure_size() in chars - or pass font to it as well - would be easier than scaling. Bruno > Thanks > David -- 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] x86: redo "x86: Use inline assembler to get sp"
This patch restores the changes of commit dff38e3e93 "x86: Use inline
assembler instead of global register variable to get sp". They got lost
in commit 198d208df4 "x86: Keep thread_info on thread stack in x86_32"
while moving the code to arch/x86/kernel/irq_32.c.
Quoting Andi from commit dff38e3e93:
"""
LTO in gcc 4.6/47. has trouble with global register variables. They were
used to read the stack pointer. Use a simple inline assembler statement
with a mov instead.
This also helps LLVM/clang, which does not support global register
variables.
"""
Cc: Steven Rostedt
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Andi Kleen
Cc: H. Peter Anvin
Signed-off-by: Mathias Krause
---
If it's not obvious, this patch should be applied to tip.git on top of
tip/x86/threadinfo.
arch/x86/kernel/irq_32.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/irq_32.c b/arch/x86/kernel/irq_32.c
index 988dc8bcae..63ce838e5a 100644
--- a/arch/x86/kernel/irq_32.c
+++ b/arch/x86/kernel/irq_32.c
@@ -70,7 +70,11 @@ static void call_on_stack(void *func, void *stack)
}
/* how to get the current stack pointer from C */
-register unsigned long current_stack_pointer asm("esp") __used;
+#define current_stack_pointer ({ \
+ unsigned long sp; \
+ asm("mov %%esp,%0" : "=g" (sp));\
+ sp; \
+})
static inline void *current_stack(void)
{
--
1.7.10.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] ioat: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Function pci_enable_msix() returns a tri-state value while pci_enable_msi_exact() is a canonical zero/-errno variant. The former is being phased out in favor of the latter. In case of 'ioat' there (should be) no difference. Signed-off-by: Alexander Gordeev Cc: Dan Williams Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org Cc: linux-...@vger.kernel.org Acked-by: Dan Williams --- drivers/dma/ioat/dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c index 4e3549a..b76c148 100644 --- a/drivers/dma/ioat/dma.c +++ b/drivers/dma/ioat/dma.c @@ -947,7 +947,7 @@ msix: for (i = 0; i < msixcnt; i++) device->msix_entries[i].entry = i; - err = pci_enable_msix(pdev, device->msix_entries, msixcnt); + err = pci_enable_msix_exact(pdev, device->msix_entries, msixcnt); if (err) goto msi; -- 1.7.7.6 -- Regards, Alexander Gordeev agord...@redhat.com -- 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/2] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Sarah Sharp
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/xhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6fbba7a..dc7cfb5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -292,7 +292,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci)
xhci->msix_entries[i].vector = 0;
}
- ret = pci_enable_msix(pdev, xhci->msix_entries, xhci->msix_count);
+ ret = pci_enable_msix_exact(pdev, xhci->msix_entries, xhci->msix_count);
if (ret) {
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Failed to enable MSI-X");
--
1.7.7.6
--
Regards,
Alexander Gordeev
agord...@redhat.com
--
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/2] xhci: Cleanup xhci_setup_msi() and xhci_setup_msix()
Make xhci_setup_msi() and xhci_setup_msix() functions return error code in a consistent and more clear way. Signed-off-by: Alexander Gordeev Cc: Sarah Sharp Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/usb/host/xhci.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 6fe577d..6fbba7a 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -232,9 +232,10 @@ static int xhci_setup_msi(struct xhci_hcd *xhci) xhci_dbg_trace(xhci, trace_xhci_dbg_init, "disable MSI interrupt"); pci_disable_msi(pdev); + return ret; } - return ret; + return 0; } /* @@ -307,7 +308,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci) } hcd->msix_enabled = 1; - return ret; + return 0; disable_msix: xhci_dbg_trace(xhci, trace_xhci_dbg_init, "disable MSI-X interrupt"); -- 1.7.7.6 -- Regards, Alexander Gordeev agord...@redhat.com -- 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/
[GIT PULL] sound fixes for 3.14-rc6
Linus,
please pull sound fixes for v3.14-rc6 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-3.14-rc6
The topmost commit is e805ca8b0a9b6c91099c0eaa4b160a1196a4ae25
sound fixes for 3.14-rc6
Just a few device-specific quirks for HD-audio and USB-audio, most of
which are one-liners.
Hui Wang (1):
ALSA: hda - add automute fix for another dell AIO model
Marius Knaust (1):
ALSA: hda - Added inverted digital-mic handling for Acer TravelMate 8371
Takashi Iwai (3):
ALSA: hda - Add missing loopback merge path for AD1884/1984 codecs
ALSA: hda - Use analog beep for Thinkpads with AD1984 codecs
ALSA: usb-audio: Add quirk for Logitech Webcam C500
---
sound/pci/hda/patch_analog.c | 4
sound/pci/hda/patch_realtek.c | 3 ++-
sound/usb/mixer.c | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
index df3652ad15ef..8ed0bcc01386 100644
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -1026,6 +1026,9 @@ static void ad1884_fixup_thinkpad(struct hda_codec *codec,
spec->gen.keep_eapd_on = 1;
spec->gen.vmaster_mute.hook = ad_vmaster_eapd_hook;
spec->eapd_nid = 0x12;
+ /* Analog PC Beeper - allow firmware/ACPI beeps */
+ spec->beep_amp = HDA_COMPOSE_AMP_VAL(0x20, 3, 3, HDA_INPUT);
+ spec->gen.beep_nid = 0; /* no digital beep */
}
}
@@ -1092,6 +1095,7 @@ static int patch_ad1884(struct hda_codec *codec)
spec = codec->spec;
spec->gen.mixer_nid = 0x20;
+ spec->gen.mixer_merge_nid = 0x21;
spec->gen.beep_nid = 0x10;
set_beep_amp(spec, 0x10, 0, HDA_OUTPUT);
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ec304f3ae3b4..850296a1e0ff 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4253,6 +4253,7 @@ static const struct hda_fixup alc269_fixups[] = {
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x1025, 0x0283, "Acer TravelMate 8371",
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1025, 0x029b, "Acer 1810TZ", ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1025, 0x0349, "Acer AOD260", ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1025, 0x047c, "Acer AC700", ALC269_FIXUP_ACER_AC700),
@@ -5163,7 +5164,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = {
SND_PCI_QUIRK(0x1028, 0x0625, "Dell",
ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0626, "Dell",
ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0628, "Dell", ALC668_FIXUP_AUTO_MUTE),
- SND_PCI_QUIRK(0x1028, 0x064e, "Dell",
ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1028, 0x064e, "Dell", ALC668_FIXUP_AUTO_MUTE),
SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_BASS_1A_CHMAP),
SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", ALC662_FIXUP_BASS_CHMAP),
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 44b0ba4feab3..1bed780e21d9 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -883,6 +883,7 @@ static void volume_control_quirks(struct
usb_mixer_elem_info *cval,
}
break;
+ case USB_ID(0x046d, 0x0807): /* Logitech Webcam C500 */
case USB_ID(0x046d, 0x0808):
case USB_ID(0x046d, 0x0809):
case USB_ID(0x046d, 0x081b): /* HD Webcam c310 */
--
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] usb/core/hub.c: return immediately when hub_port_init hits timedout
于 2014年03月07日 14:47, Greg KH 写道: > On Fri, Mar 07, 2014 at 02:15:48PM +0800, xinhui.pan wrote: >> From: "xinhui.pan" > > I doubt your name as a "." in it, right? > yes :) >> some devices go crasy, we can't resume it even after reset. > > I don't understand, what do you mean by this? What exactly does a > device do, and why does it do it? And what happens? > the device(modem) did not response. below is the call trace. [ 2950.647310] usb 1-1: reset high-speed USB device number 2 using ehci-intel-hsic [ 2957.535127] usb 1-1: DPM device timeout [ 2957.535153] 88003a1df930 0046 0001 88003a1dffd8 [ 2957.535170] 88003a14 88003a1dffd8 88003a1dffd8 830cb440 [ 2957.535187] 88003a14 833964c0 88003a1df960 00010003e2df [ 2957.535192] Call Trace: [ 2957.535221] [] schedule+0x29/0x70 [ 2957.535237] [] schedule_timeout+0x15b/0x300 [ 2957.535255] [] ? __internal_add_timer+0x130/0x130 [ 2957.535271] [] wait_for_completion_timeout+0xd7/0x120 [ 2957.535286] [] ? try_to_wake_up+0x2d0/0x2d0 [ 2957.535303] [] usb_start_wait_urb+0x7e/0x150 [ 2957.535318] [] usb_control_msg+0xc2/0x100 [ 2957.535334] [] hub_port_init+0x4d8/0xa90 [ 2957.535351] [] usb_reset_and_verify_device+0x102/0x430 [ 2957.535364] [] ? usb_get_status+0x8c/0xb0 [ 2957.535379] [] usb_port_resume+0x408/0x660 [ 2957.535393] [] ? schedule+0x29/0x70 [ 2957.535406] [] ? usb_dev_thaw+0x20/0x20 [ 2957.535419] [] generic_resume+0x1e/0x50 [ 2957.535431] [] ? get_parent_ip+0xd/0x50 [ 2957.535445] [] usb_resume_both+0x105/0x150 [ 2957.535458] [] usb_resume+0x1f/0xd0 [ 2957.535471] [] ? usb_dev_thaw+0x20/0x20 [ 2957.535484] [] usb_dev_resume+0x13/0x20 [ 2957.535499] [] dpm_run_callback+0x4e/0x80 [ 2957.535513] [] device_resume+0xf3/0x260 [ 2957.535526] [] ? dpm_wd_set+0x60/0x60 [ 2957.535541] [] async_resume+0x1d/0x50 [ 2957.53] [] async_run_entry_fn+0x39/0x120 [ 2957.535572] [] process_one_work+0x177/0x490 [ 2957.535585] [] worker_thread+0x123/0x380 [ 2957.535599] [] ? rescuer_thread+0x310/0x310 [ 2957.535613] [] kthread+0xd3/0xe0 [ 2957.535625] [] ? get_parent_ip+0xd/0x50 [ 2957.535642] [] ? kthread_create_on_node+0x110/0x110 [ 2957.535657] [] ret_from_fork+0x7c/0xb0 [ 2957.535672] [] ? kthread_create_on_node+0x110/0x110 the device can't resume during the kernel resume progress. perhaps it has some issue to deal with and has to reset itself. waiting for it to be completed seems wasting time. >> This case will cause timeout again and again. What is worse, if there >> is a watchdog, panic will be generated as timer expires. > > A watchdog where? > [ 2957.535526] [] ? dpm_wd_set+0x60/0x60 I also doubt the use of watchdog. but we really know some not good devices make the kernel in risk. >> To prevent this, we just return -ENODEV immediately. Later it will be >> re-enumerated. > > What will cause it to be re-enumerated? > > confused, > after return, hub_port_logical_disconnect will be called. to my knowledge it will re-enumerate if there actually is a device attached. > greg k-h > thanks :) -- 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 2/3] regulator: s2mps11: Add set_suspend_disable for S2MPS14
On Fri, 2014-03-07 at 09:51 +0800, Mark Brown wrote: > On Thu, Mar 06, 2014 at 10:48:54AM +0100, Krzysztof Kozlowski wrote: > > > Anyway can you look at other two patches and apply them if they are OK? > > They don't depend on this. > > There appears to be some external dependency for the definition of > macros like S2MPS14X? The patchset depends on S2MPS14 support for MFD driver. This was applied by Lee here: https://git.linaro.org/people/lee.jones/mfd.git/shortlog/refs/heads/for-mfd-next and merged into linux-next. Best regards, Krzysztof -- 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/
Linux 3.13.6
I'm announcing the release of the 3.13.6 kernel. All users of the 3.13 kernel series must upgrade. The updated 3.13.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.13.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/include/asm/cacheflush.h |1 arch/arm/include/asm/pgtable-3level.h | 15 - arch/arm/include/asm/spinlock.h | 15 - arch/arm/mach-imx/Makefile |2 arch/arm/mach-imx/common.h |4 arch/arm/mach-omap2/gpmc.c |4 arch/arm/mach-tegra/tegra.c | 10 + arch/arm/mm/dma-mapping.c |2 arch/arm/mm/mm.h|1 arch/arm/mm/mmu.c |7 arch/arm/mm/proc-v6.S |3 arch/arm/mm/proc-v7.S |2 arch/arm64/kernel/stacktrace.c |6 arch/avr32/Makefile |2 arch/avr32/boards/mimc200/fram.c|1 arch/powerpc/include/asm/compat.h |5 arch/powerpc/include/asm/opal.h |4 arch/powerpc/include/asm/ptrace.h | 16 + arch/powerpc/kernel/crash_dump.c|8 arch/powerpc/kernel/misc_32.S |5 arch/powerpc/kernel/signal_64.c |4 arch/powerpc/platforms/powernv/eeh-ioda.c | 29 --- arch/powerpc/platforms/powernv/opal-xscom.c | 21 +- arch/powerpc/platforms/pseries/hotplug-cpu.c| 22 +- arch/x86/kernel/cpu/perf_event.c|3 arch/x86/kernel/pci-dma.c |4 arch/x86/kvm/vmx.c |2 arch/x86/kvm/x86.c |2 arch/xtensa/include/asm/traps.h | 44 +++- arch/xtensa/kernel/entry.S | 72 ++- drivers/acpi/pci_irq.c |1 drivers/acpi/processor_throttling.c | 69 +++ drivers/acpi/video.c|8 drivers/ata/ahci.c | 14 + drivers/ata/libata-pmp.c|7 drivers/ata/sata_sil.c |1 drivers/base/firmware_class.c |1 drivers/cpufreq/intel_pstate.c |2 drivers/cpufreq/powernow-k8.c | 10 - drivers/dma/ioat/dma.c | 52 - drivers/dma/ioat/dma.h |1 drivers/dma/ioat/dma_v2.c | 11 - drivers/dma/ioat/dma_v3.c |3 drivers/dma/ste_dma40.c |4 drivers/edac/i7300_edac.c | 38 ++-- drivers/edac/i7core_edac.c |9 drivers/gpu/drm/i915/intel_display.c| 14 + drivers/gpu/drm/i915/intel_dp.c | 19 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 21 ++ drivers/gpu/drm/i915/intel_ringbuffer.h |1 drivers/gpu/drm/nouveau/core/engine/disp/nv50.c |2 drivers/gpu/drm/nouveau/core/subdev/fb/nv1a.c |2 drivers/gpu/drm/nouveau/nouveau_drm.c |3 drivers/gpu/drm/radeon/atombios_crtc.c | 29 ++- drivers/gpu/drm/radeon/dce6_afmt.c |2 drivers/gpu/drm/radeon/evergreen.c |2 drivers/gpu/drm/radeon/ni_dpm.c |2 drivers/gpu/drm/radeon/radeon.h |4 drivers/gpu/drm/radeon/radeon_atpx_handler.c|3 drivers/gpu/drm/radeon/radeon_kms.c |6 drivers/gpu/drm/radeon/radeon_ring.c|2 drivers/gpu/drm/radeon/radeon_semaphore.c | 19 +- drivers/gpu/drm/radeon/radeon_uvd.c |2 drivers/gpu/drm/radeon/rv770.c |2 drivers/hwmon/max1668.c |2 drivers/iio/gyro/Kconfig|2 drivers/iio/gyro/st_gyro.h |1 drivers/iio/gyro/st_gyro_core.c |9 drivers/iio/gyro/st_gyro_i2c.c |1 drivers/iio/gyro/st_gyro_spi.c |1 drivers/input/misc/arizona-haptics.c| 11 - drivers/iommu/arm-smmu.c| 101 ++- drivers/irqchip/irq-metag-ext.c |2 drivers/irqchip/irq-metag.c |2 drivers/irqchip/irq-orion.c | 22 ++ drivers/md/dm-cache-target.c|2 drivers/md/dm-mpath.c |7 drivers/md/dm-thin-metadata.c | 17 +
Re: [PATCH] mac80211: LLVMLinux: Remove VLAIS usage from mac80211
On Thu, 2014-03-06 at 11:52 -0800, beh...@converseincode.com wrote: > From: Jan-Simon Möller > > Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 > compliant equivalent. Fine, but > + char aead_req_data[sizeof(struct aead_request) > + + crypto_aead_reqsize(tfm) > + + CRYPTO_MINALIGN] CRYPTO_MINALIGN_ATTR; You really should be using kernel coding style, which changes indentation and has the + on the previous line. > + struct aead_request *aead_req > + = (struct aead_request *) aead_req_data; (void *) is perfectly find and it'll probably fit on one line then. > + memset(_req_data, 0, (sizeof(struct aead_request)+ > + crypto_aead_reqsize(tfm) + CRYPTO_MINALIGN)); You don't need the size calculation again, you can use sizeof(aead_req_data) johannes -- 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/
Linux 3.10.33
I'm announcing the release of the 3.10.33 kernel. All users of the 3.10 kernel series must upgrade. The updated 3.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/include/asm/cacheflush.h |1 arch/arm/include/asm/spinlock.h | 82 ++-- arch/arm/mach-omap2/gpmc.c |4 - arch/arm/mach-tegra/common.c| 11 +++ arch/arm/mm/dma-mapping.c |2 arch/arm/mm/proc-v6.S |3 arch/arm/mm/proc-v7.S |2 arch/arm64/kernel/stacktrace.c |6 + arch/avr32/Makefile |2 arch/avr32/boards/mimc200/fram.c|1 arch/powerpc/kernel/crash_dump.c|8 +- arch/powerpc/platforms/pseries/hotplug-cpu.c| 22 +++--- arch/x86/kernel/cpu/perf_event.c|3 arch/x86/kernel/pci-dma.c |4 - arch/x86/kvm/x86.c |2 arch/xtensa/include/asm/traps.h | 44 arch/xtensa/kernel/entry.S | 60 ++--- drivers/acpi/pci_irq.c |1 drivers/acpi/processor_throttling.c | 69 +--- drivers/acpi/video.c|8 ++ drivers/ata/ahci.c | 14 drivers/ata/libata-pmp.c|7 +- drivers/ata/sata_sil.c |1 drivers/cpufreq/powernow-k8.c | 10 ++ drivers/dma/ioat/dma.c | 52 +-- drivers/dma/ioat/dma.h |1 drivers/dma/ioat/dma_v2.c | 11 +-- drivers/dma/ioat/dma_v3.c |3 drivers/dma/ste_dma40.c |4 - drivers/edac/i7300_edac.c | 38 +-- drivers/edac/i7core_edac.c |9 ++ drivers/gpu/drm/nouveau/core/engine/disp/nv50.c |2 drivers/gpu/drm/nouveau/nouveau_drm.c |3 drivers/gpu/drm/radeon/atombios_crtc.c | 16 drivers/gpu/drm/radeon/radeon_atpx_handler.c|3 drivers/gpu/drm/radeon/radeon_kms.c |6 + drivers/hwmon/max1668.c |2 drivers/iio/gyro/Kconfig|2 drivers/iio/gyro/st_gyro.h |1 drivers/iio/gyro/st_gyro_core.c |9 +- drivers/iio/gyro/st_gyro_i2c.c |1 drivers/iio/gyro/st_gyro_spi.c |1 drivers/input/misc/arizona-haptics.c| 11 +-- drivers/irqchip/irq-metag-ext.c |2 drivers/irqchip/irq-metag.c |2 drivers/md/dm-mpath.c |7 +- drivers/md/dm-thin-metadata.c | 17 drivers/md/dm-thin-metadata.h |2 drivers/md/dm-thin.c|8 +- drivers/misc/mei/client.c |4 - drivers/net/bonding/bond_3ad.c |6 - drivers/net/bonding/bond_3ad.h |1 drivers/net/can/dev.c | 15 drivers/net/can/janz-ican3.c| 18 + drivers/net/can/usb/kvaser_usb.c|2 drivers/net/can/vcan.c |9 +- drivers/net/ethernet/broadcom/tg3.c |4 - drivers/net/usb/asix_devices.c |3 drivers/net/usb/ax88179_178a.c |4 + drivers/net/usb/gl620a.c|4 + drivers/net/usb/mcs7830.c |5 - drivers/net/usb/net1080.c |4 + drivers/net/usb/qmi_wwan.c |9 +- drivers/net/usb/rndis_host.c|4 + drivers/net/usb/smsc75xx.c |4 + drivers/net/usb/smsc95xx.c |4 + drivers/net/usb/usbnet.c| 25 ++- drivers/net/wireless/rtl818x/rtl8187/rtl8187.h | 10 ++ drivers/net/wireless/rtlwifi/ps.c |2 drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 - drivers/pci/pci.c | 10 ++ drivers/scsi/qla2xxx/qla_target.c |3 drivers/staging/android/binder.c|3 drivers/usb/chipidea/udc.c |4 - drivers/usb/gadget/bcm63xx_udc.c| 58 +--- drivers/usb/host/ehci-hcd.c
Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000
erge 'renesas/next' into devel-hourly-2014030618 > git bisect good 6543ca6fee7d3b314bda69b83fd429ed3e336645 # 06:35 20+ > 0 x86, vdso: Cleanup __vdso_gettimeofday() > git bisect bad 4dea8e4824b363c53f320d328040d7c6c5921419 # 06:37 0- > 15 x86, vdso: Add 32 bit VDSO time support for 32 bit kernel > git bisect good 8272416968a9bd8244515179625cdeffd7c2c90a # 06:41 20+ > 0 x86, vdso: Patch alternatives in the 32-bit VDSO > # first bad commit: [4dea8e4824b363c53f320d328040d7c6c5921419] x86, vdso: Add > 32 bit VDSO time support for 32 bit kernel > git bisect good 8272416968a9bd8244515179625cdeffd7c2c90a # 06:43 60+ > 0 x86, vdso: Patch alternatives in the 32-bit VDSO > git bisect bad d478a960edf1ea61ca31a07a48a8771f043dba78 # 06:43 0- > 19 0day head guard for 'devel-hourly-2014030618' > git bisect good c3bebc71c4bcdafa24b506adf0c1de3c1f77e2e0 # 06:56 60+ > 0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > git bisect good 0ffb2fe7b9c30082876fa3a17da018bf0632cf03 # 06:59 60+ > 69 Add linux-next specific files for 20140306 > > Thanks, > Fengguang > ___ > LKP mailing list > l...@linux.intel.com -- 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] Drivers: hv: vmbus: Increase the limit on the number of pfns we can handle
Increase the number of PFNs we can handle in a single vmbus packet. Some network packets may have more PFNs than the current limit we have. This is not a bug and this patch can be applied to the *next tree. Signed-off-by: K. Y. Srinivasan --- include/linux/hyperv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index 330ec44..ab7359f 100644 --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -37,7 +37,7 @@ #include -#define MAX_PAGE_BUFFER_COUNT 19 +#define MAX_PAGE_BUFFER_COUNT 32 #define MAX_MULTIPAGE_BUFFER_COUNT 32 /* 128K */ #pragma pack(push, 1) -- 1.7.4.1 -- 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 1/1] Drivers: hv: vmbus: Include the limit on the number of pfns we can handle
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Friday, March 7, 2014 12:19 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Include the limit on the number > of pfns we can handle > > On Thu, Mar 06, 2014 at 11:15:08PM -0800, K. Y. Srinivasan wrote: > > Increase the maximum number of pfns we can handle is a single vmbus > packet. > > Is that a correct sentance? I will fix the typo in the sentence. > > > > > > Signed-off-by: K. Y. Srinivasan > > --- > > include/linux/hyperv.h |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index > > 330ec44..ab7359f 100644 > > --- a/include/linux/hyperv.h > > +++ b/include/linux/hyperv.h > > @@ -37,7 +37,7 @@ > > #include > > > > > > -#define MAX_PAGE_BUFFER_COUNT 19 > > +#define MAX_PAGE_BUFFER_COUNT 32 > > What is the problem if this number isn't changed? On the networking side we may send frames that require more than 19 PFN entries. Number 32 is imposed by some limitations by the vmbus data structures. For some reason MAX_PAGE_BUFFER_COUNT was set to a lower value and I want to bump this up to what vmbus can support. > > Again, I'm going to have to ask you, what kernel is this for? > > Please remember this when sending patches that look like they might be > fixing a bug, you don't want me to guess, as my "guess" usually is "delete the > patch". Sorry Greg; this is not a bug fix and can go into the *next kernel. I will resend this patch after fixing the changelog comment. Regards, K. Y > > greg k-h -- 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 1/1] Drivers: hv: vmbus: Include the limit on the number of pfns we can handle
On Thu, Mar 06, 2014 at 11:15:08PM -0800, K. Y. Srinivasan wrote: > Increase the maximum number of pfns we can handle is a single vmbus packet. Is that a correct sentance? > > Signed-off-by: K. Y. Srinivasan > --- > include/linux/hyperv.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h > index 330ec44..ab7359f 100644 > --- a/include/linux/hyperv.h > +++ b/include/linux/hyperv.h > @@ -37,7 +37,7 @@ > #include > > > -#define MAX_PAGE_BUFFER_COUNT19 > +#define MAX_PAGE_BUFFER_COUNT32 What is the problem if this number isn't changed? Again, I'm going to have to ask you, what kernel is this for? Please remember this when sending patches that look like they might be fixing a bug, you don't want me to guess, as my "guess" usually is "delete the patch". greg k-h -- 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 5/7] pinctrl: msm: Replace lookup tables with math
We don't need to waste space with these lookup tables, just do
the math directly.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
drivers/pinctrl/pinctrl-msm.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index 5daad720ecbb..58c23f138d7a 100644
--- a/drivers/pinctrl/pinctrl-msm.c
+++ b/drivers/pinctrl/pinctrl-msm.c
@@ -260,8 +260,10 @@ static int msm_config_set(struct pinctrl_dev *pctldev,
unsigned int pin,
#define MSM_PULL_DOWN 1
#define MSM_PULL_UP3
-static const unsigned msm_regval_to_drive[] = { 2, 4, 6, 8, 10, 12, 14, 16 };
-static const unsigned msm_drive_to_regval[] = { -1, -1, 0, -1, 1, -1, 2, -1,
3, -1, 4, -1, 5, -1, 6, -1, 7 };
+static unsigned msm_regval_to_drive(u32 val)
+{
+ return (val + 1) * 2;
+}
static int msm_config_group_get(struct pinctrl_dev *pctldev,
unsigned int group,
@@ -298,7 +300,7 @@ static int msm_config_group_get(struct pinctrl_dev *pctldev,
arg = arg == MSM_PULL_UP;
break;
case PIN_CONFIG_DRIVE_STRENGTH:
- arg = msm_regval_to_drive[arg];
+ arg = msm_regval_to_drive(arg);
break;
default:
dev_err(pctrl->dev, "Unsupported config parameter: %x\n",
@@ -351,10 +353,10 @@ static int msm_config_group_set(struct pinctrl_dev
*pctldev,
break;
case PIN_CONFIG_DRIVE_STRENGTH:
/* Check for invalid values */
- if (arg >= ARRAY_SIZE(msm_drive_to_regval))
+ if (arg > 16 || arg < 2 || (arg % 2) != 0)
arg = -1;
else
- arg = msm_drive_to_regval[arg];
+ arg = (arg / 2) - 1;
break;
default:
dev_err(pctrl->dev, "Unsupported config parameter:
%x\n",
@@ -533,7 +535,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
pull = (ctl_reg >> g->pull_bit) & 3;
seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func);
- seq_printf(s, " %dmA", msm_regval_to_drive[drive]);
+ seq_printf(s, " %dmA", msm_regval_to_drive(drive));
seq_printf(s, " %s", pulls[pull]);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 4/7] pinctrl: msm: Drop OF_IRQ dependency
This driver doesn't rely on any functionality living in drivers/of/irq.c to compile. Drop this dependency. Cc: Bjorn Andersson Signed-off-by: Stephen Boyd --- drivers/pinctrl/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index be361b7cd30f..32b6b49f28ec 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -224,7 +224,7 @@ config PINCTRL_MSM config PINCTRL_MSM8X74 tristate "Qualcomm 8x74 pin controller driver" - depends on GPIOLIB && OF && OF_IRQ + depends on GPIOLIB && OF select PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 7/7] pinctrl: msm: Simplify msm_config_reg() and callers
We don't need to check for a negative reg here because reg is
always the same and is always non-negative. Also, collapse the
switch statement down for the duplicate cases.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
drivers/pinctrl/pinctrl-msm.c | 29 +
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index bdfb697194f6..534dd117dab4 100644
--- a/drivers/pinctrl/pinctrl-msm.c
+++ b/drivers/pinctrl/pinctrl-msm.c
@@ -202,28 +202,17 @@ static const struct pinmux_ops msm_pinmux_ops = {
static int msm_config_reg(struct msm_pinctrl *pctrl,
const struct msm_pingroup *g,
unsigned param,
- s16 *reg,
unsigned *mask,
unsigned *bit)
{
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- *reg = g->ctl_reg;
- *bit = g->pull_bit;
- *mask = 3;
- break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- *reg = g->ctl_reg;
- *bit = g->pull_bit;
- *mask = 3;
- break;
case PIN_CONFIG_BIAS_PULL_UP:
- *reg = g->ctl_reg;
*bit = g->pull_bit;
*mask = 3;
break;
case PIN_CONFIG_DRIVE_STRENGTH:
- *reg = g->ctl_reg;
*bit = g->drv_bit;
*mask = 7;
break;
@@ -232,12 +221,6 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
return -ENOTSUPP;
}
- if (*reg < 0) {
- dev_err(pctrl->dev, "Config param %04x not supported on group
%s\n",
- param, g->name);
- return -ENOTSUPP;
- }
-
return 0;
}
@@ -275,17 +258,16 @@ static int msm_config_group_get(struct pinctrl_dev
*pctldev,
unsigned mask;
unsigned arg;
unsigned bit;
- s16 reg;
int ret;
u32 val;
g = >soc->groups[group];
- ret = msm_config_reg(pctrl, g, param, , , );
+ ret = msm_config_reg(pctrl, g, param, , );
if (ret < 0)
return ret;
- val = readl(pctrl->regs + reg);
+ val = readl(pctrl->regs + g->ctl_reg);
arg = (val >> bit) & mask;
/* Convert register value to pinconf value */
@@ -325,7 +307,6 @@ static int msm_config_group_set(struct pinctrl_dev *pctldev,
unsigned mask;
unsigned arg;
unsigned bit;
- s16 reg;
int ret;
u32 val;
int i;
@@ -336,7 +317,7 @@ static int msm_config_group_set(struct pinctrl_dev *pctldev,
param = pinconf_to_config_param(configs[i]);
arg = pinconf_to_config_argument(configs[i]);
- ret = msm_config_reg(pctrl, g, param, , , );
+ ret = msm_config_reg(pctrl, g, param, , );
if (ret < 0)
return ret;
@@ -371,10 +352,10 @@ static int msm_config_group_set(struct pinctrl_dev
*pctldev,
}
spin_lock_irqsave(>lock, flags);
- val = readl(pctrl->regs + reg);
+ val = readl(pctrl->regs + g->ctl_reg);
val &= ~(mask << bit);
val |= arg << bit;
- writel(val, pctrl->regs + reg);
+ writel(val, pctrl->regs + g->ctl_reg);
spin_unlock_irqrestore(>lock, flags);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/7] pinctrl-msm cleanups
Here are some small fixes and cleanups for the msm pinctrl driver. Stephen Boyd (7): pinctrl: msm: Silence recursive lockdep warning pinctrl: msm: Check for ngpios > MAX_NR_GPIO pinctrl: msm: Drop unused includes pinctrl: msm: Drop OF_IRQ dependency pinctrl: msm: Replace lookup tables with math pinctrl: msm: Remove impossible WARN_ON()s pinctrl: msm: Simplify msm_config_reg() and callers drivers/pinctrl/Kconfig | 2 +- drivers/pinctrl/pinctrl-msm.c | 73 ++- drivers/pinctrl/pinctrl-msm.h | 5 +-- drivers/pinctrl/pinctrl-msm8x74.c | 1 - 4 files changed, 27 insertions(+), 54 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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] usb/core/hub.c: return immediately when hub_port_init hits timedout
On Fri, Mar 07, 2014 at 02:15:48PM +0800, xinhui.pan wrote: > From: "xinhui.pan" I doubt your name as a "." in it, right? > some devices go crasy, we can't resume it even after reset. I don't understand, what do you mean by this? What exactly does a device do, and why does it do it? And what happens? > This case will cause timeout again and again. What is worse, if there > is a watchdog, panic will be generated as timer expires. A watchdog where? > To prevent this, we just return -ENODEV immediately. Later it will be > re-enumerated. What will cause it to be re-enumerated? confused, greg k-h -- 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 6/7] pinctrl: msm: Remove impossible WARN_ON()s
All these functions are limited in what they can pass as the gpio or irq number to whatever is setup during probe. Remove the checks. Cc: Bjorn Andersson Signed-off-by: Stephen Boyd --- drivers/pinctrl/pinctrl-msm.c | 16 1 file changed, 16 deletions(-) diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c index 58c23f138d7a..bdfb697194f6 100644 --- a/drivers/pinctrl/pinctrl-msm.c +++ b/drivers/pinctrl/pinctrl-msm.c @@ -403,8 +403,6 @@ static int msm_gpio_direction_input(struct gpio_chip *chip, unsigned offset) u32 val; g = >soc->groups[offset]; - if (WARN_ON(g->io_reg < 0)) - return -EINVAL; spin_lock_irqsave(>lock, flags); @@ -425,8 +423,6 @@ static int msm_gpio_direction_output(struct gpio_chip *chip, unsigned offset, in u32 val; g = >soc->groups[offset]; - if (WARN_ON(g->io_reg < 0)) - return -EINVAL; spin_lock_irqsave(>lock, flags); @@ -453,8 +449,6 @@ static int msm_gpio_get(struct gpio_chip *chip, unsigned offset) u32 val; g = >soc->groups[offset]; - if (WARN_ON(g->io_reg < 0)) - return -EINVAL; val = readl(pctrl->regs + g->io_reg); return !!(val & BIT(g->in_bit)); @@ -468,8 +462,6 @@ static void msm_gpio_set(struct gpio_chip *chip, unsigned offset, int value) u32 val; g = >soc->groups[offset]; - if (WARN_ON(g->io_reg < 0)) - return; spin_lock_irqsave(>lock, flags); @@ -618,8 +610,6 @@ static void msm_gpio_irq_mask(struct irq_data *d) pctrl = irq_data_get_irq_chip_data(d); g = >soc->groups[d->hwirq]; - if (WARN_ON(g->intr_cfg_reg < 0)) - return; spin_lock_irqsave(>lock, flags); @@ -641,8 +631,6 @@ static void msm_gpio_irq_unmask(struct irq_data *d) pctrl = irq_data_get_irq_chip_data(d); g = >soc->groups[d->hwirq]; - if (WARN_ON(g->intr_status_reg < 0)) - return; spin_lock_irqsave(>lock, flags); @@ -668,8 +656,6 @@ static void msm_gpio_irq_ack(struct irq_data *d) pctrl = irq_data_get_irq_chip_data(d); g = >soc->groups[d->hwirq]; - if (WARN_ON(g->intr_status_reg < 0)) - return; spin_lock_irqsave(>lock, flags); @@ -694,8 +680,6 @@ static int msm_gpio_irq_set_type(struct irq_data *d, unsigned int type) pctrl = irq_data_get_irq_chip_data(d); g = >soc->groups[d->hwirq]; - if (WARN_ON(g->intr_cfg_reg < 0)) - return -EINVAL; spin_lock_irqsave(>lock, flags); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/7] pinctrl: msm: Silence recursive lockdep warning
If a driver calls enable_irq_wake() on a gpio turned interrupt
from the msm pinctrl driver we'll get a lockdep warning like so:
=
[ INFO: possible recursive locking detected ]
3.14.0-rc3 #2 Not tainted
-
modprobe/52 is trying to acquire lock:
(_desc_lock_class){-.}, at: [] __irq_get_desc_lock+0x48/0x88
but task is already holding lock:
(_desc_lock_class){-.}, at: [] __irq_get_desc_lock+0x48/0x88
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_desc_lock_class);
lock(_desc_lock_class);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by modprobe/52:
#0: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x48/0x98
#1: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x58/0x98
#2: (_desc_lock_class){-.}, at: []
__irq_get_desc_lock+0x48/0x88
#3: (&(>lock)->rlock){..}, at: []
msm_gpio_irq_set_wake+0x20/0xa8
Silence it by putting the gpios into their own lock class.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
drivers/pinctrl/pinctrl-msm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index ef2bf3126da6..ac7223dab4a3 100644
--- a/drivers/pinctrl/pinctrl-msm.c
+++ b/drivers/pinctrl/pinctrl-msm.c
@@ -869,6 +869,12 @@ static void msm_gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
chained_irq_exit(chip, desc);
}
+/*
+ * This lock class tells lockdep that GPIO irqs are in a different
+ * category than their parents, so it won't report false recursion.
+ */
+static struct lock_class_key gpio_lock_class;
+
static int msm_gpio_init(struct msm_pinctrl *pctrl)
{
struct gpio_chip *chip;
@@ -907,6 +913,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
for (i = 0; i < chip->ngpio; i++) {
irq = irq_create_mapping(pctrl->domain, i);
+ irq_set_lockdep_class(irq, _lock_class);
irq_set_chip_and_handler(irq, _gpio_irq_chip,
handle_edge_irq);
irq_set_chip_data(irq, pctrl);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/7] pinctrl: msm: Check for ngpios > MAX_NR_GPIO
Fail the probe and print a warning if SoC specific drivers have more GPIOs than there can be accounted for in the static bitmaps. This should avoid silent corruption/failures in the future. Cc: Bjorn Andersson Signed-off-by: Stephen Boyd --- drivers/pinctrl/pinctrl-msm.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c index ac7223dab4a3..19b0de89dc07 100644 --- a/drivers/pinctrl/pinctrl-msm.c +++ b/drivers/pinctrl/pinctrl-msm.c @@ -882,10 +882,14 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl) int ret; int i; int r; + unsigned ngpio = pctrl->soc->ngpios; + + if (WARN_ON(ngpio > MAX_NR_GPIO)) + return -EINVAL; chip = >chip; chip->base = 0; - chip->ngpio = pctrl->soc->ngpios; + chip->ngpio = ngpio; chip->label = dev_name(pctrl->dev); chip->dev = pctrl->dev; chip->owner = THIS_MODULE; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 3/7] pinctrl: msm: Drop unused includes
These includes are unused or can be handled via forward declarations. Remove them. Cc: Bjorn Andersson Signed-off-by: Stephen Boyd --- drivers/pinctrl/pinctrl-msm.c | 1 - drivers/pinctrl/pinctrl-msm.h | 5 + drivers/pinctrl/pinctrl-msm8x74.c | 1 - 3 files changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c index 19b0de89dc07..5daad720ecbb 100644 --- a/drivers/pinctrl/pinctrl-msm.c +++ b/drivers/pinctrl/pinctrl-msm.c @@ -28,7 +28,6 @@ #include #include #include -#include #include #include "core.h" diff --git a/drivers/pinctrl/pinctrl-msm.h b/drivers/pinctrl/pinctrl-msm.h index 206e782e2daa..8fbe9fb19f36 100644 --- a/drivers/pinctrl/pinctrl-msm.h +++ b/drivers/pinctrl/pinctrl-msm.h @@ -13,10 +13,7 @@ #ifndef __PINCTRL_MSM_H__ #define __PINCTRL_MSM_H__ -#include -#include -#include -#include +struct pinctrl_pin_desc; /** * struct msm_function - a pinmux function diff --git a/drivers/pinctrl/pinctrl-msm8x74.c b/drivers/pinctrl/pinctrl-msm8x74.c index f944bf2172ef..bb5ded69f963 100644 --- a/drivers/pinctrl/pinctrl-msm8x74.c +++ b/drivers/pinctrl/pinctrl-msm8x74.c @@ -15,7 +15,6 @@ #include #include #include -#include #include "pinctrl-msm.h" -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 1/1] mtd: mtd_blkdevs: handle REQ_FLUSH request and do explicit flush of writeback buffer
On Thu, Jan 02, 2014 at 01:21:21AM +0900, Roman Pen wrote:
> From: Roman Peniaev
>
> mtd_blkdevs is device with volatile cache (writeback buffer), so it should
> support
> REQ_FLUSH to do explicit flush.
>
> Without this patch 'sync' does not guarantee that writeback buffer will be
> flushed
> on disk in case of power off, e.g.:
>
> $ cp some_file /mnt
> $ sync
>
> ### POWER OFF
>
> In case of this sequence writeback buffer will not be flushed on disk.
>
> This patch fixes this behaviour and explicitly reports to block layer that
> flush
> requests are being supported.
>
> Signed-off-by: Roman Peniaev
> CC: David Woodhouse
> CC: linux-...@lists.infradead.org
> CC: linux-kernel@vger.kernel.org
> ---
> drivers/mtd/mtd_blkdevs.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> index 5073cbc..feafe5c 100644
> --- a/drivers/mtd/mtd_blkdevs.c
> +++ b/drivers/mtd/mtd_blkdevs.c
> @@ -89,6 +89,12 @@ static int do_blktrans_request(struct mtd_blktrans_ops *tr,
> if (req->cmd_type != REQ_TYPE_FS)
> return -EIO;
>
> + if (req->cmd_flags & REQ_FLUSH) {
> + if (tr->flush)
> + return tr->flush(dev);
> + return 0;
> + }
> +
> if (blk_rq_pos(req) + blk_rq_cur_sectors(req) >
> get_capacity(req->rq_disk))
> return -EIO;
> @@ -409,6 +415,8 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> if (!new->rq)
> goto error3;
>
> + blk_queue_flush(new->rq, REQ_FLUSH);
How about only registering the flush command if we support it? So:
if (tr->flush)
blk_queue_flush(new->rq, REQ_FLUSH);
Then you can probably also change the earlier hunk to the following, no?
if (req->cmd_flags & REQ_FLUSH)
return tr->flush(dev);
> +
> new->rq->queuedata = new;
> blk_queue_logical_block_size(new->rq, tr->blksize);
>
Brian
--
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: WIP: sc16is7xx.c
On Thu, 2014-03-06 at 21:52 -0800, Greg KH wrote: > On Thu, Mar 06, 2014 at 09:35:46PM -0500, j...@ringle.org wrote: > > From: Jon Ringle > > > > I am requesting comments on this serial driver. > > I am currently having some latency issues with it where I experience > > packet loss at speed of 19200. > > > > I welcome any and all comments. > > The basic coding style problems make it hard to read to be able to help > review it, sorry. > > Yes, brains have patterns, you want to follow the same patterns as > others, it matters. Here's a patternizing patch on top of this... It's an extended version of what I sent Jon privately. Mostly whitespace but some other neatening too. Brace removals, tabifying, 80 column comments, spelling typos, pr_, c90 comments, etc. I don't care that's it does a lot of things in a single patch because this hasn't ever been submitted before and I hope Jon rolls it into his next submission. --- drivers/tty/serial/sc16is7xx.c | 485 + 1 file changed, 253 insertions(+), 232 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 5daed84..045241e 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -1,28 +1,34 @@ /* - * The SC16IS740/750/760 is a slave I2C-bus/SPI interface to a single-channel high - * performance UART. The SC16IS740/750/760’s internal register set is backward-compatible - * with the widely used and widely popular 16C450. The SC16IS740/750/760 also provides - * additional advanced features such as auto hardware and software flow control, automatic - * RS-485 support, and software reset. - * - * Copyright (C) 2014 GridPoint + * SC16IS740/750/760 tty serial driver - Copyright (C) 2014 GridPoint * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * + * The SC16IS740/750/760 is a slave I2C-bus/SPI interface to a single-channel + * high performance UART. The SC16IS740/750/760’s internal register set is + * backward-compatible with the widely used and widely popular 16C450. + * + * The SC16IS740/750/760 also provides additional advanced features such as + * auto hardware and software flow control, automatic RS-485 support, and + * software reset. + * * Notes: + * * The sc16is740 driver is used for the GPEC RS485 Half duplex communication. - * In the EC1K board the sc16is740 RTS line is connected to the SN65HVD1780DR chip and which - * is used to signal the RS485 diretion. When the RTS is low the RS485 direction is set to - * output from the CPU. - * To set the RS485 diretion we use the sc16is740 internal RS485 feature where the chip drives - * the RTS line when the data is written to the TX FIFO (see the spec note for the EFCR[4] bit - * configuration). * + * In the EC1K board the sc16is740 RTS line is connected to a SN65HVD1780DR + * chip which is used to signal the RS485 direction. + * When RTS is low, the RS485 direction is set to output from the CPU. + * + * To set the RS485 direction we use the sc16is740 internal RS485 feature + * where the chip drives the RTS line when the data is written to the TX FIFO + * (see the spec note for the EFCR[4] bit configuration). */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include @@ -39,116 +45,139 @@ #include #include -#define DRV_VERSION"0.3" -#define DRV_NAME"sc16is7xx" -#define DEV_NAME"ttySC" -#define SC16IS7XX_MAJOR204 /* Take place of the /dev/ttySC0 SCI serial port 0 */ -#define SC16IS7XX_MINOR8 +#define DRV_VERSION"0.3" +#define DRV_NAME "sc16is7xx" +#define DEV_NAME "ttySC" + +#define SC16IS7XX_MAJOR204 /* Take place of the /dev/ttySC0 +* SCI serial port 0 +*/ +#define SC16IS7XX_MINOR8 /* * Software Definitions */ /* Commands sent from the uart callbacks to the work handler */ -#define SC16IS7XX_CMND_STOP_RX (0) /* Disable the RX interrupt */ -#define SC16IS7XX_CMND_START_TX (1) /* Enable the TX holding register empty interrupt */ -#define SC16IS7XX_CMND_STOP_TX (2) /* Disable the TX holding register empty interrupt */ -#define SC16IS7XX_CMND_NEW_TERMIOS (3) /* Apply new termios configuration */ -#define SC16IS7XX_CMND_BREAK_CTRL(4) -#define SC16IS7XX_CMND_TX_RX (5) - -#define SC16IS7XX_CLEAR_FIFO_ON_TX /* If defined controller will clear tx fifo before it transmits chars */ +#define SC16IS7XX_CMND_STOP_RX (0) /* Disable the RX interrupt */ +#define SC16IS7XX_CMND_START_TX(1) /* Enable the TX holding register +* empty interrupt +*/
[PATCH 1/1] Drivers: hv: vmbus: Include the limit on the number of pfns we can handle
Increase the maximum number of pfns we can handle is a single vmbus packet. Signed-off-by: K. Y. Srinivasan --- include/linux/hyperv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index 330ec44..ab7359f 100644 --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -37,7 +37,7 @@ #include -#define MAX_PAGE_BUFFER_COUNT 19 +#define MAX_PAGE_BUFFER_COUNT 32 #define MAX_MULTIPAGE_BUFFER_COUNT 32 /* 128K */ #pragma pack(push, 1) -- 1.7.4.1 -- 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 14/52] powerpc, sysfs: Fix CPU hotplug callback registration
Hello Ben, On Fri, Mar 07, 2014 at 01:57:31PM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2014-02-14 at 13:22 +0530, Srivatsa S. Bhat wrote: > > Subsystems that want to register CPU hotplug callbacks, as well as perform > > initialization for the CPUs that are already online, often do it as shown > > below: > > > > get_online_cpus(); > > > > for_each_online_cpu(cpu) > > init_cpu(cpu); > > > > register_cpu_notifier(_cpu_notifier); > > > > put_online_cpus(); > > This patch breaks a good half of my test configs with: > > /home/benh/linux-powerpc-test/arch/powerpc/kernel/sysfs.c: In function > 'topology_init': > /home/benh/linux-powerpc-test/arch/powerpc/kernel/sysfs.c:979:2: error: > implicit declaration of function 'cpu_notifier_register_begin' > [-Werror=implicit-function-declaration] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/sysfs.c:1004:2: error: > implicit declaration of function '__register_cpu_notifier' > [-Werror=implicit-function-declaration] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/sysfs.c:1006:2: error: > implicit declaration of function 'cpu_notifier_register_done' > [-Werror=implicit-function-declaration] > cc1: all warnings being treated as errors > make[2]: *** [arch/powerpc/kernel/sysfs.o] Error 1 > make[2]: *** Waiting for unfinished jobs This patch depends on "[PATCH v2 02/52] CPU hotplug: Provide lockless versions of callback registration functions" of the series (Can be found here: https://lkml.org/lkml/2014/2/14/59). This particular patch defines 'cpu_notifier_register_begin', '__register_cpu_notifier', and 'cpu_notifier_register_done' in the cpu-hotplug core. Are you seeing the build breakage with this patch on ? -- Thanks and Regards gautham. -- 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: slub: fix leak of 'name' in sysfs_slab_add
[adding Andrew to Cc]
On 03/07/2014 01:11 AM, Dave Jones wrote:
> The failure paths of sysfs_slab_add don't release the allocation of 'name'
> made by create_unique_id() a few lines above the context of the diff below.
> Create a common exit path to make it more obvious what needs freeing.
>
> Signed-off-by: Dave Jones
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 25f14ad8f817..b2181d2682ac 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5197,17 +5197,13 @@ static int sysfs_slab_add(struct kmem_cache *s)
>
> s->kobj.kset = slab_kset;
> err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
> - if (err) {
> - kobject_put(>kobj);
> - return err;
> - }
> + if (err)
> + goto err_out;
>
> err = sysfs_create_group(>kobj, _attr_group);
> - if (err) {
> - kobject_del(>kobj);
> - kobject_put(>kobj);
> - return err;
> - }
> + if (err)
> + goto err_sysfs;
> +
> kobject_uevent(>kobj, KOBJ_ADD);
> if (!unmergeable) {
> /* Setup first alias */
> @@ -5215,6 +5211,13 @@ static int sysfs_slab_add(struct kmem_cache *s)
> kfree(name);
> }
> return 0;
> +
> +err_sysfs:
> + kobject_del(>kobj);
> +err_out:
> + kobject_put(>kobj);
> + kfree(name);
> + return err;
> }
We should free the name only if !unmergeable, because:
sysfs_slab_add():
if (unmergeable) {
/*
* Slabcache can never be merged so we can use the name proper.
* This is typically the case for debug situations. In that
* case we can catch duplicate names easily.
*/
sysfs_remove_link(_kset->kobj, s->name);
name = s->name;
} else {
/*
* Create a unique name for the slab as a target
* for the symlinks.
*/
name = create_unique_id(s);
}
Since this function was modified in the mmotm tree, I would propose
something like this on top of mmotm to avoid further merge conflicts:
diff --git a/mm/slub.c b/mm/slub.c
index c6eb29d65847..f4ca525c05b0 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5214,25 +5214,19 @@ static int sysfs_slab_add(struct kmem_cache *s)
s->kobj.kset = cache_kset(s);
err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
- if (err) {
- kobject_put(>kobj);
- return err;
- }
+ if (err)
+ goto out_put_kobj;
err = sysfs_create_group(>kobj, _attr_group);
- if (err) {
- kobject_del(>kobj);
- kobject_put(>kobj);
- return err;
- }
+ if (err)
+ goto out_del_kobj;
#ifdef CONFIG_MEMCG_KMEM
if (is_root_cache(s)) {
s->memcg_kset = kset_create_and_add("cgroup", NULL, >kobj);
if (!s->memcg_kset) {
- kobject_del(>kobj);
- kobject_put(>kobj);
- return -ENOMEM;
+ err = -ENOMEM;
+ goto out_del_kobj;
}
}
#endif
@@ -5241,9 +5235,16 @@ static int sysfs_slab_add(struct kmem_cache *s)
if (!unmergeable) {
/* Setup first alias */
sysfs_slab_alias(s, s->name);
- kfree(name);
}
- return 0;
+out:
+ if (!unmergeable)
+ kfree(name);
+ return err;
+out_del_kobj:
+ kobject_del(>kobj);
+out_put_kobj:
+ kobject_put(>kobj);
+ goto out;
}
static void sysfs_slab_remove(struct kmem_cache *s)
--
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-next: build warning after merge of the gpio tree
On Fri, Mar 7, 2014 at 11:59 AM, Stephen Rothwell wrote:
> Hi Linus,
>
> After merging the gpio tree, today's (and yesterday's) linux-next build
> (x86_64 allmodconfig among others) produced this warning:
>
> kernel/irq/Kconfig:41:error: recursive dependency detected!
> kernel/irq/Kconfig:41: symbol GENERIC_IRQ_CHIP is selected by GPIO_DWAPB
> drivers/gpio/Kconfig:131: symbol GPIO_DWAPB depends on IRQ_DOMAIN
> kernel/irq/Kconfig:46: symbol IRQ_DOMAIN is selected by GENERIC_IRQ_CHIP
>
> Caused by commit 7779b3455697 ("gpio: add a driver for the Synopsys
> DesignWare APB GPIO block").
Thanks Stephen, I merged a patch from Alan Tull earlier today fixing this
problem.
Yours,
Linus Walleij
--
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] usb/core/hub.c: return immediately when hub_port_init hits timedout
From: "xinhui.pan"
some devices go crasy, we can't resume it even after reset. This case will
cause timeout again and again. What is worse, if there is a watchdog,
panic will be generated as timer expires. To prevent this, we just return
-ENODEV immediately. Later it will be re-enumerated.
Signed-off-by: xinhui.pan
---
drivers/usb/core/hub.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 64ea219..c5d0d8d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4141,7 +4141,7 @@ hub_port_init (struct usb_hub *hub, struct usb_device
*udev, int port1,
r = -EPROTO;
break;
}
- if (r == 0)
+ if (r == 0 || r == -ETIMEDOUT)
break;
}
udev->descriptor.bMaxPacketSize0 =
@@ -4161,6 +4161,10 @@ hub_port_init (struct usb_hub *hub, struct usb_device
*udev, int port1,
if (r != -ENODEV)
dev_err(>dev, "device descriptor
read/64, error %d\n",
r);
+ if (r == -ETIMEDOUT) {
+ retval = -ENODEV;
+ goto fail;
+ }
retval = -EMSGSIZE;
continue;
}
--
1.7.9.5
--
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/RFT v3 6/9] powerpc: move cacheinfo sysfs to generic cacheinfo infrastructure
On 03/07/2014 09:36 AM, Anshuman Khandual wrote:
> On 02/19/2014 09:36 PM, Sudeep Holla wrote:
>> From: Sudeep Holla
>>
>> This patch removes the redundant sysfs cacheinfo code by making use of
>> the newly introduced generic cacheinfo infrastructure.
>>
>> Signed-off-by: Sudeep Holla
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: linuxppc-...@lists.ozlabs.org
>> ---
>> arch/powerpc/kernel/cacheinfo.c | 831
>> ++--
>> arch/powerpc/kernel/cacheinfo.h | 8 -
>> arch/powerpc/kernel/sysfs.c | 4 -
>> 3 files changed, 109 insertions(+), 734 deletions(-)
>> delete mode 100644 arch/powerpc/kernel/cacheinfo.h
>>
>> diff --git a/arch/powerpc/kernel/cacheinfo.c
>> b/arch/powerpc/kernel/cacheinfo.c
>> index 2912b87..05b7580 100644
>> --- a/arch/powerpc/kernel/cacheinfo.c
>> +++ b/arch/powerpc/kernel/cacheinfo.c
>> @@ -10,38 +10,10 @@
>> * 2 as published by the Free Software Foundation.
>> */
>>
>> +#include
>> #include
>> -#include
>> #include
>> -#include
>> -#include
>> -#include
>> #include
>> -#include
>> -#include
>> -#include
>> -
>> -#include "cacheinfo.h"
>> -
>> -/* per-cpu object for tracking:
>> - * - a "cache" kobject for the top-level directory
>> - * - a list of "index" objects representing the cpu's local cache hierarchy
>> - */
>> -struct cache_dir {
>> -struct kobject *kobj; /* bare (not embedded) kobject for cache
>> - * directory */
>> -struct cache_index_dir *index; /* list of index objects */
>> -};
>> -
>> -/* "index" object: each cpu's cache directory has an index
>> - * subdirectory corresponding to a cache object associated with the
>> - * cpu. This object's lifetime is managed via the embedded kobject.
>> - */
>> -struct cache_index_dir {
>> -struct kobject kobj;
>> -struct cache_index_dir *next; /* next index in parent directory */
>> -struct cache *cache;
>> -};
>>
>> /* Template for determining which OF properties to query for a given
>> * cache type */
>> @@ -60,11 +32,6 @@ struct cache_type_info {
>> const char *nr_sets_prop;
>> };
>>
>> -/* These are used to index the cache_type_info array. */
>> -#define CACHE_TYPE_UNIFIED 0
>> -#define CACHE_TYPE_INSTRUCTION 1
>> -#define CACHE_TYPE_DATA2
>> -
>> static const struct cache_type_info cache_type_info[] = {
>> {
>> /* PowerPC Processor binding says the [di]-cache-*
>> @@ -77,246 +44,115 @@ static const struct cache_type_info cache_type_info[]
>> = {
>> .nr_sets_prop= "d-cache-sets",
>> },
>> {
>> -.name= "Instruction",
>> -.size_prop = "i-cache-size",
>> -.line_size_props = { "i-cache-line-size",
>> - "i-cache-block-size", },
>> -.nr_sets_prop= "i-cache-sets",
>> -},
>> -{
>> .name= "Data",
>> .size_prop = "d-cache-size",
>> .line_size_props = { "d-cache-line-size",
>> "d-cache-block-size", },
>> .nr_sets_prop= "d-cache-sets",
>> },
>> +{
>> +.name= "Instruction",
>> +.size_prop = "i-cache-size",
>> +.line_size_props = { "i-cache-line-size",
>> + "i-cache-block-size", },
>> +.nr_sets_prop= "i-cache-sets",
>> +},
>> };
>
>
> Hey Sudeep,
>
> After applying this patch, the cache_type_info array looks like this.
>
> static const struct cache_type_info cache_type_info[] = {
> {
> /*
> * PowerPC Processor binding says the [di]-cache-*
> * must be equal on unified caches, so just use
> * d-cache properties.
> */
> .name= "Unified",
> .size_prop = "d-cache-size",
> .line_size_props = { "d-cache-line-size",
> "d-cache-block-size", },
> .nr_sets_prop= "d-cache-sets",
> },
> {
> .name= "Data",
> .size_prop = "d-cache-size",
> .line_size_props = { "d-cache-line-size",
> "d-cache-block-size", },
> .nr_sets_prop= "d-cache-sets",
> },
> {
> .name= "Instruction",
> .size_prop = "i-cache-size",
> .line_size_props = { "i-cache-line-size",
> "i-cache-block-size", },
> .nr_sets_prop= "i-cache-sets",
> },
> };
>
> and this function computes the the array index for any given cache type
> define for PowerPC.
>
> static inline int get_cacheinfo_idx(enum cache_type type)
> {
> if (type == CACHE_TYPE_UNIFIED)
> return
[PATCH v3] phy: ti-pipe3: Add SATA DPLL support
From: Roger Quadros
USB and SATA DPLLs need different settings. Provide
the SATA DPLL settings and use the proper DPLL settings
based on device tree node's compatible_id.
Signed-off-by: Roger Quadros
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v2:
* kept only the drivers/phy part
drivers/phy/phy-ti-pipe3.c | 76
1 file changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 211703c..f141237 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -66,6 +66,11 @@ struct pipe3_dpll_params {
u32 mf;
};
+struct pipe3_dpll_map {
+ unsigned long rate;
+ struct pipe3_dpll_params params;
+};
+
struct ti_pipe3 {
void __iomem*pll_ctrl_base;
struct device *dev;
@@ -73,20 +78,27 @@ struct ti_pipe3 {
struct clk *wkupclk;
struct clk *sys_clk;
struct clk *refclk;
+ struct pipe3_dpll_map *dpll_map;
};
-struct pipe3_dpll_map {
- unsigned long rate;
- struct pipe3_dpll_params params;
-};
-
-static struct pipe3_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map_usb[] = {
{1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */
{2000, {1000, 7, 4, 10, 0} }, /* 20 MHz */
{2600, {1250, 12, 4, 20, 0} }, /* 26 MHz */
{3840, {3125, 47, 4, 20, 92843} }, /* 38.4 MHz */
+ { },/* Terminator */
+};
+
+static struct pipe3_dpll_map dpll_map_sata[] = {
+ {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
+ {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
+ {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+ {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
+ {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
+ {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
+ { },/* Terminator */
};
static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset)
@@ -100,15 +112,20 @@ static inline void ti_pipe3_writel(void __iomem *addr,
unsigned offset,
__raw_writel(data, addr + offset);
}
-static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(struct ti_pipe3 *phy)
{
- int i;
+ unsigned long rate;
+ struct pipe3_dpll_map *dpll_map = phy->dpll_map;
- for (i = 0; i < ARRAY_SIZE(dpll_map); i++) {
- if (rate == dpll_map[i].rate)
- return _map[i].params;
+ rate = clk_get_rate(phy->sys_clk);
+
+ for (; dpll_map->rate; dpll_map++) {
+ if (rate == dpll_map->rate)
+ return _map->params;
}
+ dev_err(phy->dev, "No DPLL configuration for %lu Hz SYS CLK\n", rate);
+
return NULL;
}
@@ -182,16 +199,11 @@ static void ti_pipe3_dpll_relock(struct ti_pipe3 *phy)
static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy)
{
u32 val;
- unsigned long rate;
struct pipe3_dpll_params *dpll_params;
- rate = clk_get_rate(phy->sys_clk);
- dpll_params = ti_pipe3_get_dpll_params(rate);
- if (!dpll_params) {
- dev_err(phy->dev,
- "No DPLL configuration for %lu Hz SYS CLK\n", rate);
+ dpll_params = ti_pipe3_get_dpll_params(phy);
+ if (!dpll_params)
return -EINVAL;
- }
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION1);
val &= ~PLL_REGN_MASK;
@@ -244,6 +256,10 @@ static struct phy_ops ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct of_device_id ti_pipe3_id_table[];
+#endif
+
static int ti_pipe3_probe(struct platform_device *pdev)
{
struct ti_pipe3 *phy;
@@ -253,8 +269,10 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct device_node *control_node;
struct platform_device *control_pdev;
+ const struct of_device_id *match;
- if (!node)
+ match = of_match_device(of_match_ptr(ti_pipe3_id_table), >dev);
+ if (!match)
return -EINVAL;
phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
@@ -263,6 +281,12 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ phy->dpll_map = (struct pipe3_dpll_map *)match->data;
+ if (!phy->dpll_map) {
+ dev_err(>dev, "no DPLL data\n");
+ return -EINVAL;
+ }
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pll_ctrl");
[PATCH 0/2] i2c: designware-pci: extra features for PCI mode LPSS I2C
From: Chew, Chiau Ee These two patches contains the additional changes required for BayTrail LPSS I2C on top of the patch that Mika Westerberg has submitted previously which is still in the pending queue: "[PATCH v2] i2c: designware-pci: Add Baytrail PCI IDs" http://www.spinics.net/lists/linux-i2c/msg14709.html Basically, the changes inclusive of: i. enable the pci glue layer to pass in target HCNT, LCNT and SDA hold time values to core layer if they are known beforehand, eg: for BayTrail. ii. declare the BayTrail LPSS I2C controllers are capable of supporting 10-bit addressing mode functionality. Chew, Chiau Ee (2): i2c: designware-pci: add 10-bit addressing mode functionality for BYT I2C i2c: designware-pci: set ideal HCNT, LCNT and SDA hold time value drivers/i2c/busses/i2c-designware-pcidrv.c | 51 --- 1 files changed, 45 insertions(+), 6 deletions(-) -- 1.7.4.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/2] i2c: designware-pci: add 10-bit addressing mode functionality for BYT I2C
From: Chew, Chiau Ee
All the I2C controllers on Intel BayTrail LPSS subsystem able
to support 10-bit addressing mode functionality.
Signed-off-by: Chew, Chiau Ee
Signed-off-by: Ong, Boon Leong
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index f1dabee..87f2fc4 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -64,12 +64,19 @@ struct dw_pci_controller {
u32 tx_fifo_depth;
u32 rx_fifo_depth;
u32 clk_khz;
+ u32 functionality;
};
#define INTEL_MID_STD_CFG (DW_IC_CON_MASTER | \
DW_IC_CON_SLAVE_DISABLE | \
DW_IC_CON_RESTART_EN)
+#define DW_DEFAULT_FUNCTIONALITY (I2C_FUNC_I2C | \
+ I2C_FUNC_SMBUS_BYTE | \
+ I2C_FUNC_SMBUS_BYTE_DATA | \
+ I2C_FUNC_SMBUS_WORD_DATA | \
+ I2C_FUNC_SMBUS_I2C_BLOCK)
+
static struct dw_pci_controller dw_pci_controllers[] = {
[moorestown_0] = {
.bus_num = 0,
@@ -140,6 +147,7 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .functionality = I2C_FUNC_10BIT_ADDR,
},
};
static struct i2c_algorithm i2c_dw_algo = {
@@ -256,12 +264,9 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
dev->get_clk_rate_khz = i2c_dw_get_clk_rate_khz;
dev->base = pcim_iomap_table(pdev)[0];
dev->dev = >dev;
- dev->functionality =
- I2C_FUNC_I2C |
- I2C_FUNC_SMBUS_BYTE |
- I2C_FUNC_SMBUS_BYTE_DATA |
- I2C_FUNC_SMBUS_WORD_DATA |
- I2C_FUNC_SMBUS_I2C_BLOCK;
+ dev->functionality = controller->functionality |
+ DW_DEFAULT_FUNCTIONALITY;
+
dev->master_cfg = controller->bus_cfg;
pci_set_drvdata(pdev, dev);
--
1.7.4.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 2/2] i2c: designware-pci: set ideal HCNT, LCNT and SDA hold time value
From: Chew, Chiau Ee
On Intel BayTrail, there was case whereby the resulting fast mode
bus speed becomes slower (~20% slower compared to expected speed)
if using the HCNT/LCNT calculated in the core layer. Thus, this
patch is added to allow pci glue layer to pass in optimal
HCNT/LCNT/SDA hold time values to core layer since the core
layer supports cofigurable HCNT/LCNT/SDA hold time values now.
Signed-off-by: Chew, Chiau Ee
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 34
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 87f2fc4..96417ca 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -58,6 +58,14 @@ enum dw_pci_ctl_id_t {
baytrail,
};
+struct scl_sda_cfg {
+ u32 ss_hcnt;
+ u32 fs_hcnt;
+ u32 ss_lcnt;
+ u32 fs_lcnt;
+ u32 sda_hold;
+};
+
struct dw_pci_controller {
u32 bus_num;
u32 bus_cfg;
@@ -65,6 +73,7 @@ struct dw_pci_controller {
u32 rx_fifo_depth;
u32 clk_khz;
u32 functionality;
+ struct scl_sda_cfg *scl_sda_cfg;
};
#define INTEL_MID_STD_CFG (DW_IC_CON_MASTER | \
@@ -77,6 +86,21 @@ struct dw_pci_controller {
I2C_FUNC_SMBUS_WORD_DATA | \
I2C_FUNC_SMBUS_I2C_BLOCK)
+/* BayTrail HCNT/LCNT/SDA_HOLD */
+#define BYT_STD_MODE_HCNT 0x200
+#define BYT_STD_MODE_LCNT BYT_STD_MODE_HCNT
+#define BYT_FAST_MODE_HCNT 0x55
+#define BYT_FAST_MODE_LCNT 0x99
+#define BYT_SDA_HOLD 0x6
+
+static struct scl_sda_cfg byt_config = {
+ .ss_hcnt= BYT_STD_MODE_HCNT,
+ .fs_hcnt= BYT_FAST_MODE_HCNT,
+ .ss_lcnt= BYT_STD_MODE_LCNT,
+ .fs_lcnt= BYT_FAST_MODE_LCNT,
+ .sda_hold = BYT_SDA_HOLD,
+};
+
static struct dw_pci_controller dw_pci_controllers[] = {
[moorestown_0] = {
.bus_num = 0,
@@ -148,6 +172,7 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.rx_fifo_depth = 32,
.clk_khz = 10,
.functionality = I2C_FUNC_10BIT_ADDR,
+ .scl_sda_cfg = _config,
},
};
static struct i2c_algorithm i2c_dw_algo = {
@@ -231,6 +256,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
struct i2c_adapter *adap;
int r;
struct dw_pci_controller *controller;
+ struct scl_sda_cfg *cfg;
if (id->driver_data >= ARRAY_SIZE(dw_pci_controllers)) {
dev_err(>dev, "%s: invalid driver data %ld\n", __func__,
@@ -268,6 +294,14 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
DW_DEFAULT_FUNCTIONALITY;
dev->master_cfg = controller->bus_cfg;
+ if (controller->scl_sda_cfg) {
+ cfg = controller->scl_sda_cfg;
+ dev->ss_hcnt = cfg->ss_hcnt;
+ dev->fs_hcnt = cfg->fs_hcnt;
+ dev->ss_lcnt = cfg->ss_lcnt;
+ dev->fs_lcnt = cfg->fs_lcnt;
+ dev->sda_hold_time = cfg->sda_hold;
+ }
pci_set_drvdata(pdev, dev);
--
1.7.4.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 v3] phy: omap-control: update dra7 and am437 usb2 bindings
On 3/7/2014 11:18 AM, Kishon Vijay Abraham I wrote:
From: Roger Quadros
The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.
Signed-off-by: Roger Quadros
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v2:
Kept only the drivers/phy part in this patch
drivers/phy/phy-omap-control.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 17fc200..a7e2d7f 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -228,11 +228,11 @@ static const struct of_device_id
omap_control_phy_id_table[] = {
.data = _data,
},
{
- .compatible = "ti,control-phy-dra7usb2",
+ .compatible = "ti,control-phy-dra7-usb2",
.data = _data,
},
{
- .compatible = "ti,control-phy-am437usb2",
+ .compatible = "ti,control-phy-am437-usb2",
Tony suggested to keep the compatible
ti,control-phy-usb2-dra7 and ti,control-phy-usb2-am437
http://www.spinics.net/lists/linux-omap/msg104040.html
Since we already have a ti,control-phy-usb2 I think it make sense to keep the
new comaptible for dra7 and am437 as above.
.data = _data,
},
{},
--
-George
--
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: PROBLEM: Inotify leaks file descriptors.
I was running code related to the python script -- multiple threads doing inotify things in parallel, using watchman, and I got the following Oops: [152513.914195] watchman[4963]: segfault at 7ff04ddb09d0 ip 7ff05b831f60 sp 7ff04c5acce8 error 4 in libpthread-2.15.so[7ff05b825000+18000] [152516.577861] watchman[6138]: segfault at 7f1962e099d0 ip 7f1970489f60 sp 7f1962406ce8 error 4 in libpthread-2.15.so[7f197047d000+18000] [153010.703990] BUG: unable to handle kernel NULL pointer dereference at (null) [153010.704036] IP: [< (null)>] (null) [153010.704060] PGD 1b1b4e067 PUD 1cc1f1067 PMD 0 [153010.704084] Oops: 0010 [#1] SMP [153010.704103] Modules linked in: btrfs raid6_pq zlib_deflate xor ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs reiserfs usb_storage cdc_acm joydev pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) vboxdrv(OF) bnep rfcomm bluetooth parport_pc ppdev uvcvideo videobuf2_core binfmt_misc videodev snd_hda_codec_hdmi snd_hda_codec_conexant videobuf2_vmalloc videobuf2_memops snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi iwldvm mac80211 snd_seq_midi_event snd_seq psmouse thinkpad_acpi snd_timer snd_seq_device iwlwifi nvram serio_raw snd tpm_tis cfg80211 soundcore snd_page_alloc mac_hid mei_me mei lpc_ich lp ext2 parport dm_crypt i915 drm_kms_helper e1000e wmi drm ptp pps_core ahci libahci sdhci_pci sdhci i2c_algo_bit video [153010.704453] CPU: 1 PID: 3586 Comm: watchman Tainted: GF W O 3.11.0-17-generic #31~precise1-Ubuntu [153010.704493] Hardware name: LENOVO 4177Q5U/4177Q5U, BIOS 83ET76WW (1.46 ) 07/05/2013 [153010.704529] task: 8801b6ae ti: 88009ed3 task.ti: 88009ed3 [153010.704564] RIP: 0010:[<>] [< (null)>] (null) [153010.704600] RSP: 0018:88009ed31dc0 EFLAGS: 00010246 [153010.704624] RAX: b98ab901 RBX: 88015a9b5228 RCX: 000188d0 [153010.704655] RDX: b98a RSI: 880100b95c00 RDI: 88015a9b5228 [153010.704686] RBP: 88009ed31dd8 R08: 0001 R09: ead85640 [153010.704718] R10: 811f9628 R11: R12: 88015a9b5228 [153010.704750] R13: 880100b95ca0 R14: R15: 880100b95c00 [153010.704783] FS: 7f5b19087700() GS:88021e24() knlGS: [153010.704819] CS: 0010 DS: ES: CR0: 80050033 [153010.704846] CR2: CR3: 0001dd9d1000 CR4: 000427e0 [153010.704877] Stack: [153010.704888] 811f7120 88015a9b5228 8801e460c7f0 88009ed31e28 [153010.704926] 811f7847 88009ed31e18 880100b95c70 88009ed31f50 [153010.704965] 880100b95c00 0010 8802120433c0 8802120433c0 [153010.705005] Call Trace: [153010.705024] [] ? fsnotify_put_mark+0x30/0x40 [153010.705054] [] fsnotify_clear_marks_by_group_flags+0x87/0xb0 [153010.705088] [] fsnotify_clear_marks_by_group+0x13/0x20 [153010.705119] [] fsnotify_destroy_group+0x16/0x40 [153010.705150] [] inotify_release+0x26/0x50 [153010.705177] [] __fput+0xba/0x240 [153010.705201] [] fput+0xe/0x10 [153010.705226] [] task_work_run+0xc8/0xf0 [153010.706464] [] do_notify_resume+0xac/0xc0 [153010.707730] [] int_signal+0x12/0x17 [153010.708933] Code: Bad RIP value. [153010.710089] RIP [< (null)>] (null) [153010.711251] RSP [153010.712319] CR2: [153010.718669] ---[ end trace 17ed2927fe522cd1 ]--- -- 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] virtio-scsi: Change sense buffer size to 252
On Thu, 03/06 12:55, Paolo Bonzini wrote:
> Il 06/03/2014 12:22, Hannes Reinecke ha scritto:
> >On 03/06/2014 11:09 AM, Paolo Bonzini wrote:
> >>Il 06/03/2014 09:47, Fam Zheng ha scritto:
> >>>According to SPC-4, section 4.5.2.1, 252 is the limit of sense
> >>>data. So
> >>>increase the value.
> >>>
> >>>Signed-off-by: Fam Zheng
> >>>---
> >>> include/linux/virtio_scsi.h | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>>diff --git a/include/linux/virtio_scsi.h
> >>>b/include/linux/virtio_scsi.h
> >>>index 4195b97..a437f7f 100644
> >>>--- a/include/linux/virtio_scsi.h
> >>>+++ b/include/linux/virtio_scsi.h
> >>>@@ -28,7 +28,7 @@
> >>> #define _LINUX_VIRTIO_SCSI_H
> >>>
> >>> #define VIRTIO_SCSI_CDB_SIZE 32
> >>>-#define VIRTIO_SCSI_SENSE_SIZE 96
> >>>+#define VIRTIO_SCSI_SENSE_SIZE 252
> >>>
> >>> /* SCSI command request, followed by data-out */
> >>> struct virtio_scsi_cmd_req {
> >>>
> >>
> >>Hi Fam, how did you test this?
> >
> >Is there a specific reason _not_ to use the linux default?
> >The SCSI stack typically limits the sense code to
> >SCSI_SENSE_BUFFERSIZE, so using other values have a
> >limited sense.
> >Literally :-)
OK. So, do we need to lift the limit on other parts of SCSI stack as well?
>
> Indeed I don't think this patch makes a difference. Though I asked not from
> the SCSI stack perspective, but because right now both virtio-scsi targets
> (QEMU and vhost-scsi) are also truncating at 96.
>
Oh, I missed that, I'll do a more thorough review and testing. Thank you for
pointing out.
Thanks,
Fam
--
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] phy: ti-pipe3: cleanup clock handling
From: Roger Quadros
As this driver is no longer USB specific, use generic clock names.
- Fix PLL_SD_SHIFT from 9 to 10
- Don't separate prepare/unprepare clock from enable/disable. This
ensures optimal power savings.
Signed-off-by: Roger Quadros
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v2:
* Kept only the drivers/phy part in this patch
drivers/phy/phy-ti-pipe3.c | 55 ++--
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index fd029b1..211703c 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -45,7 +45,7 @@
#definePLL_SELFREQDCO_MASK 0x000E
#definePLL_SELFREQDCO_SHIFT0x1
#definePLL_SD_MASK 0x0003FC00
-#definePLL_SD_SHIFT0x9
+#definePLL_SD_SHIFT10
#defineSET_PLL_GO 0x1
#definePLL_TICOPWDN0x1
#definePLL_LOCK0x2
@@ -72,7 +72,7 @@ struct ti_pipe3 {
struct device *control_dev;
struct clk *wkupclk;
struct clk *sys_clk;
- struct clk *optclk;
+ struct clk *refclk;
};
struct pipe3_dpll_map {
@@ -270,23 +270,21 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->dev= >dev;
- phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
+ phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
if (IS_ERR(phy->wkupclk)) {
- dev_err(>dev, "unable to get usb_phy_cm_clk32k\n");
+ dev_err(>dev, "unable to get wkupclk\n");
return PTR_ERR(phy->wkupclk);
}
- clk_prepare(phy->wkupclk);
- phy->optclk = devm_clk_get(phy->dev, "usb_otg_ss_refclk960m");
- if (IS_ERR(phy->optclk)) {
- dev_err(>dev, "unable to get usb_otg_ss_refclk960m\n");
- return PTR_ERR(phy->optclk);
+ phy->refclk = devm_clk_get(phy->dev, "refclk");
+ if (IS_ERR(phy->refclk)) {
+ dev_err(>dev, "unable to get refclk\n");
+ return PTR_ERR(phy->refclk);
}
- clk_prepare(phy->optclk);
- phy->sys_clk = devm_clk_get(phy->dev, "sys_clkin");
+ phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
if (IS_ERR(phy->sys_clk)) {
- pr_err("%s: unable to get sys_clkin\n", __func__);
+ dev_err(>dev, "unable to get sysclk\n");
return -EINVAL;
}
@@ -326,10 +324,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
static int ti_pipe3_remove(struct platform_device *pdev)
{
- struct ti_pipe3 *phy = platform_get_drvdata(pdev);
-
- clk_unprepare(phy->wkupclk);
- clk_unprepare(phy->optclk);
if (!pm_runtime_suspended(>dev))
pm_runtime_put(>dev);
pm_runtime_disable(>dev);
@@ -343,8 +337,10 @@ static int ti_pipe3_runtime_suspend(struct device *dev)
{
struct ti_pipe3 *phy = dev_get_drvdata(dev);
- clk_disable(phy->wkupclk);
- clk_disable(phy->optclk);
+ if (!IS_ERR(phy->wkupclk))
+ clk_disable_unprepare(phy->wkupclk);
+ if (!IS_ERR(phy->refclk))
+ clk_disable_unprepare(phy->refclk);
return 0;
}
@@ -354,22 +350,27 @@ static int ti_pipe3_runtime_resume(struct device *dev)
u32 ret = 0;
struct ti_pipe3 *phy = dev_get_drvdata(dev);
- ret = clk_enable(phy->optclk);
- if (ret) {
- dev_err(phy->dev, "Failed to enable optclk %d\n", ret);
- goto err1;
+ if (!IS_ERR(phy->refclk)) {
+ ret = clk_prepare_enable(phy->refclk);
+ if (ret) {
+ dev_err(phy->dev, "Failed to enable refclk %d\n", ret);
+ goto err1;
+ }
}
- ret = clk_enable(phy->wkupclk);
- if (ret) {
- dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret);
- goto err2;
+ if (!IS_ERR(phy->wkupclk)) {
+ ret = clk_prepare_enable(phy->wkupclk);
+ if (ret) {
+ dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret);
+ goto err2;
+ }
}
return 0;
err2:
- clk_disable(phy->optclk);
+ if (!IS_ERR(phy->refclk))
+ clk_disable_unprepare(phy->refclk);
err1:
return ret;
--
1.7.9.5
--
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] virtio-scsi: Change sense buffer size to 252
On Thu, 03/06 11:09, Paolo Bonzini wrote:
> Il 06/03/2014 09:47, Fam Zheng ha scritto:
> >According to SPC-4, section 4.5.2.1, 252 is the limit of sense data. So
> >increase the value.
> >
> >Signed-off-by: Fam Zheng
> >---
> > include/linux/virtio_scsi.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
> >index 4195b97..a437f7f 100644
> >--- a/include/linux/virtio_scsi.h
> >+++ b/include/linux/virtio_scsi.h
> >@@ -28,7 +28,7 @@
> > #define _LINUX_VIRTIO_SCSI_H
> >
> > #define VIRTIO_SCSI_CDB_SIZE 32
> >-#define VIRTIO_SCSI_SENSE_SIZE 96
> >+#define VIRTIO_SCSI_SENSE_SIZE 252
> >
> > /* SCSI command request, followed by data-out */
> > struct virtio_scsi_cmd_req {
> >
>
> Hi Fam, how did you test this?
>
I only tested the basic functionality of virtio-scsi. I'm doing more testing on
this and your fix on QEMU side now.
Thanks,
Fam
--
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] [staging][r8188eu]: memory leak in rtw_free_cmd_obj if command is (_Set_Drv_Extra)
pcmd->parmbuf->pbuf has been allocated if command is
GEN_CMD_CODE(_Set_Drv_Extra),
and it enqueued by rtw_enqueue_cmd. rtw_cmd_thread dequeue pcmd by
rtw_dequeue_cmd.
The memory leak happened on this branch "if( _FAIL == rtw_cmd_filter(pcmdpriv,
pcmd) )"
which goto post_process directly against freeing pcmd->parmbuf->pbuf in
rtw_drvextra_cmd_hdl which is the cmd_hdl if command is (_Set_Drv_Extra).
This patch free pcmd->parmbuf->pbuf on forgotten branch to avoid memory leak.
Signed-off-by: Zhang Dongxing
Signed-off-by: xiaoming wang
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 82fe8c4..cec9db9 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -314,6 +314,7 @@ int rtw_cmd_thread(void *context)
void (*pcmd_callback)(struct adapter *dev, struct cmd_obj *pcmd);
struct adapter *padapter = (struct adapter *)context;
struct cmd_priv *pcmdpriv = &(padapter->cmdpriv);
+ struct drvextra_cmd_parm *extra_parm = NULL;
_func_enter_;
@@ -350,6 +351,11 @@ _next:
if (_FAIL == rtw_cmd_filter(pcmdpriv, pcmd)) {
pcmd->res = H2C_DROPPED;
+ if (pcmd->cmdcode == GEN_CMD_CODE(_Set_Drv_Extra)) {
+ extra_parm = (struct drvextra_cmd_parm
*)pcmd->parmbuf;
+ if (extra_parm && extra_parm->pbuf &&
extra_parm->size > 0)
+ rtw_mfree(extra_parm->pbuf,
extra_parm->size);
+ }
goto post_process;
}
--
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: WIP: sc16is7xx.c
On Thu, Mar 06, 2014 at 09:35:46PM -0500, j...@ringle.org wrote: > From: Jon Ringle > > I am requesting comments on this serial driver. > I am currently having some latency issues with it where I experience > packet loss at speed of 19200. > > I welcome any and all comments. The basic coding style problems make it hard to read to be able to help review it, sorry. Yes, brains have patterns, you want to follow the same patterns as others, it matters. thanks, greg k-h -- 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: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()
On Thu, Mar 06, 2014 at 09:03:50PM -0800, H. Peter Anvin wrote: > On 03/06/2014 05:58 PM, Fengguang Wu wrote: > > Hi all, > > > > I find the below WARNING shows up only in > > > > qemu-system-x86_64 -cpu qemu64,+smep,+smap > > > > Yes, it is because Qemu doesn't show the AMD-specific SMP CPUID bit. > It's harmless in that sense. > > Unfortunately these things are hard to fix in Qemu. OK. As an alternative, is it possible to pass one of the below CPUID flags in the Qemu command line, so as to quiet the warning? % qemu-system-x86_64 -cpu help x86 qemu64 QEMU Virtual CPU version 1.6.1 x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz x86kvm64 Common KVM processor x86 qemu32 QEMU Virtual CPU version 1.6.1 x86kvm32 Common 32-bit KVM processor x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz x86 486 x86 pentium x86 pentium2 x86 pentium3 x86 athlon QEMU Virtual CPU version 1.6.1 x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) x86 SandyBridge Intel Xeon E312xx (Sandy Bridge) x86 Haswell Intel Core Processor (Haswell) x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron) x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) x86 Opteron_G4 AMD Opteron 62xx class CPU x86 Opteron_G5 AMD Opteron 63xx class CPU x86 host KVM processor with all supported host features (only available in KVM mode) Recognized CPUID flags: pbe ia64 tm ht ss sse2 sse fxsr mmx acpi ds clflush pn pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de vme fpu hypervisor rdrand f16c avx osxsave xsave aes tsc-deadline popcnt movbe x2apic sse4.2|sse4_2 sse4.1|sse4_1 dca pcid pdcm xtpr cx16 fma cid ssse3 tm2 est smx vmx ds_cpl monitor dtes64 pclmulqdq|pclmuldq pni|sse3 smap adx rdseed rtm invpcid erms bmi2 smep avx2 hle bmi1 fsgsbase 3dnow 3dnowext lm|i64 rdtscp pdpe1gb fxsr_opt|ffxsr mmxext nx|xd syscall perfctr_nb perfctr_core topoext tbm nodeid_msr tce fma4 lwp wdt skinit xop ibs osvw 3dnowprefetch misalignsse sse4a abm cr8legacy extapic svm cmp_legacy lahf_lm pmm-en pmm phe-en phe ace2-en ace2 xcrypt-en xcrypt xstore-en xstore kvm_pv_eoi kvm_steal_time kvm_asyncpf kvmclock kvm_mmu kvm_nopiodelay kvmclock pfthreshold pause_filter decodeassists flushbyasid vmcb_clean tsc_scale nrip_save svm_lock lbrv npt Thanks, Fengguang -- 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] phy: omap-control: update dra7 and am437 usb2 bindings
From: Roger Quadros
The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.
Signed-off-by: Roger Quadros
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v2:
Kept only the drivers/phy part in this patch
drivers/phy/phy-omap-control.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 17fc200..a7e2d7f 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -228,11 +228,11 @@ static const struct of_device_id
omap_control_phy_id_table[] = {
.data = _data,
},
{
- .compatible = "ti,control-phy-dra7usb2",
+ .compatible = "ti,control-phy-dra7-usb2",
.data = _data,
},
{
- .compatible = "ti,control-phy-am437usb2",
+ .compatible = "ti,control-phy-am437-usb2",
.data = _data,
},
{},
--
1.7.9.5
--
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] pstore: reset ftrace_read_cnt at ramoops_pstore_open
On Thu, Mar 6, 2014 at 6:58 PM, Liu ShuoX wrote:
> On Tue 4.Mar'14 at 11:11:11 -0800, Kees Cook wrote:
>>
>> On Mon, Mar 3, 2014 at 5:40 PM, Liu ShuoX wrote:
>>>
>>> On Mon 3.Mar'14 at 11:45:59 -0800, Kees Cook wrote:
On Thu, Feb 27, 2014 at 10:37 PM, wrote:
>
>
> From: Liu ShuoX
>
> ftrace_read_cnt need to be reset in open to support mutli times
> getting the records.
>
> Signed-off-by: Liu ShuoX
> ---
> fs/pstore/ram.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index fa8cef2..a5d0cab 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -101,6 +101,7 @@ static int ramoops_pstore_open(struct pstore_info
> *psi)
>
> cxt->dump_read_cnt = 0;
> cxt->console_read_cnt = 0;
> + cxt->ftrace_read_cnt = 0;
> return 0;
> }
I think we need a separate function for "clear" for the
ramoops_context struct. IIUC, we're missing a similar initialization
in ramoops_probe, which lacks both console_read_cnt=0 and
ftrace_read_cnt=0. Then both places could call this?
>>>
>>>
>>> Hi Kees,
>>> Currently, we have only one static ramoops_context named oops_cxt.
>>> *_read_cnt should be initialized to 0 as default. Need we still add
>>> such function for 'clear'?
>>
>>
>> We have the pstore-global "oops_cxt" context. It is "initialized" only
>> once in ramoops_probe (and seems to needlessly set dump_read_cnt to
>> 0). Otherwise, the context is initialized via ramoops_register_dummy
>> from module parameters (and initialized to zero with kzalloc).
>>
>> So, I think my initial comment about "clear" is probably not right,
>> but that ramoops_pstore_open should be doing that (i.e. your original
>> patch is close). However, I think I'd like to see the needless zeroing
>> in ramoops_probe removed, and the "variables that need clearing on
>> open" documented in comments in "struct ramoops_context". That should
>> make this code more clear to read next time. :)
>
> Sorry for delay reply. How about below patch?
>
>
> From: Liu ShuoX
>
> ftrace_read_cnt need to be reset in open to support mutli times
> getting the records.
>
> Signed-off-by: Liu ShuoX
> ---
> fs/pstore/ram.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index fa8cef2..9fe5b13 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -86,6 +86,7 @@ struct ramoops_context {
> struct persistent_ram_ecc_info ecc_info;
> unsigned int max_dump_cnt;
> unsigned int dump_write_cnt;
> + /* _read_cnt need clear on ramoops_pstore_open */
> unsigned int dump_read_cnt;
> unsigned int console_read_cnt;
> unsigned int ftrace_read_cnt;
> @@ -101,6 +102,7 @@ static int ramoops_pstore_open(struct pstore_info *psi)
>
> cxt->dump_read_cnt = 0;
> cxt->console_read_cnt = 0;
> + cxt->ftrace_read_cnt = 0;
> return 0;
> }
> @@ -428,7 +430,6 @@ static int ramoops_probe(struct platform_device *pdev)
> if (pdata->ftrace_size && !is_power_of_2(pdata->ftrace_size))
> pdata->ftrace_size =
> rounddown_pow_of_two(pdata->ftrace_size);
> - cxt->dump_read_cnt = 0;
> cxt->size = pdata->mem_size;
> cxt->phys_addr = pdata->mem_address;
> cxt->record_size = pdata->record_size;
> --
> 1.8.3.2
>
Thanks! That looks right to me.
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Chrome OS Security
--
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 2/2] kallsyms: handle special absolute symbols
On Thu, Mar 6, 2014 at 7:25 PM, Rusty Russell wrote: > Kees Cook writes: >> This forces the entire per_cpu range to be reported as absolute without >> losing their linker symbol types. Without this, the variables are >> incorrectly shown as relocated under kASLR. > > I like these patches, thanks! Oh good! Glad this is getting closer. :) > This one's a bit broken, since the zero-based __per_cpu_start/end thing > is an x86-64-ism. You really do want them relocated on other > platforms, so I think you'll need do make this conditional via > a --per-cpu-absolute flag to kallsyms (which x86-64 would set). Ah, hm. Can this maybe just be dynamically detected (e.g. if __per_cpu_start == 0?), I'd hate to have another arch run into this glitch when we could "notice" it and deal with it instead. > Dumb Q: why don't we actually present these symbols as absolute in > /proc/kallsyms? Seems like it would be clearer... You mean set "sym[0] = 'A'" instead of the force_absolute thing I added? It seemed like I shouldn't mess with existing information, and as you say, they're not absolute on all platforms. -Kees -- Kees Cook Chrome OS Security -- 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: power_supply mailing list
On Sat, Feb 01, 2014 at 09:06:48AM -0700, Dmitry Eremin-Solenikov wrote: > Hello, > > On Thu, Jan 30, 2014 at 10:46 PM, Jenny Tc wrote: > > > > Do we have any mailing list for power_supply subsystem? If not what about > > having > > one - linux-power-sup...@vger.kernel.org? > > I'm not sure that if that ML will have enough traffic to be fully > usefull or enough > reviewers on it. However as currently most of the power_supply patches receive > a long list of To and Cc people, let's try that ML. > > > David, could you please create a mailing list for power_supply discussions? > Dmitry/David, Any update on this. Appreciate your help on this. Thanks Jenny -- 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/
linux-next: Tree for Mar 7
Hi all, I am on vacation for the next week. Mark or Thierry may do some releases during the week, otherwise the next linux-next will be next-20140317 (which will be about when -rc7 is released). This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140305: New trees: arm-kvm-cpuresume, powernv-cpuidle The powerpc tree still had its build failure. The wireless-next tree lost one if its build failures so I reverted a commit and disabled a staging driver. It also gained a conflict against the net-next tree. The char-misc tree still had its 2 build failures for which I reverted 2 commits. The akpm-current tree lost its build failure (a patch was supplied). The akpm tree lost its build failures. Non-merge commits (relative to Linus' tree): 6268 6776 files changed, 585647 insertions(+), 447033 deletions(-) (the shortstat with -M -C looks like this: 6173 files changed, 260027 insertions(+), 142456 deletions(-) so there is a bit of movement of files going on.) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 212 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (c3bebc71c4bc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (b36345759308 ARM: 7980/1: kernel: improve error message when LPAE config doesn't match CPU) Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and sched_getattr) Merging metag-fixes/fixes (f229006ec6be irq-metag*: stop set_affinity vectoring to offline cpus) Merging powerpc-merge/merge (e0cf95761497 powerpc/powernv: Fix indirect XSCOM unmangling) Merging sparc/master (e58e241c1788 sparc: serial: Clean up the locking for -rt) Merging net/master (c88507fbad80 ipv6: don't set DST_NOCOUNT for remotely added routes) Merging ipsec/master (3a9016f97fdc xfrm: Fix unlink race when policies are deleted.) Merging sound-current/for-linus (e805ca8b0a9b ALSA: usb-audio: Add quirk for Logitech Webcam C500) Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single MSI mode) Merging wireless/master (d51246481c7f mwifiex: save and copy AP's VHT capability info correctly) Merging driver-core.current/driver-core-linus (0414855fdc4a Linux 3.14-rc5) Merging tty.current/tty-linus (0414855fdc4a Linux 3.14-rc5) Merging usb.current/usb-linus (0414855fdc4a Linux 3.14-rc5) Merging staging.current/staging-linus (084b6e7765b9 staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()) Merging char-misc.current/char-misc-linus (0414855fdc4a Linux 3.14-rc5) Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct register bit for key status) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede ctr concurrency issue) Merging ide/master (a259d5320537 m68k/atari - ide: do not register interrupt if host->get_lock is set) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging
[PATCHv8 4/4] power_supply: bq24261 charger driver
This patch introduces BQ24261 charger driver. The driver makes use of power supply charging driver to setup charging. So the driver does hardware abstraction and handles h/w specific corner cases. The charging logic resides with power supply charging driver Signed-off-by: Jenny TC --- drivers/power/Kconfig | 10 + drivers/power/Makefile|1 + drivers/power/bq24261-charger.c | 1350 + include/linux/power/bq24261-charger.h | 25 + 4 files changed, 1386 insertions(+) create mode 100644 drivers/power/bq24261-charger.c create mode 100644 include/linux/power/bq24261-charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 54a0321..4ff080c 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -411,6 +411,16 @@ config BATTERY_GOLDFISH Say Y to enable support for the battery and AC power in the Goldfish emulator. +config CHARGER_BQ24261 + tristate "BQ24261 charger driver" + select POWER_SUPPLY_CHARGER + depends on I2C + help + Say Y to include support for BQ24261 Charger driver. This driver + makes use of power supply charging driver. So the driver gives + the charger hardware abstraction only. Charging logic is abstracted + in the power supply charging driver. + source "drivers/power/reset/Kconfig" endif # POWER_SUPPLY diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 77535fd..9dde895 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o +obj-$(CONFIG_CHARGER_BQ24261) += bq24261-charger.o obj-$(CONFIG_POWER_RESET) += reset/ diff --git a/drivers/power/bq24261-charger.c b/drivers/power/bq24261-charger.c new file mode 100644 index 000..187c1fe --- /dev/null +++ b/drivers/power/bq24261-charger.c @@ -0,0 +1,1350 @@ +/* + * bq24261-charger.c - BQ24261 Charger I2C client driver + * + * Copyright (C) 2011 Intel Corporation + * + * ~~ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that 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. + * + * ~~ + * Author: Jenny TC + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define DEV_NAME "bq24261_charger" +#define MODEL_NAME_SIZE 8 + +#define EXCEPTION_MONITOR_DELAY (60 * HZ) +#define WDT_RESET_DELAY (15 * HZ) + +/* BQ24261 registers */ +#define BQ24261_STAT_CTRL0_ADDR0x00 +#define BQ24261_CTRL_ADDR 0x01 +#define BQ24261_BATT_VOL_CTRL_ADDR 0x02 +#define BQ24261_VENDOR_REV_ADDR0x03 +#define BQ24261_TERM_FCC_ADDR 0x04 +#define BQ24261_VINDPM_STAT_ADDR 0x05 +#define BQ24261_ST_NTC_MON_ADDR0x06 + +#define BQ24261_RESET_MASK (0x01 << 7) +#define BQ24261_RESET_ENABLE (0x01 << 7) + +#define BQ24261_FAULT_MASK 0x07 +#define BQ24261_STAT_MASK (0x03 << 4) +#define BQ24261_BOOST_MASK (0x01 << 6) +#define BQ24261_TMR_RST_MASK (0x01 << 7) +#define BQ24261_TMR_RST(0x01 << 7) + +#define BQ24261_ENABLE_BOOST (0x01 << 6) + +#define BQ24261_VOVP 0x01 +#define BQ24261_LOW_SUPPLY 0x02 +#define BQ24261_THERMAL_SHUTDOWN 0x03 +#define BQ24261_BATT_TEMP_FAULT0x04 +#define BQ24261_TIMER_FAULT0x05 +#define BQ24261_BATT_OVP 0x06 +#define BQ24261_NO_BATTERY 0x07 +#define BQ24261_STAT_READY 0x00 + +#define BQ24261_STAT_CHRG_PRGRSS (0x01 << 4) +#define BQ24261_STAT_CHRG_DONE (0x02 << 4) +#define BQ24261_STAT_FAULT (0x03 << 4) + +#define BQ24261_CE_MASK(0x01 << 1) +#define BQ24261_CE_DISABLE (0x01 << 1) + +#define BQ24261_HZ_MASK(0x01) +#define BQ24261_HZ_ENABLE (0x01) + +#define BQ24261_ICHRG_MASK (0x1F << 3) +#define BQ24261_MIN_CC 500 /* 500mA */ +#define BQ24261_MAX_CC 3000 /* 3A */ + +#define BQ24261_ITERM_MASK (0x03) +#define BQ24261_MIN_ITERM 50 /* 50 mA */ +#define BQ24261_MAX_ITERM 300 /*
[PATCHv8 1/4] power_supply: Add inlmt,iterm, min/max temp props
Add new power supply properties for input current, charge termination
current, min and max temperature
POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature
POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates
the input current for a charging source.
POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect
the end of charge condition
Signed-off-by: Jenny TC
---
Documentation/power/power_supply_class.txt |6 ++
drivers/power/power_supply_sysfs.c |4
include/linux/power_supply.h |4
3 files changed, 14 insertions(+)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 89a8816..48cff88 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -118,6 +118,10 @@ relative, time-based measurements.
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
power supply object.
+INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
+the current drawn from a charging source.
+CHARGE_TERM_CURRENT - Charge termination current used to detect the end of
charge
+condition.
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
@@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert.
TEMP_AMBIENT - ambient temperature.
TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
+TEMP_MIN - minimum operatable temperature
+TEMP_MAX - maximum operatable temperature
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
while battery powers a load)
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 44420d1..750a202 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+ POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
@@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(capacity_alert_max),
POWER_SUPPLY_ATTR(capacity_level),
POWER_SUPPLY_ATTR(temp),
+ POWER_SUPPLY_ATTR(temp_max),
+ POWER_SUPPLY_ATTR(temp_min),
POWER_SUPPLY_ATTR(temp_alert_min),
POWER_SUPPLY_ATTR(temp_alert_max),
POWER_SUPPLY_ATTR(temp_ambient),
@@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
+ POWER_SUPPLY_ATTR(charge_term_current),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c9dc4e0..0278600 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -120,6 +120,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+ POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -131,6 +132,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TEMP_MAX,
+ POWER_SUPPLY_PROP_TEMP_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
@@ -142,6 +145,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
--
1.7.9.5
--
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/
[PATCHv8 0/4] power_supply: Introduce power supply charging driver
v1: introduced feature as a framework within power supply class driver with separate files for battid framework and charging framework v2: fixed review comments, moved macros and inline functions to power_supply.h v3: moved the feature as a separate driver, combined battid framework and charging framework inside the power supply charging driver. Moved charger specific properties to power_supply_charger.h and plugged the driver with power supply subsystem using power_supply_notifier introduced in my previous patch. Also a sample charger chip driver (bq24261) patch added to give more idea on the psy charging driver usage v4: Fixed review comments, no major design changes. v5: Fixed makefile inconsistencies, removed unused pdata callbacks v6: Fixed nested loops, commenting style v7: added kerneldocs for structs and minor fixes v8: used msecs_to_jiffies instead of HZ directly, modified Kconfig help text for POWER_SUPPLY_CHARGING_ALGO_PSE The Power Supply charging driver connects multiple subsystems to do charging in a generic way. The subsystems involves power_supply, thermal and battery communication subsystems (1wire).With this the charging is handled in a generic way. The driver makes use of different new features - Battery Identification interfaces, pluggable charging algorithms, charger cable arbitrations etc. The patch also introduces generic interface for charger cable notifications. Charger cable events and capabilities can be notified using the generic power_supply_notifier chain. Overall this driver removes the charging logic out of the charger chip driver and the charger chip driver can just listen to the request from the power supply charging driver to set the charger properties. This can be implemented by exposing get_property and set property callbacks. Jenny TC (4): power_supply: Add inlmt,iterm, min/max temp props power_supply: Introduce generic psy charging driver power_supply: Introduce PSE compliant algorithm power_supply: bq24261 charger driver Documentation/power/power_supply_charger.txt | 353 +++ Documentation/power/power_supply_class.txt |6 + drivers/power/Kconfig| 31 + drivers/power/Makefile |3 + drivers/power/bq24261-charger.c | 1350 ++ drivers/power/charging_algo_pse.c| 204 drivers/power/power_supply_charger.c | 1186 ++ drivers/power/power_supply_charger.h | 218 + drivers/power/power_supply_core.c|3 + drivers/power/power_supply_sysfs.c |4 + include/linux/power/bq24261-charger.h| 25 + include/linux/power/power_supply_charger.h | 341 +++ include/linux/power_supply.h | 164 13 files changed, 3888 insertions(+) create mode 100644 Documentation/power/power_supply_charger.txt create mode 100644 drivers/power/bq24261-charger.c create mode 100644 drivers/power/charging_algo_pse.c create mode 100644 drivers/power/power_supply_charger.c create mode 100644 drivers/power/power_supply_charger.h create mode 100644 include/linux/power/bq24261-charger.h create mode 100644 include/linux/power/power_supply_charger.h -- 1.7.9.5 -- 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/
[PATCHv8 3/4] power_supply: Introduce PSE compliant algorithm
As per Product Safety Engineering (PSE) specification for battery charging, the
battery characteristics and thereby the charging rates can vary on different
temperature zones. This patch introduces a PSE compliant charging algorithm with
maintenance charging support. The algorithm can be selected by the power supply
charging driver based on the type of the battery charging profile.
Signed-off-by: Jenny TC
---
drivers/power/Kconfig | 15 ++
drivers/power/Makefile |1 +
drivers/power/charging_algo_pse.c | 204
include/linux/power/power_supply_charger.h | 63 +
4 files changed, 283 insertions(+)
create mode 100644 drivers/power/charging_algo_pse.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f679f82..54a0321 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,21 @@ config POWER_SUPPLY_CHARGER
drivers to keep the charging logic outside and the charger driver
just need to abstract the charger hardware.
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+ bool "PSE compliant charging algorithm"
+ depends on POWER_SUPPLY_CHARGER
+ help
+ Say Y here to select Product Safety Engineering (PSE) compliant
+ charging algorithm. As per PSE standard the battery characteristics
+ and thereby the charging rates can vary on different temperature
+ zones. Select this if your charging algorithm need to change the
+ charging parameters based on the battery temperature and the battery
+ charging profile follows the struct psy_pse_chrg_prof definition.
+ This config will enable PSE compliant charging algorithm with
+ maintenance charging support. At runtime the algorithm will be
+ selected by the psy charger driver based on the type of the battery
+ charging profile.
+
config PDA_POWER
tristate "Generic PDA/phone power driver"
depends on !S390
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 405f0f4..77535fd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY) += power_supply.o
obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
+obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
diff --git a/drivers/power/charging_algo_pse.c
b/drivers/power/charging_algo_pse.c
new file mode 100644
index 000..ac95885
--- /dev/null
+++ b/drivers/power/charging_algo_pse.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ * ~~
+ * Author: Jenny TC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "power_supply.h"
+#include "power_supply_charger.h"
+
+/* 98% of CV is considered as voltage to detect Full */
+#define FULL_CV_MIN 98
+
+/*
+ * Offset to exit from maintenance charging. In maintenance charging
+ * if the volatge is less than the (maintenance_lower_threshold -
+ * MAINT_EXIT_OFFSET) then system can switch to normal charging
+ */
+
+#define MAINT_EXIT_OFFSET 50 /* mV */
+
+static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
+ int temp)
+{
+ int i = 0;
+ int temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
+ BATT_TEMP_NR_RNG);
+
+ if ((temp < pse_mod_bprof->temp_low_lim) ||
+ (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim))
+ return -EINVAL;
+
+ for (i = 0; i < temp_range_cnt; ++i)
+ if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim)
+ break;
+ return i-1;
+}
+
+static inline bool is_charge_terminated(long volt, long cur,
+ long iterm, unsigned long cv)
+{
+ pr_devel("%s:current=%ld pse_mod_bprof->chrg_term_mA =%ld
voltage_now=%ld full_cond=%ld",
+ __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv));
+
+ return (cur > 0) && (cur <= iterm) &&
+ ((volt * 100) >= (FULL_CV_MIN * cv));
[PATCH net V2] vhost: net: switch to use data copy if pending DMAs exceed the limit
We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-++-+ | VM1 || VM2 | +--+--++--+--+ | | +--+--++--+--+ | tap0|| tap1| +--+--++--+--+ | | pfifo_fast htb(10Mbit/s) | | +--+--+---+ | bridge | +--+--+ | pfifo_fast | +-+ | eth0|(100Mbit/s) +-+ - start two VMs and connect them to a bridge - add an physical card (100Mbit/s) to that bridge - setup htb on tap1 and limit its throughput to 10Mbit/s - run two netperfs in the same time, one is from VM1 to VM2. Another is from VM1 to an external host through eth0. - result shows that not only the VM1 to VM2 traffic were throttled but also the VM1 to external host through eth0 is also throttled somehow. This is because the delay added by htb may lead the delay the finish of DMAs and cause the pending DMAs for tap0 exceeds the limit (VHOST_MAX_PEND). In this case vhost stop handling tx request until htb send some packets. The problem here is all of the packets transmission were blocked even if it does not go to VM2. We can solve this issue by relaxing it a little bit: switching to use data copy instead of stopping tx when the number of pending DMAs exceed half of the vq size. This is safe because: - The number of pending DMAs were still limited (half of the vq size) - The out of order completion during mode switch can make sure that most of the tx buffers were freed in time in guest. So even if about 50% packets were delayed in zero-copy case, vhost could continue to do the transmission through data copy in this case. Test result: Before this patch: VM1 to VM2 throughput is 9.3Mbit/s VM1 to External throughput is 40Mbit/s CPU utilization is 7% After this patch: VM1 to VM2 throughput is 9.3Mbit/s Vm1 to External throughput is 93Mbit/s CPU utilization is 16% Completed performance test on 40gbe shows no obvious changes in both throughput and cpu utilization with this patch. The patch only solve this issue when unlimited sndbuf. We still need a solution for limited sndbuf. Cc: Michael S. Tsirkin Cc: Qin Chuanyu Signed-off-by: Jason Wang --- Changes from V1: - Remove VHOST_MAX_PEND and switch to use half of the vq size as the limit - Add cpu utilization in commit log --- drivers/vhost/net.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index a0fa5de..2925e9a 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -38,8 +38,6 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;" * Using this limit prevents one virtqueue from starving others. */ #define VHOST_NET_WEIGHT 0x8 -/* MAX number of TX used buffers for outstanding zerocopy */ -#define VHOST_MAX_PEND 128 #define VHOST_GOODCOPY_LEN 256 /* @@ -345,7 +343,7 @@ static void handle_tx(struct vhost_net *net) .msg_flags = MSG_DONTWAIT, }; size_t len, total_len = 0; - int err; + int err, num_pends; size_t hdr_size; struct socket *sock; struct vhost_net_ubuf_ref *uninitialized_var(ubufs); @@ -366,13 +364,6 @@ static void handle_tx(struct vhost_net *net) if (zcopy) vhost_zerocopy_signal_used(net, vq); - /* If more outstanding DMAs, queue the work. -* Handle upend_idx wrap around -*/ - if (unlikely((nvq->upend_idx + vq->num - VHOST_MAX_PEND) - % UIO_MAXIOV == nvq->done_idx)) - break; - head = vhost_get_vq_desc(>dev, vq, vq->iov, ARRAY_SIZE(vq->iov), , , @@ -405,9 +396,13 @@ static void handle_tx(struct vhost_net *net) break; } + num_pends = likely(nvq->upend_idx >= nvq->done_idx) ? + (nvq->upend_idx - nvq->done_idx) : + (nvq->upend_idx + UIO_MAXIOV - +nvq->done_idx); + zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN - && (nvq->upend_idx + 1) % UIO_MAXIOV != - nvq->done_idx + && num_pends <= vq->num >> 1 && vhost_net_tx_select_zcopy(net); /* use msg_control to pass vhost zerocopy ubuf info to skb */ -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe
RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
Hi,
> Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
>
> Hi,
>
> On Thursday 06 March 2014 02:49 PM, Anton Tikhomirov wrote:
> > Hi,
> >
> >> Subject: RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
> >>
> >> Hi,
> >>
> >>> Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
> >>>
> >>> Hi,
> >>>
> >>> On Thursday 06 March 2014 02:22 PM, Anton Tikhomirov wrote:
> Hello,
>
> > Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY
> driver
> >
> >
> >
> > On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
> >> Hi Kamil,
> >>
> >> ...
> >>
> >>> +| 3. Supporting SoCs
> >>> ++
> >>> +
> >>> +To support a new SoC a new file should be added to the
> >>> drivers/phy
> >>> +directory. Each SoC's configuration is stored in an instance
> of
> >>> the
> >>> +struct samsung_usb2_phy_config.
> >>> +
> >>> +struct samsung_usb2_phy_config {
> >>> + const struct samsung_usb2_common_phy *phys;
> >>> + unsigned int num_phys;
> >>> + bool has_mode_switch;
> >>
> >> You missed rate_to_clk here.
> >>
> >>> +};
> >>> +
> >>
> >> ...
> >>
> >>> diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
> > samsung-
> >>> usb2.c
> >>> new file mode 100644
> >>> index 000..c3b7719
> >>> --- /dev/null
> >>> +++ b/drivers/phy/phy-samsung-usb2.c
> >>> @@ -0,0 +1,222 @@
> >>> +/*
> >>> + * Samsung SoC USB 1.1/2.0 PHY driver
> >>> + *
> >>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> >>> + * Author: Kamil Debski
> >>> + *
> >>> + * This program is free software; you can redistribute it
> >> and/or
> >>> modify
> >>> + * it under the terms of the GNU General Public License
> version
> >> 2
> > as
> >>> + * published by the Free Software Foundation.
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include "phy-samsung-usb2.h"
> >>> +
> >>> +static int samsung_usb2_phy_power_on(struct phy *phy)
> >>> +{
> >>> + struct samsung_usb2_phy_instance *inst =
> >>> phy_get_drvdata(phy);
> >>> + struct samsung_usb2_phy_driver *drv = inst->drv;
> >>> + int ret;
> >>> +
> >>> + dev_dbg(drv->dev, "Request to power_on \"%s\" usb phy\n",
> >>> + inst->cfg->label);
> >>> + ret = clk_prepare_enable(drv->clk);
> >>
> >> clk_prepare_enable() can sleep, and therefore doesn't allow
> >> samusng_usb2_phy_power_on() to be used in atomic context
> >> (e.g. inside spin_lock-ed area), what sometimes may be desirable.
> >> What about to prepare clock in probe, and just enable it here
> >> (note: clk_enable() doesn't sleep).
> >
> > The PHY power-on callback is anyway called with mutex held, so I
> >>> guess
> > it's fine to have clk_prepare_enable() here.
>
> If we rely totally on generic PHY functions such as phy_power_on()
> and friends, why do we need to use locking in callbacks at all.
> >>>
> >>> Didn't get you.. We don't want to invoke power_on when init is
> >> getting
> >>> executed or you don't want power on or power off to get executed
> >>> simultaneously right? So we need to protect it.
> >>
> >> I mean callbacks such as samsung_usb2_phy_power_on() which uses
> >> spin_lock.
> >> It's already protected by mutex in phy_power_on().
> >
> > Well... phy_power_on() uses mutex to protect power_on() callback.
> > power_on() is samsung_usb2_phy_power_on() in our case.
> > samsung_usb2_phy_power_on() uses spinlock.
> > My question is why do we need to use spinlock _inside_ callback
> > if it is already protected by mutex.
>
> It is needed when the same PHY provider implements multiple PHYs.
> phy-core can protect phy-ops of same PHY. However if the PHY provider
> implements multiple PHYs, phy-core won't be able to protect.
Thank you Kishon. Now it's clear.
--
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 6/9] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM
In sleep mode, the clocks of e500 cores and unused IP blocks is
turned off. The IP blocks which are allowed to wake up the processor
are still running.
The sleep mode is equal to the Standby state in Linux. Use the
command to enter sleep mode:
echo standby > /sys/power/state
Signed-off-by: Chenhui Zhao
---
arch/powerpc/Kconfig |4 +-
arch/powerpc/platforms/85xx/Makefile |3 +
arch/powerpc/platforms/85xx/qoriq_pm.c | 78
3 files changed, 83 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 05f6323..e1d6510 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -222,7 +222,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
- (PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
+ FSL_SOC_BOOKE || PPC_86xx || PPC_PSERIES \
|| 44x || 40x
config PPC_DCR_NATIVE
@@ -709,7 +709,7 @@ config FSL_PCI
config FSL_PMC
bool
default y
- depends on SUSPEND && (PPC_85xx || PPC_86xx)
+ depends on SUSPEND && (PPC_85xx && !PPC_E500MC || PPC_86xx)
help
Freescale MPC85xx/MPC86xx power management controller support
(suspend/resume). For MPC83xx see platforms/83xx/suspend.c
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 25cebe7..7fae817 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -2,6 +2,9 @@
# Makefile for the PowerPC 85xx linux kernel.
#
obj-$(CONFIG_SMP) += smp.o
+ifeq ($(CONFIG_FSL_CORENET_RCPM), y)
+obj-$(CONFIG_SUSPEND) += qoriq_pm.o
+endif
obj-y += common.o
diff --git a/arch/powerpc/platforms/85xx/qoriq_pm.c
b/arch/powerpc/platforms/85xx/qoriq_pm.c
new file mode 100644
index 000..915b13b
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qoriq_pm.c
@@ -0,0 +1,78 @@
+/*
+ * Support Power Management feature
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Author: Chenhui Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#define FSL_SLEEP 0x1
+#define FSL_DEEP_SLEEP 0x2
+
+/* specify the sleep state of the present platform */
+int sleep_pm_state;
+/* supported sleep modes by the present platform */
+static unsigned int sleep_modes;
+
+static int qoriq_suspend_enter(suspend_state_t state)
+{
+ int ret = 0;
+
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+
+ if (cur_cpu_spec->cpu_flush_caches)
+ cur_cpu_spec->cpu_flush_caches();
+
+ ret = qoriq_pm_ops->plat_enter_state(sleep_pm_state);
+
+ break;
+
+ default:
+ ret = -EINVAL;
+
+ }
+
+ return ret;
+}
+
+static int qoriq_suspend_valid(suspend_state_t state)
+{
+ if (state == PM_SUSPEND_STANDBY && (sleep_modes & FSL_SLEEP))
+ return 1;
+
+ return 0;
+}
+
+static const struct platform_suspend_ops qoriq_suspend_ops = {
+ .valid = qoriq_suspend_valid,
+ .enter = qoriq_suspend_enter,
+};
+
+static int __init qoriq_suspend_init(void)
+{
+ struct device_node *np;
+
+ sleep_modes = FSL_SLEEP;
+ sleep_pm_state = PLAT_PM_SLEEP;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qoriq-rcpm-2.0");
+ if (np)
+ sleep_pm_state = PLAT_PM_LPM20;
+
+ suspend_set_ops(_suspend_ops);
+
+ return 0;
+}
+arch_initcall(qoriq_suspend_init);
--
1.7.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/
[PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Zhao Chenhui T1040 supports deep sleep feature, which can switch off most parts of the SoC when it is in deep sleep mode. This way, it becomes more energy-efficient. The DDR controller will also be powered off in deep sleep. Therefore, the last stage (the latter part of fsl_dp_enter_low) will run without DDR access. This piece of code and related TLBs will be prefetched. Due to the different initialization code between 32-bit and 64-bit, they have seperate resume entry and precedure. The feature supports 32-bit and 64-bit kernel mode. Signed-off-by: Zhao Chenhui --- arch/powerpc/include/asm/booke_save_regs.h |3 + arch/powerpc/kernel/cpu_setup_fsl_booke.S | 17 ++ arch/powerpc/kernel/head_fsl_booke.S | 30 +++ arch/powerpc/platforms/85xx/Makefile |2 +- arch/powerpc/platforms/85xx/deepsleep.c| 201 +++ arch/powerpc/platforms/85xx/qoriq_pm.c | 38 arch/powerpc/platforms/85xx/sleep.S| 295 arch/powerpc/sysdev/fsl_soc.h |7 + 8 files changed, 592 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c create mode 100644 arch/powerpc/platforms/85xx/sleep.S diff --git a/arch/powerpc/include/asm/booke_save_regs.h b/arch/powerpc/include/asm/booke_save_regs.h index 87c357a..37c1f6c 100644 --- a/arch/powerpc/include/asm/booke_save_regs.h +++ b/arch/powerpc/include/asm/booke_save_regs.h @@ -88,6 +88,9 @@ #define HIBERNATION_FLAG 1 #define DEEPSLEEP_FLAG 2 +#define CPLD_FLAG 1 +#define FPGA_FLAG 2 + #ifndef __ASSEMBLY__ extern void booke_cpu_state_save(void *buf, int type); extern void *booke_cpu_state_restore(void *buf, int type); diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index e59d6de..ea9bc28 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -318,6 +318,23 @@ flush_backside_L2_cache: 2: blr +#define CPC_CPCCSR00x0 +#define CPC_CPCCSR0_CPCFL 0x800 + +/* r3 : the base address of CPC */ +_GLOBAL(fsl_flush_cpc_cache) + lwz r6, CPC_CPCCSR0(r3) + ori r6, r6, CPC_CPCCSR0_CPCFL + stw r6, CPC_CPCCSR0(r3) + sync + + /* Wait until completing the flush */ +1: lwz r6, CPC_CPCCSR0(r3) + andi. r6, r6, CPC_CPCCSR0_CPCFL + bne 1b + + blr + _GLOBAL(__flush_caches_e500v2) mflr r0 bl flush_dcache_L1 diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 20204fe..3285752 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -162,6 +162,19 @@ _ENTRY(__early_start) #include "fsl_booke_entry_mapping.S" #undef ENTRY_MAPPING_BOOT_SETUP +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM) + /* if deep_sleep_flag != 0, jump to the deep sleep resume entry */ + LOAD_REG_ADDR(r4, deep_sleep_flag) + lwz r3, 0(r4) + cmpwi r3, 0 + beq 11f + /* clear deep_sleep_flag */ + li r3, 0 + stw r3, 0(r4) + b fsl_deepsleep_resume +11: +#endif + set_ivor: /* Establish the interrupt vector offsets */ SET_IVOR(0, CriticalInput); @@ -343,6 +356,23 @@ set_ivor: lwz r11, 0(r12);/* Get Linux PTE */ #endif +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM) +_ENTRY(__entry_deep_sleep) +/* + * Bootloader will jump to here when resuming from deep sleep. + * After executing the init code in fsl_booke_entry_mapping.S, + * will jump to the real resume entry. + */ + li r8, 1 + bl 12f +12:mflrr9 + addir9, r9, (deep_sleep_flag - 12b) + stw r8, 0(r9) + b __early_start +deep_sleep_flag: + .long 0 +#endif + /* * Interrupt vector entry code * diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile index 7fae817..9a4ea86 100644 --- a/arch/powerpc/platforms/85xx/Makefile +++ b/arch/powerpc/platforms/85xx/Makefile @@ -3,7 +3,7 @@ # obj-$(CONFIG_SMP) += smp.o ifeq ($(CONFIG_FSL_CORENET_RCPM), y) -obj-$(CONFIG_SUSPEND) += qoriq_pm.o +obj-$(CONFIG_SUSPEND) += qoriq_pm.o deepsleep.o sleep.o endif obj-y += common.o diff --git a/arch/powerpc/platforms/85xx/deepsleep.c b/arch/powerpc/platforms/85xx/deepsleep.c new file mode 100644 index 000..ddd7185 --- /dev/null +++ b/arch/powerpc/platforms/85xx/deepsleep.c @@ -0,0 +1,201 @@ +/* + * Support deep sleep feature + * + * Copyright 2014 Freescale Semiconductor Inc. + * + * Author: Chenhui Zhao + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include
RE: linux rdma 3.14 merge plans
Hi Roland,
Is it okay to send next series of patches even if previous series is not
accepted yet in your tree? Off-course I will cut patches on top of previous
series of patches.
-Regards
Devesh
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Nicholas A. Bellinger
Sent: Thursday, March 06, 2014 12:34 AM
To: Roland Dreier
Cc: Or Gerlitz; Hefty Sean; linux-rdma; Martin K. Petersen; target-devel; Sagi
Grimberg; linux-kernel
Subject: Re: linux rdma 3.14 merge plans
On Wed, 2014-03-05 at 07:18 -0800, Roland Dreier wrote:
> On Wed, Mar 5, 2014 at 1:54 AM, Nicholas A. Bellinger
> wrote:
> > That all said, do you have an objection wrt taking this bits through
> > target-pending..? Given the dependencies involved, that would seem
> > the most logical path to take.
>
> Perhaps not surprisingly, I would prefer to get a chance to review a
> major change to the core RDMA midlayer rather than having you merge it
> through your tree. So yes I do object. Please give me a chance to
> review and merge it. I am working on that this week.
>
Great. We'll be looking for a response by the end of the week.
Otherwise if you end up not having time, we'd still like to move forward for
v3.15 given the amount of review the series has already gotten on the list.
Thank you,
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
From: Hongbo Zhang In the last stage of deep sleep, software will trigger a Finite State Machine (FSM) to control the hardware precedure, such as board isolation, killing PLLs, removing power, and so on. When the system is waked up by an interrupt, the FSM controls the hardware to complete the early resume precedure. This patch configure the EPU FSM preparing for deep sleep. Signed-off-by: Hongbo Zhang Signed-off-by: Chenhui Zhao --- arch/powerpc/platforms/85xx/Kconfig |1 + arch/powerpc/sysdev/fsl_soc.h |3 + drivers/platform/Kconfig|4 + drivers/platform/Makefile |1 + drivers/platform/fsl/Kconfig| 10 + drivers/platform/fsl/Makefile |5 + drivers/platform/fsl/sleep_fsm.c| 415 +++ 7 files changed, 439 insertions(+), 0 deletions(-) create mode 100644 drivers/platform/fsl/Kconfig create mode 100644 drivers/platform/fsl/Makefile create mode 100644 drivers/platform/fsl/sleep_fsm.c diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 54d8843..27e2174 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -261,6 +261,7 @@ config CORENET_GENERIC select GPIO_MPC8XXX select HAS_RAPIDIO select PPC_EPAPR_HV_PIC + select FSL_SLEEP_FSM if SUSPEND help This option enables support for the FSL CoreNet based boards. For 32bit kernel, the following boards are supported: diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h index 9b9a34a..eb83a30 100644 --- a/arch/powerpc/sysdev/fsl_soc.h +++ b/arch/powerpc/sysdev/fsl_soc.h @@ -69,5 +69,8 @@ extern const struct fsl_pm_ops *qoriq_pm_ops; extern int fsl_rcpm_init(void); +extern void fsl_dp_fsm_setup(void *dcsr_base); +extern void fsl_dp_fsm_clean(void *dcsr_base); + #endif #endif diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 09fde58..6539e6d 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -6,3 +6,7 @@ source "drivers/platform/goldfish/Kconfig" endif source "drivers/platform/chrome/Kconfig" + +if FSL_SOC +source "drivers/platform/fsl/Kconfig" +endif diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 3656b7b..37c6f72 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_X86) += x86/ obj-$(CONFIG_OLPC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ +obj-$(CONFIG_FSL_SOC) += fsl/ diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig new file mode 100644 index 000..72ed053 --- /dev/null +++ b/drivers/platform/fsl/Kconfig @@ -0,0 +1,10 @@ +# +# Freescale Specific Power Management Drivers +# + +config FSL_SLEEP_FSM + bool + help + This driver configures a hardware FSM (Finite State Machine) for deep sleep. + The FSM is used to finish clean-ups at the last stage of system entering deep + sleep, and also wakes up system when a wake up event happens. diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile new file mode 100644 index 000..d99ca0e --- /dev/null +++ b/drivers/platform/fsl/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for linux/drivers/platform/fsl +# Freescale Specific Power Management Drivers +# +obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o diff --git a/drivers/platform/fsl/sleep_fsm.c b/drivers/platform/fsl/sleep_fsm.c new file mode 100644 index 000..102 --- /dev/null +++ b/drivers/platform/fsl/sleep_fsm.c @@ -0,0 +1,415 @@ +/* + * Freescale deep sleep FSM (finite-state machine) configuration + * + * Copyright 2014 Freescale Semiconductor Inc. + * + * Author: Hongbo Zhang + * Chenhui Zhao + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include + +#define FSL_STRIDE_4B 4 +#define FSL_STRIDE_8B 8 + +/* Event Processor Global Control Register */ +#defineEPGCR 0x000 + +/* Event Processor EVT Pin Control Registers */ +#defineEPEVTCR00x050 +#defineEPEVTCR10x054 +#defineEPEVTCR20x058 +#defineEPEVTCR30x05C +#defineEPEVTCR40x060 +#defineEPEVTCR50x064 +#defineEPEVTCR60x068 +#defineEPEVTCR70x06C +#defineEPEVTCR80x070 +#defineEPEVTCR90x074 + +/* Event Processor Crosstrigger Control Register */ +#defineEPXTRIGCR 0x090 + +/* Event Processor Input Mux Control Registers */ +#defineEPIMCR0 0x100 +#defineEPIMCR1 0x104 +#defineEPIMCR2 0x108
Re: [PATCH] kexec/powerpc: fix exporting memory limit
> On Thu, 2014-03-06 at 18:24 +0400, Nikita Yushchenko wrote: > > When preparing dump-capturing kernel, kexec userspace tool needs to > > know actual amount of memory used by the running kernel. This may > > differ from extire available DRAM for a couple of reasons. To address > > this issue, kdump kernel support code injects several attributes into > > device tree that are later captured by userspace kexec tool via /proc > > interface. > > > > One such attrubute is 'chosen/linux,memory_limit' that is used to pass > > memory limit of the running kernel. > > > > This was initialized using kernel's 'memory_limit' variable, that is > > set by early init code based on mem= kernel parameter and other > > reasons. > > > > But there are cases when memory_limit variable does not contain proper > > information. One such case is when !CONFIG_HIGHMEM kernel runs on > > system with memory large enough not to fit into lowmem. > > Why doesn't the !CONFIG_HIGHMEM code update memory_limit to reflect > reality. I guess because memory_limit is used for ... well, memory limit, set by mem=. And for the rest memblock is used (and it *is* updated). And code elsewhere does use memblock, see e.g. numa_enforce_memory_limit() in arch/powerpc/mm/numa.c In MMU init (MMU_init() in arch/powerpc/mm/init_32.c -which is the point where final memory configuration is set) memblock, not memory_limit, is both used and updated. -- 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: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()
On 03/06/2014 05:58 PM, Fengguang Wu wrote: > Hi all, > > I find the below WARNING shows up only in > > qemu-system-x86_64 -cpu qemu64,+smep,+smap > Yes, it is because Qemu doesn't show the AMD-specific SMP CPUID bit. It's harmless in that sense. Unfortunately these things are hard to fix in Qemu. -hpa -- 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/
[GIT PULL] spi fixes for v3.14
The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
tags/spi-v3.14-rc5
for you to fetch changes up to d930acfdb021f9d61e156c4f53d42043305f5bf6:
Merge remote-tracking branches 'spi/fix/ath79', 'spi/fix/atmel',
'spi/fix/coldfire', 'spi/fix/fsl-dspi', 'spi/fix/imx' and
'spi/fix/topcliff-pch' into spi-linus (2014-03-07 11:08:13 +0800)
spi: Fixes for v3.14
A scattering of driver specific fixes here. The fixes from Axel cover
bitrot in apparently unmaintained drivers, the at79 bug is fixing a
glitch on /CS during initialisation of some devices which could break
some slaves and the remainder are fixes for recently introduced bugs
from the past release cycle or so.
Alexander Stein (2):
spi/topcliff-pch: Fix DMA channel
spi-topcliff-pch: Fix probing when DMA mode is used
Axel Lin (2):
spi: fsl-dspi: Fix getting correct address for master
spi: coldfire-qspi: Fix getting correct address for *mcfqspi
Gabor Juhos (1):
spi: spi-ath79: fix initial GPIO CS line setup
Mark Brown (1):
Merge remote-tracking branches 'spi/fix/ath79', 'spi/fix/atmel',
'spi/fix/coldfire', 'spi/fix/fsl-dspi', 'spi/fix/imx' and
'spi/fix/topcliff-pch' into spi-linus
Philippe De Muyter (1):
spi: spi-imx: spi_imx_remove: do not disable disabled clocks
Wenyou Yang (1):
spi: atmel: add missing spi_master_{resume,suspend} calls to PM callbacks
drivers/spi/spi-ath79.c | 4 ++--
drivers/spi/spi-atmel.c | 17 -
drivers/spi/spi-coldfire-qspi.c | 6 --
drivers/spi/spi-fsl-dspi.c | 6 +++---
drivers/spi/spi-imx.c | 4 ++--
drivers/spi/spi-topcliff-pch.c | 15 ---
6 files changed, 35 insertions(+), 17 deletions(-)
signature.asc
Description: Digital signature
[PATCH 5/9] powerpc/85xx: disable irq by hardware when suspend for 64-bit
In 64-bit mode, kernel just clears the irq soft-enable flag
in struct paca_struct to disable external irqs. But, in
the case of suspend, irqs should be disabled by hardware.
Therefore, hook a function to ppc_md.suspend_disable_irqs
to really disable irqs.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/platforms/85xx/corenet_generic.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 3fdf9f3..983d81f 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -32,6 +32,13 @@
#include
#include "smp.h"
+#if defined(CONFIG_PPC64) && defined(CONFIG_SUSPEND)
+static void fsl_suspend_disable_irqs(void)
+{
+ __hard_irq_disable();
+}
+#endif
+
void __init corenet_gen_pic_init(void)
{
struct mpic *mpic;
@@ -58,6 +65,11 @@ void __init corenet_gen_setup_arch(void)
fsl_rcpm_init();
+#if defined(CONFIG_PPC64) && defined(CONFIG_SUSPEND)
+ /* physically disable irq for 64-bit mode when suspend */
+ ppc_md.suspend_disable_irqs = fsl_suspend_disable_irqs;
+#endif
+
pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
}
--
1.7.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/
[PATCH 2/9] powerpc/cache: add cache flush operation for various e500
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all caches in the current cpu.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/include/asm/cacheflush.h |2 -
arch/powerpc/include/asm/cputable.h | 11 +++
arch/powerpc/kernel/asm-offsets.c |3 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 114 -
arch/powerpc/kernel/cputable.c|4 +
arch/powerpc/kernel/head_fsl_booke.S | 74 ---
arch/powerpc/platforms/85xx/smp.c |4 +-
7 files changed, 134 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 5b93122..039753e 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -30,8 +30,6 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void __flush_disable_L1(void);
-
extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 617cc76..2c497a2 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -43,6 +43,13 @@ extern int machine_check_e500(struct pt_regs *regs);
extern int machine_check_e200(struct pt_regs *regs);
extern int machine_check_47x(struct pt_regs *regs);
+#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
+extern void __flush_caches_e500v2(void);
+extern void __flush_caches_e500mc(void);
+extern void __flush_caches_e5500(void);
+extern void __flush_caches_e6500(void);
+#endif
+
/* NOTE WELL: Update identify_cpu() if fields are added or removed! */
struct cpu_spec {
/* CPU is matched via (PVR & pvr_mask) == pvr_value */
@@ -59,6 +66,10 @@ struct cpu_spec {
unsigned inticache_bsize;
unsigned intdcache_bsize;
+#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
+ /* flush caches of the cpu which is running the function */
+ void (*cpu_flush_caches)(void);
+#endif
/* number of performance monitor counters */
unsigned intnum_pmcs;
enum powerpc_pmc_type pmc_type;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 8d1d94d..5157fb4 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -372,6 +372,9 @@ int main(void)
DEFINE(CPU_SPEC_FEATURES, offsetof(struct cpu_spec, cpu_features));
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
DEFINE(CPU_SPEC_RESTORE, offsetof(struct cpu_spec, cpu_restore));
+#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
+ DEFINE(CPU_FLUSH_CACHES, offsetof(struct cpu_spec, cpu_flush_caches));
+#endif
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index cc2d896..e59d6de 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -1,7 +1,7 @@
/*
* This file contains low level CPU setup functions.
* Kumar Gala
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2009, 2014 Freescale Semiconductor, Inc.
*
* Based on cpu_setup_6xx code by
* Benjamin Herrenschmidt
@@ -13,11 +13,13 @@
*
*/
+#include
#include
#include
#include
#include
#include
+#include
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
@@ -223,3 +225,113 @@ _GLOBAL(__setup_cpu_e5500)
mtlrr5
blr
#endif
+
+/* flush L1 date cache, it can apply to e500v2, e500mc and e5500 */
+_GLOBAL(flush_dcache_L1)
+ mfmsr r10
+ wrteei 0
+
+ mfspr r3,SPRN_L1CFG0
+ rlwinm r5,r3,9,3 /* Extract cache block size */
+ twlgti r5,1/* Only 32 and 64 byte cache blocks
+* are currently defined.
+*/
+ li r4,32
+ subfic r6,r5,2 /* r6 = log2(1KiB / cache block size) -
+* log2(number of ways)
+*/
+ slw r5,r4,r5/* r5 = cache block size */
+
+ rlwinm r7,r3,0,0xff/* Extract number of KiB in the cache */
+ mulli r7,r7,13/* An 8-way cache will require 13
+* loads per set.
+
[PATCH 4/9] powerpc/85xx: support CPU hotplug for e500mc and e5500
Implemented CPU hotplug on e500mc and e5500. On e5500 both 32-bit and
64-bit modes can work. Used some callback functions implemented in RCPM
driver.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/kernel/smp.c |6 ++-
arch/powerpc/mm/tlb_nohash.c |6 ++-
arch/powerpc/platforms/85xx/smp.c | 94 ++---
4 files changed, 87 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a5e5d2e..05f6323 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -362,7 +362,7 @@ config SWIOTLB
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && (PPC_PSERIES || \
- PPC_PMAC || PPC_POWERNV || (PPC_85xx && !PPC_E500MC))
+ PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
---help---
Say Y here to be able to disable and re-enable individual
CPUs at runtime on SMP machines.
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ac2621a..f3f4401 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -405,8 +405,12 @@ void generic_cpu_die(unsigned int cpu)
for (i = 0; i < 100; i++) {
smp_rmb();
- if (per_cpu(cpu_state, cpu) == CPU_DEAD)
+ if (per_cpu(cpu_state, cpu) == CPU_DEAD) {
+#ifdef CONFIG_PPC64
+ paca[cpu].cpu_start = 0;
+#endif
return;
+ }
msleep(100);
}
printk(KERN_ERR "CPU%d didn't die...\n", cpu);
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index b37a58e..d24e06c 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -648,8 +648,10 @@ static void __early_init_mmu(int boot_cpu)
num_cams = (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) / 4;
linear_map_top = map_mem_in_cams(linear_map_top, num_cams);
- /* limit memory so we dont have linear faults */
- memblock_enforce_memory_limit(linear_map_top);
+ if (boot_cpu) {
+ /* limit memory so we dont have linear faults */
+ memblock_enforce_memory_limit(linear_map_top);
+ }
if (book3e_htw_mode == PPC_HTW_NONE) {
patch_exception(0x1c0, exc_data_tlb_miss_bolted_book3e);
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 2e5911e..0047883 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -46,6 +47,17 @@ static u64 timebase;
static int tb_req;
static int tb_valid;
+#ifdef CONFIG_PPC_E500MC
+/* specify the cpu PM state when cpu dies, PH15/NAP is the default */
+int qoriq_cpu_die_state = E500_PM_PH15;
+#endif
+
+#ifdef CONFIG_PPC_E500MC
+static void mpc85xx_timebase_freeze(int freeze)
+{
+ qoriq_pm_ops->freeze_time_base(freeze);
+}
+#else
static void mpc85xx_timebase_freeze(int freeze)
{
uint32_t mask;
@@ -58,6 +70,7 @@ static void mpc85xx_timebase_freeze(int freeze)
in_be32(>devdisr);
}
+#endif
static void mpc85xx_give_timebase(void)
{
@@ -125,6 +138,34 @@ static void mpc85xx_take_timebase(void)
}
#ifdef CONFIG_HOTPLUG_CPU
+#ifdef CONFIG_PPC_E500MC
+static void qoriq_cpu_die(void)
+{
+ unsigned int cpu = smp_processor_id();
+
+ local_irq_disable();
+#ifdef CONFIG_PPC64
+ __hard_irq_disable();
+#endif
+ idle_task_exit();
+
+ if (qoriq_pm_ops->irq_mask)
+ qoriq_pm_ops->irq_mask(cpu);
+
+ mtspr(SPRN_TCR, 0);
+ mtspr(SPRN_TSR, mfspr(SPRN_TSR));
+
+ generic_set_cpu_dead(cpu);
+
+ if (cur_cpu_spec && cur_cpu_spec->cpu_flush_caches)
+ cur_cpu_spec->cpu_flush_caches();
+
+ qoriq_pm_ops->cpu_enter_state(cpu, qoriq_cpu_die_state);
+
+ while (1)
+ ;
+}
+#else
static void smp_85xx_mach_cpu_die(void)
{
unsigned int cpu = smp_processor_id();
@@ -155,6 +196,7 @@ static void smp_85xx_mach_cpu_die(void)
;
}
#endif
+#endif
static inline void flush_spin_table(void *spin_table)
{
@@ -208,11 +250,8 @@ static int smp_85xx_kick_cpu(int nr)
spin_table = phys_to_virt(*cpu_rel_addr);
local_irq_save(flags);
-#ifdef CONFIG_PPC32
-#ifdef CONFIG_HOTPLUG_CPU
- /* Corresponding to generic_set_cpu_dead() */
- generic_set_cpu_up(nr);
+#ifdef CONFIG_HOTPLUG_CPU
if (system_state == SYSTEM_RUNNING) {
/*
* To keep it compatible with old boot program which uses
@@ -225,6 +264,12 @@ static int smp_85xx_kick_cpu(int nr)
out_be32(_table->addr_l, 0);
flush_spin_table(spin_table);
+#ifdef CONFIG_PPC_E500MC
+ /* Due to an erratum, wake the core
[PATCH 8/9] powerpc/85xx: add save/restore functions for core registers
From: Wang Dongsheng Add booke_cpu_state_save() and booke_cpu_state_restore() functions which can be used to save/restore CPU's registers in the case of deep sleep and hibernation. Supported processors: E6500, E5500, E500MC, E500v2 and E500v1. Signed-off-by: Wang Dongsheng Signed-off-by: Chenhui Zhao --- arch/powerpc/include/asm/booke_save_regs.h | 96 arch/powerpc/kernel/Makefile |1 + arch/powerpc/kernel/booke_save_regs.S | 361 3 files changed, 458 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/include/asm/booke_save_regs.h create mode 100644 arch/powerpc/kernel/booke_save_regs.S diff --git a/arch/powerpc/include/asm/booke_save_regs.h b/arch/powerpc/include/asm/booke_save_regs.h new file mode 100644 index 000..87c357a --- /dev/null +++ b/arch/powerpc/include/asm/booke_save_regs.h @@ -0,0 +1,96 @@ +/* + * Save/restore e500 series core registers + * + * Author: Wang Dongsheng + * + * Copyright 2014 Freescale Semiconductor Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ASM_FSL_SLEEP_H +#define __ASM_FSL_SLEEP_H + +/* + * 8 bytes for each register, which is compatible with + * both 32-bit and 64-bit registers + * + * Acronyms: + * dw(data width) 0x08 + * + * Map: + * General-Purpose Registers + * GPR1(sp)0 + * GPR20x8 (dw * 1) + * GPR13 - GPR31 0x10 ~ 0xa0 (dw * 2 ~ dw * 20) + * Foating-point registers + * FPR14 - FPR31 0xa8 ~ 0x130(dw * 21 ~ dw * 38) + * Registers for Branch Operations + * CR 0x138 (dw * 39) + * LR 0x140 (dw * 40) + * Processor Control Registers + * MSR 0x148 (dw * 41) + * EPCR0x150 (dw * 42) + * + * Only e500, e500v2 need to save HID0 - HID1 + * HID0 - HID1 0x158 ~ 0x160 (dw * 43 ~ dw * 44) + * Timer Registers + * TCR 0x168 (dw * 45) + * TB(64bit) 0x170 (dw * 46) + * TBU(32bit) 0x178 (dw * 47) + * TBL(32bit) 0x180 (dw * 48) + * Interrupt Registers + * IVPR0x188 (dw * 49) + * IVOR0 - IVOR15 0x190 ~ 0x208 (dw * 50 ~ dw * 65) + * IVOR32 - IVOR41 0x210 ~ 0x258 (dw * 66 ~ dw * 75) + * Software-Use Registers + * SPRG1 0x260 (dw * 76), 64-bit need to save. + * SPRG3 0x268 (dw * 77), 32-bit need to save. + * MMU Registers + * PID0 - PID2 0x270 ~ 0x280 (dw * 78 ~ dw * 80) + * Debug Registers + * DBCR0 - DBCR2 0x288 ~ 0x298 (dw * 81 ~ dw * 83) + * IAC1 - IAC4 0x2a0 ~ 0x2b8 (dw * 84 ~ dw * 87) + * DAC1 - DAC2 0x2c0 ~ 0x2c8 (dw * 88 ~ dw * 89) + * + */ + +#define SR_GPR10x000 +#define SR_GPR20x008 +#define SR_GPR13 0x010 +#define SR_FPR14 0x0a8 +#define SR_CR 0x138 +#define SR_LR 0x140 +#define SR_MSR 0x148 +#define SR_EPCR0x150 +#define SR_HID00x158 +#define SR_TCR 0x168 +#define SR_TB 0x170 +#define SR_TBU 0x178 +#define SR_TBL 0x180 +#define SR_IVPR0x188 +#define SR_IVOR0 0x190 +#define SR_IVOR32 0x210 +#define SR_SPRG1 0x260 +#define SR_SPRG3 0x268 +#define SR_PID00x270 +#define SR_DBCR0 0x288 +#define SR_IAC10x2a0 +#define SR_DAC10x2c0 +#define REGS_BUFFER_SIZE (SR_DAC1 + 0x10) + +/* + * hibernation and deepsleep save/restore different number of registers, + * use these flags to indicate. + */ +#define HIBERNATION_FLAG 1 +#define DEEPSLEEP_FLAG 2 + +#ifndef __ASSEMBLY__ +extern void booke_cpu_state_save(void *buf, int type); +extern void *booke_cpu_state_restore(void *buf, int type); +#endif +#endif + diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index fcc9a89..64acae6 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -73,6 +73,7 @@ obj-$(CONFIG_HIBERNATION) += swsusp_booke.o else obj-$(CONFIG_HIBERNATION) += swsusp_$(CONFIG_WORD_SIZE).o endif +obj-$(CONFIG_E500) += booke_save_regs.o obj64-$(CONFIG_HIBERNATION)+= swsusp_asm64.o obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o obj-$(CONFIG_44x) += cpu_setup_44x.o diff --git
[PATCH 1/9] powerpc/fsl: add PVR definition for E500MC and E5500
From: Wang Dongsheng Signed-off-by: Wang Dongsheng --- arch/powerpc/include/asm/reg.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 62b114e..cd7b630 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1075,6 +1075,8 @@ #define PVR_8560 0x8020 #define PVR_VER_E500V1 0x8020 #define PVR_VER_E500V2 0x8021 +#define PVR_VER_E500MC 0x8023 +#define PVR_VER_E5500 0x8024 #define PVR_VER_E6500 0x8040 /* -- 1.7.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/
[PATCH 3/9] powerpc/rcpm: add RCPM driver
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
There are two versions of register map in RCPM, which is specified by
the compatible entry in the RCPM node of device tree.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/include/asm/fsl_guts.h | 105
arch/powerpc/platforms/85xx/Kconfig |1 +
arch/powerpc/platforms/85xx/corenet_generic.c |2 +
arch/powerpc/sysdev/Kconfig |5 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_rcpm.c| 315 +
arch/powerpc/sysdev/fsl_soc.h | 24 ++
7 files changed, 453 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
diff --git a/arch/powerpc/include/asm/fsl_guts.h
b/arch/powerpc/include/asm/fsl_guts.h
index 77ced0b..492534a 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -185,5 +185,110 @@ static inline void guts_set_pmuxcr_dma(struct ccsr_guts
__iomem *guts,
#endif
+struct ccsr_rcpm_v1 {
+ u8 res[4];
+ __be32 cdozsr; /* 0x0004 Core Doze Status Register */
+ u8 res0008[4];
+ __be32 cdozcr; /* 0x000c Core Doze Control Register */
+ u8 res0010[4];
+ __be32 cnapsr; /* 0x0014 Core Nap Status Register */
+ u8 res0018[4];
+ __be32 cnapcr; /* 0x001c Core Nap Control Register */
+ u8 res0020[4];
+ __be32 cdozpsr;/* 0x0024 Core Doze Previous Status Register */
+ u8 res0028[4];
+ __be32 cnappsr;/* 0x002c Core Nap Previous Status Register */
+ u8 res0030[4];
+ __be32 cwaitsr;/* 0x0034 Core Wait Status Register */
+ u8 res0038[4];
+ __be32 cwdtdsr;/* 0x003c Core Watchdog Detect Status Register */
+ __be32 powmgtcsr; /* 0x0040 Power Mangement Control Register */
+#define RCPM_POWMGTCSR_SLP 0x0002
+ u8 res0044[12];
+ __be32 ippdexpcr; /* 0x0050 IP Powerdown Exception Control Register */
+ u8 res0054[16];
+ __be32 cpmimr; /* 0x0064 Core PM IRQ Mask Register */
+ u8 res0068[4];
+ __be32 cpmcimr;/* 0x006c Core PM Critical IRQ Mask Register */
+ u8 res0070[4];
+ __be32 cpmmcmr;/* 0x0074 Core PM Machine Check Mask Register */
+ u8 res0078[4];
+ __be32 cpmnmimr; /* 0x007c Core PM NMI Mask Register */
+ u8 res0080[4];
+ __be32 ctbenr; /* 0x0084 Core Time Base Enable Register */
+ u8 res0088[4];
+ __be32 ctbckselr; /* 0x008c Core Time Base Clock Select Register */
+ u8 res0090[4];
+ __be32 ctbhltcr; /* 0x0094 Core Time Base Halt Control Register */
+ u8 res0098[4];
+ __be32 cmcpmaskcr; /* 0x00a4 Core Machine Check Mask Register */
+};
+
+struct ccsr_rcpm_v2 {
+ u8 res_00[12];
+ u32 tph10sr0; /* Thread PH10 Status Register */
+ u8 res_10[12];
+ u32 tph10setr0; /* Thread PH10 Set Control Register */
+ u8 res_20[12];
+ u32 tph10clrr0; /* Thread PH10 Clear Control Register */
+ u8 res_30[12];
+ u32 tph10psr0; /* Thread PH10 Previous Status Register */
+ u8 res_40[12];
+ u32 twaitsr0; /* Thread Wait Status Register */
+ u8 res_50[96];
+ u32 pcph15sr; /* Physical Core PH15 Status Register */
+ u32 pcph15setr; /* Physical Core PH15 Set Control Register */
+ u32 pcph15clrr; /* Physical Core PH15 Clear Control Register */
+ u32 pcph15psr; /* Physical Core PH15 Prev Status Register */
+ u8 res_c0[16];
+ u32 pcph20sr; /* Physical Core PH20 Status Register */
+ u32 pcph20setr; /* Physical Core PH20 Set Control Register */
+ u32 pcph20clrr; /* Physical Core PH20 Clear Control Register */
+ u32 pcph20psr; /* Physical Core PH20 Prev Status Register */
+ u32 pcpw20sr; /* Physical Core PW20 Status Register */
+ u8 res_e0[12];
+ u32 pcph30sr; /* Physical Core PH30 Status Register */
+ u32 pcph30setr; /* Physical Core PH30 Set Control Register */
+ u32 pcph30clrr; /* Physical Core PH30 Clear Control Register */
+ u32 pcph30psr; /* Physical Core PH30 Prev Status Register */
+ u8 res_100[32];
+ u32 ippwrgatecr;/* IP Power Gating Control Register */
+ u8 res_124[12];
+ u32 powmgtcsr; /* Power Management Control & Status Reg */
+#define RCPM_POWMGTCSR_LPM20_RQ0x0010
+#define
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On Thu, Mar 6, 2014 at 9:09 AM, Zoltan Kiss wrote: > Do you have any feedback on this? I'm also adding KVM list as they might be > interested in this. > > Zoli > > > On 28/02/14 19:16, Zoltan Kiss wrote: >> >> The kernel datapath now switched to zerocopy Netlink messages, but that >> also >> means that the pages on frags array are sent straight to userspace. If >> those >> pages came outside the kernel, we have to swap them out with local copies. >> >> Signed-off-by: Zoltan Kiss I do not think this is required, netlink zero copy only maps pre-allocated buffers to user-space. But I found bug in datapath user-space queue code. I am not sure how this can work with skb fragments and MMAP-netlink socket. Here is what happens, OVS allocates netlink skb and adds fragments to skb using skb_zero_copy(), then calls genlmsg_unicast(). But if netlink sock is mmped then netlink-send queues netlink allocated skb->head (linear data of skb) and ignore skb frags. Currently this is not problem with OVS vswitchd since it does not use netlink MMAP sockets. But if vswitchd stats using MMAP-netlink socket, it can break it. -- 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] perf/x86/intel: Use rdmsrl_safe when initializing RAPL PMU.
CPUs which should support the RAPL counters according to
Family/Model/Stepping may still issue #GP when attempting to access
the RAPL MSRs. This may happen when Linux is running under KVM and
we are passing-through host F/M/S data, for example. Use rdmsrl_safe
to first access the RAPL_POWER_UNIT MSR; if this fails, do not
attempt to use this PMU.
Signed-off-by: Venkatesh Srinivas
---
arch/x86/kernel/cpu/perf_event_intel_rapl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
index 5ad35ad..95700e5 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
@@ -511,6 +511,7 @@ static int rapl_cpu_prepare(int cpu)
struct rapl_pmu *pmu = per_cpu(rapl_pmu, cpu);
int phys_id = topology_physical_package_id(cpu);
u64 ms;
+ u64 msr_rapl_power_unit_bits;
if (pmu)
return 0;
@@ -518,6 +519,9 @@ static int rapl_cpu_prepare(int cpu)
if (phys_id < 0)
return -1;
+ if (!rdmsrl_safe(MSR_RAPL_POWER_UNIT, _rapl_power_unit_bits))
+ return -1;
+
pmu = kzalloc_node(sizeof(*pmu), GFP_KERNEL, cpu_to_node(cpu));
if (!pmu)
return -1;
@@ -531,8 +535,7 @@ static int rapl_cpu_prepare(int cpu)
*
* we cache in local PMU instance
*/
- rdmsrl(MSR_RAPL_POWER_UNIT, pmu->hw_unit);
- pmu->hw_unit = (pmu->hw_unit >> 8) & 0x1FULL;
+ pmu->hw_unit = (msr_rapl_power_unit_bits >> 8) & 0x1FULL;
pmu->pmu = _pmu_class;
/*
@@ -649,7 +652,9 @@ static int __init rapl_pmu_init(void)
get_online_cpus();
for_each_online_cpu(cpu) {
- rapl_cpu_prepare(cpu);
+ ret = rapl_cpu_prepare(cpu);
+ if (ret)
+ goto out;
rapl_cpu_init(cpu);
}
@@ -672,6 +677,7 @@ static int __init rapl_pmu_init(void)
hweight32(rapl_cntr_mask),
ktime_to_ms(pmu->timer_interval));
+out:
put_online_cpus();
return 0;
--
1.9.0.279.gdc9e3eb
--
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 v7 2/2] ARM hibernation / suspend-to-disk
On 03/05, Sebastian Capella wrote:
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 8756e4b..d32adbb 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -291,6 +291,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> */
> #define __pa(x) __virt_to_phys((unsigned long)(x))
> #define __va(x) ((void
> *)__phys_to_virt((phys_addr_t)(x)))
> +#define __pa_symbol(x) __pa((unsigned long)(x))
Thanks for removing RELOC_HIDE, as Russell already stated it's
never been necessary on ARM.
Looking at this definition now it doesn't look right. Isn't
&__nosave_begin a virtual address? Casting it to an unsigned long
isn't going to give you a physical address. Why can't we use
__pa()?
> +extern const void __nosave_begin, __nosave_end;
> +
> +int pfn_is_nosave(unsigned long pfn)
> +{
> + unsigned long nosave_begin_pfn =
> + __pa_symbol(&__nosave_begin) >> PAGE_SHIFT;
> + unsigned long nosave_end_pfn =
> + PAGE_ALIGN(__pa_symbol(&__nosave_end)) >> PAGE_SHIFT;
> +
> + return (pfn >= nosave_begin_pfn) && (pfn < nosave_end_pfn);
> +}
Perhaps this code could be:
unsigned long nosave_begin_pfn = virt_to_pfn(&__nosave_begin);
unsigned long nosave_end_pfn = virt_to_pfn(&__nosave_end);
return (pfn >= nosave_begin_pfn) && (pfn <= nosave_end_pfn);
or if virt_to_pfn() doesn't exist on ARM and we can't add it for
some reason:
unsigned long nosave_begin_pfn = __phys_to_pfn(__pa(&__nosave_begin));
unsigned long nosave_end_pfn = __phys_to_pfn(__pa(&__nosave_end));
return (pfn >= nosave_begin_pfn) && (pfn <= nosave_end_pfn);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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/6] Drivers: net: hyperv: Enable scatter gather I/O
Cleanup the code and enable scatter gather I/O.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/netvsc_drv.c | 153 +--
1 files changed, 114 insertions(+), 39 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 9ef6be9..94271bf 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -140,21 +140,123 @@ static void netvsc_xmit_completion(void *context)
dev_kfree_skb_any(skb);
}
+static u32 fill_pg_buf(struct page *page, u32 offset, u32 len,
+ struct hv_page_buffer *pb)
+{
+ int j = 0;
+
+ /* Deal with compund pages by ignoring unused part
+* of the page.
+*/
+ page += offset >> PAGE_SHIFT;
+ offset &= ~PAGE_MASK;
+
+ while (len > 0) {
+ unsigned long bytes;
+
+ bytes = PAGE_SIZE - offset;
+ if (bytes > len)
+ bytes = len;
+ pb[j].pfn = page_to_pfn(page);
+ pb[j].offset = offset;
+ pb[j].len = bytes;
+
+ offset += bytes;
+ len -= bytes;
+
+ if (offset == PAGE_SIZE && len) {
+ page++;
+ offset = 0;
+ j++;
+ }
+ }
+
+ return j + 1;
+}
+
+static void init_page_array(void *hdr, u32 len, struct sk_buff *skb,
+ struct hv_page_buffer *pb)
+{
+ u32 slots_used = 0;
+ char *data = skb->data;
+ int frags = skb_shinfo(skb)->nr_frags;
+ int i;
+
+ /* The packet is laid out thus:
+* 1. hdr
+* 2. skb linear data
+* 3. skb fragment data
+*/
+ if (hdr != NULL)
+ slots_used += fill_pg_buf(virt_to_page(hdr),
+ offset_in_page(hdr),
+ len, [slots_used]);
+
+ slots_used += fill_pg_buf(virt_to_page(data),
+ offset_in_page(data),
+ skb_headlen(skb), [slots_used]);
+
+ for (i = 0; i < frags; i++) {
+ skb_frag_t *frag = skb_shinfo(skb)->frags + i;
+
+ slots_used += fill_pg_buf(skb_frag_page(frag),
+ frag->page_offset,
+ skb_frag_size(frag), [slots_used]);
+ }
+}
+
+static int count_skb_frag_slots(struct sk_buff *skb)
+{
+ int i, frags = skb_shinfo(skb)->nr_frags;
+ int pages = 0;
+
+ for (i = 0; i < frags; i++) {
+ skb_frag_t *frag = skb_shinfo(skb)->frags + i;
+ unsigned long size = skb_frag_size(frag);
+ unsigned long offset = frag->page_offset;
+
+ /* Skip unused frames from start of page */
+ offset &= ~PAGE_MASK;
+ pages += PFN_UP(offset + size);
+ }
+ return pages;
+}
+
+static int netvsc_get_slots(struct sk_buff *skb)
+{
+ char *data = skb->data;
+ unsigned int offset = offset_in_page(data);
+ unsigned int len = skb_headlen(skb);
+ int slots;
+ int frag_slots;
+
+ slots = DIV_ROUND_UP(offset + len, PAGE_SIZE);
+ frag_slots = count_skb_frag_slots(skb);
+ return slots + frag_slots;
+}
+
static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
{
struct net_device_context *net_device_ctx = netdev_priv(net);
struct hv_netvsc_packet *packet;
int ret;
- unsigned int i, num_pages, npg_data;
+ unsigned int num_data_pages;
- /* Add multipages for skb->data and additional 2 for RNDIS */
- npg_data = (((unsigned long)skb->data + skb_headlen(skb) - 1)
- >> PAGE_SHIFT) - ((unsigned long)skb->data >> PAGE_SHIFT) + 1;
- num_pages = skb_shinfo(skb)->nr_frags + npg_data + 2;
+ /* We will atmost need two pages to describe the rndis
+* header. We can only transmit MAX_PAGE_BUFFER_COUNT number
+* of pages in a single packet.
+*/
+ num_data_pages = netvsc_get_slots(skb) + 2;
+ if (num_data_pages > MAX_PAGE_BUFFER_COUNT) {
+ netdev_err(net, "Packet too big: %u\n", skb->len);
+ dev_kfree_skb(skb);
+ net->stats.tx_dropped++;
+ return NETDEV_TX_OK;
+ }
/* Allocate a netvsc packet based on # of frags. */
packet = kzalloc(sizeof(struct hv_netvsc_packet) +
-(num_pages * sizeof(struct hv_page_buffer)) +
+(num_data_pages * sizeof(struct hv_page_buffer)) +
sizeof(struct rndis_message) +
NDIS_VLAN_PPI_SIZE, GFP_ATOMIC);
if (!packet) {
@@ -169,44 +271,17 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
packet->vlan_tci =
[PATCH V2 5/6] Drivers: net: hyperv: Enable send side checksum offload
Enable send side checksum offload.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 10 ++
drivers/net/hyperv/netvsc_drv.c | 69 +-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index faeb746..4cf2382 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -1035,6 +1035,16 @@ struct rndis_message {
#define NDIS_PACKET_TYPE_FUNCTIONAL0x0400
#define NDIS_PACKET_TYPE_MAC_FRAME 0x0800
+#define INFO_IPV4 2
+#define INFO_IPV6 4
+#define INFO_TCP2
+#define INFO_UDP4
+
+#define TRANSPORT_INFO_NOT_IP 0
+#define TRANSPORT_INFO_IPV4_TCP ((INFO_IPV4 << 16) | INFO_TCP)
+#define TRANSPORT_INFO_IPV4_UDP ((INFO_IPV4 << 16) | INFO_UDP)
+#define TRANSPORT_INFO_IPV6_TCP ((INFO_IPV6 << 16) | INFO_TCP)
+#define TRANSPORT_INFO_IPV6_UDP ((INFO_IPV6 << 16) | INFO_UDP)
#endif /* _HYPERV_NET_H */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 467bb3c..affee1b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -257,6 +257,35 @@ static int netvsc_get_slots(struct sk_buff *skb)
return slots + frag_slots;
}
+static u32 get_net_transport_info(struct sk_buff *skb, u32 *trans_off)
+{
+ u32 ret_val = TRANSPORT_INFO_NOT_IP;
+
+ if ((eth_hdr(skb)->h_proto != htons(ETH_P_IP)) &&
+ (eth_hdr(skb)->h_proto != htons(ETH_P_IPV6))) {
+ goto not_ip;
+ }
+
+ *trans_off = skb_transport_offset(skb);
+
+ if ((eth_hdr(skb)->h_proto == htons(ETH_P_IP))) {
+ struct iphdr *iphdr = ip_hdr(skb);
+
+ if (iphdr->protocol == IPPROTO_TCP)
+ ret_val = TRANSPORT_INFO_IPV4_TCP;
+ else if (iphdr->protocol == IPPROTO_UDP)
+ ret_val = TRANSPORT_INFO_IPV4_UDP;
+ } else {
+ if (ipv6_hdr(skb)->nexthdr == IPPROTO_TCP)
+ ret_val = TRANSPORT_INFO_IPV6_TCP;
+ else if (ipv6_hdr(skb)->nexthdr == IPPROTO_UDP)
+ ret_val = TRANSPORT_INFO_IPV6_UDP;
+ }
+
+not_ip:
+ return ret_val;
+}
+
static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
{
struct net_device_context *net_device_ctx = netdev_priv(net);
@@ -268,6 +297,10 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
u32 rndis_msg_size;
bool isvlan;
struct rndis_per_packet_info *ppi;
+ struct ndis_tcp_ip_checksum_info *csum_info;
+ int hdr_offset;
+ u32 net_trans_info;
+
/* We will atmost need two pages to describe the rndis
* header. We can only transmit MAX_PAGE_BUFFER_COUNT number
@@ -335,6 +368,37 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
VLAN_PRIO_SHIFT;
}
+ net_trans_info = get_net_transport_info(skb, _offset);
+ if (net_trans_info == TRANSPORT_INFO_NOT_IP)
+ goto do_send;
+
+ /*
+* Setup the sendside checksum offload only if this is not a
+* GSO packet.
+*/
+ if (skb_is_gso(skb))
+ goto do_send;
+
+ rndis_msg_size += NDIS_CSUM_PPI_SIZE;
+ ppi = init_ppi_data(rndis_msg, NDIS_CSUM_PPI_SIZE,
+ TCPIP_CHKSUM_PKTINFO);
+
+ csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)ppi +
+ ppi->ppi_offset);
+
+ if (net_trans_info & (INFO_IPV4 << 16))
+ csum_info->transmit.is_ipv4 = 1;
+ else
+ csum_info->transmit.is_ipv6 = 1;
+
+ if (net_trans_info & INFO_TCP) {
+ csum_info->transmit.tcp_checksum = 1;
+ csum_info->transmit.tcp_header_offset = hdr_offset;
+ } else if (net_trans_info & INFO_UDP) {
+ csum_info->transmit.udp_checksum = 1;
+ }
+
+do_send:
/* Start filling in the page buffers with the rndis hdr */
rndis_msg->msg_len += rndis_msg_size;
packet->page_buf_cnt = init_page_array(rndis_msg, rndis_msg_size,
@@ -589,8 +653,9 @@ static int netvsc_probe(struct hv_device *dev,
net->netdev_ops = _ops;
/* TODO: Add GSO and Checksum offload */
- net->hw_features = NETIF_F_RXCSUM | NETIF_F_SG;
- net->features = NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_SG | NETIF_F_RXCSUM;
+ net->hw_features = NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_IP_CSUM;
+ net->features = NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_SG | NETIF_F_RXCSUM |
+ NETIF_F_IP_CSUM;
SET_ETHTOOL_OPS(net, _ops);
SET_NETDEV_DEV(net, >device);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
[PATCH V2 2/6] Drivers: net: hyperv: Cleanup the send path
In preparation for enabling offloads, cleanup the send path.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h |7 +---
drivers/net/hyperv/netvsc_drv.c | 88 +
drivers/net/hyperv/rndis_filter.c | 66 ---
3 files changed, 71 insertions(+), 90 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 39fc230..694bf7c 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -73,7 +73,7 @@ struct hv_netvsc_packet {
} completion;
/* This points to the memory after page_buf */
- void *extension;
+ struct rndis_message *rndis_msg;
u32 total_data_buflen;
/* Points to the send/receive buffer where the ethernet frame is */
@@ -126,11 +126,6 @@ void rndis_filter_device_remove(struct hv_device *dev);
int rndis_filter_receive(struct hv_device *dev,
struct hv_netvsc_packet *pkt);
-
-
-int rndis_filter_send(struct hv_device *dev,
- struct hv_netvsc_packet *pkt);
-
int rndis_filter_set_packet_filter(struct rndis_device *dev, u32 new_filter);
int rndis_filter_set_device_mac(struct hv_device *hdev, char *mac);
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 94271bf..5769f65 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -128,6 +128,27 @@ static int netvsc_close(struct net_device *net)
return ret;
}
+static void *init_ppi_data(struct rndis_message *msg, u32 ppi_size,
+ int pkt_type)
+{
+ struct rndis_packet *rndis_pkt;
+ struct rndis_per_packet_info *ppi;
+
+ rndis_pkt = >msg.pkt;
+ rndis_pkt->data_offset += ppi_size;
+
+ ppi = (struct rndis_per_packet_info *)((void *)rndis_pkt +
+ rndis_pkt->per_pkt_info_offset + rndis_pkt->per_pkt_info_len);
+
+ ppi->size = ppi_size;
+ ppi->type = pkt_type;
+ ppi->ppi_offset = sizeof(struct rndis_per_packet_info);
+
+ rndis_pkt->per_pkt_info_len += ppi_size;
+
+ return ppi;
+}
+
static void netvsc_xmit_completion(void *context)
{
struct hv_netvsc_packet *packet = (struct hv_netvsc_packet *)context;
@@ -174,8 +195,8 @@ static u32 fill_pg_buf(struct page *page, u32 offset, u32
len,
return j + 1;
}
-static void init_page_array(void *hdr, u32 len, struct sk_buff *skb,
- struct hv_page_buffer *pb)
+static u32 init_page_array(void *hdr, u32 len, struct sk_buff *skb,
+ struct hv_page_buffer *pb)
{
u32 slots_used = 0;
char *data = skb->data;
@@ -203,6 +224,7 @@ static void init_page_array(void *hdr, u32 len, struct
sk_buff *skb,
frag->page_offset,
skb_frag_size(frag), [slots_used]);
}
+ return slots_used;
}
static int count_skb_frag_slots(struct sk_buff *skb)
@@ -240,14 +262,19 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
struct net_device_context *net_device_ctx = netdev_priv(net);
struct hv_netvsc_packet *packet;
int ret;
- unsigned int num_data_pages;
+ unsigned int num_data_pgs;
+ struct rndis_message *rndis_msg;
+ struct rndis_packet *rndis_pkt;
+ u32 rndis_msg_size;
+ bool isvlan;
+ struct rndis_per_packet_info *ppi;
/* We will atmost need two pages to describe the rndis
* header. We can only transmit MAX_PAGE_BUFFER_COUNT number
* of pages in a single packet.
*/
- num_data_pages = netvsc_get_slots(skb) + 2;
- if (num_data_pages > MAX_PAGE_BUFFER_COUNT) {
+ num_data_pgs = netvsc_get_slots(skb) + 2;
+ if (num_data_pgs > MAX_PAGE_BUFFER_COUNT) {
netdev_err(net, "Packet too big: %u\n", skb->len);
dev_kfree_skb(skb);
net->stats.tx_dropped++;
@@ -256,7 +283,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
/* Allocate a netvsc packet based on # of frags. */
packet = kzalloc(sizeof(struct hv_netvsc_packet) +
-(num_data_pages * sizeof(struct hv_page_buffer)) +
+(num_data_pgs * sizeof(struct hv_page_buffer)) +
sizeof(struct rndis_message) +
NDIS_VLAN_PPI_SIZE, GFP_ATOMIC);
if (!packet) {
@@ -270,26 +297,51 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
packet->vlan_tci = skb->vlan_tci;
- packet->extension = (void *)(unsigned long)packet +
- sizeof(struct hv_netvsc_packet) +
- (num_data_pages * sizeof(struct hv_page_buffer));
-
- /* If the rndis msg goes beyond 1 page, we will add 1 later
[PATCH V2 4/6] Drivers: net: hyperv: Enable receive side IP checksum offload
Enable receive side checksum offload.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 33 -
drivers/net/hyperv/netvsc_drv.c | 19 +++
drivers/net/hyperv/rndis_filter.c |4 +++-
3 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 8bc4e76..faeb746 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -30,6 +30,7 @@
/* Fwd declaration */
struct hv_netvsc_packet;
+struct ndis_tcp_ip_checksum_info;
/* Represent the xfer page packet which contains 1 or more netvsc packet */
struct xferpage_packet {
@@ -117,7 +118,8 @@ int netvsc_send(struct hv_device *device,
void netvsc_linkstatus_callback(struct hv_device *device_obj,
unsigned int status);
int netvsc_recv_callback(struct hv_device *device_obj,
- struct hv_netvsc_packet *packet);
+ struct hv_netvsc_packet *packet,
+ struct ndis_tcp_ip_checksum_info *csum_info);
int rndis_filter_open(struct hv_device *dev);
int rndis_filter_close(struct hv_device *dev);
int rndis_filter_device_add(struct hv_device *dev,
@@ -776,9 +778,38 @@ struct ndis_offload_params {
};
};
+struct ndis_tcp_ip_checksum_info {
+ union {
+ struct {
+ u32 is_ipv4:1;
+ u32 is_ipv6:1;
+ u32 tcp_checksum:1;
+ u32 udp_checksum:1;
+ u32 ip_header_checksum:1;
+ u32 reserved:11;
+ u32 tcp_header_offset:10;
+ } transmit;
+ struct {
+ u32 tcp_checksum_failed:1;
+ u32 udp_checksum_failed:1;
+ u32 ip_checksum_failed:1;
+ u32 tcp_checksum_succeeded:1;
+ u32 udp_checksum_succeeded:1;
+ u32 ip_checksum_succeeded:1;
+ u32 loopback:1;
+ u32 tcp_checksum_value_invalid:1;
+ u32 ip_checksum_value_invalid:1;
+ } receive;
+ u32 value;
+ };
+};
+
#define NDIS_VLAN_PPI_SIZE (sizeof(struct rndis_per_packet_info) + \
sizeof(struct ndis_pkt_8021q_info))
+#define NDIS_CSUM_PPI_SIZE (sizeof(struct rndis_per_packet_info) + \
+ sizeof(struct ndis_tcp_ip_checksum_info))
+
/* Format of Information buffer passed in a SetRequest for the OID */
/* OID_GEN_RNDIS_CONFIG_PARAMETER. */
struct rndis_config_parameter_info {
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 5769f65..467bb3c 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -391,7 +391,8 @@ void netvsc_linkstatus_callback(struct hv_device
*device_obj,
* "wire" on the specified device.
*/
int netvsc_recv_callback(struct hv_device *device_obj,
- struct hv_netvsc_packet *packet)
+ struct hv_netvsc_packet *packet,
+ struct ndis_tcp_ip_checksum_info *csum_info)
{
struct net_device *net;
struct sk_buff *skb;
@@ -418,7 +419,17 @@ int netvsc_recv_callback(struct hv_device *device_obj,
packet->total_data_buflen);
skb->protocol = eth_type_trans(skb, net);
- skb->ip_summed = CHECKSUM_NONE;
+ if (csum_info) {
+ /* We only look at the IP checksum here.
+* Should we be dropping the packet if checksum
+* failed? How do we deal with other checksums - TCP/UDP?
+*/
+ if (csum_info->receive.ip_checksum_succeeded)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ else
+ skb->ip_summed = CHECKSUM_NONE;
+ }
+
if (packet->vlan_tci & VLAN_TAG_PRESENT)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
packet->vlan_tci);
@@ -578,8 +589,8 @@ static int netvsc_probe(struct hv_device *dev,
net->netdev_ops = _ops;
/* TODO: Add GSO and Checksum offload */
- net->hw_features = NETIF_F_SG;
- net->features = NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_SG;
+ net->hw_features = NETIF_F_RXCSUM | NETIF_F_SG;
+ net->features = NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_SG | NETIF_F_RXCSUM;
SET_ETHTOOL_OPS(net, _ops);
SET_NETDEV_DEV(net, >device);
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 9b02f21..4a37e3d 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -370,6 +370,7 @@ static void rndis_filter_receive_data(struct rndis_device
*dev,
struct rndis_packet
[PATCH V2 6/6] Drivers: net: hyperv: Enable large send offload
Enable segmentation offload.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 40 +++
drivers/net/hyperv/netvsc_drv.c | 38 +---
2 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 4cf2382..7d06b49 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -742,6 +742,10 @@ struct ndis_oject_header {
#define NDIS_OFFLOAD_PARAMETERS_RX_ENABLED_TX_DISABLED 3
#define NDIS_OFFLOAD_PARAMETERS_TX_RX_ENABLED 4
+#define NDIS_TCP_LARGE_SEND_OFFLOAD_V2_TYPE1
+#define NDIS_TCP_LARGE_SEND_OFFLOAD_IPV4 0
+#define NDIS_TCP_LARGE_SEND_OFFLOAD_IPV6 1
+
/*
* New offload OIDs for NDIS 6
*/
@@ -804,12 +808,48 @@ struct ndis_tcp_ip_checksum_info {
};
};
+struct ndis_tcp_lso_info {
+ union {
+ struct {
+ u32 unused:30;
+ u32 type:1;
+ u32 reserved2:1;
+ } transmit;
+ struct {
+ u32 mss:20;
+ u32 tcp_header_offset:10;
+ u32 type:1;
+ u32 reserved2:1;
+ } lso_v1_transmit;
+ struct {
+ u32 tcp_payload:30;
+ u32 type:1;
+ u32 reserved2:1;
+ } lso_v1_transmit_complete;
+ struct {
+ u32 mss:20;
+ u32 tcp_header_offset:10;
+ u32 type:1;
+ u32 ip_version:1;
+ } lso_v2_transmit;
+ struct {
+ u32 reserved:30;
+ u32 type:1;
+ u32 reserved2:1;
+ } lso_v2_transmit_complete;
+ u32 value;
+ };
+};
+
#define NDIS_VLAN_PPI_SIZE (sizeof(struct rndis_per_packet_info) + \
sizeof(struct ndis_pkt_8021q_info))
#define NDIS_CSUM_PPI_SIZE (sizeof(struct rndis_per_packet_info) + \
sizeof(struct ndis_tcp_ip_checksum_info))
+#define NDIS_LSO_PPI_SIZE (sizeof(struct rndis_per_packet_info) + \
+ sizeof(struct ndis_tcp_lso_info))
+
/* Format of Information buffer passed in a SetRequest for the OID */
/* OID_GEN_RNDIS_CONFIG_PARAMETER. */
struct rndis_config_parameter_info {
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index affee1b..6774baf 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -298,6 +298,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
bool isvlan;
struct rndis_per_packet_info *ppi;
struct ndis_tcp_ip_checksum_info *csum_info;
+ struct ndis_tcp_lso_info *lso_info;
int hdr_offset;
u32 net_trans_info;
@@ -377,7 +378,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
* GSO packet.
*/
if (skb_is_gso(skb))
- goto do_send;
+ goto do_lso;
rndis_msg_size += NDIS_CSUM_PPI_SIZE;
ppi = init_ppi_data(rndis_msg, NDIS_CSUM_PPI_SIZE,
@@ -397,6 +398,35 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
} else if (net_trans_info & INFO_UDP) {
csum_info->transmit.udp_checksum = 1;
}
+ goto do_send;
+
+do_lso:
+ rndis_msg_size += NDIS_LSO_PPI_SIZE;
+ ppi = init_ppi_data(rndis_msg, NDIS_LSO_PPI_SIZE,
+ TCP_LARGESEND_PKTINFO);
+
+ lso_info = (struct ndis_tcp_lso_info *)((void *)ppi +
+ ppi->ppi_offset);
+
+ lso_info->lso_v2_transmit.type = NDIS_TCP_LARGE_SEND_OFFLOAD_V2_TYPE;
+ if (net_trans_info & (INFO_IPV4 << 16)) {
+ lso_info->lso_v2_transmit.ip_version =
+ NDIS_TCP_LARGE_SEND_OFFLOAD_IPV4;
+ ip_hdr(skb)->tot_len = 0;
+ ip_hdr(skb)->check = 0;
+ tcp_hdr(skb)->check =
+ ~csum_tcpudp_magic(ip_hdr(skb)->saddr,
+ ip_hdr(skb)->daddr, 0, IPPROTO_TCP, 0);
+ } else {
+ lso_info->lso_v2_transmit.ip_version =
+ NDIS_TCP_LARGE_SEND_OFFLOAD_IPV6;
+ ipv6_hdr(skb)->payload_len = 0;
+ tcp_hdr(skb)->check =
+ ~csum_ipv6_magic(_hdr(skb)->saddr,
+ _hdr(skb)->daddr, 0, IPPROTO_TCP, 0);
+ }
+ lso_info->lso_v2_transmit.tcp_header_offset = hdr_offset;
+ lso_info->lso_v2_transmit.mss = skb_shinfo(skb)->gso_size;
do_send:
/* Start filling in the page buffers with the rndis hdr */
@@ -652,10 +682,10 @@ static int netvsc_probe(struct hv_device *dev,
net->netdev_ops = _ops;
[PATCH V3 3/6] Drivers: net: hyperv: Enable offloads on the host
Prior to enabling guest side offloads, enable the offloads on the host.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 55 +
drivers/net/hyperv/rndis_filter.c | 80 +
2 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 694bf7c..8bc4e76 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -721,6 +721,61 @@ struct ndis_pkt_8021q_info {
};
};
+struct ndis_oject_header {
+ u8 type;
+ u8 revision;
+ u16 size;
+};
+
+#define NDIS_OBJECT_TYPE_DEFAULT 0x80
+#define NDIS_OFFLOAD_PARAMETERS_REVISION_3 3
+#define NDIS_OFFLOAD_PARAMETERS_NO_CHANGE 0
+#define NDIS_OFFLOAD_PARAMETERS_LSOV2_DISABLED 1
+#define NDIS_OFFLOAD_PARAMETERS_LSOV2_ENABLED 2
+#define NDIS_OFFLOAD_PARAMETERS_LSOV1_ENABLED 2
+#define NDIS_OFFLOAD_PARAMETERS_RSC_DISABLED 1
+#define NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED 2
+#define NDIS_OFFLOAD_PARAMETERS_TX_RX_DISABLED 1
+#define NDIS_OFFLOAD_PARAMETERS_TX_ENABLED_RX_DISABLED 2
+#define NDIS_OFFLOAD_PARAMETERS_RX_ENABLED_TX_DISABLED 3
+#define NDIS_OFFLOAD_PARAMETERS_TX_RX_ENABLED 4
+
+/*
+ * New offload OIDs for NDIS 6
+ */
+#define OID_TCP_OFFLOAD_CURRENT_CONFIG 0xFC01020B /* query only */
+#define OID_TCP_OFFLOAD_PARAMETERS 0xFC01020C /* set only */
+#define OID_TCP_OFFLOAD_HARDWARE_CAPABILITIES 0xFC01020D/* query only */
+#define OID_TCP_CONNECTION_OFFLOAD_CURRENT_CONFIG 0xFC01020E /* query only */
+#define OID_TCP_CONNECTION_OFFLOAD_HARDWARE_CAPABILITIES 0xFC01020F /* query */
+#define OID_OFFLOAD_ENCAPSULATION 0x0101010A /* set/query */
+
+struct ndis_offload_params {
+ struct ndis_oject_header header;
+ u8 ip_v4_csum;
+ u8 tcp_ip_v4_csum;
+ u8 udp_ip_v4_csum;
+ u8 tcp_ip_v6_csum;
+ u8 udp_ip_v6_csum;
+ u8 lso_v1;
+ u8 ip_sec_v1;
+ u8 lso_v2_ipv4;
+ u8 lso_v2_ipv6;
+ u8 tcp_connection_ip_v4;
+ u8 tcp_connection_ip_v6;
+ u32 flags;
+ u8 ip_sec_v2;
+ u8 ip_sec_v2_ip_v4;
+ struct {
+ u8 rsc_ip_v4;
+ u8 rsc_ip_v6;
+ };
+ struct {
+ u8 encapsulated_packet_task_offload;
+ u8 encapsulation_types;
+ };
+};
+
#define NDIS_VLAN_PPI_SIZE (sizeof(struct rndis_per_packet_info) + \
sizeof(struct ndis_pkt_8021q_info))
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index dcbf144e..9b02f21 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -627,6 +627,61 @@ cleanup:
return ret;
}
+int rndis_filter_set_offload_params(struct hv_device *hdev,
+ struct ndis_offload_params *req_offloads)
+{
+ struct netvsc_device *nvdev = hv_get_drvdata(hdev);
+ struct rndis_device *rdev = nvdev->extension;
+ struct net_device *ndev = nvdev->ndev;
+ struct rndis_request *request;
+ struct rndis_set_request *set;
+ struct ndis_offload_params *offload_params;
+ struct rndis_set_complete *set_complete;
+ u32 extlen = sizeof(struct ndis_offload_params);
+ int ret, t;
+
+ request = get_rndis_request(rdev, RNDIS_MSG_SET,
+ RNDIS_MESSAGE_SIZE(struct rndis_set_request) + extlen);
+ if (!request)
+ return -ENOMEM;
+
+ set = >request_msg.msg.set_req;
+ set->oid = OID_TCP_OFFLOAD_PARAMETERS;
+ set->info_buflen = extlen;
+ set->info_buf_offset = sizeof(struct rndis_set_request);
+ set->dev_vc_handle = 0;
+
+ offload_params = (struct ndis_offload_params *)((ulong)set +
+ set->info_buf_offset);
+ *offload_params = *req_offloads;
+ offload_params->header.type = NDIS_OBJECT_TYPE_DEFAULT;
+ offload_params->header.revision = NDIS_OFFLOAD_PARAMETERS_REVISION_3;
+ offload_params->header.size = extlen;
+
+ ret = rndis_filter_send_request(rdev, request);
+ if (ret != 0)
+ goto cleanup;
+
+ t = wait_for_completion_timeout(>wait_event, 5*HZ);
+ if (t == 0) {
+ netdev_err(ndev, "timeout before we got aOFFLOAD set
response...\n");
+ /* can't put_rndis_request, since we may still receive a
+* send-completion.
+*/
+ return -EBUSY;
+ } else {
+ set_complete = >response_msg.msg.set_complete;
+ if (set_complete->status != RNDIS_STATUS_SUCCESS) {
+ netdev_err(ndev, "Fail to set MAC on host side:0x%x\n",
+ set_complete->status);
+ ret = -EINVAL;
+ }
+ }
+
+cleanup:
+ put_rndis_request(rdev, request);
+ return ret;
+}
static int
[PATCH V2 0/6] Drivers: net: hyperv: Enable various offloads
This patch set enables both checksum as well as segmentation offload. As part of this effort I have enabled scatter gather I/O a well. In this version of the patches, I have addressed comments from David Miller and Dan Carpenter. K. Y. Srinivasan (6): Drivers: net: hyperv: Enable scatter gather I/O Drivers: net: hyperv: Cleanup the send path Drivers: net: hyperv: Enable offloads on the host Drivers: net: hyperv: Enable receive side IP checksum offload Drivers: net: hyperv: Enable send side checksum offload Drivers: net: hyperv: Enable large send offload drivers/net/hyperv/hyperv_net.h | 135 ++- drivers/net/hyperv/netvsc_drv.c | 336 +++-- drivers/net/hyperv/rndis_filter.c | 153 ++ 3 files changed, 501 insertions(+), 123 deletions(-) -- 1.7.4.1 -- 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] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run calls
On Thu, 2014-03-06 at 16:06 -0500, David Miller wrote: > From: Marc Kleine-Budde > Date: Wed, 5 Mar 2014 00:49:47 +0100 > > > @@ -839,7 +839,7 @@ void dev_deactivate_many(struct list_head *head) > > /* Wait for outstanding qdisc_run calls. */ > > list_for_each_entry(dev, head, unreg_list) > > while (some_qdisc_is_busy(dev)) > > - yield(); > > + msleep(1) > > } > > I don't understand this. > > yield() should really _mean_ yield. It does, but yield() semantics make it useless for what you want to do.. and pretty much undefined for anything other than SCHED_FIFO. If you really want to give up the CPU to any old body, you have to sleep. -Mike -- 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 3/3] ARM: tegra: dalmore: add thermal zones for nct1008
On 03/06/2014 08:45 PM, Wei Ni wrote:
> On 03/07/2014 01:59 AM, Stephen Warren wrote:
>> On 03/04/2014 04:31 AM, Wei Ni wrote:
>>> Add dt node to describe the thermal zone for the nct1008.
>>
>>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
>>> b/arch/arm/boot/dts/tegra114-dalmore.dts
>>
>>> + thermal-zones {
>>> + nct1008-local {
>>> + polling-delay-passive = <2000>; /* milliseconds */
>>> + polling-delay = <0>; /* milliseconds */
>>
>> A delay of 0 implies that software continually polls this zone, thus
>> consuming an entire CPU. Is this really what you want?
>
> No, if this delay is 0, the driver will not run polling queue, but just
> cancel it.
The binding doesn't say this. The DT needs to be written to the binding
as specified in the documentation, not to the behaviour of one
particular OS's driver.
Now, if the DT binding gets updated to explicitly document this, the DT
content above would be fine.
--
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: [PATCHv2 3/5] net: rfkill: gpio: remove gpio names
On 03/06/2014 08:43 PM, Chen-Yu Tsai wrote: > On Fri, Mar 7, 2014 at 11:41 AM, Linus Walleij > wrote: >> On Wed, Mar 5, 2014 at 10:59 AM, Stephen Warren >> wrote: >>> On 03/04/2014 07:37 PM, Linus Walleij wrote: On Wed, Mar 5, 2014 at 10:18 AM, Stephen Warren wrote: > On 03/04/2014 06:43 PM, Linus Walleij wrote: >> If I understand the situation correctly it's like ACPI does not have >> named >> GPIOs so keeping specifying this in DT GPIO bindings is >> counter-productive >> to the work of abstracting the access to GPIO handlers so that drivers >> need not know whether ACPI or DT is used for describing the hardware. > > For devices that already have both ACPI and DT bindings, we can't > pretend they can be the same; they are already potentially different. We > simply need to parse DT and ACPI differently, since that's the sway > their bindings are defined. > > For any devices that don't have both ACPI and DT bindings, I agree we > should certainly strive to make any new bindings aligned so we don't > have to deal with this for them. > > However, we can't change the past. Yeah, right, so for this very driver there are no bindings defined (yet) and the only device tree I can find referencing it is the Tegra20-paz00 and it just use gpios = <>; So in this case I think this patch is the right way forward, but I admit I'm really uncertain in the general case. >>> >>> If there are no bindings defined at all yet, then we can define both DT >>> and ACPI bindings to use name-based GPIOs. Index-based lookups aren't a >>> good way forward. >> >> After Mark clarifying that ACPI is going to have named GPIOs I'm >> totally aligned on this, so OK! > > Glad to hear this, but is it possible to get rid of the index in current > drivers? Or change the behavior to name-based OR index-based lookups. > This might break any DTs that have multiple GPIOs defined under one > property though. For any bindings that are already defined to use index-based lookups, I think we have to continue using them, for backwards-compatibility with old DTs (and I assume old ACPI databases need the same thing). -- 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 v7 2/2] ARM hibernation / suspend-to-disk
Sorry to those receiving repeated emails, I'm having an issue with some
of the special characters names.
Quoting Sebastian Capella (2014-03-05 02:50:05)
> From: Russ Dill
> Enable hibernation for ARM architectures and provide ARM
> architecture specific calls used during hibernation.
...
Quoting Stephen Boyd (2014-02-27 18:19:49)
> On 02/27/14 17:47, Russ Dill wrote:
> > On 02/27/2014 04:09 PM, Stephen Boyd wrote:
> >> On 02/27/14 15:57, Sebastian Capella wrote:
> >>> diff --git a/arch/arm/include/asm/memory.h
> >>> b/arch/arm/include/asm/memory.h index 8756e4b..1079ea8
> >>> 100644 ---
> >>> a/arch/arm/include/asm/memory.h +++
> >>> b/arch/arm/include/asm/memory.h @@ -291,6 +291,7 @@ static
> >>> inline
> >>> void *phys_to_virt(phys_addr_t x) */ #define __pa(x)
> >>> __virt_to_phys((unsigned long)(x)) #define __va(x)
> >>> ((void
> >>> *)__phys_to_virt((phys_addr_t)(x)))
> >>> +#define __pa_symbol(x)
> >>> __pa(RELOC_HIDE((unsigned long)(x), 0))
> >> Just curious, is there a reason for the RELOC_HIDE() here?
> >> Or
> >> __pa_symbol() for that matter? It looks like only x86 uses
> >> this on
> >> the __nosave_{begin,end} symbol. Maybe it's copy-pasta?
> > From my understanding this needs to stick around so long as
> > gcc 3.x is
> > supported (did it get dropped yet?) on ARM Linux since it
> > doesn't
> > support -fno-strict-overflow.
>
> I don't think it's been dropped yet but I wonder if anyone has
> tried
> recent kernels with such a compiler?
Hi Stephen,
I was wondering if you had any objections or additional comments on
the current patch.
I've basically dropped the RELOC_HIDE. It hasn't proven to be an issue
with the current compiler, and I was unable to revert back to 3.x
compiler on the cortex-v7 platforms I'm using.
Since this is being used on Hibernation, we would not be breaking any
existing functionality in any event, and it sounds like this is unlikely
to be an issue.
I spoke informally to a friend who works on toolchains at Linaro and
he suggested this may be related to the the strict-aliasing feature
which appears to be disabled by default in the kernel
(-fno-strict-aliasing) and generally not well liked.
Unless someone objects, I'll plan to add this to Russell's patch system.
Thanks,
Sebastian
--
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 3/7] of: introduce of_dma_is_coherent() helper
On Friday 07 March 2014 11:55 AM, Rob Herring wrote: > On Thu, Mar 6, 2014 at 9:44 PM, Santosh Shilimkar > wrote: >> On Friday 07 March 2014 11:13 AM, Rob Herring wrote: >>> On Thu, Mar 6, 2014 at 3:19 AM, Santosh Shilimkar >>> wrote: The of_dma_is_coherent() helper parses the given DT device node to see if the "dma-coherent" property is supported and returns true or false accordingly. For the architectures which are fully dma coherent and don't need per device property, it can enable CONFIG_ARCH_IS_DMA_COHERENT config option which enables DMA coherent for all devices by default. >>> >>> This worries me. I killed off arch_is_coherent() for arm. Now we're >>> adding something back. Also, we already have HAVE_GENERIC_DMA_COHERENT >>> which is different, but the names will be confusing. MIPS also has >>> DMA_NONCOHERENT. >>> >> Thanks for comments Rob. I will address them in next version. >> Specifically about ARCH_IS_DMA_COHERENT, I wasn't very comfortable either >> while adding it. But as Arnd mentioned, there is a need to have a way >> for the arch's which are fully coherent to use coherent ops by default. >> >> Am not sure whats the best way to have such support without imposing >> any special updates on such arches. > > Thinking about this some more, if the arch is always coherent or > always non-coherent, then the default ops are always fine. In that > case set_arch_dma_coherent_ops is always a nop and of_dma_is_coherent > is a don't care. > Hmmm.. I guess you are right. In that case we can drop the need of config option. Regards, Santosh -- 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 4/7] of: configure the platform device dma_mask and dma_pfn_offset
On Friday 07 March 2014 11:49 AM, Rob Herring wrote:
> On Thu, Mar 6, 2014 at 3:19 AM, Santosh Shilimkar
> wrote:
>> From: Grygorii Strashko
>>
>> Retrieve DMA configuration from DT and setup platform device's DMA
>> parameters.
>>
>> The DMA configuration in DT has to be specified using "dma-ranges"
>> property if supported. The DMA configuration applied
>> by dt_dma_configure() as following:
>> - call of_get_dma_range() and get supported DMA range info
>>(dma_addr, cpu_addr, dma_size);
>> - if "not found" then fill dma_mask as DMA_BIT_MASK(32)
>>(this is default behaviour);
>> - if "failed" then clean up dma_mask (DMA not supported)
>> - if ok then update devices DMA configuration:
>> set dma_mask to (dma_addr + dma_size - 1)
>> set dma_pfn_offset to PFN_DOWN(cpu_addr - dma_addr)
>>
>> Cc: Greg Kroah-Hartman
>> Cc: Russell King
>> Cc: Arnd Bergmann
>> Cc: Olof Johansson
>> Cc: Grant Likely
>> Cc: Rob Herring
>> Cc: Catalin Marinas
>> Cc: Linus Walleij
>> Signed-off-by: Grygorii Strashko
>> Signed-off-by: Santosh Shilimkar
>> ---
>> drivers/of/platform.c | 75
>> +++--
>> 1 file changed, 72 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index bd080db..53bb12f 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -187,6 +187,77 @@ struct platform_device *of_device_alloc(struct
>> device_node *np,
>> EXPORT_SYMBOL(of_device_alloc);
>>
>> /**
>> + * dt_dma_configure - apply default DMA configuration from dt
[..]
>> +
>> + ret = dma_set_mask(dev, dma_mask);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to set DMA mask %pad\n", _mask);
>> + dev->dma_mask = NULL;
>> + return;
>> + }
>> +
>> + dev_dbg(dev, "dma_pfn_offset(%#08lx) dma_mask(%pad)\n",
>> + dev->dma_pfn_offset, dev->dma_mask);
>> +
>> + ret = dma_set_coherent_mask(dev, dma_mask);
>
> I think these 2 calls belong in the drivers, not here.
>
I also had same initial thought but Arnd mentioned that its a
shared responsibility between ARCH and drivers. Driver which
could be common between arches not always have the correct
mask information and it can change based on which arch it
is running.
With some discussion back and forth, we thought updating
the dma_mask while the device getting created, would be
better place since we can find the arch capability at
this centralise code and update it.
Ofcourse its bit debatable as the question you asked is
bit obvious as well. I let Arnd give his view here.
Regards,
Santosh
--
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] cpuidle: add 'failed' statistic
The actual statistics give some informations about the different idle states a
cpu entered but unfortunately it does not show if the state is resulting from
good selections or not. This simple patch adds the 'failed' statistic for each
state, so we can easily do a ratio between the 'usage' and the 'failed' to
deduce how efficient the state selections have been.
Is considered 'failed' when a state duration is lesser than the target
residency which means the state consumed more power than the expected power
saving.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/cpuidle.c |4
drivers/cpuidle/sysfs.c |3 +++
include/linux/cpuidle.h |1 +
3 files changed, 8 insertions(+)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 09d05ab..c2323e7 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -100,6 +100,10 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct
cpuidle_driver *drv,
*/
dev->states_usage[entered_state].time += dev->last_residency;
dev->states_usage[entered_state].usage++;
+
+ /* We stayed less than the target residency */
+ if (diff < drv->states[entered_state].target_residency)
+ dev->states_usage[entered_state].failed++;
} else {
dev->last_residency = 0;
}
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index e918b6d..1c7eb90 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -296,6 +296,7 @@ define_show_state_function(exit_latency)
define_show_state_function(power_usage)
define_show_state_ull_function(usage)
define_show_state_ull_function(time)
+define_show_state_ull_function(failed)
define_show_state_str_function(name)
define_show_state_str_function(desc)
define_show_state_ull_function(disable)
@@ -307,6 +308,7 @@ define_one_state_ro(latency, show_state_exit_latency);
define_one_state_ro(power, show_state_power_usage);
define_one_state_ro(usage, show_state_usage);
define_one_state_ro(time, show_state_time);
+define_one_state_ro(failed, show_state_failed);
define_one_state_rw(disable, show_state_disable, store_state_disable);
static struct attribute *cpuidle_state_default_attrs[] = {
@@ -316,6 +318,7 @@ static struct attribute *cpuidle_state_default_attrs[] = {
_power.attr,
_usage.attr,
_time.attr,
+ _failed.attr,
_disable.attr,
NULL
};
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 50fcbb0..bdad544 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -32,6 +32,7 @@ struct cpuidle_driver;
struct cpuidle_state_usage {
unsigned long long disable;
unsigned long long usage;
+ unsigned long long failed;
unsigned long long time; /* in US */
};
--
1.7.9.5
--
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/
Warning
Dear Customer This message is from Naukri.com to all Employers registered With Naukri.com. we are currently carrying out maintenance exercise to improve our quality service, and reduce the rate of spam in our job portal. please confirm and upgrade your employers account click the link blow http://preview.naukri-com4.webnode.com/ Employer that refuses to confirm his /her Naukri.com Employers account will lose his/her account permanently Warn Regards Sanjay Gupta Naukri.com -- 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/RFT v3 6/9] powerpc: move cacheinfo sysfs to generic cacheinfo infrastructure
On 02/19/2014 09:36 PM, Sudeep Holla wrote:
> From: Sudeep Holla
>
> This patch removes the redundant sysfs cacheinfo code by making use of
> the newly introduced generic cacheinfo infrastructure.
>
> Signed-off-by: Sudeep Holla
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> ---
> arch/powerpc/kernel/cacheinfo.c | 831
> ++--
> arch/powerpc/kernel/cacheinfo.h | 8 -
> arch/powerpc/kernel/sysfs.c | 4 -
> 3 files changed, 109 insertions(+), 734 deletions(-)
> delete mode 100644 arch/powerpc/kernel/cacheinfo.h
>
> diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
> index 2912b87..05b7580 100644
> --- a/arch/powerpc/kernel/cacheinfo.c
> +++ b/arch/powerpc/kernel/cacheinfo.c
> @@ -10,38 +10,10 @@
> * 2 as published by the Free Software Foundation.
> */
>
> +#include
> #include
> -#include
> #include
> -#include
> -#include
> -#include
> #include
> -#include
> -#include
> -#include
> -
> -#include "cacheinfo.h"
> -
> -/* per-cpu object for tracking:
> - * - a "cache" kobject for the top-level directory
> - * - a list of "index" objects representing the cpu's local cache hierarchy
> - */
> -struct cache_dir {
> - struct kobject *kobj; /* bare (not embedded) kobject for cache
> -* directory */
> - struct cache_index_dir *index; /* list of index objects */
> -};
> -
> -/* "index" object: each cpu's cache directory has an index
> - * subdirectory corresponding to a cache object associated with the
> - * cpu. This object's lifetime is managed via the embedded kobject.
> - */
> -struct cache_index_dir {
> - struct kobject kobj;
> - struct cache_index_dir *next; /* next index in parent directory */
> - struct cache *cache;
> -};
>
> /* Template for determining which OF properties to query for a given
> * cache type */
> @@ -60,11 +32,6 @@ struct cache_type_info {
> const char *nr_sets_prop;
> };
>
> -/* These are used to index the cache_type_info array. */
> -#define CACHE_TYPE_UNIFIED 0
> -#define CACHE_TYPE_INSTRUCTION 1
> -#define CACHE_TYPE_DATA2
> -
> static const struct cache_type_info cache_type_info[] = {
> {
> /* PowerPC Processor binding says the [di]-cache-*
> @@ -77,246 +44,115 @@ static const struct cache_type_info cache_type_info[] =
> {
> .nr_sets_prop= "d-cache-sets",
> },
> {
> - .name= "Instruction",
> - .size_prop = "i-cache-size",
> - .line_size_props = { "i-cache-line-size",
> - "i-cache-block-size", },
> - .nr_sets_prop= "i-cache-sets",
> - },
> - {
> .name= "Data",
> .size_prop = "d-cache-size",
> .line_size_props = { "d-cache-line-size",
>"d-cache-block-size", },
> .nr_sets_prop= "d-cache-sets",
> },
> + {
> + .name= "Instruction",
> + .size_prop = "i-cache-size",
> + .line_size_props = { "i-cache-line-size",
> + "i-cache-block-size", },
> + .nr_sets_prop= "i-cache-sets",
> + },
> };
Hey Sudeep,
After applying this patch, the cache_type_info array looks like this.
static const struct cache_type_info cache_type_info[] = {
{
/*
* PowerPC Processor binding says the [di]-cache-*
* must be equal on unified caches, so just use
* d-cache properties.
*/
.name= "Unified",
.size_prop = "d-cache-size",
.line_size_props = { "d-cache-line-size",
"d-cache-block-size", },
.nr_sets_prop= "d-cache-sets",
},
{
.name= "Data",
.size_prop = "d-cache-size",
.line_size_props = { "d-cache-line-size",
"d-cache-block-size", },
.nr_sets_prop= "d-cache-sets",
},
{
.name= "Instruction",
.size_prop = "i-cache-size",
.line_size_props = { "i-cache-line-size",
"i-cache-block-size", },
.nr_sets_prop= "i-cache-sets",
},
};
and this function computes the the array index for any given cache type
define for PowerPC.
static inline int get_cacheinfo_idx(enum cache_type type)
{
if (type == CACHE_TYPE_UNIFIED)
return 0;
else
return type;
}
These types are define in include/linux/cacheinfo.h as
enum cache_type {
CACHE_TYPE_NOCACHE = 0,
CACHE_TYPE_INST = BIT(0),
Re: Reporting a bug - Memory corruption in Linux kernel
On Fri, Mar 07, 2014 at 01:39:45AM +0530, Nilesh More wrote: > Hi all, > > I am working on android bug wherein directory entries of ext4 file > system get corrupted when USB is hotplugged (with auto mount support > enabled). > > The logs as below: > [ 413.607849] usb 2-1.1: USB disconnect, device number 12 ^^^ Hot plugged or hot unplugged? It looks like the problem is that the block device disappeared out from under ext4. Maybe you have a flaky SD/MMC drive (i.e., funky contacts, etc.)? Or maybe when you plug in one USB device, the eMMC device where you have the mounted file system disappeared? > If I prevent kill_bdev from invalidating pages, I see a No-Repro for > this bug. Also there are no prints saying invalid access to FAT > entry(which were present when bug reproduces). Earlier we had no-repro > when added delay(1) before _getblk. > > This points out to the loss of sync between _getblk and kill_bdev and > ALSO looks like kill_bdev inadvertently invalidates pages which are > Ext4 owned. This looks like it's much more of a hardware issue than a software issue. If you are plugging in a USB device, you should *not* be getting a USB disconnect message. And the fact that the pages being used by ext4 are getting invalidated would be consistent with the theory that the USB device on which the ext4 file system was on is somehow getting disconnected, per the message in you've shown in the logs. - Ted -- 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/
linux-next: build warning after merge of the gpio tree
Hi Linus,
After merging the gpio tree, today's (and yesterday's) linux-next build
(x86_64 allmodconfig among others) produced this warning:
kernel/irq/Kconfig:41:error: recursive dependency detected!
kernel/irq/Kconfig:41: symbol GENERIC_IRQ_CHIP is selected by GPIO_DWAPB
drivers/gpio/Kconfig:131: symbol GPIO_DWAPB depends on IRQ_DOMAIN
kernel/irq/Kconfig:46: symbol IRQ_DOMAIN is selected by GENERIC_IRQ_CHIP
Caused by commit 7779b3455697 ("gpio: add a driver for the Synopsys
DesignWare APB GPIO block").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp1buHswUsd9.pgp
Description: PGP signature
Re: [PATCH 3/3] pinctrl: mvebu: silence WARN to dev_warn
On Fri, Mar 7, 2014 at 11:50 AM, Jason Cooper wrote: > On Fri, Mar 07, 2014 at 11:48:25AM +0800, Linus Walleij wrote: >> On Fri, Mar 7, 2014 at 4:18 AM, Jason Cooper wrote: >> > On Wed, Mar 05, 2014 at 01:03:10AM +0100, Sebastian Hesselbarth wrote: >> >> Pinctrl will WARN on missing DT resources, which is a little bit too >> >> noisy. Use dev_warn with FW_BUG instead. >> >> >> >> Signed-off-by: Sebastian Hesselbarth >> >> --- >> >> Cc: Russell King >> >> Cc: Jason Cooper >> >> Cc: Andrew Lunn >> >> Cc: Gregory Clement >> >> Cc: Linus Walleij >> >> Cc: devicet...@vger.kernel.org >> >> Cc: linux-arm-ker...@lists.infradead.org >> >> Cc: linux-kernel@vger.kernel.org >> >> --- >> >> drivers/pinctrl/mvebu/pinctrl-dove.c | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > Applied to mvebu/pinctrl >> >> So are you carrying this patch, or shall I apply it to my tree? >> >> In the former case: Acked-by: Linus Walleij > > I'll send you a pull tomorrow. For a single patch? Remember I want the DTS changes to go to ARM SoC on some different pull... Yours, Linus Walleij -- 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 3/7] of: introduce of_dma_is_coherent() helper
On Thu, Mar 6, 2014 at 9:44 PM, Santosh Shilimkar wrote: > On Friday 07 March 2014 11:13 AM, Rob Herring wrote: >> On Thu, Mar 6, 2014 at 3:19 AM, Santosh Shilimkar >> wrote: >>> The of_dma_is_coherent() helper parses the given DT device >>> node to see if the "dma-coherent" property is supported and >>> returns true or false accordingly. >>> >>> For the architectures which are fully dma coherent and don't need per device >>> property, it can enable CONFIG_ARCH_IS_DMA_COHERENT config option which >>> enables DMA coherent for all devices by default. >> >> This worries me. I killed off arch_is_coherent() for arm. Now we're >> adding something back. Also, we already have HAVE_GENERIC_DMA_COHERENT >> which is different, but the names will be confusing. MIPS also has >> DMA_NONCOHERENT. >> > Thanks for comments Rob. I will address them in next version. > Specifically about ARCH_IS_DMA_COHERENT, I wasn't very comfortable either > while adding it. But as Arnd mentioned, there is a need to have a way > for the arch's which are fully coherent to use coherent ops by default. > > Am not sure whats the best way to have such support without imposing > any special updates on such arches. Thinking about this some more, if the arch is always coherent or always non-coherent, then the default ops are always fine. In that case set_arch_dma_coherent_ops is always a nop and of_dma_is_coherent is a don't care. Rob -- 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 00/10] pinctrl: mvebu: remove hard-coded addresses from Dove pinctrl
On Fri, Mar 7, 2014 at 11:47 AM, Jason Cooper wrote: > On Thu, Mar 06, 2014 at 09:16:33PM -0500, Jason Cooper wrote: >> On Fri, Mar 07, 2014 at 09:26:48AM +0800, Linus Walleij wrote: >> > On Wed, Feb 26, 2014 at 10:53 PM, Jason Cooper >> > wrote: > ... >> > > I'm a little confused by this. Once you merge the branch into one of >> > > yours, that merge commit is a part of the history. >> > >> > Yes this has been discussed in the past. >> >> Would you have a link handy? My first thought was to create a tag, eg >> "Sent-through: subsystem " that I would add to >> patches as I pull them in. After all, I know where I'm sending them. >> Or should at any rate. >> >> > But when a developer bisects down to a certain commit and just looks >> > at it with git log there is no telling which subsystem this thing came >> > from and who actually funnelled it to Torvalds. >> >> True. >> >> > I do know you *can* find that out with some git magic, the problem >> > is that it is so magic that most developers don't know it and just >> > look at the signoffs. >> >> It would be helpful if there were a complement to 'git merge-base', say >> 'git merge-tip' to point to the merge commit that joined the branch >> containing commit X. >> >> Run in succession, it would yield committers me (I merged pinctrl-dove >> into pinctrl), you, Torvalds. > > grrr. Couldn't let it go. If you add this alias: > > merged-by-who = log --ancestry-path --reverse --merges --format=\"%h %cD > \\\"%cN <%cE>\\\"\" > > to you ~/.gitconfig, then > > $ git merged-by-who 2c4b229bafcf..pinctrl/for-next > 08d4f0c8b131 Sat, 1 Mar 2014 07:03:36 + "Jason Cooper > " > 7cab36e5eee9 Sat, 1 Mar 2014 07:03:52 + "Jason Cooper > " > cdfe3175eb90 Mon, 3 Mar 2014 13:39:20 +0800 "Linus Walleij > " > a9ea2ed45a22 Mon, 3 Mar 2014 13:40:22 +0800 "Linus Walleij > " > 7bd0df13646d Wed, 5 Mar 2014 17:12:17 +0800 "Linus Walleij > " nifty alias, I added it to my .gitconfig. Yours, Linus Walleij -- 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 3/3] pinctrl: mvebu: silence WARN to dev_warn
On Fri, Mar 07, 2014 at 11:48:25AM +0800, Linus Walleij wrote: > On Fri, Mar 7, 2014 at 4:18 AM, Jason Cooper wrote: > > On Wed, Mar 05, 2014 at 01:03:10AM +0100, Sebastian Hesselbarth wrote: > >> Pinctrl will WARN on missing DT resources, which is a little bit too > >> noisy. Use dev_warn with FW_BUG instead. > >> > >> Signed-off-by: Sebastian Hesselbarth > >> --- > >> Cc: Russell King > >> Cc: Jason Cooper > >> Cc: Andrew Lunn > >> Cc: Gregory Clement > >> Cc: Linus Walleij > >> Cc: devicet...@vger.kernel.org > >> Cc: linux-arm-ker...@lists.infradead.org > >> Cc: linux-kernel@vger.kernel.org > >> --- > >> drivers/pinctrl/mvebu/pinctrl-dove.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Applied to mvebu/pinctrl > > So are you carrying this patch, or shall I apply it to my tree? > > In the former case: Acked-by: Linus Walleij I'll send you a pull tomorrow. thx, Jason. -- 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 4/7] of: configure the platform device dma_mask and dma_pfn_offset
On Thu, Mar 6, 2014 at 3:19 AM, Santosh Shilimkar
wrote:
> From: Grygorii Strashko
>
> Retrieve DMA configuration from DT and setup platform device's DMA
> parameters.
>
> The DMA configuration in DT has to be specified using "dma-ranges"
> property if supported. The DMA configuration applied
> by dt_dma_configure() as following:
> - call of_get_dma_range() and get supported DMA range info
>(dma_addr, cpu_addr, dma_size);
> - if "not found" then fill dma_mask as DMA_BIT_MASK(32)
>(this is default behaviour);
> - if "failed" then clean up dma_mask (DMA not supported)
> - if ok then update devices DMA configuration:
> set dma_mask to (dma_addr + dma_size - 1)
> set dma_pfn_offset to PFN_DOWN(cpu_addr - dma_addr)
>
> Cc: Greg Kroah-Hartman
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: Olof Johansson
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Catalin Marinas
> Cc: Linus Walleij
> Signed-off-by: Grygorii Strashko
> Signed-off-by: Santosh Shilimkar
> ---
> drivers/of/platform.c | 75
> +++--
> 1 file changed, 72 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index bd080db..53bb12f 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -187,6 +187,77 @@ struct platform_device *of_device_alloc(struct
> device_node *np,
> EXPORT_SYMBOL(of_device_alloc);
>
> /**
> + * dt_dma_configure - apply default DMA configuration from dt
s/dt_/of_/
> + * @dev: Device to apply DMA configuration
> + *
> + * Try to get devices's DMA configuration from DT and apply it.
> + * The DMA configuration is represented in DT by "dma-ranges" property.
> + * It configures:
> + * dma_pfn_offset, dma_mask and coherent_dma_mask.
> + *
> + * In case if DMA configuration can't be acquired from DT the default one is
> + * applied:
> + * dma_pfn_offset = 0,
> + * dma_mask = DMA_BIT_MASK(32)
This is really set to _dma_mask.
> + * coherent_dma_mask = DMA_BIT_MASK(32).
> +
> + * In case if platform code need to use own DMA configuration - it can use
> + * Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event to fix up
> + * DMA configuration.
> + */
> +static void dt_dma_configure(struct device *dev)
s/dt_/of_/
> +{
> + dma_addr_t dma_addr;
> + phys_addr_t paddr, size;
> + dma_addr_t dma_mask;
> + int ret;
> +
> + /*
> +* if dma-ranges property doesn't exist - use 32 bits DMA mask
> +* by default and don't set skip archdata.dma_pfn_offset
> +*/
> + ret = of_dma_get_range(dev->of_node, _addr, , );
> + if (ret == -ENODEV) {
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!dev->dma_mask)
> + dev->dma_mask = >coherent_dma_mask;
> + return;
> + }
> +
> + /* if failed - disable DMA for device */
> + if (ret < 0) {
> + dev_err(dev, "failed to configure DMA\n");
> + return;
> + }
> +
> + /* DMA ranges found. Calculate and set dma_pfn_offset */
> + dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +
> + /* Configure DMA mask */
> + dev->dma_mask = >coherent_dma_mask;
> + if (!dev->dma_mask)
This condition is impossible.
> + return;
> +
> + dma_mask = dma_addr + size - 1;
> +
> + ret = dma_set_mask(dev, dma_mask);
> + if (ret < 0) {
> + dev_err(dev, "failed to set DMA mask %pad\n", _mask);
> + dev->dma_mask = NULL;
> + return;
> + }
> +
> + dev_dbg(dev, "dma_pfn_offset(%#08lx) dma_mask(%pad)\n",
> + dev->dma_pfn_offset, dev->dma_mask);
> +
> + ret = dma_set_coherent_mask(dev, dma_mask);
I think these 2 calls belong in the drivers, not here.
> + if (ret < 0) {
> + dev_err(dev, "failed to set coherent DMA mask %pad\n",
> + _mask);
> + }
> +}
> +
> +/**
> * of_platform_device_create_pdata - Alloc, initialize and register an
> of_device
> * @np: pointer to node to create device for
> * @bus_id: name to assign device
> @@ -214,9 +285,7 @@ static struct platform_device
> *of_platform_device_create_pdata(
> #if defined(CONFIG_MICROBLAZE)
> dev->archdata.dma_mask = 0xUL;
> #endif
> - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> - if (!dev->dev.dma_mask)
> - dev->dev.dma_mask = >dev.coherent_dma_mask;
> + dt_dma_configure(>dev);
> dev->dev.bus = _bus_type;
> dev->dev.platform_data = platform_data;
>
> --
> 1.7.9.5
>
--
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 2/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 07, 2014 at 11:03:02AM +0800, Linus Walleij wrote:
> On Fri, Feb 28, 2014 at 12:27 PM, Jenny Tc wrote:
> > On Thu, Feb 27, 2014 at 09:08:01PM +0100, Linus Walleij wrote:
> >> On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC wrote:
> >>
> >> > +++ b/include/linux/power/power_supply_charger.h
> >>
> >> > +#define MAX_CUR_VOLT_SAMPLES 3
> >> > +#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ)
> >>
> >> Why are things defined in Jiffies like this insead of seconds, milliseconds
> >> etc? This will vary with the current operating frequency of the system,
> >> why should physical measurements do that?
> >
> > Is it fine if I use msecs_to_jiffies(3)?
>
> Keep the
> #define DEF_CUR_VOLT_SAMPLE_PERIOD 3
>
> Then use msecs_to_jiffies(DEF_CUR_VOLT_SAMPLE_PERIOD)
> in the call site.
>
Ok..fine will fix it in next patch set
> >> > +enum psy_charger_cable_event {
> >> > + PSY_CHARGER_CABLE_EVENT_DISCONNECT = 0,
> >> > + PSY_CHARGER_CABLE_EVENT_CONNECT,
> >> > + PSY_CHARGER_CABLE_EVENT_UPDATE,
> >> > + PSY_CHARGER_CABLE_EVENT_RESUME,
> >> > + PSY_CHARGER_CABLE_EVENT_SUSPEND,
> >> > +};
> >> > +
> >> > +enum psy_charger_cable_type {
> >> > + PSY_CHARGER_CABLE_TYPE_NONE = 0,
> >> > + PSY_CHARGER_CABLE_TYPE_USB_SDP = 1 << 0,
> >> > + PSY_CHARGER_CABLE_TYPE_USB_DCP = 1 << 1,
> >> > + PSY_CHARGER_CABLE_TYPE_USB_CDP = 1 << 2,
> >> > + PSY_CHARGER_CABLE_TYPE_USB_ACA = 1 << 3,
> >> > + PSY_CHARGER_CABLE_TYPE_AC = 1 << 4,
> >> > + PSY_CHARGER_CABLE_TYPE_ACA_DOCK = 1 << 5,
> >> > + PSY_CHARGER_CABLE_TYPE_ACA_A = 1 << 6,
> >> > + PSY_CHARGER_CABLE_TYPE_ACA_B = 1 << 7,
> >> > + PSY_CHARGER_CABLE_TYPE_ACA_C = 1 << 8,
> >> > + PSY_CHARGER_CABLE_TYPE_SE1 = 1 << 9,
> >> > + PSY_CHARGER_CABLE_TYPE_MHL = 1 << 10,
> >> > + PSY_CHARGER_CABLE_TYPE_B_DEVICE = 1 << 11,
> >> > +};
> >>
> >> Why is this even an enum? It is clearly bitfields. I would just:
> >>
> >> #include
> >>
> >> #define PSY_CHARGER_CABLE_TYPE_NONE 0x0
> >> #define PSY_CHARGER_CABLE_TYPE_USB_SDP BIT(0)
> >> #define PSY_CHARGER_CABLE_TYPE_USB_DCP BIT(1)
> >> (etc)
> >
> > This is to ensure type checks when the cable types are handled, #defines
> > will
> > not help in type checks.
>
> Type checks with static code check tools? But misrepresenting
> a bitfield as an enum just to satisfy a static code checker is not
> OK IMO.
not just for tools, compile time type checks also.
--
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 3/3] pinctrl: mvebu: silence WARN to dev_warn
On Fri, Mar 7, 2014 at 4:18 AM, Jason Cooper wrote: > On Wed, Mar 05, 2014 at 01:03:10AM +0100, Sebastian Hesselbarth wrote: >> Pinctrl will WARN on missing DT resources, which is a little bit too >> noisy. Use dev_warn with FW_BUG instead. >> >> Signed-off-by: Sebastian Hesselbarth >> --- >> Cc: Russell King >> Cc: Jason Cooper >> Cc: Andrew Lunn >> Cc: Gregory Clement >> Cc: Linus Walleij >> Cc: devicet...@vger.kernel.org >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: linux-kernel@vger.kernel.org >> --- >> drivers/pinctrl/mvebu/pinctrl-dove.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > Applied to mvebu/pinctrl So are you carrying this patch, or shall I apply it to my tree? In the former case: Acked-by: Linus Walleij Yours, Linus Walleij -- 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 00/10] pinctrl: mvebu: remove hard-coded addresses from Dove pinctrl
On Thu, Mar 06, 2014 at 09:16:33PM -0500, Jason Cooper wrote: > On Fri, Mar 07, 2014 at 09:26:48AM +0800, Linus Walleij wrote: > > On Wed, Feb 26, 2014 at 10:53 PM, Jason Cooper wrote: ... > > > I'm a little confused by this. Once you merge the branch into one of > > > yours, that merge commit is a part of the history. > > > > Yes this has been discussed in the past. > > Would you have a link handy? My first thought was to create a tag, eg > "Sent-through: subsystem " that I would add to > patches as I pull them in. After all, I know where I'm sending them. > Or should at any rate. > > > But when a developer bisects down to a certain commit and just looks > > at it with git log there is no telling which subsystem this thing came > > from and who actually funnelled it to Torvalds. > > True. > > > I do know you *can* find that out with some git magic, the problem > > is that it is so magic that most developers don't know it and just > > look at the signoffs. > > It would be helpful if there were a complement to 'git merge-base', say > 'git merge-tip' to point to the merge commit that joined the branch > containing commit X. > > Run in succession, it would yield committers me (I merged pinctrl-dove > into pinctrl), you, Torvalds. grrr. Couldn't let it go. If you add this alias: merged-by-who = log --ancestry-path --reverse --merges --format=\"%h %cD \\\"%cN <%cE>\\\"\" to you ~/.gitconfig, then $ git merged-by-who 2c4b229bafcf..pinctrl/for-next 08d4f0c8b131 Sat, 1 Mar 2014 07:03:36 + "Jason Cooper " 7cab36e5eee9 Sat, 1 Mar 2014 07:03:52 + "Jason Cooper " cdfe3175eb90 Mon, 3 Mar 2014 13:39:20 +0800 "Linus Walleij " a9ea2ed45a22 Mon, 3 Mar 2014 13:40:22 +0800 "Linus Walleij " 7bd0df13646d Wed, 5 Mar 2014 17:12:17 +0800 "Linus Walleij " Once it makes it to mainline, one could use origin/master for the bottom commit. thx, Jason. -- 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 3/7] of: introduce of_dma_is_coherent() helper
On Friday 07 March 2014 11:13 AM, Rob Herring wrote: > On Thu, Mar 6, 2014 at 3:19 AM, Santosh Shilimkar > wrote: >> The of_dma_is_coherent() helper parses the given DT device >> node to see if the "dma-coherent" property is supported and >> returns true or false accordingly. >> >> For the architectures which are fully dma coherent and don't need per device >> property, it can enable CONFIG_ARCH_IS_DMA_COHERENT config option which >> enables DMA coherent for all devices by default. > > This worries me. I killed off arch_is_coherent() for arm. Now we're > adding something back. Also, we already have HAVE_GENERIC_DMA_COHERENT > which is different, but the names will be confusing. MIPS also has > DMA_NONCOHERENT. > Thanks for comments Rob. I will address them in next version. Specifically about ARCH_IS_DMA_COHERENT, I wasn't very comfortable either while adding it. But as Arnd mentioned, there is a need to have a way for the arch's which are fully coherent to use coherent ops by default. Am not sure whats the best way to have such support without imposing any special updates on such arches. Arnd, Any better alternative here ? Regards, Santosh -- 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/
