[PATCH v2 5/7] vfio: Use new interfaces for MSI/MSI-X enablement

[Alexander Gordeev]

Signed-off-by: Alexander Gordeev 
---
 drivers/vfio/pci/vfio_pci_intrs.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 641bc87..66d1746 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -482,15 +482,15 @@ static int vfio_msi_enable(struct vfio_pci_device *vdev, 
int nvec, bool msix)
for (i = 0; i < nvec; i++)
vdev->msix[i].entry = i;
 
-   ret = pci_enable_msix(pdev, vdev->msix, nvec);
-   if (ret) {
+   ret = pci_enable_msix_range(pdev, vdev->msix, nvec, nvec);
+   if (ret < 0) {
kfree(vdev->msix);
kfree(vdev->ctx);
return ret;
}
} else {
-   ret = pci_enable_msi_block(pdev, nvec);
-   if (ret) {
+   ret = pci_enable_msi_range(pdev, nvec, nvec);
+   if (ret < 0) {
kfree(vdev->ctx);
return ret;
}
-- 
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/

RE: [PATCH 1/3] mfd: Add realtek USB card reader driver

[Roger Tseng]

Hi Dan,

>> +int rtsx_usb_ep0_write_register(struct rtsx_ucr *ucr, u16 addr,
>> + u8 mask, u8 data)
>> +{
>> + u16 value = 0, index = 0;
>> +
>> + value |= (u16)(3 & 0x03) << 14;
>> + value |= (u16)(addr & 0x3FFF);
>
>Don't do pointless things:
>
>value |= 0x03 << 14;
>value |= addr & 0x3FFF;
>
>> + value = ((value << 8) & 0xFF00) | ((value >> 8) & 0x00FF);
>
>This is an endian conversion?  It is buggy.  Use the kernel endian
>conversion functions cpu_to_le16().

This is not a conversion for endianess with respect to CPU but for command 
format  of the device. It should always be performed regardless of platform.

In other words, it could be equivalent to:
value |= 0x03 << 6; // lower byte
value |= (addr & 0x3F00) >> 8; // lower byte
value |= (addr & 0xFF) << 8; //higher byte

We think the previous form is easier to read. Should we keep it or change to 
the later one?--
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][PATCH] tracing: Show available event triggers when no trigger is set

[Namhyung Kim]

Hi Steve,

On Tue, 7 Jan 2014 10:35:48 -0500, Steven Rostedt wrote:
> Currently there's no way to know what triggers exist on a kernel without
> looking at the source of the kernel or randomly trying out triggers.
> Instead of creating another file in the debugfs system, simply show
> what available triggers are there when cat'ing the trigger file when
> it has no events:
>
>  [root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
>  # Available triggers:
>  # disable_event enable_event stacktrace snapshot traceoff traceon
>
> This stays consistent with other debugfs files where meta data like
> this is always proceeded with a '#' at the start of the line so that
> tools can strip these out.

[SNIP]
> + if (v == SHOW_AVAILABLE_TRIGGERS) {
> + seq_puts(m, "# Available triggers:\n");
> + seq_putc(m, '#');
> + mutex_lock(_cmd_mutex);
> + list_for_each_entry(p, _commands, list)

I guess the list_for_each_entry_reverse() will give a more intuitive
result here:

  [root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
  # Available triggers:
  # traceon traceoff snapshot stacktrace enable_event disable_event

Thanks,
Namhyung


> + seq_printf(m, " %s", p->name);
> + seq_putc(m, '\n');
> + mutex_unlock(_cmd_mutex);
> + return 0;
> + }
>  
>   data = list_entry(v, struct event_trigger_data, list);
>   data->ops->print(m, data->ops, data);
--
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: Sanitize CPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task)

[halfdog]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Update to the issue:

* Although first observed with virtual-8086 mode, the bug is not
specific to virtual-8086 mode, it can be triggered with normal x86
userspace code also, even with better reproducibility.

* Ben Hutchings looked at the Debian bug report [1], he failed to
reproduce on his hardware, so it might be specific to some CPU models
(currently my AMD E-350 is only machine known to be affected).

* When deactivating mmap_min_addr, the NULL-dereferences during
task-switch is exploitable, works both on native hardware and within
VirtualBox. See [2] for POC to gain root privileges.

* It seems, that when changing the FPU control word with "fstcw" just
before exit of the process, then another process could suffer when
doing __do_switch, probably related to the xsave instruction and a x86
processor bug workaround, see "noxsave" switch [3]: [BUGS=X86]
Disables x86 extended register state save and restore using xsave. The
kernel will fallback to enabling legacy floating-point and sse state.

hd

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733551
[2]
http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/
[3] https://www.kernel.org/doc/Documentation/kernel-parameters.txt

- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlLNAjEACgkQxFmThv7tq+44FACfeDHQHK71+7tZawm9Ftjw7Hvp
j04AmwY04UwG9clERS3e1HisM2swbo1i
=KoQL
-END PGP SIGNATURE-
--
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] comedi: Humusoft MF634 and MF624 DAQ cards driver

[Dan Carpenter]

On Tue, Jan 07, 2014 at 11:24:57PM +0100, Rostislav Lisovy wrote:
> This patch adds Comedi driver for Humusoft MF634 (PCIe) and
> MF624 (PCI) data acquisition cards. The legacy card Humusoft
> MF614 is not supported. More info about the cards may be found
> at http://humusoft.cz/produkty/datacq/
> The driver was tested with both cards. Everything seems to work
> properly. Just the basic functionality of the card (DIO, ADC, DAC)
> is supported by this driver.
> 
> Signed-off-by: Rostislav Lisovy 
> 
>  create mode 100644 drivers/staging/comedi/drivers/mf6x4.c
> 

There should be a "---" after the Signed-off-by line and before the
diffstat "create mode 100644 drivers/staging/comedi/drivers/mf6x4.c"
line.  Otherwise, the diffstat gets included in the changelog.

Signed-off-by: Rostislav Lisovy 
---
create mode 100644 drivers/staging/comedi/drivers/mf6x4.c

It's a small thing...  I almost feel bad for pointing it out.

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: [PATCH 5/7] vfio: Use new interfaces for MSI/MSI-X enablement

[Alexander Gordeev]

On Tue, Jan 07, 2014 at 11:34:13AM -0700, Alex Williamson wrote:
> On Tue, 2014-01-07 at 19:05 +0100, Alexander Gordeev wrote:
> > This update also fixes a bug when deprecated pci_enable_msix()
> > and pci_enable_msi_block() functions return a positive return
> > value which indicats the number of interrupts that could have
> > been allocated rather than a successful allocation. The driver
> > misinterpreted this value and assumed MSI-X/MSIs are enabled,
> > although in fact it were not.
> 
> No, the driver interpreted it correctly, which is why anything other
> than zero is handled as an error.  This patch looks incorrect if the new
> interfaces follow the same return convention.  Thanks,

The new interfaces differ wrt the return value - it is eigher a negative
error code or a positive number of successfuly allocated vectors. 

If the user level makes use of a number of vectors that could have been
allocated then it should cease doing it, since only 0 or a negative error
code is returned after this update.

The changelog is incorrect as the driver indeed bailes out on positive
return values. I will send a updated version.

> Alex

-- 
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/

Re: [PATCH 1/5] tools lib traceevent: Add WARN and WARN_ONCE macros

[Namhyung Kim]

Hi Arnaldo,

On Tue, 7 Jan 2014 11:07:47 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jan 07, 2014 at 12:00:08PM +0900, Namhyung Kim escreveu:
>> They're copied from the perf code and will be used to print error
>> message during trace_seq_printf() and friends.
>> 
>> Suggested-by: Jiri Olsa 
>> Signed-off-by: Namhyung Kim 
>
> We could take this opportunity and come up with
> tools/lib/{bug,compiler}.h, matching the files in include/linux/ where
> those helpers come from, no?

Hmm.. maybe under tools/include/ ?

>
> Then make both tools/perf/ and tools/lib/traceevent/ use it, instead of
> creating the third copy (kernel proper, perf, libtraceevent).

Okay.

>
> Then, does anybody know why likely/unlikely is guarded inside __KERNEL__
> in include/linux/compiler.h?

IIUC it's because of BRANCH_PROFILING..


> I think the best thing would be for us to just use:
>
> #include  
>
> just like kernel code and be done with it :-\

Yeah, but it seems to require some modifications.

Thanks,
Namhyung
--
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] drm/i915: silence compiler warning

[Daniel Vetter]

On Wed, Jan 8, 2014 at 2:56 AM, Ying Xue  wrote:
> drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
> drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used 
> uninitialized in this function [-Wuninitialized]
> drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val’ was declared here
>
> Signed-off-by: Ying Xue 

I already have such a patch in my -next queue, thanks anyway.
-Daniel


> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6ed45a9..7963ba5 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2347,7 +2347,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
> enum pipe pipe,
>  {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
> -   u32 val;
> +   u32 val = 0;
> int ret;
>
> if (pipe_crc->source == source)
> --
> 1.7.9.5
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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: [B.A.T.M.A.N.] [PATCH v3.6 06/19] batman-adv: use batadv_compare_eth for concise

[Ding Tianhong]

On 2014/1/8 15:06, Antonio Quartulli wrote:
> On 08/01/14 03:53, Ding Tianhong wrote:
>> It is better to use batadv_compate_eth instead of memcpy for
>> concise style.
>>
>> Cc: Marek Lindner 
>> Cc: Simon Wunderlich 
>> Cc: Antonio Quartulli 
>> Cc: "David S. Miller" 
>> Cc: b.a.t.m@lists.open-mesh.org
>> Cc: net...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Tan Xiaojun 
>> Signed-off-by: Ding Tianhong 
>> Acked-by: Antonio Quartulli 
> 
> Am I wrong or this patch has already been merged in net-next (together
> with other patches from this series)?
> 
> 
> 
> Regards,
> 
> 
Yes， it is already in net-next, so miss it, thanks.

Regards
Ding

--
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] drivers: target: target_core_mod: use div64_u64_rem() instead of operator '%' for u64

[Hannes Reinecke]

On 12/24/2013 04:35 AM, Chen Gang wrote:
> On 12/23/2013 02:51 PM, Nicholas A. Bellinger wrote:
>> On Sun, 2013-12-22 at 17:17 +0800, Chen Gang wrote:
>>> On 12/22/2013 10:56 AM, Nicholas A. Bellinger wrote:
 Hi Chen,

 On Sat, 2013-12-21 at 10:08 +0800, Chen Gang wrote:
> In kernel, need use div64_u64_rem() instead of operator '%' for u64, or
> can not pass compiling (with allmodconfig under metag):
>
> MODPOST 2909 modules
>   ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
>
> Also need u64 type cast for u32 variable multiply u32 variable, or will
> cause type overflow issue.
>
>
> Signed-off-by: Chen Gang 
> ---
>  drivers/target/target_core_alua.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

 FYI, this unsigned long long division in core_alua_state_lba_dependent()
 was fixed for 32-bit in linux-next >= 12192013 code.

>>>
>>> OK, thanks.
>>>
>>> The related fix patch changed "start_lba = lba % ..." to "start_lba =
>>> lba / ...", and also assumed "segment_size * segment_mult" is still
>>> within u32 (can not cause type over flow).
>>>
>>> I guess the original author already knew about them, and intended to do
>>> like that (if not, please let me know, thanks).
>>>
>>
>> Sorry, your correct that the original code is using modulo division to
>> calculate start_lba.
>>
> 
> Oh, that's all right, (in fact, don't need sorry), I am not quite
> familiar with the details, so need related member help check it.  :-)
> 
>> Hannes, can you please double check this below..?
>>
> 
> Please help check when have time, thanks.
> 
I would even convert segment_size and segment_mult to u64,
to ensure no overflows occur:

diff --git a/drivers/target/target_core_alua.c
b/drivers/target/target_core_alua
.c
index 9b1856d..54b1e52 100644
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -477,8 +477,7 @@ static inline int core_alua_state_lba_dependent(
u8 *alua_ascq)
 {
struct se_device *dev = cmd->se_dev;
-   u32 segment_size, segment_mult, sectors;
-   u64 lba;
+   u64 segment_size, segment_mult, sectors, lba;

/* Only need to check for cdb actually containing LBAs */
if (!(cmd->se_cmd_flags & SCF_SCSI_DATA_CDB))


Other than that the sector_div() patch is correct.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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: Confusion about Pinctrl and GPIO

[Rongrong Cao]

Hi Stephen,
Thank you very much!
I understood now!

2014/1/7 Stephen Warren :
> On 12/25/2013 10:18 PM, 曹荣荣 wrote:
>
>> I noticed that Stephen submitted a patch for pinctrl:
>> http://www.gossamer-threads.com/lists/linux/kernel/1500890?do=post_view_threaded
>>
>> In this patch, Stephen said, "When an SoC muxes pins in a group, it's
>> quite possible for the group to contain e.g. 6 pins, but only 4 of
>> them actually be needed by the HW module that's mux'd to them. In this
>> case, the other 2 pins could be used as GPIOs. However, pinctrl marks
>> all the pins within the group as in-use by the selected mux function.
>> To allow the expected gpiolib interaction, separate the concepts of
>> pin ownership into two parts: One for the mux function and one for
>> GPIO usage. Finally, allow those two ownerships to exist in parallel.
>> "
>>
>> I agree that gpiolib should be able to use the two idle pins as GPIO,
>> but after apply this patch, gpiolib can also request the 4 pins used
>> by HW module succesfully, and this will override the settings of the 4
>> pins for HW module.
>
> Yes, that's true.
>
> The solution is: don't do that.
>
>> Let me talk again about the example described by Stephen. If actually
>> only 4 pins of the group which contains 6 pins are needed by HW
>> module, then why does the group be defined to contain 6 pins? I think
>> the group should be defined only containing 4 pins rather than 6 pins,
>> then the other 2 idle pins can be used for any other purpose.
>
> It all depends on what you mean by group...
>
> A lot of HW has a mux setting per pin. In this case, it would make sense
> for the pinctrl driver to expose a separate group for each pin, and for
> the pinctrl mapping table (or DT content) to contain an entry for each
> individual pin setting that pin to whatever mux function was relevant.
>
> So in this case, yes, it'd make sense in most cases to disallow pins
> with a defined/selected mux setting from being used as a GPIO. However,
> even in this case, we can't ban dual mux/GPIO usage completely, since
> e.g. an I2C driver might want the I2C HW module to drive the pins most
> of the time, but still need to acquire the pins as GPIO to implement
> some kind of manual bit-banging e.g. to implement a "bus unstick" algorithm.
>
> Some other HW has mux settings that affect multiple pins at once. Tegra
> is an example. In this case, there's a single register bit that defines
> the mux functions for e.g. 6 pins. In this case, there *must* be a
> single pinctrl group definition that encompasses all those 6 pins, since
> that's how the HW works. However, the GPIO-vs-non-GPIO setting on Tegra
> at least is still per pin, hence the need for the patch of mine that you
> mentioned above.
>
> Finally, some people want to use pinctrl groups to represent something
> higher level than HW that has a mux bit for a group of pins rather than
> per-pin. In that case, you also may need GPIO/mux sharing of a pin, for
> similar reasons to the case where the HW muxing really does operate in
> groups.
--
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 RT] add missing local serialization in ip_output.c

[Sami Pietikäinen]

Hello,

Patch also tested overnight with the Atmel SAMA5D35 evaluation board using
the same setup that originally produced the oops. No problems whatsoever.

BR,
Sami
--
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] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()

[Roger Quadros]

pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.

This patch prevents a BUG() during system suspend when
CONFIG_DEBUG_ATOMIC_SLEEP is enabled.

Bug is present in Kernel versions v3.9 onwards.

Reported-by: Tomi Valkeinen 
Signed-off-by: Roger Quadros 
Tested-by: Tomi Valkeinen 
Cc:  # 3.9+
---
 drivers/mfd/omap-usb-tll.c | 36 
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0d946ae1..c409be9 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -333,21 +333,17 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
unsigned reg;
struct usbtll_omap *tll;
 
-   spin_lock(_lock);
-
-   if (!tll_dev) {
-   spin_unlock(_lock);
+   if (!tll_dev)
return -ENODEV;
-   }
 
-   tll = dev_get_drvdata(tll_dev);
+   pm_runtime_get_sync(tll_dev);
 
+   spin_lock(_lock);
+   tll = dev_get_drvdata(tll_dev);
needs_tll = false;
for (i = 0; i < tll->nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata->port_mode[i]);
 
-   pm_runtime_get_sync(tll_dev);
-
if (needs_tll) {
void __iomem *base = tll->base;
 
@@ -398,9 +394,8 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
}
}
 
-   pm_runtime_put_sync(tll_dev);
-
spin_unlock(_lock);
+   pm_runtime_put_sync(tll_dev);
 
return 0;
 }
@@ -411,17 +406,14 @@ int omap_tll_enable(struct usbhs_omap_platform_data 
*pdata)
int i;
struct usbtll_omap *tll;
 
-   spin_lock(_lock);
-
-   if (!tll_dev) {
-   spin_unlock(_lock);
+   if (!tll_dev)
return -ENODEV;
-   }
-
-   tll = dev_get_drvdata(tll_dev);
 
pm_runtime_get_sync(tll_dev);
 
+   spin_lock(_lock);
+   tll = dev_get_drvdata(tll_dev);
+
for (i = 0; i < tll->nch; i++) {
if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
int r;
@@ -448,13 +440,10 @@ int omap_tll_disable(struct usbhs_omap_platform_data 
*pdata)
int i;
struct usbtll_omap *tll;
 
-   spin_lock(_lock);
-
-   if (!tll_dev) {
-   spin_unlock(_lock);
+   if (!tll_dev)
return -ENODEV;
-   }
 
+   spin_lock(_lock);
tll = dev_get_drvdata(tll_dev);
 
for (i = 0; i < tll->nch; i++) {
@@ -464,9 +453,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data *pdata)
}
}
 
-   pm_runtime_put_sync(tll_dev);
-
spin_unlock(_lock);
+   pm_runtime_put_sync(tll_dev);
 
return 0;
 }
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: status of block-integrity

[Hannes Reinecke]

On 01/07/2014 10:43 PM, Martin K. Petersen wrote:
>> "Hannes" == Hannes Reinecke  writes:
> 
> Hannes> Plus (as hch rightly pointed out) as there is no defined
> Hannes> userland interface the question is why we bother with all the
> Hannes> DIX stuff in the block layer.  
> 
> Because it catches problems in the path between block layer and HBA
> ASIC? FWIW, we find more issues there than we do between initiator and
> target.
> 
But how should it do that exactly?
As there is no user (apart from oracleasm) no-one can attach
protection information to any data, so even the most dedicated admin
cannot exercise this path, let alone find issues here.

> API issues aside, another reason adoption has been slow is that very few
> applications truly care about this stuff. The current approach in which
> data is protected when the I/O is submitted by the filesystem is good
> enough for most things. Saves the filesystem people the trouble of
> dealing with it too.
> 
> In reality there are only a handful of applications that would actually
> benefit from an explicit userland API. Mostly in the database
> department. All the potential consumers of an interface I talked to
> wanted to use aio so that's why we've focused our efforts there.
> 
aio is perfectly fine; all I care is to have _any_ way of feeding
protection information into the kernel.

> Both Darrick and I have been busy with other projects the last little
> while. I'll start looking at this again when I'm done with copy
> offload...
> 
Speaking of which, are there any patches?
Doug Gilbert and I are currently discussing LID4 / ROD Token copy
for sg3_utils and the block layer, so any patches would be very
helpful here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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: [B.A.T.M.A.N.] [PATCH v3.6 06/19] batman-adv: use batadv_compare_eth for concise

[Antonio Quartulli]

On 08/01/14 03:53, Ding Tianhong wrote:
> It is better to use batadv_compate_eth instead of memcpy for
> concise style.
> 
> Cc: Marek Lindner 
> Cc: Simon Wunderlich 
> Cc: Antonio Quartulli 
> Cc: "David S. Miller" 
> Cc: b.a.t.m@lists.open-mesh.org
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Tan Xiaojun 
> Signed-off-by: Ding Tianhong 
> Acked-by: Antonio Quartulli 

Am I wrong or this patch has already been merged in net-next (together
with other patches from this series)?



Regards,


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature

Re: [Patch Part2 V1 03/14] iommu/vt-d: simplify function get_domain_for_dev()

[Jiang Liu]

On 2014/1/8 14:48, Kai Huang wrote:
> On Wed, Jan 8, 2014 at 2:31 PM, Jiang Liu  wrote:
>>
>>
>> On 2014/1/8 14:06, Kai Huang wrote:
>>> On Wed, Jan 8, 2014 at 1:48 PM, Jiang Liu  wrote:


 On 2014/1/8 11:06, Kai Huang wrote:
>
>
>
> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  > wrote:
>
> Function get_domain_for_dev() is a little complex, simplify it
> by factoring out dmar_search_domain_by_dev_info() and
> dmar_insert_dev_info().
>
> Signed-off-by: Jiang Liu  >
> ---
>  drivers/iommu/intel-iommu.c |  161
> ---
>  1 file changed, 75 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 1704e97..da65884 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1957,18 +1957,70 @@ find_domain(struct pci_dev *pdev)
> return NULL;
>  }
>
> +static inline struct dmar_domain *
> +dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
> +{
> +   struct device_domain_info *info;
> +
> +   list_for_each_entry(info, _domain_list, global)
> +   if (info->segment == segment && info->bus == bus &&
> +   info->devfn == devfn)
> +   return info->domain;
> +
> +   return NULL;
> +}
> +
> +static int dmar_insert_dev_info(int segment, int bus, int devfn,
> +   struct pci_dev *dev, struct
> dmar_domain **domp)
> +{
> +   struct dmar_domain *found, *domain = *domp;
> +   struct device_domain_info *info;
> +   unsigned long flags;
> +
> +   info = alloc_devinfo_mem();
> +   if (!info)
> +   return -ENOMEM;
> +
> +   info->segment = segment;
> +   info->bus = bus;
> +   info->devfn = devfn;
> +   info->dev = dev;
> +   info->domain = domain;
> +   if (!dev)
> +   domain->flags |= DOMAIN_FLAG_P2P_MULTIPLE_DEVICES;
> +
> +   spin_lock_irqsave(_domain_lock, flags);
> +   if (dev)
> +   found = find_domain(dev);
> +   else
> +   found = dmar_search_domain_by_dev_info(segment, bus,
> devfn);
> +   if (found) {
> +   spin_unlock_irqrestore(_domain_lock, flags);
> +   free_devinfo_mem(info);
> +   if (found != domain) {
> +   domain_exit(domain);
> +   *domp = found;
> +   }
> +   } else {
> +   list_add(>link, >devices);
> +   list_add(>global, _domain_list);
> +   if (dev)
> +   dev->dev.archdata.iommu = info;
> +   spin_unlock_irqrestore(_domain_lock, flags);
> +   }
> +
> +   return 0;
> +}
>
>
> I am a little bit confused about the "alloc before check" sequence in
> above function. I believe the purpose of allocating the
> device_domain_info before searching the domain with spin_lock hold is to
> avoid the memory allocation in the spin_lock? In this case, why can't we
> use mutex instead of spin_lock? In my understanding, if we use mutex, we
> can first check if the domain exists or not before we really allocate
> device_domain_info, right?
 Hi Kai,
 Thanks for review!
 The domain->devices list may be access in interrupt context,
 so we need to protect it with spin_lock_irqsave(). Otherwise it may
 case deadlock.

>>>
>>> Thanks. That's what I am thinking. I observed lots of other iommu
>>> functions also use spin_lock.
>>>
>
> Another question is when is info->iommu field initialized? Looks it is
> not initialized here?
 It's set in function iommu_support_dev_iotlb() for devices supporting
 device IOTLB.
>>>
>>> Thanks. I see in iommu_support_dev_iotlb, info->iommu won't be set
>>> unless the device supports iotlb and ATS. Does this mean the
>>> info->iommu won't be used if the device doesn't support iotlb?
>>>
>>> If this is true, looks it's not convenient to find the IOMMU that
>>> handles the device via info, as it's possible that different IOMMUs
>>> share the same domain, and we don't know which IOMMU actually handles
>>> this device if we try to find it via the info->domain.
>> It's a little heavy to find info by walking the list too:)
>> Please 

Re: [Patch Part2 V1 03/14] iommu/vt-d: simplify function get_domain_for_dev()

[Kai Huang]

On Wed, Jan 8, 2014 at 2:48 PM, Kai Huang  wrote:
> On Wed, Jan 8, 2014 at 2:31 PM, Jiang Liu  wrote:
>>
>>
>> On 2014/1/8 14:06, Kai Huang wrote:
>>> On Wed, Jan 8, 2014 at 1:48 PM, Jiang Liu  wrote:


 On 2014/1/8 11:06, Kai Huang wrote:
>
>
>
> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  > wrote:
>
> Function get_domain_for_dev() is a little complex, simplify it
> by factoring out dmar_search_domain_by_dev_info() and
> dmar_insert_dev_info().
>
> Signed-off-by: Jiang Liu  >
> ---
>  drivers/iommu/intel-iommu.c |  161
> ---
>  1 file changed, 75 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 1704e97..da65884 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1957,18 +1957,70 @@ find_domain(struct pci_dev *pdev)
> return NULL;
>  }
>
> +static inline struct dmar_domain *
> +dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
> +{
> +   struct device_domain_info *info;
> +
> +   list_for_each_entry(info, _domain_list, global)
> +   if (info->segment == segment && info->bus == bus &&
> +   info->devfn == devfn)
> +   return info->domain;
> +
> +   return NULL;
> +}
> +
> +static int dmar_insert_dev_info(int segment, int bus, int devfn,
> +   struct pci_dev *dev, struct
> dmar_domain **domp)
> +{
> +   struct dmar_domain *found, *domain = *domp;
> +   struct device_domain_info *info;
> +   unsigned long flags;
> +
> +   info = alloc_devinfo_mem();
> +   if (!info)
> +   return -ENOMEM;
> +
> +   info->segment = segment;
> +   info->bus = bus;
> +   info->devfn = devfn;
> +   info->dev = dev;
> +   info->domain = domain;
> +   if (!dev)
> +   domain->flags |= DOMAIN_FLAG_P2P_MULTIPLE_DEVICES;
> +
> +   spin_lock_irqsave(_domain_lock, flags);
> +   if (dev)
> +   found = find_domain(dev);
> +   else
> +   found = dmar_search_domain_by_dev_info(segment, bus,
> devfn);
> +   if (found) {
> +   spin_unlock_irqrestore(_domain_lock, flags);
> +   free_devinfo_mem(info);
> +   if (found != domain) {
> +   domain_exit(domain);
> +   *domp = found;
> +   }
> +   } else {
> +   list_add(>link, >devices);
> +   list_add(>global, _domain_list);
> +   if (dev)
> +   dev->dev.archdata.iommu = info;
> +   spin_unlock_irqrestore(_domain_lock, flags);
> +   }
> +
> +   return 0;
> +}
>
>
> I am a little bit confused about the "alloc before check" sequence in
> above function. I believe the purpose of allocating the
> device_domain_info before searching the domain with spin_lock hold is to
> avoid the memory allocation in the spin_lock? In this case, why can't we
> use mutex instead of spin_lock? In my understanding, if we use mutex, we
> can first check if the domain exists or not before we really allocate
> device_domain_info, right?
 Hi Kai,
 Thanks for review!
 The domain->devices list may be access in interrupt context,
 so we need to protect it with spin_lock_irqsave(). Otherwise it may
 case deadlock.

>>>
>>> Thanks. That's what I am thinking. I observed lots of other iommu
>>> functions also use spin_lock.
>>>
>
> Another question is when is info->iommu field initialized? Looks it is
> not initialized here?
 It's set in function iommu_support_dev_iotlb() for devices supporting
 device IOTLB.
>>>
>>> Thanks. I see in iommu_support_dev_iotlb, info->iommu won't be set
>>> unless the device supports iotlb and ATS. Does this mean the
>>> info->iommu won't be used if the device doesn't support iotlb?
>>>
>>> If this is true, looks it's not convenient to find the IOMMU that
>>> handles the device via info, as it's possible that different IOMMUs
>>> share the same domain, and we don't know which IOMMU actually handles
>>> this device if we try to find it via the info->domain.
>> It's a little heavy to find info by walking the list too:)

Re: [Patch Part2 V1 03/14] iommu/vt-d: simplify function get_domain_for_dev()

[Kai Huang]

On Wed, Jan 8, 2014 at 2:31 PM, Jiang Liu  wrote:
>
>
> On 2014/1/8 14:06, Kai Huang wrote:
>> On Wed, Jan 8, 2014 at 1:48 PM, Jiang Liu  wrote:
>>>
>>>
>>> On 2014/1/8 11:06, Kai Huang wrote:



 On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu >>> > wrote:

 Function get_domain_for_dev() is a little complex, simplify it
 by factoring out dmar_search_domain_by_dev_info() and
 dmar_insert_dev_info().

 Signed-off-by: Jiang Liu >>> >
 ---
  drivers/iommu/intel-iommu.c |  161
 ---
  1 file changed, 75 insertions(+), 86 deletions(-)

 diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
 index 1704e97..da65884 100644
 --- a/drivers/iommu/intel-iommu.c
 +++ b/drivers/iommu/intel-iommu.c
 @@ -1957,18 +1957,70 @@ find_domain(struct pci_dev *pdev)
 return NULL;
  }

 +static inline struct dmar_domain *
 +dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
 +{
 +   struct device_domain_info *info;
 +
 +   list_for_each_entry(info, _domain_list, global)
 +   if (info->segment == segment && info->bus == bus &&
 +   info->devfn == devfn)
 +   return info->domain;
 +
 +   return NULL;
 +}
 +
 +static int dmar_insert_dev_info(int segment, int bus, int devfn,
 +   struct pci_dev *dev, struct
 dmar_domain **domp)
 +{
 +   struct dmar_domain *found, *domain = *domp;
 +   struct device_domain_info *info;
 +   unsigned long flags;
 +
 +   info = alloc_devinfo_mem();
 +   if (!info)
 +   return -ENOMEM;
 +
 +   info->segment = segment;
 +   info->bus = bus;
 +   info->devfn = devfn;
 +   info->dev = dev;
 +   info->domain = domain;
 +   if (!dev)
 +   domain->flags |= DOMAIN_FLAG_P2P_MULTIPLE_DEVICES;
 +
 +   spin_lock_irqsave(_domain_lock, flags);
 +   if (dev)
 +   found = find_domain(dev);
 +   else
 +   found = dmar_search_domain_by_dev_info(segment, bus,
 devfn);
 +   if (found) {
 +   spin_unlock_irqrestore(_domain_lock, flags);
 +   free_devinfo_mem(info);
 +   if (found != domain) {
 +   domain_exit(domain);
 +   *domp = found;
 +   }
 +   } else {
 +   list_add(>link, >devices);
 +   list_add(>global, _domain_list);
 +   if (dev)
 +   dev->dev.archdata.iommu = info;
 +   spin_unlock_irqrestore(_domain_lock, flags);
 +   }
 +
 +   return 0;
 +}


 I am a little bit confused about the "alloc before check" sequence in
 above function. I believe the purpose of allocating the
 device_domain_info before searching the domain with spin_lock hold is to
 avoid the memory allocation in the spin_lock? In this case, why can't we
 use mutex instead of spin_lock? In my understanding, if we use mutex, we
 can first check if the domain exists or not before we really allocate
 device_domain_info, right?
>>> Hi Kai,
>>> Thanks for review!
>>> The domain->devices list may be access in interrupt context,
>>> so we need to protect it with spin_lock_irqsave(). Otherwise it may
>>> case deadlock.
>>>
>>
>> Thanks. That's what I am thinking. I observed lots of other iommu
>> functions also use spin_lock.
>>

 Another question is when is info->iommu field initialized? Looks it is
 not initialized here?
>>> It's set in function iommu_support_dev_iotlb() for devices supporting
>>> device IOTLB.
>>
>> Thanks. I see in iommu_support_dev_iotlb, info->iommu won't be set
>> unless the device supports iotlb and ATS. Does this mean the
>> info->iommu won't be used if the device doesn't support iotlb?
>>
>> If this is true, looks it's not convenient to find the IOMMU that
>> handles the device via info, as it's possible that different IOMMUs
>> share the same domain, and we don't know which IOMMU actually handles
>> this device if we try to find it via the info->domain.
> It's a little heavy to find info by walking the list too:)
> Please refer to domain_get_iommu() for the way to find iommu associated
> with a domain.
>
Looks domain_get_iommu just returns the first IOMMU in the bitmap, so
it can't 

[PATCH] usb:hub set hub->change_bits when over-current happens

[Shen Guang]

When we are doing compliance test with xHCI, we found that if we
enable CONFIG_USB_SUSPEND and plug in a bad device which causes
over-current condition to the root port, software will not be noticed.
The reason is that current code don't set hub->change_bits in
hub_activate() when over-current happens, and then hub_events() will
not check the port status because it thinks nothing changed.
If CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will
report the change and set hub->event_bits, and then hub_events() will
check what events happened.In this case over-current can be detected.

Signed-off-by: Shen Guang 
---
 drivers/usb/core/hub.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bd9dc35..98b5679 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1154,7 +1154,8 @@ static void hub_activate(struct usb_hub *hub,
enum hub_activation_type type)
/* Tell khubd to disconnect the device or
 * check for a new connection
 */
-   if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
+   if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
+   (portstatus & USB_PORT_STAT_OVERCURRENT))
set_bit(port1, hub->change_bits);

} else if (portstatus & USB_PORT_STAT_ENABLE) {
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: Regression (ARM) arch/arm/mm/init.c doesn't build without CONFIG_ARM_PATCH_PHYS_VIRT.

[Krzysztof Hałasa]

Russell King - ARM Linux  writes:

> Okay, reverted.

Thanks.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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/3] regulator: Add support for S2MPA01 regulator

[Sachin Kamat]

Add support for S2MPA01 voltage and current regulator.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/Kconfig   |7 +
 drivers/regulator/Makefile  |1 +
 drivers/regulator/s2mpa01.c |  497 +++
 3 files changed, 505 insertions(+)
 create mode 100644 drivers/regulator/s2mpa01.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a7932822e37..8f8e6710bb45 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -416,6 +416,13 @@ config REGULATOR_RC5T583
  through regulator interface. The device supports multiple DCDC/LDO
  outputs which can be controlled by i2c communication.
 
+config REGULATOR_S2MPA01
+   tristate "Samsung S2MPA01 voltage regulator"
+   depends on MFD_SEC_CORE
+   help
+This driver controls Samsung S2MPA01 voltage output regulator
+via I2C bus. S2MPA01 has 10 Bucks and 26 LDO outputs.
+
 config REGULATOR_S2MPS11
tristate "Samsung S2MPS11 voltage regulator"
depends on MFD_SEC_CORE
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9ddcf259..b3ece84289cf 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
 obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
 obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_RC5T583)  += rc5t583-regulator.o
+obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
 obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
 obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
new file mode 100644
index ..f1c831d5fc87
--- /dev/null
+++ b/drivers/regulator/s2mpa01.c
@@ -0,0 +1,497 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ *  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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S2MPA01_REGULATOR_CNT ARRAY_SIZE(regulators)
+
+struct s2mpa01_info {
+   struct regulator_dev *rdev[S2MPA01_REGULATOR_MAX];
+
+   int ramp_delay24;
+   int ramp_delay3;
+   int ramp_delay5;
+   int ramp_delay16;
+   int ramp_delay7;
+   int ramp_delay8910;
+};
+
+static int get_ramp_delay(int ramp_delay)
+{
+   unsigned char cnt = 0;
+
+   ramp_delay /= 6250;
+
+   while (true) {
+   ramp_delay = ramp_delay >> 1;
+   if (ramp_delay == 0)
+   break;
+   cnt++;
+   }
+
+   if (cnt > 3)
+   cnt = 3;
+
+   return cnt;
+}
+
+static int s2mpa01_regulator_set_voltage_time_sel(struct regulator_dev *rdev,
+  unsigned int old_selector,
+  unsigned int new_selector)
+{
+   struct s2mpa01_info *s2mpa01 = rdev_get_drvdata(rdev);
+   unsigned int ramp_delay = 0;
+   int old_volt, new_volt;
+
+   switch (rdev->desc->id) {
+   case S2MPA01_BUCK2:
+   case S2MPA01_BUCK4:
+   ramp_delay = s2mpa01->ramp_delay24;
+   break;
+   case S2MPA01_BUCK3:
+   ramp_delay = s2mpa01->ramp_delay3;
+   break;
+   case S2MPA01_BUCK5:
+   ramp_delay = s2mpa01->ramp_delay5;
+   break;
+   case S2MPA01_BUCK1:
+   case S2MPA01_BUCK6:
+   ramp_delay = s2mpa01->ramp_delay16;
+   break;
+   case S2MPA01_BUCK7:
+   ramp_delay = s2mpa01->ramp_delay7;
+   break;
+   case S2MPA01_BUCK8:
+   case S2MPA01_BUCK9:
+   case S2MPA01_BUCK10:
+   ramp_delay = s2mpa01->ramp_delay8910;
+   break;
+   }
+
+   if (ramp_delay == 0)
+   ramp_delay = rdev->desc->ramp_delay;
+
+   old_volt = rdev->desc->min_uV + (rdev->desc->uV_step * old_selector);
+   new_volt = rdev->desc->min_uV + (rdev->desc->uV_step * new_selector);
+
+   return DIV_ROUND_UP(abs(new_volt - old_volt), ramp_delay);
+}
+
+static int s2mpa01_set_ramp_delay(struct regulator_dev *rdev, int ramp_delay)
+{
+   struct s2mpa01_info *s2mpa01 = rdev_get_drvdata(rdev);
+   unsigned int ramp_val, ramp_shift, ramp_reg = S2MPA01_REG_RAMP2;
+   unsigned int ramp_enable = 1, enable_shift = 0;
+   int ret;
+
+   switch (rdev->desc->id) {
+   case S2MPA01_BUCK1:
+   enable_shift = S2MPA01_BUCK1_RAMP_EN_SHIFT;
+   if (!ramp_delay) {
+   ramp_enable = 0;
+   break;
+ 

Re: [Patch Part2 V1 03/14] iommu/vt-d: simplify function get_domain_for_dev()

[Jiang Liu]

On 2014/1/8 14:06, Kai Huang wrote:
> On Wed, Jan 8, 2014 at 1:48 PM, Jiang Liu  wrote:
>>
>>
>> On 2014/1/8 11:06, Kai Huang wrote:
>>>
>>>
>>>
>>> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu >> > wrote:
>>>
>>> Function get_domain_for_dev() is a little complex, simplify it
>>> by factoring out dmar_search_domain_by_dev_info() and
>>> dmar_insert_dev_info().
>>>
>>> Signed-off-by: Jiang Liu >> >
>>> ---
>>>  drivers/iommu/intel-iommu.c |  161
>>> ---
>>>  1 file changed, 75 insertions(+), 86 deletions(-)
>>>
>>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>>> index 1704e97..da65884 100644
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -1957,18 +1957,70 @@ find_domain(struct pci_dev *pdev)
>>> return NULL;
>>>  }
>>>
>>> +static inline struct dmar_domain *
>>> +dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
>>> +{
>>> +   struct device_domain_info *info;
>>> +
>>> +   list_for_each_entry(info, _domain_list, global)
>>> +   if (info->segment == segment && info->bus == bus &&
>>> +   info->devfn == devfn)
>>> +   return info->domain;
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +static int dmar_insert_dev_info(int segment, int bus, int devfn,
>>> +   struct pci_dev *dev, struct
>>> dmar_domain **domp)
>>> +{
>>> +   struct dmar_domain *found, *domain = *domp;
>>> +   struct device_domain_info *info;
>>> +   unsigned long flags;
>>> +
>>> +   info = alloc_devinfo_mem();
>>> +   if (!info)
>>> +   return -ENOMEM;
>>> +
>>> +   info->segment = segment;
>>> +   info->bus = bus;
>>> +   info->devfn = devfn;
>>> +   info->dev = dev;
>>> +   info->domain = domain;
>>> +   if (!dev)
>>> +   domain->flags |= DOMAIN_FLAG_P2P_MULTIPLE_DEVICES;
>>> +
>>> +   spin_lock_irqsave(_domain_lock, flags);
>>> +   if (dev)
>>> +   found = find_domain(dev);
>>> +   else
>>> +   found = dmar_search_domain_by_dev_info(segment, bus,
>>> devfn);
>>> +   if (found) {
>>> +   spin_unlock_irqrestore(_domain_lock, flags);
>>> +   free_devinfo_mem(info);
>>> +   if (found != domain) {
>>> +   domain_exit(domain);
>>> +   *domp = found;
>>> +   }
>>> +   } else {
>>> +   list_add(>link, >devices);
>>> +   list_add(>global, _domain_list);
>>> +   if (dev)
>>> +   dev->dev.archdata.iommu = info;
>>> +   spin_unlock_irqrestore(_domain_lock, flags);
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>>
>>>
>>> I am a little bit confused about the "alloc before check" sequence in
>>> above function. I believe the purpose of allocating the
>>> device_domain_info before searching the domain with spin_lock hold is to
>>> avoid the memory allocation in the spin_lock? In this case, why can't we
>>> use mutex instead of spin_lock? In my understanding, if we use mutex, we
>>> can first check if the domain exists or not before we really allocate
>>> device_domain_info, right?
>> Hi Kai,
>> Thanks for review!
>> The domain->devices list may be access in interrupt context,
>> so we need to protect it with spin_lock_irqsave(). Otherwise it may
>> case deadlock.
>>
> 
> Thanks. That's what I am thinking. I observed lots of other iommu
> functions also use spin_lock.
> 
>>>
>>> Another question is when is info->iommu field initialized? Looks it is
>>> not initialized here?
>> It's set in function iommu_support_dev_iotlb() for devices supporting
>> device IOTLB.
> 
> Thanks. I see in iommu_support_dev_iotlb, info->iommu won't be set
> unless the device supports iotlb and ATS. Does this mean the
> info->iommu won't be used if the device doesn't support iotlb?
> 
> If this is true, looks it's not convenient to find the IOMMU that
> handles the device via info, as it's possible that different IOMMUs
> share the same domain, and we don't know which IOMMU actually handles
> this device if we try to find it via the info->domain.
It's a little heavy to find info by walking the list too:)
Please refer to domain_get_iommu() for the way to find iommu associated
with a domain.

> 
> -Kai
> 
>>
>>>
>>> -Kai
>>>
>>> +
>>>  /* domain is initialized */
>>>  static struct dmar_domain *get_domain_for_dev(struct pci_dev *pdev,
>>> int gaw)
>>>  {
>>> -   struct dmar_domain *domain, *found = NULL;
>>> + 

[PATCH 3/3] Documentation: mfd: Add binding document for S2MPA01

[Sachin Kamat]

Added initial binding documentation for S2MPA01 MFD.

Signed-off-by: Sachin Kamat 
---
 Documentation/devicetree/bindings/mfd/s2mpa01.txt |   91 +
 1 file changed, 91 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt

diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt 
b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
new file mode 100644
index ..ae750a28821b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
@@ -0,0 +1,91 @@
+
+* Samsung S2MPA01 Voltage and Current Regulator
+
+The Samsung S2MPA01 is a multi-function device which includes high
+efficiency buck converters including Dual-Phase buck converter, various LDOs,
+and an RTC. It is interfaced to the host controller using an I2C interface.
+Each sub-block is addressed by the host system using different I2C slave
+addresses.
+
+Required properties:
+- compatible: Should be "samsung,s2mpa01-pmic".
+- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the interrupts from s2mpa01 are delivered to.
+- interrupts: Interrupt specifiers for interrupt sources.
+
+Optional nodes:
+- regulators: The regulators of s2mpa01 that have to be instantiated should be
+included in a sub-node named 'regulators'. Regulator nodes included in this
+sub-node should be of the format as listed below.
+
+   regulator_name {
+   [standard regulator constraints];
+   };
+
+ regulator-ramp-delay for BUCKs = [6250/12500(default)/25000/5] uV/us
+
+ BUCK[1/2/3/4] supports disabling ramp delay on hardware, so explictly
+ regulator-ramp-delay = <0> can be used for them to disable ramp delay.
+ In the absence of the regulator-ramp-delay property, the default ramp
+ delay will be used.
+
+NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
+for a particular group of BUCKs. So provide same regulator-ramp-delay.
+Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
+BUCK[2, 4], and BUCK[8, 9, 10]
+
+The regulator constraints inside the regulator nodes use the standard regulator
+bindings which are documented elsewhere.
+
+The following are the names of the regulators that the s2mpa01 PMIC block
+supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
+as per the datasheet of s2mpa01.
+
+   - LDOn
+ - valid values for n are 1 to 26
+ - Example: LDO1, LD02, LDO26
+   - BUCKn
+ - valid values for n are 1 to 10.
+ - Example: BUCK1, BUCK2, BUCK9
+
+Example:
+
+   s2mpa01_pmic@66 {
+   compatible = "samsung,s2mpa01-pmic";
+   reg = <0x66>;
+
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "VDD_ALIVE";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   };
+
+   ldo2_reg: LDO2 {
+   regulator-name = "VDDQ_MMC2";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-always-on;
+   };
+
+   buck1_reg: BUCK1 {
+   regulator-name = "vdd_mif";
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <135>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   buck2_reg: BUCK2 {
+   regulator-name = "vdd_arm";
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <135>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-ramp-delay = <5>;
+   };
+   };
+   };
-- 
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/

[PATCH 1/3] mfd: Add support for S2MPA01 device

[Sachin Kamat]

Add the necessary entries required for S2MPA01 multi-function
device. While at it also convert whitespaces to tabs in core.h.

Signed-off-by: Sachin Kamat 
---
 drivers/mfd/sec-core.c  |   39 +++
 include/linux/mfd/samsung/core.h|   16 ++-
 include/linux/mfd/samsung/irq.h |   50 +
 include/linux/mfd/samsung/s2mpa01.h |  192 +++
 4 files changed, 292 insertions(+), 5 deletions(-)
 create mode 100644 include/linux/mfd/samsung/s2mpa01.h

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index a139798b8065..d2e890d50a36 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,13 @@ static const struct mfd_cell s2mps11_devs[] = {
}
 };
 
+static const struct mfd_cell s2mpa01_devs[] = {
+   {
+   .name = "s2mpa01-pmic",
+   },
+};
+
+
 #ifdef CONFIG_OF
 static struct of_device_id sec_dt_match[] = {
{   .compatible = "samsung,s5m8767-pmic",
@@ -77,10 +85,25 @@ static struct of_device_id sec_dt_match[] = {
{   .compatible = "samsung,s2mps11-pmic",
.data = (void *)S2MPS11X,
},
+   {   .compatible = "samsung,s2mpa01-pmic",
+   .data = (void *)S2MPA01,
+   },
{},
 };
 #endif
 
+static bool s2mpa01_volatile(struct device *dev, unsigned int reg)
+{
+   switch (reg) {
+   case S2MPA01_REG_INT1M:
+   case S2MPA01_REG_INT2M:
+   case S2MPA01_REG_INT3M:
+   return false;
+   default:
+   return true;
+   }
+}
+
 static bool s2mps11_volatile(struct device *dev, unsigned int reg)
 {
switch (reg) {
@@ -111,6 +134,15 @@ static const struct regmap_config sec_regmap_config = {
.val_bits = 8,
 };
 
+static const struct regmap_config s2mpa01_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = S2MPA01_REG_LDO_OVCB4,
+   .volatile_reg = s2mpa01_volatile,
+   .cache_type = REGCACHE_FLAT,
+};
+
 static const struct regmap_config s2mps11_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -229,6 +261,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
}
 
switch (sec_pmic->device_type) {
+   case S2MPA01:
+   regmap = _regmap_config;
+   break;
case S2MPS11X:
regmap = _regmap_config;
break;
@@ -283,6 +318,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
ret = mfd_add_devices(sec_pmic->dev, -1, s5m8767_devs,
  ARRAY_SIZE(s5m8767_devs), NULL, 0, NULL);
break;
+   case S2MPA01:
+   ret = mfd_add_devices(sec_pmic->dev, -1, s2mpa01_devs,
+ ARRAY_SIZE(s2mpa01_devs), NULL, 0, NULL);
+   break;
case S2MPS11X:
ret = mfd_add_devices(sec_pmic->dev, -1, s2mps11_devs,
  ARRAY_SIZE(s2mps11_devs), NULL, 0, NULL);
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index 41c9bde410c5..db165f8712d3 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -18,6 +18,7 @@ enum sec_device_type {
S5M8751X,
S5M8763X,
S5M8767X,
+   S2MPA01,
S2MPS11X,
 };
 
@@ -92,7 +93,7 @@ struct sec_platform_data {
int buck3_default_idx;
int buck4_default_idx;
 
-   int buck_ramp_delay;
+   int buck_ramp_delay;
 
int buck2_ramp_delay;
int buck34_ramp_delay;
@@ -100,10 +101,15 @@ struct sec_platform_data {
int buck16_ramp_delay;
int buck7810_ramp_delay;
int buck9_ramp_delay;
-
-   boolbuck2_ramp_enable;
-   boolbuck3_ramp_enable;
-   boolbuck4_ramp_enable;
+   int buck24_ramp_delay;
+   int buck3_ramp_delay;
+   int buck7_ramp_delay;
+   int buck8910_ramp_delay;
+
+   boolbuck1_ramp_enable;
+   boolbuck2_ramp_enable;
+   boolbuck3_ramp_enable;
+   boolbuck4_ramp_enable;
boolbuck6_ramp_enable;
 
int buck2_init;
diff --git a/include/linux/mfd/samsung/irq.h b/include/linux/mfd/samsung/irq.h
index d43b4f9e7fb2..2ca965948cd4 100644
--- 

Re: [PATCH] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()

[Roger Quadros]

Hi,

On 12/18/2013 04:06 PM, Lee Jones wrote:
>> pm_runtime_get/put_sync() can sleep so don't hold spinlock while
>> calling them.
>>
>> This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
>> Bug is present in Kernel versions v3.9 onwards.
>>
>> Reported-by: Tomi Valkeinen 
>> Signed-off-by: Roger Quadros 
>> Tested-by: Tomi Valkeinen 
>> Cc:  # 3.9+
>> ---
>>  drivers/mfd/omap-usb-tll.c | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
>> index 0d946ae1..248004c 100644
>> --- a/drivers/mfd/omap-usb-tll.c
>> +++ b/drivers/mfd/omap-usb-tll.c
>> @@ -346,7 +346,9 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
>>  for (i = 0; i < tll->nch; i++)
>>  needs_tll |= omap_usb_mode_needs_tll(pdata->port_mode[i]);
>>  
>> +spin_unlock(_lock);
>>  pm_runtime_get_sync(tll_dev);
>> +spin_lock(_lock);
> 
> This is pretty ugly. Can't you move it above the spin_lock() instead?

OK. I'll also remove NULL check for tll_dev outside the spin_lock().

> 
> 
> 
>>  tll = dev_get_drvdata(tll_dev);
>>  
>> +spin_unlock(_lock);
>>  pm_runtime_get_sync(tll_dev);
>> +spin_lock(_lock);
> 
> Same here?

Yes.

> 
>>  for (i = 0; i < tll->nch; i++) {
>>  if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
>> @@ -438,7 +441,6 @@ int omap_tll_enable(struct usbhs_omap_platform_data 
>> *pdata)
>>  }
>>  
>>  spin_unlock(_lock);
>> -
> 
> This doesn't belong in this patch and is now inconsistent with the
> other functions in the driver.

OK.

> 
>>  return 0;
>>  }
>>  EXPORT_SYMBOL_GPL(omap_tll_enable);
>> @@ -464,9 +466,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data 
>> *pdata)
>>  }
>>  }
>>  
>> -pm_runtime_put_sync(tll_dev);
>> -
>>  spin_unlock(_lock);
>> +pm_runtime_put_sync(tll_dev);
>>  
>>  return 0;
>>  }
> 

cheers,
-roger

--
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 Patch Part2 V1 14/14] iommu/vt-d: update IOMMU state when memory hotplug happens

[Kai Huang]

On Wed, Jan 8, 2014 at 2:21 PM, Jiang Liu  wrote:
>
>
> On 2014/1/8 14:14, Kai Huang wrote:
>> On Wed, Jan 8, 2014 at 2:01 PM, Jiang Liu  wrote:
>>>
>>>
>>> On 2014/1/8 13:07, Kai Huang wrote:
 On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  
 wrote:
> If static identity domain is created, IOMMU driver needs to update
> si_domain page table when memory hotplug event happens. Otherwise
> PCI device DMA operations can't access the hot-added memory regions.
>
> Signed-off-by: Jiang Liu 
> ---
>  drivers/iommu/intel-iommu.c |   52 
> ++-
>  1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 83e3ed4..35a987d 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3689,6 +3690,54 @@ static struct notifier_block device_nb = {
> .notifier_call = device_notifier,
>  };
>
> +static int intel_iommu_memory_notifier(struct notifier_block *nb,
> +  unsigned long val, void *v)
> +{
> +   struct memory_notify *mhp = v;
> +   unsigned long long start, end;
> +   struct iova *iova;
> +
> +   switch (val) {
> +   case MEM_GOING_ONLINE:
> +   start = mhp->start_pfn << PAGE_SHIFT;
> +   end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 
> 1;
> +   if (iommu_domain_identity_map(si_domain, start, end)) {
> +   pr_warn("dmar: failed to build identity map for 
> [%llx-%llx]\n",
> +   start, end);
> +   return NOTIFY_BAD;
> +   }

 Better to use iommu_prepare_identity_map? For si_domain, if
 hw_pass_through is used, there's no page table.
>>> Hi Kai,
>>> Good catch!
>>> Seems function iommu_prepare_identity_map() is designed to handle
>>> RMRRs. So how about avoiding of registering memory hotplug notifier
>>> if hw_pass_through is true?
>>
>> I think that's also fine :)
>>
>> Btw, I have a related question to memory hotplug but not related to
>> intel IOMMU specifically. For the devices use DMA remapping, suppose
>> the device is already using the memory that we are trying to remove,
>> is this case, looks we need to change the existing iova <-> pa
>> mappings for the pa that is in the memory range about to be removed,
>> and reset the mapping to different pa (iova remains the same). Does
>> existing code have this covered? Is there a generic IOMMU layer memory
>> hotplug notifier to handle memory removal?
> That's a big issue about how to reclaim memory in use. Current rule
> is that memory used by DMA won't be removed until released.
>

Understood. Thanks.

-Kai
>>
>> -Kai
>>>
>>> Thanks!
>>> Gerry
>>>

> +   break;
> +   case MEM_OFFLINE:
> +   case MEM_CANCEL_ONLINE:
> +   /* TODO: enhance RB-tree and IOVA code to support of 
> splitting iova */
> +   iova = find_iova(_domain->iovad, mhp->start_pfn);
> +   if (iova) {
> +   unsigned long start_pfn, last_pfn;
> +   struct dmar_drhd_unit *drhd;
> +   struct intel_iommu *iommu;
> +
> +   start_pfn = mm_to_dma_pfn(iova->pfn_lo);
> +   last_pfn = mm_to_dma_pfn(iova->pfn_hi + 1) - 1;
> +   dma_pte_clear_range(si_domain, start_pfn, 
> last_pfn);
> +   dma_pte_free_pagetable(si_domain, start_pfn, 
> last_pfn);
> +   rcu_read_lock();
> +   for_each_active_iommu(iommu, drhd)
> +   iommu_flush_iotlb_psi(iommu, 
> si_domain->id,
> +   start_pfn, last_pfn - start_pfn + 
> 1, 0);
> +   rcu_read_unlock();
> +   __free_iova(_domain->iovad, iova);
> +   }

 The same as above. Looks we need to consider hw_pass_through for the 
 si_domain.

 -Kai

> +   break;
> +   }
> +
> +   return NOTIFY_OK;
> +}
> +
> +static struct notifier_block intel_iommu_memory_nb = {
> +   .notifier_call = intel_iommu_memory_notifier,
> +   .priority = 0
> +};
> +
>  int __init intel_iommu_init(void)
>  {
> int ret = -ENODEV;
> @@ -3761,8 +3810,9 @@ int __init intel_iommu_init(void)
> init_iommu_pm_ops();
>
> bus_set_iommu(_bus_type, _iommu_ops);
> -
> 

[PATCH 2/2] usb/gadget: fix printer memory leak

[wenlin.kang]

From: "wenlin.kang" 

When read data from g_printer, we see a Segmentation fault. eg:

Unable to handle kernel paging request at virtual address bf048000 pgd
= cf038000 [bf048000] *pgd=8e8cf811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM Modules linked in: bluetooth
rfcomm g_printer
CPU: 0Not tainted  (3.4.43-WR5.0.1.9_standard #1)
PC is at __copy_to_user_std+0x310/0x3a8 LR is at 0x4c808010
pc : []lr : [<4c808010>]psr: 2013
sp : cf883ea8  ip : 80801018  fp : cf883f24
r10: bf04706c  r9 : 18a21205  r8 : 21953888
r7 : 201588aa  r6 : 5109aa16  r5 : 0705aaa2  r4 : 5140aa8a
r3 : 004c  r2 : 0fdc  r1 : bf048000  r0 : bef5fc3c
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8f038019  DAC: 0015 Process
g_printer_test. (pid: 661, stack limit = 0xcf8822e8)
Stack: (0xcf883ea8 to 0xcf884000)
3ea0:   bf047068 1fff bef5ecb9 cf882000 1fff bef5ecb9
3ec0: 1fff  cf2e8724 bf044d3c 8013 8013 0001
bf04706c
3ee0: cf883f24 cf883ef0 c012e5ac c0324388 c007c8ac c0046298 8180
cf29b900
3f00: 2000 bef5ecb8 cf883f68 0003 cf882000 cf29b900 cf883f54
cf883f28
3f20: c012ea08 bf044b0c c000eb88  cf883f7c  
2000
3f40: bef5ecb8 0003 cf883fa4 cf883f58 c012eae8 c012e960 0001
bef60cb8
3f60: 00a8 c000eb88   cf883fa4  c014329c

3f80: 00d4 41af63f0 0003 c000eb88 cf882000  
cf883fa8
3fa0: c000e920 c012eaa4  00d4 0003 bef5ecb8 2000
bef5ecb8
3fc0:  00d4 41af63f0 0003 b6f534c0  419f9000

3fe0:  bef5ecac 86d9 41a986bc 6010 0003 0109608a
0088828a
Code: f5d1f07c e8b100f0 e1a03c2e e2522020 (e8b15300) ---[ end trace
97e2618e250e3377 ]--- Segmentation fault

The root cause is the dev->rx_buffers list has been broken.
When we call printer_read(), the following call tree is triggered:

printer_read()
|
+---setup_rx_reqs(req)
|   |
|   +---usb_ep_queue(req)
|   |   |
|   |   +---...
|   |   |
|   |   +---rx_complete(req).
|   |
|   +---add the req to dev->rx_reqs_active
|
+---while(!list_empty(>rx_buffers)))

The route happens when we don't use DMA or fail to start DMA in USB
driver. We can see: in the case, in rx_complete() it will add the req
to dev->rx_buffers. meanwhile we see that we will also add the req to
dev->rx_reqs_active after usb_ep_queue() return, so this adding will
break the dev->rx_buffers out.

After, when we call list_empty() to check dev->rx_buffers in while(),
due to can't check correctly dev->rx_buffers, so the Segmentation fault 
occurs when copy_to_user() is called.

Signed-off-by: wenlin.kang 
---
 drivers/usb/gadget/printer.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index f4b4fa8..1f15ad0 100644
--- a/drivers/usb/gadget/printer.c
+++ b/drivers/usb/gadget/printer.c
@@ -534,7 +534,9 @@ setup_rx_reqs(struct printer_dev *dev)
DBG(dev, "rx submit --> %d\n", error);
list_add(>list, >rx_reqs);
break;
-   } else {
+   }
+   /* if the req is empty, then add it into dev->rx_reqs_active. */
+   else if (list_empty(>list)) {
list_add(>list, >rx_reqs_active);
}
}
-- 
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/

[PATCH 1/2] usb/gadget: fix printer deadlock

[wenlin.kang]

From: "wenlin.kang" 

The problem occurs in follow path.

printer_read()
|
+---setup_rx_reqs()
|
+---usb_ep_queue()
|
+---...
|
+---rx_complete()

Although it is clear from code, we can't get it normally.
only when we enable some spin_lock debug config option, we can find it.
eg:
BUG: spinlock lockup on CPU#0, g_printer_test_/584
 lock: bf05e158, .magic: dead4ead, .owner: g_printer_test_/584, .owner_cpu: 0
[] (unwind_backtrace+0x0/0x104) from [] 
(dump_stack+0x20/0x24)
[] (dump_stack+0x20/0x24) from [] (spin_dump+0x8c/0x94)
[] (spin_dump+0x8c/0x94) from [] 
(do_raw_spin_lock+0x128/0x154)
[] (do_raw_spin_lock+0x128/0x154) from [] 
(_raw_spin_lock_irqsave+0x64/0x70)
[] (_raw_spin_lock_irqsave+0x64/0x70) from [] 
(rx_complete+0x54/0x10c [g_printer])
[] (rx_complete+0x54/0x10c [g_printer]) from [] 
(musb_g_giveback+0x78/0x88)
[] (musb_g_giveback+0x78/0x88) from [] (rxstate+0xa0/0x10c)
[] (rxstate+0xa0/0x10c) from [] (musb_ep_restart+0x44/0x70)
[] (musb_ep_restart+0x44/0x70) from [] 
(musb_gadget_queue+0xe8/0xf8)
[] (musb_gadget_queue+0xe8/0xf8) from [] 
(setup_rx_reqs+0xa4/0x178 [g_printer])
[] (setup_rx_reqs+0xa4/0x178 [g_printer]) from [] 
(printer_read+0x9c/0x3f4 [g_printer])
[] (printer_read+0x9c/0x3f4 [g_printer]) from [] 
(vfs_read+0xb4/0x144)
[] (vfs_read+0xb4/0x144) from [] (sys_read+0x50/0x124)
[] (sys_read+0x50/0x124) from [] (ret_fast_syscall+0x0/0x3c)

The root cause is that we use the same lock two time in a path, so to avoid
the deadlock, we need to unlock in setup_rx_reqs(), and only unlock.

Signed-off-by: wenlin.kang 
---
 drivers/usb/gadget/printer.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index 4e4dc1f..f4b4fa8 100644
--- a/drivers/usb/gadget/printer.c
+++ b/drivers/usb/gadget/printer.c
@@ -526,7 +526,10 @@ setup_rx_reqs(struct printer_dev *dev)
req->length = USB_BUFSIZE;
req->complete = rx_complete;
 
+   /* here, we unlock, and only unlock, to avoid deadlock. */
+   spin_unlock(>lock);
error = usb_ep_queue(dev->out_ep, req, GFP_ATOMIC);
+   spin_lock(>lock);
if (error) {
DBG(dev, "rx submit --> %d\n", error);
list_add(>list, >rx_reqs);
-- 
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: [RFC Patch Part2 V1 14/14] iommu/vt-d: update IOMMU state when memory hotplug happens

[Jiang Liu]

On 2014/1/8 14:14, Kai Huang wrote:
> On Wed, Jan 8, 2014 at 2:01 PM, Jiang Liu  wrote:
>>
>>
>> On 2014/1/8 13:07, Kai Huang wrote:
>>> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  wrote:
 If static identity domain is created, IOMMU driver needs to update
 si_domain page table when memory hotplug event happens. Otherwise
 PCI device DMA operations can't access the hot-added memory regions.

 Signed-off-by: Jiang Liu 
 ---
  drivers/iommu/intel-iommu.c |   52 
 ++-
  1 file changed, 51 insertions(+), 1 deletion(-)

 diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
 index 83e3ed4..35a987d 100644
 --- a/drivers/iommu/intel-iommu.c
 +++ b/drivers/iommu/intel-iommu.c
 @@ -33,6 +33,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -3689,6 +3690,54 @@ static struct notifier_block device_nb = {
 .notifier_call = device_notifier,
  };

 +static int intel_iommu_memory_notifier(struct notifier_block *nb,
 +  unsigned long val, void *v)
 +{
 +   struct memory_notify *mhp = v;
 +   unsigned long long start, end;
 +   struct iova *iova;
 +
 +   switch (val) {
 +   case MEM_GOING_ONLINE:
 +   start = mhp->start_pfn << PAGE_SHIFT;
 +   end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
 +   if (iommu_domain_identity_map(si_domain, start, end)) {
 +   pr_warn("dmar: failed to build identity map for 
 [%llx-%llx]\n",
 +   start, end);
 +   return NOTIFY_BAD;
 +   }
>>>
>>> Better to use iommu_prepare_identity_map? For si_domain, if
>>> hw_pass_through is used, there's no page table.
>> Hi Kai,
>> Good catch!
>> Seems function iommu_prepare_identity_map() is designed to handle
>> RMRRs. So how about avoiding of registering memory hotplug notifier
>> if hw_pass_through is true?
> 
> I think that's also fine :)
> 
> Btw, I have a related question to memory hotplug but not related to
> intel IOMMU specifically. For the devices use DMA remapping, suppose
> the device is already using the memory that we are trying to remove,
> is this case, looks we need to change the existing iova <-> pa
> mappings for the pa that is in the memory range about to be removed,
> and reset the mapping to different pa (iova remains the same). Does
> existing code have this covered? Is there a generic IOMMU layer memory
> hotplug notifier to handle memory removal?
That's a big issue about how to reclaim memory in use. Current rule
is that memory used by DMA won't be removed until released.

> 
> -Kai
>>
>> Thanks!
>> Gerry
>>
>>>
 +   break;
 +   case MEM_OFFLINE:
 +   case MEM_CANCEL_ONLINE:
 +   /* TODO: enhance RB-tree and IOVA code to support of 
 splitting iova */
 +   iova = find_iova(_domain->iovad, mhp->start_pfn);
 +   if (iova) {
 +   unsigned long start_pfn, last_pfn;
 +   struct dmar_drhd_unit *drhd;
 +   struct intel_iommu *iommu;
 +
 +   start_pfn = mm_to_dma_pfn(iova->pfn_lo);
 +   last_pfn = mm_to_dma_pfn(iova->pfn_hi + 1) - 1;
 +   dma_pte_clear_range(si_domain, start_pfn, 
 last_pfn);
 +   dma_pte_free_pagetable(si_domain, start_pfn, 
 last_pfn);
 +   rcu_read_lock();
 +   for_each_active_iommu(iommu, drhd)
 +   iommu_flush_iotlb_psi(iommu, si_domain->id,
 +   start_pfn, last_pfn - start_pfn + 
 1, 0);
 +   rcu_read_unlock();
 +   __free_iova(_domain->iovad, iova);
 +   }
>>>
>>> The same as above. Looks we need to consider hw_pass_through for the 
>>> si_domain.
>>>
>>> -Kai
>>>
 +   break;
 +   }
 +
 +   return NOTIFY_OK;
 +}
 +
 +static struct notifier_block intel_iommu_memory_nb = {
 +   .notifier_call = intel_iommu_memory_notifier,
 +   .priority = 0
 +};
 +
  int __init intel_iommu_init(void)
  {
 int ret = -ENODEV;
 @@ -3761,8 +3810,9 @@ int __init intel_iommu_init(void)
 init_iommu_pm_ops();

 bus_set_iommu(_bus_type, _iommu_ops);
 -
 bus_register_notifier(_bus_type, _nb);
 +   if (si_domain)
 +   register_memory_notifier(_iommu_memory_nb);

 intel_iommu_enabled = 1;

 --
 1.7.10.4

 

[PATCH v4 3/5] ARM: dts: omap4-panda: Provide USB PHY clock

[Roger Quadros]

The USB PHY gets its clock from AUXCLK3. Provide this
information.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..50b72966 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -83,12 +83,8 @@
compatible = "usb-nop-xceiv";
reset-gpios = < 30 GPIO_ACTIVE_LOW>;   /* gpio_62 */
vcc-supply = <_power>;
-   /**
-* FIXME:
-* put the right clock phandle here when available
-*  clocks = <>;
-*  clock-names = "main_clk";
-*/
+   clocks = <_ck>;
+   clock-names = "main_clk";
clock-frequency = <1920>;
};
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

The omap-usb-host driver expects the 60MHz functional clock
of the USB host module to be named as "init_60m_fclk".
Add this information in the DT binding document.

CC: Lee Jones 
CC: Samuel Ortiz 
Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index b381fa6..5635202 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -32,6 +32,10 @@ Optional properties:
 - single-ulpi-bypass: Must be present if the controller contains a single
   ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
 
+- clocks: phandle to 60MHz functional clock to the USB Host module.
+
+- clock-names: must be "init_60m_fclk"
+
 Required properties if child node exists:
 
 - #address-cells: Must be 1
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 5/5] ARM: OMAP2+: Remove legacy_init_ehci_clk()

[Roger Quadros]

The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/pdata-quirks.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 39f020c..6a4e2d1 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,20 +26,6 @@ struct pdata_init {
void (*fn)(void);
 };
 
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
-   int ret;
-
-   ret = clk_add_alias("main_clk", NULL, clkname, NULL);
-   if (ret)
-   pr_err("%s:Failed to add main_clk alias to %s :%d\n",
-  __func__, clkname, ret);
-}
-
 #if IS_ENABLED(CONFIG_WL12XX)
 
 static struct wl12xx_platform_data wl12xx __initdata;
@@ -105,7 +91,6 @@ static void __init omap4_sdp_legacy_init(void)
 static void __init omap4_panda_legacy_init(void)
 {
omap4_panda_display_init_of();
-   legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
 }
 #endif
@@ -113,7 +98,6 @@ static void __init omap4_panda_legacy_init(void)
 #ifdef CONFIG_SOC_OMAP5
 static void __init omap5_uevm_legacy_init(void)
 {
-   legacy_init_ehci_clk("auxclk1_ck");
 }
 #endif
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 4/5] ARM: dts: omap5-uevm: Provide USB PHY clock

[Roger Quadros]

The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
reset-gpios = < 16 GPIO_ACTIVE_LOW>; /* gpio3_80 
HUB_NRESET */
-   /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = <>;
- * clock-names = "main_clk";
- */
+   clocks = <_ck>;
+   clock-names = "main_clk";
clock-frequency = <1920>;
};
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/5] USB Host support for OMAP5 uEVM (for 3.14)

[Roger Quadros]

Hi Benoit & Tony,

This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.

It depends on the TI Clock DT conversion patches [1] and is based
on 3.13-rc7

[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/289895

Changelog:

v4:
- Updated DT binding document for clock binding

v3:
- Rebased on top of 3.13-rc7

cheers,
-roger

Roger Quadros (5):
  mfd: omap-usb-host: Update DT clock binding information
  ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module
  ARM: dts: omap4-panda: Provide USB PHY clock
  ARM: dts: omap5-uevm: Provide USB PHY clock
  ARM: OMAP2+: Remove legacy_init_ehci_clk()

 Documentation/devicetree/bindings/mfd/omap-usb-host.txt |  4 
 arch/arm/boot/dts/omap4-panda-common.dtsi   |  8 ++--
 arch/arm/boot/dts/omap5-uevm.dts|  8 ++--
 arch/arm/boot/dts/omap5.dtsi|  2 ++
 arch/arm/mach-omap2/pdata-quirks.c  | 16 
 5 files changed, 10 insertions(+), 28 deletions(-)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/5] ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module

[Roger Quadros]

USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
reference clock to be named "init_60m_fclk". Provide this
information.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap5.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2f12a47..e0ab379 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -765,6 +765,8 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+   clocks = <_60m_fclk>;
+   clock-names = "init_60m_fclk";
 
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch Part2 V1 14/14] iommu/vt-d: update IOMMU state when memory hotplug happens

[Kai Huang]

On Wed, Jan 8, 2014 at 2:01 PM, Jiang Liu  wrote:
>
>
> On 2014/1/8 13:07, Kai Huang wrote:
>> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  wrote:
>>> If static identity domain is created, IOMMU driver needs to update
>>> si_domain page table when memory hotplug event happens. Otherwise
>>> PCI device DMA operations can't access the hot-added memory regions.
>>>
>>> Signed-off-by: Jiang Liu 
>>> ---
>>>  drivers/iommu/intel-iommu.c |   52 
>>> ++-
>>>  1 file changed, 51 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>>> index 83e3ed4..35a987d 100644
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -33,6 +33,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -3689,6 +3690,54 @@ static struct notifier_block device_nb = {
>>> .notifier_call = device_notifier,
>>>  };
>>>
>>> +static int intel_iommu_memory_notifier(struct notifier_block *nb,
>>> +  unsigned long val, void *v)
>>> +{
>>> +   struct memory_notify *mhp = v;
>>> +   unsigned long long start, end;
>>> +   struct iova *iova;
>>> +
>>> +   switch (val) {
>>> +   case MEM_GOING_ONLINE:
>>> +   start = mhp->start_pfn << PAGE_SHIFT;
>>> +   end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
>>> +   if (iommu_domain_identity_map(si_domain, start, end)) {
>>> +   pr_warn("dmar: failed to build identity map for 
>>> [%llx-%llx]\n",
>>> +   start, end);
>>> +   return NOTIFY_BAD;
>>> +   }
>>
>> Better to use iommu_prepare_identity_map? For si_domain, if
>> hw_pass_through is used, there's no page table.
> Hi Kai,
> Good catch!
> Seems function iommu_prepare_identity_map() is designed to handle
> RMRRs. So how about avoiding of registering memory hotplug notifier
> if hw_pass_through is true?

I think that's also fine :)

Btw, I have a related question to memory hotplug but not related to
intel IOMMU specifically. For the devices use DMA remapping, suppose
the device is already using the memory that we are trying to remove,
is this case, looks we need to change the existing iova <-> pa
mappings for the pa that is in the memory range about to be removed,
and reset the mapping to different pa (iova remains the same). Does
existing code have this covered? Is there a generic IOMMU layer memory
hotplug notifier to handle memory removal?

-Kai
>
> Thanks!
> Gerry
>
>>
>>> +   break;
>>> +   case MEM_OFFLINE:
>>> +   case MEM_CANCEL_ONLINE:
>>> +   /* TODO: enhance RB-tree and IOVA code to support of 
>>> splitting iova */
>>> +   iova = find_iova(_domain->iovad, mhp->start_pfn);
>>> +   if (iova) {
>>> +   unsigned long start_pfn, last_pfn;
>>> +   struct dmar_drhd_unit *drhd;
>>> +   struct intel_iommu *iommu;
>>> +
>>> +   start_pfn = mm_to_dma_pfn(iova->pfn_lo);
>>> +   last_pfn = mm_to_dma_pfn(iova->pfn_hi + 1) - 1;
>>> +   dma_pte_clear_range(si_domain, start_pfn, last_pfn);
>>> +   dma_pte_free_pagetable(si_domain, start_pfn, 
>>> last_pfn);
>>> +   rcu_read_lock();
>>> +   for_each_active_iommu(iommu, drhd)
>>> +   iommu_flush_iotlb_psi(iommu, si_domain->id,
>>> +   start_pfn, last_pfn - start_pfn + 
>>> 1, 0);
>>> +   rcu_read_unlock();
>>> +   __free_iova(_domain->iovad, iova);
>>> +   }
>>
>> The same as above. Looks we need to consider hw_pass_through for the 
>> si_domain.
>>
>> -Kai
>>
>>> +   break;
>>> +   }
>>> +
>>> +   return NOTIFY_OK;
>>> +}
>>> +
>>> +static struct notifier_block intel_iommu_memory_nb = {
>>> +   .notifier_call = intel_iommu_memory_notifier,
>>> +   .priority = 0
>>> +};
>>> +
>>>  int __init intel_iommu_init(void)
>>>  {
>>> int ret = -ENODEV;
>>> @@ -3761,8 +3810,9 @@ int __init intel_iommu_init(void)
>>> init_iommu_pm_ops();
>>>
>>> bus_set_iommu(_bus_type, _iommu_ops);
>>> -
>>> bus_register_notifier(_bus_type, _nb);
>>> +   if (si_domain)
>>> +   register_memory_notifier(_iommu_memory_nb);
>>>
>>> intel_iommu_enabled = 1;
>>>
>>> --
>>> 1.7.10.4
>>>
>>> ___
>>> iommu mailing list
>>> io...@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
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  

Re: [Patch Part2 V1 03/14] iommu/vt-d: simplify function get_domain_for_dev()

[Kai Huang]

On Wed, Jan 8, 2014 at 1:48 PM, Jiang Liu  wrote:
>
>
> On 2014/1/8 11:06, Kai Huang wrote:
>>
>>
>>
>> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu > > wrote:
>>
>> Function get_domain_for_dev() is a little complex, simplify it
>> by factoring out dmar_search_domain_by_dev_info() and
>> dmar_insert_dev_info().
>>
>> Signed-off-by: Jiang Liu > >
>> ---
>>  drivers/iommu/intel-iommu.c |  161
>> ---
>>  1 file changed, 75 insertions(+), 86 deletions(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 1704e97..da65884 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -1957,18 +1957,70 @@ find_domain(struct pci_dev *pdev)
>> return NULL;
>>  }
>>
>> +static inline struct dmar_domain *
>> +dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
>> +{
>> +   struct device_domain_info *info;
>> +
>> +   list_for_each_entry(info, _domain_list, global)
>> +   if (info->segment == segment && info->bus == bus &&
>> +   info->devfn == devfn)
>> +   return info->domain;
>> +
>> +   return NULL;
>> +}
>> +
>> +static int dmar_insert_dev_info(int segment, int bus, int devfn,
>> +   struct pci_dev *dev, struct
>> dmar_domain **domp)
>> +{
>> +   struct dmar_domain *found, *domain = *domp;
>> +   struct device_domain_info *info;
>> +   unsigned long flags;
>> +
>> +   info = alloc_devinfo_mem();
>> +   if (!info)
>> +   return -ENOMEM;
>> +
>> +   info->segment = segment;
>> +   info->bus = bus;
>> +   info->devfn = devfn;
>> +   info->dev = dev;
>> +   info->domain = domain;
>> +   if (!dev)
>> +   domain->flags |= DOMAIN_FLAG_P2P_MULTIPLE_DEVICES;
>> +
>> +   spin_lock_irqsave(_domain_lock, flags);
>> +   if (dev)
>> +   found = find_domain(dev);
>> +   else
>> +   found = dmar_search_domain_by_dev_info(segment, bus,
>> devfn);
>> +   if (found) {
>> +   spin_unlock_irqrestore(_domain_lock, flags);
>> +   free_devinfo_mem(info);
>> +   if (found != domain) {
>> +   domain_exit(domain);
>> +   *domp = found;
>> +   }
>> +   } else {
>> +   list_add(>link, >devices);
>> +   list_add(>global, _domain_list);
>> +   if (dev)
>> +   dev->dev.archdata.iommu = info;
>> +   spin_unlock_irqrestore(_domain_lock, flags);
>> +   }
>> +
>> +   return 0;
>> +}
>>
>>
>> I am a little bit confused about the "alloc before check" sequence in
>> above function. I believe the purpose of allocating the
>> device_domain_info before searching the domain with spin_lock hold is to
>> avoid the memory allocation in the spin_lock? In this case, why can't we
>> use mutex instead of spin_lock? In my understanding, if we use mutex, we
>> can first check if the domain exists or not before we really allocate
>> device_domain_info, right?
> Hi Kai,
> Thanks for review!
> The domain->devices list may be access in interrupt context,
> so we need to protect it with spin_lock_irqsave(). Otherwise it may
> case deadlock.
>

Thanks. That's what I am thinking. I observed lots of other iommu
functions also use spin_lock.

>>
>> Another question is when is info->iommu field initialized? Looks it is
>> not initialized here?
> It's set in function iommu_support_dev_iotlb() for devices supporting
> device IOTLB.

Thanks. I see in iommu_support_dev_iotlb, info->iommu won't be set
unless the device supports iotlb and ATS. Does this mean the
info->iommu won't be used if the device doesn't support iotlb?

If this is true, looks it's not convenient to find the IOMMU that
handles the device via info, as it's possible that different IOMMUs
share the same domain, and we don't know which IOMMU actually handles
this device if we try to find it via the info->domain.

-Kai

>
>>
>> -Kai
>>
>> +
>>  /* domain is initialized */
>>  static struct dmar_domain *get_domain_for_dev(struct pci_dev *pdev,
>> int gaw)
>>  {
>> -   struct dmar_domain *domain, *found = NULL;
>> +   struct dmar_domain *domain;
>> struct intel_iommu *iommu;
>> struct dmar_drhd_unit *drhd;
>> -   struct device_domain_info *info, *tmp;
>> -   struct pci_dev *dev_tmp;
>> +   struct pci_dev *bridge;
>> unsigned long flags;
>> -   int bus = 0, devfn = 0;
>> -  

RE: [PATCH] [v5] phylib: Add Clause 45 read/write functions

[Shaohui Xie]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, January 08, 2014 1:58 PM
> To: shh@gmail.com
> Cc: jg1@samsung.com; mugunthan...@ti.com; f.faine...@gmail.com;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Xie Shaohui-B21989;
> aflem...@gmail.com
> Subject: Re: [PATCH] [v5] phylib: Add Clause 45 read/write functions
> 
> From: David Miller 
> Date: Wed, 08 Jan 2014 00:56:14 -0500 (EST)
> 
> >
> > When you are asked to make changes to a patch in a series, you must
> > repost the entire series, not just the patch which has changed.
> 
> Nevermind I see that you did this, you just messed up the Subject line
> for this patch by not providing the patch number there.
>
[S.H] Oh.. Sorry!

Do I need to resend the entire series? :(

Thanks!
Shaohui Xie
 

--
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 Patch Part2 V1 14/14] iommu/vt-d: update IOMMU state when memory hotplug happens

[Jiang Liu]

On 2014/1/8 13:07, Kai Huang wrote:
> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  wrote:
>> If static identity domain is created, IOMMU driver needs to update
>> si_domain page table when memory hotplug event happens. Otherwise
>> PCI device DMA operations can't access the hot-added memory regions.
>>
>> Signed-off-by: Jiang Liu 
>> ---
>>  drivers/iommu/intel-iommu.c |   52 
>> ++-
>>  1 file changed, 51 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 83e3ed4..35a987d 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -33,6 +33,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -3689,6 +3690,54 @@ static struct notifier_block device_nb = {
>> .notifier_call = device_notifier,
>>  };
>>
>> +static int intel_iommu_memory_notifier(struct notifier_block *nb,
>> +  unsigned long val, void *v)
>> +{
>> +   struct memory_notify *mhp = v;
>> +   unsigned long long start, end;
>> +   struct iova *iova;
>> +
>> +   switch (val) {
>> +   case MEM_GOING_ONLINE:
>> +   start = mhp->start_pfn << PAGE_SHIFT;
>> +   end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
>> +   if (iommu_domain_identity_map(si_domain, start, end)) {
>> +   pr_warn("dmar: failed to build identity map for 
>> [%llx-%llx]\n",
>> +   start, end);
>> +   return NOTIFY_BAD;
>> +   }
> 
> Better to use iommu_prepare_identity_map? For si_domain, if
> hw_pass_through is used, there's no page table.
Hi Kai,
Good catch!
Seems function iommu_prepare_identity_map() is designed to handle
RMRRs. So how about avoiding of registering memory hotplug notifier
if hw_pass_through is true?

Thanks!
Gerry

> 
>> +   break;
>> +   case MEM_OFFLINE:
>> +   case MEM_CANCEL_ONLINE:
>> +   /* TODO: enhance RB-tree and IOVA code to support of 
>> splitting iova */
>> +   iova = find_iova(_domain->iovad, mhp->start_pfn);
>> +   if (iova) {
>> +   unsigned long start_pfn, last_pfn;
>> +   struct dmar_drhd_unit *drhd;
>> +   struct intel_iommu *iommu;
>> +
>> +   start_pfn = mm_to_dma_pfn(iova->pfn_lo);
>> +   last_pfn = mm_to_dma_pfn(iova->pfn_hi + 1) - 1;
>> +   dma_pte_clear_range(si_domain, start_pfn, last_pfn);
>> +   dma_pte_free_pagetable(si_domain, start_pfn, 
>> last_pfn);
>> +   rcu_read_lock();
>> +   for_each_active_iommu(iommu, drhd)
>> +   iommu_flush_iotlb_psi(iommu, si_domain->id,
>> +   start_pfn, last_pfn - start_pfn + 1, 
>> 0);
>> +   rcu_read_unlock();
>> +   __free_iova(_domain->iovad, iova);
>> +   }
> 
> The same as above. Looks we need to consider hw_pass_through for the 
> si_domain.
> 
> -Kai
> 
>> +   break;
>> +   }
>> +
>> +   return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block intel_iommu_memory_nb = {
>> +   .notifier_call = intel_iommu_memory_notifier,
>> +   .priority = 0
>> +};
>> +
>>  int __init intel_iommu_init(void)
>>  {
>> int ret = -ENODEV;
>> @@ -3761,8 +3810,9 @@ int __init intel_iommu_init(void)
>> init_iommu_pm_ops();
>>
>> bus_set_iommu(_bus_type, _iommu_ops);
>> -
>> bus_register_notifier(_bus_type, _nb);
>> +   if (si_domain)
>> +   register_memory_notifier(_iommu_memory_nb);
>>
>> intel_iommu_enabled = 1;
>>
>> --
>> 1.7.10.4
>>
>> ___
>> iommu mailing list
>> io...@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
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] [v5] phylib: Add Clause 45 read/write functions

[David Miller]

From: David Miller 
Date: Wed, 08 Jan 2014 00:56:14 -0500 (EST)

> 
> When you are asked to make changes to a patch in a series, you must
> repost the entire series, not just the patch which has changed.

Nevermind I see that you did this, you just messed up the Subject
line for this patch by not providing the patch number there.
--
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] spi: atmel: Refactor spi-atmel to use SPI framework queue

[Wenyou Yang]

Replace the deprecated master->transfer with transfer_one_message()
and allow the SPI subsystem handle all the queuing of messages.

Signed-off-by: Wenyou Yang 
---
Hi Mark,

The patch is based on for-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git

It is tested on sama5d3xek and at91sam9m10g45ek board.

Best Regards,
Wenyou Yang

 drivers/spi/spi-atmel.c |  681 +++
 1 file changed, 220 insertions(+), 461 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 57fa738..2a8c1d0 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -189,6 +189,8 @@
  */
 #define DMA_MIN_BYTES  16
 
+#define SPI_DMA_TIMEOUT(msecs_to_jiffies(1000))
+
 struct atmel_spi_dma {
struct dma_chan *chan_rx;
struct dma_chan *chan_tx;
@@ -220,17 +222,14 @@ struct atmel_spi {
int irq;
struct clk  *clk;
struct platform_device  *pdev;
-   struct spi_device   *stay;
 
u8  stopping;
-   struct list_headqueue;
-   struct tasklet_struct   tasklet;
struct spi_transfer *current_transfer;
unsigned long   current_remaining_bytes;
-   struct spi_transfer *next_transfer;
-   unsigned long   next_remaining_bytes;
int done_status;
 
+   struct completion   xfer_completion;
+
/* scratch buffer */
void*buffer;
dma_addr_t  buffer_dma;
@@ -376,17 +375,6 @@ static inline bool atmel_spi_use_dma(struct atmel_spi *as,
return as->use_dma && xfer->len >= DMA_MIN_BYTES;
 }
 
-static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
-   struct spi_transfer *xfer)
-{
-   return msg->transfers.prev == >transfer_list;
-}
-
-static inline int atmel_spi_xfer_can_be_chained(struct spi_transfer *xfer)
-{
-   return xfer->delay_usecs == 0 && !xfer->cs_change;
-}
-
 static int atmel_spi_dma_slave_config(struct atmel_spi *as,
struct dma_slave_config *slave_config,
u8 bits_per_word)
@@ -507,29 +495,28 @@ static void atmel_spi_release_dma(struct atmel_spi *as)
dma_release_channel(as->dma.chan_tx);
 }
 
-/* This function is called by the DMA driver from tasklet context */
+/* This function is called by the DMA driver */
 static void dma_callback(void *data)
 {
struct spi_master   *master = data;
struct atmel_spi*as = spi_master_get_devdata(master);
 
-   /* trigger SPI tasklet */
-   tasklet_schedule(>tasklet);
+   atmel_spi_lock(as);
+   complete(>xfer_completion);
+   atmel_spi_unlock(as);
 }
 
 /*
  * Next transfer using PIO.
- * lock is held, spi tasklet is blocked
  */
 static void atmel_spi_next_xfer_pio(struct spi_master *master,
struct spi_transfer *xfer)
 {
struct atmel_spi*as = spi_master_get_devdata(master);
+   unsigned long xfer_pos = xfer->len - as->current_remaining_bytes;
 
dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_pio\n");
 
-   as->current_remaining_bytes = xfer->len;
-
/* Make sure data is not remaining in RDR */
spi_readl(as, RDR);
while (spi_readl(as, SR) & SPI_BIT(RDRF)) {
@@ -537,13 +524,14 @@ static void atmel_spi_next_xfer_pio(struct spi_master 
*master,
cpu_relax();
}
 
-   if (xfer->tx_buf)
+   if (xfer->tx_buf) {
if (xfer->bits_per_word > 8)
-   spi_writel(as, TDR, *(u16 *)(xfer->tx_buf));
+   spi_writel(as, TDR, *(u16 *)(xfer->tx_buf + xfer_pos));
else
-   spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
-   else
+   spi_writel(as, TDR, *(u8 *)(xfer->tx_buf + xfer_pos));
+   } else {
spi_writel(as, TDR, 0);
+   }
 
dev_dbg(master->dev.parent,
"  start pio xfer %p: len %u tx %p rx %p bitpw %d\n",
@@ -556,7 +544,6 @@ static void atmel_spi_next_xfer_pio(struct spi_master 
*master,
 
 /*
  * Submit next transfer for DMA.
- * lock is held, spi tasklet is blocked
  */
 static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
struct spi_transfer *xfer,
@@ -696,72 +683,39 @@ static void atmel_spi_next_xfer_data(struct spi_master 
*master,
 
 /*
  * Submit next transfer for PDC.
- * lock is held, spi irq is blocked
  */
 static void atmel_spi_pdc_next_xfer(struct spi_master *master,
-   struct spi_message *msg)
+   struct spi_message *msg,
+   struct spi_transfer *xfer)
 {
struct atmel_spi*as = 

[PATCH 6/6] [v5] phylib: Add of_phy_attach

[shh.xie]

From: Andy Fleming 

10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
Acked-by: Florian Fainelli 
---
changes for v5:
revised for opening parenthesis.

 drivers/of/of_mdio.c| 20 
 include/linux/of_mdio.h | 10 ++
 2 files changed, 30 insertions(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..7f4195b 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -247,3 +247,23 @@ struct phy_device *of_phy_connect_fixed_link(struct 
net_device *dev,
return IS_ERR(phy) ? NULL : phy;
 }
 EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+struct device_node *phy_np, u32 flags,
+phy_interface_t iface)
+{
+   struct phy_device *phy = of_phy_find_device(phy_np);
+
+   if (!phy)
+   return NULL;
+
+   return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..6fe8464 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,9 @@ extern struct phy_device *of_phy_connect(struct net_device 
*dev,
 struct device_node *phy_np,
 void (*hndlr)(struct net_device *),
 u32 flags, phy_interface_t iface);
+struct phy_device *of_phy_attach(struct net_device *dev,
+struct device_node *phy_np, u32 flags,
+phy_interface_t iface);
 extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
 void (*hndlr)(struct net_device *),
 phy_interface_t iface);
@@ -44,6 +47,13 @@ static inline struct phy_device *of_phy_connect(struct 
net_device *dev,
return NULL;
 }
 
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+  struct device_node *phy_np,
+  u32 flags, phy_interface_t iface)
+{
+   return NULL;
+}
+
 static inline struct phy_device *of_phy_connect_fixed_link(struct net_device 
*dev,
   void (*hndlr)(struct 
net_device *),
   phy_interface_t 
iface)
-- 
1.8.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/

[PATCH 4/6] [v5] phylib: Add generic 10G driver

[shh.xie]

From: Andy Fleming 

Very incomplete, but will allow for binding an ethernet controller
to it.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
resend for v5.

 drivers/net/phy/phy_device.c | 80 
 1 file changed, 80 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 748bf07..439b0d4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -55,6 +56,7 @@ static void phy_device_release(struct device *dev)
 
 enum genphy_driver {
GENPHY_DRV_1G,
+   GENPHY_DRV_10G,
GENPHY_DRV_MAX
 };
 
@@ -699,6 +701,12 @@ static int genphy_config_advert(struct phy_device *phydev)
return changed;
 }
 
+int gen10g_config_advert(struct phy_device *dev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_config_advert);
+
 /**
  * genphy_setup_forced - configures/forces speed/duplex from @phydev
  * @phydev: target phy_device struct
@@ -752,6 +760,11 @@ int genphy_restart_aneg(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_restart_aneg);
 
+int gen10g_restart_aneg(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_restart_aneg);
 
 /**
  * genphy_config_aneg - restart auto-negotiation or write BMCR
@@ -794,6 +807,12 @@ int genphy_config_aneg(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_config_aneg);
 
+int gen10g_config_aneg(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_config_aneg);
+
 /**
  * genphy_update_link - update link status in @phydev
  * @phydev: target phy_device struct
@@ -923,6 +942,34 @@ int genphy_read_status(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_read_status);
 
+int gen10g_read_status(struct phy_device *phydev)
+{
+   int devad, reg;
+   u32 mmd_mask = phydev->c45_ids.devices_in_package;
+
+   phydev->link = 1;
+
+   /* For now just lie and say it's 10G all the time */
+   phydev->speed = SPEED_1;
+   phydev->duplex = DUPLEX_FULL;
+
+   for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
+   if (!(mmd_mask & 1))
+   continue;
+
+   /* Read twice because link state is latched and a
+* read moves the current state into the register
+*/
+   phy_read_mmd(phydev, devad, MDIO_STAT1);
+   reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
+   if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
+   phydev->link = 0;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_read_status);
+
 static int genphy_config_init(struct phy_device *phydev)
 {
int val;
@@ -969,6 +1016,16 @@ static int genphy_config_init(struct phy_device *phydev)
 
return 0;
 }
+
+static int gen10g_config_init(struct phy_device *phydev)
+{
+   /* Temporarily just say we support everything */
+   phydev->supported = SUPPORTED_1baseT_Full;
+   phydev->advertising = SUPPORTED_1baseT_Full;
+
+   return 0;
+}
+
 int genphy_suspend(struct phy_device *phydev)
 {
int value;
@@ -984,6 +1041,12 @@ int genphy_suspend(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_suspend);
 
+int gen10g_suspend(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_suspend);
+
 int genphy_resume(struct phy_device *phydev)
 {
int value;
@@ -999,6 +1062,12 @@ int genphy_resume(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_resume);
 
+int gen10g_resume(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_resume);
+
 /**
  * phy_probe - probe and init a PHY device
  * @dev: device to probe and init
@@ -1138,6 +1207,17 @@ static struct phy_driver genphy_driver[] = {
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = {.owner= THIS_MODULE, },
+}, {
+   .phy_id = 0x,
+   .phy_id_mask= 0x,
+   .name   = "Generic 10G PHY",
+   .config_init= gen10g_config_init,
+   .features   = 0,
+   .config_aneg= gen10g_config_aneg,
+   .read_status= gen10g_read_status,
+   .suspend= gen10g_suspend,
+   .resume = gen10g_resume,
+   .driver = {.owner = THIS_MODULE, },
 } };
 
 static int __init phy_init(void)
-- 
1.8.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] [v5] phylib: Add Clause 45 read/write functions

[David Miller]

When you are asked to make changes to a patch in a series, you must
repost the entire series, not just the patch which has changed.
--
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/6] [v5] phylib: Support attaching to generic 10g driver

[shh.xie]

From: Andy Fleming 

phy_attach_direct() may now attach to a generic 10G driver. It can
also be used exactly as phy_connect_direct(), which will be useful
when using of_mdio, as phy_connect (and therefore of_phy_connect)
start the PHY state machine, which is currently irrelevant for 10G
PHYs.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
Acked-by: Florian Fainelli 
---
changes for v5:
revised for opening parenthesis.

 drivers/net/phy/phy_device.c | 22 +-
 include/linux/phy.h  |  2 ++
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 439b0d4..4a9f2b3 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -67,9 +67,6 @@ extern void mdio_bus_exit(void);
 static LIST_HEAD(phy_fixup_list);
 static DEFINE_MUTEX(phy_fixup_lock);
 
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface);
-
 /*
  * Creates a new phy_fixup and adds it to the list
  * @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID)
@@ -527,13 +524,13 @@ int phy_init_hw(struct phy_device *phydev)
  *
  * Description: Called by drivers to attach to a particular PHY
  * device. The phy_device is found, and properly hooked up
- * to the phy_driver.  If no driver is attached, then the
- * genphy_driver is used.  The phy_device is given a ptr to
+ * to the phy_driver.  If no driver is attached, then a
+ * generic driver is used.  The phy_device is given a ptr to
  * the attaching device, and given a callback for link status
  * change.  The phy_device is returned to the attaching driver.
  */
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface)
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+ u32 flags, phy_interface_t interface)
 {
struct device *d = >dev;
int err;
@@ -541,12 +538,10 @@ static int phy_attach_direct(struct net_device *dev, 
struct phy_device *phydev,
/* Assume that if there is no driver, that it doesn't
 * exist, and we should use the genphy driver. */
if (NULL == d->driver) {
-   if (phydev->is_c45) {
-   pr_err("No driver for phy %x\n", phydev->phy_id);
-   return -ENODEV;
-   }
-
-   d->driver = _driver[GENPHY_DRV_1G].driver;
+   if (phydev->is_c45)
+   d->driver = _driver[GENPHY_DRV_10G].driver;
+   else
+   d->driver = _driver[GENPHY_DRV_1G].driver;
 
err = d->driver->probe(d);
if (err >= 0)
@@ -579,6 +574,7 @@ static int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
 
return err;
 }
+EXPORT_SYMBOL(phy_attach_direct);
 
 /**
  * phy_attach - attach a network device to a particular PHY device
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 15b7447..8615a56 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -581,6 +581,8 @@ int phy_init_hw(struct phy_device *phydev);
 struct phy_device * phy_attach(struct net_device *dev,
const char *bus_id, phy_interface_t interface);
 struct phy_device *phy_find_first(struct mii_bus *bus);
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+ u32 flags, phy_interface_t interface);
 int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
void (*handler)(struct net_device *),
phy_interface_t interface);
-- 
1.8.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/

[PATCH 3/6] [v5] phylib: turn genphy_driver to an array

[shh.xie]

From: Shaohui Xie 

Then other generic phy driver such as generic 10g phy driver can join it.

Signed-off-by: Shaohui Xie 
---
resend for v5.

 drivers/net/phy/phy_device.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d6447b3..748bf07 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -53,7 +53,12 @@ static void phy_device_release(struct device *dev)
kfree(to_phy_device(dev));
 }
 
-static struct phy_driver genphy_driver;
+enum genphy_driver {
+   GENPHY_DRV_1G,
+   GENPHY_DRV_MAX
+};
+
+static struct phy_driver genphy_driver[GENPHY_DRV_MAX];
 extern int mdio_bus_init(void);
 extern void mdio_bus_exit(void);
 
@@ -539,7 +544,7 @@ static int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
return -ENODEV;
}
 
-   d->driver = _driver.driver;
+   d->driver = _driver[GENPHY_DRV_1G].driver;
 
err = d->driver->probe(d);
if (err >= 0)
@@ -613,6 +618,7 @@ EXPORT_SYMBOL(phy_attach);
  */
 void phy_detach(struct phy_device *phydev)
 {
+   int i;
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
 
@@ -620,8 +626,12 @@ void phy_detach(struct phy_device *phydev)
 * was using the generic driver), we unbind the device
 * from the generic driver so that there's a chance a
 * real driver could be loaded */
-   if (phydev->dev.driver == _driver.driver)
-   device_release_driver(>dev);
+   for (i = 0; i < ARRAY_SIZE(genphy_driver); i++) {
+   if (phydev->dev.driver == _driver[i].driver) {
+   device_release_driver(>dev);
+   break;
+   }
+   }
 }
 EXPORT_SYMBOL(phy_detach);
 
@@ -1116,7 +1126,8 @@ void phy_drivers_unregister(struct phy_driver *drv, int n)
 }
 EXPORT_SYMBOL(phy_drivers_unregister);
 
-static struct phy_driver genphy_driver = {
+static struct phy_driver genphy_driver[] = {
+{
.phy_id = 0x,
.phy_id_mask= 0x,
.name   = "Generic PHY",
@@ -1127,7 +1138,7 @@ static struct phy_driver genphy_driver = {
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = {.owner= THIS_MODULE, },
-};
+} };
 
 static int __init phy_init(void)
 {
@@ -1137,7 +1148,8 @@ static int __init phy_init(void)
if (rc)
return rc;
 
-   rc = phy_driver_register(_driver);
+   rc = phy_drivers_register(genphy_driver,
+ ARRAY_SIZE(genphy_driver));
if (rc)
mdio_bus_exit();
 
@@ -1146,7 +1158,8 @@ static int __init phy_init(void)
 
 static void __exit phy_exit(void)
 {
-   phy_driver_unregister(_driver);
+   phy_drivers_unregister(genphy_driver,
+  ARRAY_SIZE(genphy_driver));
mdio_bus_exit();
 }
 
-- 
1.8.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/

[PATCH 2/6] [v5] phylib: introduce PHY_INTERFACE_MODE_XGMII for 10G PHY

[shh.xie]

From: Andy Fleming 

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
Acked-by: Florian Fainelli 
---
resend for v5.

 drivers/of/of_net.c | 1 +
 include/linux/phy.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 8f9be2e..a208a45 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -30,6 +30,7 @@ static const char *phy_modes[] = {
[PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
[PHY_INTERFACE_MODE_RTBI]   = "rtbi",
[PHY_INTERFACE_MODE_SMII]   = "smii",
+   [PHY_INTERFACE_MODE_XGMII]  = "xgmii",
 };
 
 /**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index a083650..15b7447 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -66,6 +66,7 @@ typedef enum {
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
+   PHY_INTERFACE_MODE_XGMII,
 } phy_interface_t;
 
 
-- 
1.8.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/

[PATCH] [v5] phylib: Add Clause 45 read/write functions

[shh.xie]

From: Andy Fleming 

Need an extra parameter to read or write Clause 45 PHYs, so
need a different API with the extra parameter.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
changes for v5:
revised for opening parenthesis.

 include/linux/phy.h | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..e5eed18 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -498,6 +498,24 @@ static inline int phy_read(struct phy_device *phydev, u32 
regnum)
 }
 
 /**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32 
regnum)
+{
+   if (!phydev->is_c45)
+   return -EOPNOTSUPP;
+
+   return mdiobus_read(phydev->bus, phydev->addr,
+   MII_ADDR_C45 | (devad << 16) | (regnum & 0x));
+}
+
+/**
  * phy_write - Convenience function for writing a given PHY register
  * @phydev: the phy_device struct
  * @regnum: register number to write
@@ -533,6 +551,27 @@ static inline bool phy_is_internal(struct phy_device 
*phydev)
return phydev->is_internal;
 }
 
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+   u32 regnum, u16 val)
+{
+   if (!phydev->is_c45)
+   return -EOPNOTSUPP;
+
+   regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0x);
+
+   return mdiobus_write(phydev->bus, phydev->addr, regnum, val);
+}
+
 struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
bool is_c45, struct phy_c45_device_ids *c45_ids);
 struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
-- 
1.8.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/2] cpufreq: try to resume policies which failed on last resume

[Viresh Kumar]

On 6 January 2014 16:47, Bjørn Mork  wrote:
> Viresh Kumar  writes:
>
>> On 6 January 2014 16:19, Bjørn Mork  wrote:
>>> I cancelled by pressing backspace while the image was being written.
>>
>> I will answer other queries on next mail, but a quick question:
>> Do you get these warnings even if you don't cancel hibernation?
>
> Yes.

Hmm.. I see. Now, I really don't believe that you wouldn't get these
warnings on a suspend/resume but only on hibernation.

> I believe the photo shows that you are right: This warning happens when
> the failure path is entered, even if both the hibernation and following
> resume is successful.  We see __cpufreq_add_dev calling
> cpufreq_policy_put_kobj here as well.

@Rafael: I need your expert opinion here, I am not so good with these
concepts :)

Here is my theory about these warnings:
- Bjorn gets these only when CONFIG_PROVE_LOCKING=y.
- This feature enables the kernel to report locking related deadlocks
before they actually occur. (lib/Kconfig.debug)
- So, no locking issue has happened here but its just an warning that
you might end up getting into such issue later.
- Contention is between sysfs and cpu-hotplug lock.
- While changing stuff from sysfs we do this:
   sysfs-lock (by kernel)
   cpu-hotplug lock (by cpufreq)
- And while doing hibernation if add_dev fails then we do this
   cpu-hotplug lock (by kernel while adding CPUs)
   sysfs-lock (by cpufreq while removing sysfs directories)

And kernel is recording all these sequences all the time. Because
we first tried changing values from sysfs, kernel recorded that
sequence. And as soon as it found another one it WARNed us?

While on a suspend/resume, we will get into add-dev failure only
in resume and probably by that time these recordings are refreshed?
And that's why Bjorn isn't facing any issue there ? Just an wild guess.

And if all above "virtual" theory is correct, then I don't know if we
can/want to fix that..

> Thinking about this: This failure will always happen, regardless of
> cancelling or not, won't it?

Yeah.

> But it happens *after* the freeze so it
> doesn't matter if we resume from the frozen image.

yeah..

So, even tests like this should give you this warning:

Documentation/power/basic-pm-debugging.txt
core
- test the freezing of processes, suspending of devices, platform global
  control methods(*), the disabling of nonboot CPUs and suspending of
  platform/system devices

> So you are probably right as usual:

Really? Ask Rafael, he doesn't agree :)

> This warning is related to the
> acpi-cpufreq driver failing, and you cannot reproduce it without
> simulating such a failure (or using that driver yourself).  Which means
> that the warning disappears with my patch in
> http://www.spinics.net/lists/cpufreq/msg08714.html
> which explains why I don't normally see it.  I depend on being able to
> cancel hibernation, so I use that patch most of the time. Except when
> I'm testing one of your branches.

Correct.
--
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 Part2 V1 03/14] iommu/vt-d: simplify function get_domain_for_dev()

[Jiang Liu]

On 2014/1/8 11:06, Kai Huang wrote:
> 
> 
> 
> On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  > wrote:
> 
> Function get_domain_for_dev() is a little complex, simplify it
> by factoring out dmar_search_domain_by_dev_info() and
> dmar_insert_dev_info().
> 
> Signed-off-by: Jiang Liu  >
> ---
>  drivers/iommu/intel-iommu.c |  161
> ---
>  1 file changed, 75 insertions(+), 86 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 1704e97..da65884 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1957,18 +1957,70 @@ find_domain(struct pci_dev *pdev)
> return NULL;
>  }
> 
> +static inline struct dmar_domain *
> +dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
> +{
> +   struct device_domain_info *info;
> +
> +   list_for_each_entry(info, _domain_list, global)
> +   if (info->segment == segment && info->bus == bus &&
> +   info->devfn == devfn)
> +   return info->domain;
> +
> +   return NULL;
> +}
> +
> +static int dmar_insert_dev_info(int segment, int bus, int devfn,
> +   struct pci_dev *dev, struct
> dmar_domain **domp)
> +{
> +   struct dmar_domain *found, *domain = *domp;
> +   struct device_domain_info *info;
> +   unsigned long flags;
> +
> +   info = alloc_devinfo_mem();
> +   if (!info)
> +   return -ENOMEM;
> +
> +   info->segment = segment;
> +   info->bus = bus;
> +   info->devfn = devfn;
> +   info->dev = dev;
> +   info->domain = domain;
> +   if (!dev)
> +   domain->flags |= DOMAIN_FLAG_P2P_MULTIPLE_DEVICES;
> +
> +   spin_lock_irqsave(_domain_lock, flags);
> +   if (dev)
> +   found = find_domain(dev);
> +   else
> +   found = dmar_search_domain_by_dev_info(segment, bus,
> devfn);
> +   if (found) {
> +   spin_unlock_irqrestore(_domain_lock, flags);
> +   free_devinfo_mem(info);
> +   if (found != domain) {
> +   domain_exit(domain);
> +   *domp = found;
> +   }
> +   } else {
> +   list_add(>link, >devices);
> +   list_add(>global, _domain_list);
> +   if (dev)
> +   dev->dev.archdata.iommu = info;
> +   spin_unlock_irqrestore(_domain_lock, flags);
> +   }
> +
> +   return 0;
> +}
> 
> 
> I am a little bit confused about the "alloc before check" sequence in
> above function. I believe the purpose of allocating the
> device_domain_info before searching the domain with spin_lock hold is to
> avoid the memory allocation in the spin_lock? In this case, why can't we
> use mutex instead of spin_lock? In my understanding, if we use mutex, we
> can first check if the domain exists or not before we really allocate
> device_domain_info, right?
Hi Kai,
Thanks for review!
The domain->devices list may be access in interrupt context,
so we need to protect it with spin_lock_irqsave(). Otherwise it may
case deadlock.

> 
> Another question is when is info->iommu field initialized? Looks it is
> not initialized here?
It's set in function iommu_support_dev_iotlb() for devices supporting
device IOTLB.

> 
> -Kai
> 
> +
>  /* domain is initialized */
>  static struct dmar_domain *get_domain_for_dev(struct pci_dev *pdev,
> int gaw)
>  {
> -   struct dmar_domain *domain, *found = NULL;
> +   struct dmar_domain *domain;
> struct intel_iommu *iommu;
> struct dmar_drhd_unit *drhd;
> -   struct device_domain_info *info, *tmp;
> -   struct pci_dev *dev_tmp;
> +   struct pci_dev *bridge;
> unsigned long flags;
> -   int bus = 0, devfn = 0;
> -   int segment;
> -   int ret;
> +   int segment, bus, devfn;
> 
> domain = find_domain(pdev);
> if (domain)
> @@ -1976,119 +2028,56 @@ static struct dmar_domain
> *get_domain_for_dev(struct pci_dev *pdev, int gaw)
> 
> segment = pci_domain_nr(pdev->bus);
> 
> -   dev_tmp = pci_find_upstream_pcie_bridge(pdev);
> -   if (dev_tmp) {
> -   if (pci_is_pcie(dev_tmp)) {
> -   bus = dev_tmp->subordinate->number;
> +   bridge = pci_find_upstream_pcie_bridge(pdev);
> +   if (bridge) {
> +   if (pci_is_pcie(bridge)) {
> +   bus = 

[PATCH 1/2] f2fs: improve write performance under frequent fsync calls

[Jaegeuk Kim]

When considering a bunch of data writes with very frequent fsync calls, we
are able to think the following performance regression.

N: Node IO, D: Data IO, IO scheduler: cfq

Issuepending IOs
 D1 D2 D3 D4
 D1 D2 D3 D4 N1
 D2D3 D4 N1 N2
 N1D3 D4 N2 D1
 --> N1 can be selected by cfq becase of the same priority of N and D.
 Then D3 and D4 would be delayed, resuling in performance degradation.

So, when processing the fsync call, it'd better give higher priority to data IOs
than node IOs by assigning WRITE and WRITE_SYNC respectively.
This patch improves the random wirte performance with frequent fsync calls by up
to 10%.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h| 4 ++--
 fs/f2fs/file.c| 2 +-
 fs/f2fs/node.c| 7 ++-
 fs/f2fs/segment.c | 8 ++--
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 07a7ae0..b69f190 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1118,8 +1118,8 @@ int npages_for_summary_flush(struct f2fs_sb_info *);
 void allocate_new_segments(struct f2fs_sb_info *);
 struct page *get_sum_page(struct f2fs_sb_info *, unsigned int);
 void write_meta_page(struct f2fs_sb_info *, struct page *);
-void write_node_page(struct f2fs_sb_info *, struct page *, unsigned int,
-   block_t, block_t *);
+void write_node_page(struct f2fs_sb_info *, struct page *,
+   struct f2fs_io_info *, unsigned int, block_t, block_t *);
 void write_data_page(struct page *, struct dnode_of_data *, block_t *,
struct f2fs_io_info *);
 void rewrite_data_page(struct page *, block_t, struct f2fs_io_info *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index c77ad4d..14511b0 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -115,7 +115,7 @@ int f2fs_sync_file(struct file *file, loff_t start, loff_t 
end, int datasync)
int ret = 0;
bool need_cp = false;
struct writeback_control wbc = {
-   .sync_mode = WB_SYNC_ALL,
+   .sync_mode = WB_SYNC_NONE,
.nr_to_write = LONG_MAX,
.for_reclaim = 0,
};
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 0230326..b8c9301 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1194,6 +1194,10 @@ static int f2fs_write_node_page(struct page *page,
nid_t nid;
block_t new_addr;
struct node_info ni;
+   struct f2fs_io_info fio = {
+   .type = NODE,
+   .rw = (wbc->sync_mode == WB_SYNC_ALL) ? WRITE_SYNC: WRITE,
+   };
 
if (unlikely(sbi->por_doing))
goto redirty_out;
@@ -1218,7 +1222,7 @@ static int f2fs_write_node_page(struct page *page,
 
mutex_lock(>node_write);
set_page_writeback(page);
-   write_node_page(sbi, page, nid, ni.blk_addr, _addr);
+   write_node_page(sbi, page, , nid, ni.blk_addr, _addr);
set_node_addr(sbi, , new_addr);
dec_page_count(sbi, F2FS_DIRTY_NODES);
mutex_unlock(>node_write);
@@ -1253,6 +1257,7 @@ static int f2fs_write_node_pages(struct address_space 
*mapping,
 
/* if mounting is failed, skip writing node pages */
wbc->nr_to_write = 3 * max_hw_blocks(sbi);
+   wbc->sync_mode = WB_SYNC_NONE;
sync_node_pages(sbi, 0, wbc);
wbc->nr_to_write = nr_to_write - (3 * max_hw_blocks(sbi) -
wbc->nr_to_write);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 555ae76..5f84639 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -924,16 +924,12 @@ void write_meta_page(struct f2fs_sb_info *sbi, struct 
page *page)
 }
 
 void write_node_page(struct f2fs_sb_info *sbi, struct page *page,
+   struct f2fs_io_info *fio,
unsigned int nid, block_t old_blkaddr, block_t *new_blkaddr)
 {
struct f2fs_summary sum;
-   struct f2fs_io_info fio = {
-   .type = NODE,
-   .rw = WRITE_SYNC,
-   };
-
set_summary(, nid, 0, 0);
-   do_write_page(sbi, page, old_blkaddr, new_blkaddr, , );
+   do_write_page(sbi, page, old_blkaddr, new_blkaddr, , fio);
 }
 
 void write_data_page(struct page *page, struct dnode_of_data *dn,
-- 
1.8.4.474.g128a96c

--
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] f2fs: add a sysfs entry to control max_victim_search

[Jaegeuk Kim]

Previously during SSR and GC, the maximum number of retrials to find a victim
segment was hard-coded by MAX_VICTIM_SEARCH, 4096 by default.

This number makes an effect on IO locality, when SSR mode is activated, which
results in performance fluctuation on some low-end devices.

If max_victim_search = 4, the victim will be searched like below.
("D" represents a dirty segment, and "*" indicates a selected victim segment.)

 D1 D2 D3 D4 D5 D6 D7 D8 D9
[   *   ]
  [   *]
[ * ]
[ ]

This patch adds a sysfs entry to control the number dynamically through:
  /sys/fs/f2fs/$dev/max_victim_search

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 3 +++
 fs/f2fs/gc.c| 4 ++--
 fs/f2fs/gc.h| 2 +-
 fs/f2fs/super.c | 6 ++
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index b69f190..5f7dc4f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -451,6 +451,9 @@ struct f2fs_sb_info {
struct f2fs_gc_kthread  *gc_thread; /* GC thread */
unsigned int cur_victim_sec;/* current victim section num */
 
+   /* maximum # of trials to find a victim segment for SSR and GC */
+   unsigned int max_victim_search;
+
/*
 * for stat information.
 * one is for the LFS mode, and the other is for the SSR mode.
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 599f546..9117cca 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -163,8 +163,8 @@ static void select_policy(struct f2fs_sb_info *sbi, int 
gc_type,
p->ofs_unit = sbi->segs_per_sec;
}
 
-   if (p->max_search > MAX_VICTIM_SEARCH)
-   p->max_search = MAX_VICTIM_SEARCH;
+   if (p->max_search > sbi->max_victim_search)
+   p->max_search = sbi->max_victim_search;
 
p->offset = sbi->last_victim[p->gc_mode];
 }
diff --git a/fs/f2fs/gc.h b/fs/f2fs/gc.h
index 507056d..5d5eb60 100644
--- a/fs/f2fs/gc.h
+++ b/fs/f2fs/gc.h
@@ -20,7 +20,7 @@
 #define LIMIT_FREE_BLOCK   40 /* percentage over invalid + free space */
 
 /* Search max. number of dirty segments to select a victim segment */
-#define MAX_VICTIM_SEARCH 4096 /* covers 8GB */
+#define DEF_MAX_VICTIM_SEARCH 4096 /* covers 8GB */
 
 struct f2fs_gc_kthread {
struct task_struct *f2fs_gc_task;
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f16da92..b070f30 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -74,6 +74,7 @@ static match_table_t f2fs_tokens = {
 enum {
GC_THREAD,  /* struct f2fs_gc_thread */
SM_INFO,/* struct f2fs_sm_info */
+   F2FS_SBI,   /* struct f2fs_sb_info */
 };
 
 struct f2fs_attr {
@@ -91,6 +92,8 @@ static unsigned char *__struct_ptr(struct f2fs_sb_info *sbi, 
int struct_type)
return (unsigned char *)sbi->gc_thread;
else if (struct_type == SM_INFO)
return (unsigned char *)SM_I(sbi);
+   else if (struct_type == F2FS_SBI)
+   return (unsigned char *)sbi;
return NULL;
 }
 
@@ -180,6 +183,7 @@ F2FS_RW_ATTR(SM_INFO, f2fs_sm_info, reclaim_segments, 
rec_prefree_segments);
 F2FS_RW_ATTR(SM_INFO, f2fs_sm_info, max_small_discards, max_discards);
 F2FS_RW_ATTR(SM_INFO, f2fs_sm_info, ipu_policy, ipu_policy);
 F2FS_RW_ATTR(SM_INFO, f2fs_sm_info, min_ipu_util, min_ipu_util);
+F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, max_victim_search, max_victim_search);
 
 #define ATTR_LIST(name) (_attr_##name.attr)
 static struct attribute *f2fs_attrs[] = {
@@ -191,6 +195,7 @@ static struct attribute *f2fs_attrs[] = {
ATTR_LIST(max_small_discards),
ATTR_LIST(ipu_policy),
ATTR_LIST(min_ipu_util),
+   ATTR_LIST(max_victim_search),
NULL,
 };
 
@@ -775,6 +780,7 @@ static void init_sb_info(struct f2fs_sb_info *sbi)
sbi->node_ino_num = le32_to_cpu(raw_super->node_ino);
sbi->meta_ino_num = le32_to_cpu(raw_super->meta_ino);
sbi->cur_victim_sec = NULL_SECNO;
+   sbi->max_victim_search = DEF_MAX_VICTIM_SEARCH;
 
for (i = 0; i < NR_COUNT_TYPE; i++)
atomic_set(>nr_pages[i], 0);
-- 
1.8.4.474.g128a96c

--
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 1/4] ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module

[Roger Quadros]

On 01/07/2014 08:43 PM, Arnd Bergmann wrote:
> On Tuesday 07 January 2014, Roger Quadros wrote:
>> USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
>> reference clock to be named "init_60m_fclk". Provide this
>> information.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  arch/arm/boot/dts/omap5.dtsi | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index 2f12a47..e0ab379 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -765,6 +765,8 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges;
>> +   clocks = <_60m_fclk>;
>> +   clock-names = "init_60m_fclk";
>>  
>> usbhsohci: ohci@4a064800 {
>> compatible = "ti,ohci-omap3", "usb-ohci";
> 
> The bindings/mfd/omap-usb-host.txt file doesn't document any clocks.
> Please create another patch to document the clock names in this binding
> before you start putting them into the dtsi file. So far the clock
> names are an implementation detail of Linux as they are not part
> of the binding, and with your patch it becomes part of the ABI.
> 
Right. I'll re-post the series.

cheers,
-roger
--
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/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

[David Cohen]

Hi Greg,

On Tue, Jan 07, 2014 at 08:16:20PM -0800, Greg KH wrote:
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
> 
> On Wed, Jan 08, 2014 at 03:49:07AM +, Tang, Jianqiang wrote:
> > Hi,
> >  1) I met this issue one time just boot up our Linux Platform(Kernel3.10) 
> > with XHCI driver, then kernel panic happen.
> > 
> >And this issue reported once by other internal team.
> > 
> >Nothing special of reproduce step and do not need special Hardware I 
> > think.
> > 
> >Just random issue which will happen when meet the timing condition.
> > 
> >  2) This issue is introduced by this patch:
> > 
> >  
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=596d789a211d134dc5f94d1e5957248c204ef850
> > 
> >which set all hub autosuspend delay to 0.
> 
> That patch was released in a kernel almost a full year ago, yet we have
> never had a report of this happening before, so are you sure this patch
> is the root cause?

This bug happened in a platform with 1 usb3 host controller + 1 usb3 OTG
controller (Jianqiang, please correct me if I'm wrong).
How common is this configuration out there?

Br, David Cohen

> 
> >This causes race condition during XHCI driver initialization,
> > 
> > After USB2 hcd and USB2 root hub finish the initialization, USB2 root 
> > hub is functional and auto suspend right now, hence trigger XHCI runtime 
> > suspend flow;
> > 
> > At the same time, XHCI driver continue to initialize the USB3 hcd and 
> > assign to xhci->shared_hcd after finish the initialization;
> > 
> > Since xhci_suspend() use the xhci->shared_hcd, so there is race 
> > condition that when XHCI runtime suspend called, xhci->shared_hcd still 
> > NULL.
> > 
> > I think this patch is a fix solution since before XHCI finish the whole 
> > initialization, USB2 root hub triggered runtime suspend is mean less and do 
> > not need to handle.
> 
> With this patch applied, does the crash go away?
--
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 v6][RESEND] platform: x86: New BayTrail IOSF-SB MBI driver

[David E. Box]

On Wed, Jan 08, 2014 at 01:11:22AM +0100, Rafael J. Wysocki wrote:
> Well, I personally think that this code should go into arch/x86/ as library 
> code
> needed to access IOSF Sideband on some platforms.

I don't disagree. However for the record this is not the first time it has been
discussed and I already moved it from arch/x86 to platform on the suggestion of
several maintainers. I will keep the interface generic except that it has to be
stated that it will only support those platforms that can enumerate this device
using PCI. Plus I learned there are others who plan to patch when it gets
accepted to support other platforms using different methods of
enumeration/communication. I would thik this probably cements its placement in
arch/x86.

> I probably would make modules
> depending on it select it, so for example if the RAPL driver is going to be
> built, your driver should be build either and rather unconditionally in that
> case.
> 

Wouldn't such a dependency be handled by the RAPL driver et al. How can I force
modules to build this driver? Reverse dependency? Also the biggest consumer of
the driver doesn't have code upstream yet.

> So the rule should be "if something *may* need it, build it" in my opinion.

You suggest that even though non-IOSF systems don't need this driver to enable
RAPL, it should build anyway since it's a dependency for systems that do have
IOSF? Even if this is what you suggest I'd prefer the owner of the driver that
has the dependency be the one to patch this driver to make in build in that
case. I do not know all who would use it.

Dave Box
--
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: [GIT PULL 0/4] PHY: for 3.14

[Kishon Vijay Abraham I]

Hi Greg,

On Thursday 26 December 2013 10:17 PM, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> here's the patches for 3.14. It contains few fixes on phy-core and added a new
> PHY driver used by SATA in Marvell SoCs.
> 
> Let me know if you need any changes.
> 
> Thanks
> Kishon
> 
> The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:
> 
>   Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/for_3.14
> 
> for you to fetch changes up to e3eae85773ebd2165d19ca8661cca3b9c60b2ba1:
> 
>   Phy: Add a PHY driver for Marvell MVEBU SATA PHY. (2013-12-24 23:52:58 
> +0530)
> 
> 
> Pull request for PHY subsystem contains few fixes in PHY-CORE mostly
> w.r.t PM and reference counting and also a new PHY driver used by SATA
> in Marvell SoC.
> 
> 
> Andrew Lunn (1):
>   Phy: Add a PHY driver for Marvell MVEBU SATA PHY.
> 
> Felipe Balbi (1):
>   phy: core: properly handle failure of pm_runtime_get functions
> 
> Kishon Vijay Abraham I (2):
>   phy: phy-core: increment refcounting variables only on 'success'
>   phy: phy-core.c: remove unnecessary initialization of local variables\


Will you be taking these patches?

Thanks
Kishon
> 
>  drivers/phy/Kconfig  |6 ++
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-core.c   |   44 
> +-
>  drivers/phy/phy-mvebu-sata.c |  137 
> +++
>  4 files changed, 175 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/phy/phy-mvebu-sata.c
> 

--
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 Jan 8

[Stephen Rothwell]

Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140107:

Dropped tree: sh (complex merge conflicts against very old commits)

The powerpc tree still had its build failure.

The drm tree gained a conflict against the drm-intel-fixes tree.

The gpio tree gained a conflict against the xtensa tree.

Non-merge commits (relative to Linus' tree): 7094
 6958 files changed, 347730 insertions(+), 174974 deletions(-)



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 (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 29 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 (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
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 (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (1e01c7eb7c43 ARC: Allow conditional multiple 
inclusion of uapi/asm/unistd.h)
Merging arm-current/fixes (0a5ccc86507f ARM: 7933/1: rename ioremap_cached to 
ioremap_cache)
Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated 
IRQF_DISABLED)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (f991db1cf1bd Merge remote-tracking branch 
'agust/merge' into merge)
Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging net/master (732256b9335f tipc: correctly unlink packets from deferred 
packet queue)
Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in 
dccp_probe init)
Merging sound-current/for-linus (150116bcfbd9 ALSA: hiface: Fix typo in 352800 
rate definition)
Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, 
Armada, R-Car PCI host maintainers)
Merging wireless/master (e46316c86ee6 Merge branch 'for-john' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5)
Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5)
Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5)
Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5)
Merging char-misc.current/char-misc-linus (319e2e3f63c3 Linux 3.13-rc4)
Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for 
Logitech F310 and F710)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile 
error)
Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary 
pci_set_drvdata())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros 
to inline functions)
Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL 
dereference in unflatten_and_copy())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm

Re: [RFC Patch Part2 V1 14/14] iommu/vt-d: update IOMMU state when memory hotplug happens

[Kai Huang]

On Tue, Jan 7, 2014 at 5:00 PM, Jiang Liu  wrote:
> If static identity domain is created, IOMMU driver needs to update
> si_domain page table when memory hotplug event happens. Otherwise
> PCI device DMA operations can't access the hot-added memory regions.
>
> Signed-off-by: Jiang Liu 
> ---
>  drivers/iommu/intel-iommu.c |   52 
> ++-
>  1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 83e3ed4..35a987d 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3689,6 +3690,54 @@ static struct notifier_block device_nb = {
> .notifier_call = device_notifier,
>  };
>
> +static int intel_iommu_memory_notifier(struct notifier_block *nb,
> +  unsigned long val, void *v)
> +{
> +   struct memory_notify *mhp = v;
> +   unsigned long long start, end;
> +   struct iova *iova;
> +
> +   switch (val) {
> +   case MEM_GOING_ONLINE:
> +   start = mhp->start_pfn << PAGE_SHIFT;
> +   end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
> +   if (iommu_domain_identity_map(si_domain, start, end)) {
> +   pr_warn("dmar: failed to build identity map for 
> [%llx-%llx]\n",
> +   start, end);
> +   return NOTIFY_BAD;
> +   }

Better to use iommu_prepare_identity_map? For si_domain, if
hw_pass_through is used, there's no page table.

> +   break;
> +   case MEM_OFFLINE:
> +   case MEM_CANCEL_ONLINE:
> +   /* TODO: enhance RB-tree and IOVA code to support of 
> splitting iova */
> +   iova = find_iova(_domain->iovad, mhp->start_pfn);
> +   if (iova) {
> +   unsigned long start_pfn, last_pfn;
> +   struct dmar_drhd_unit *drhd;
> +   struct intel_iommu *iommu;
> +
> +   start_pfn = mm_to_dma_pfn(iova->pfn_lo);
> +   last_pfn = mm_to_dma_pfn(iova->pfn_hi + 1) - 1;
> +   dma_pte_clear_range(si_domain, start_pfn, last_pfn);
> +   dma_pte_free_pagetable(si_domain, start_pfn, 
> last_pfn);
> +   rcu_read_lock();
> +   for_each_active_iommu(iommu, drhd)
> +   iommu_flush_iotlb_psi(iommu, si_domain->id,
> +   start_pfn, last_pfn - start_pfn + 1, 
> 0);
> +   rcu_read_unlock();
> +   __free_iova(_domain->iovad, iova);
> +   }

The same as above. Looks we need to consider hw_pass_through for the si_domain.

-Kai

> +   break;
> +   }
> +
> +   return NOTIFY_OK;
> +}
> +
> +static struct notifier_block intel_iommu_memory_nb = {
> +   .notifier_call = intel_iommu_memory_notifier,
> +   .priority = 0
> +};
> +
>  int __init intel_iommu_init(void)
>  {
> int ret = -ENODEV;
> @@ -3761,8 +3810,9 @@ int __init intel_iommu_init(void)
> init_iommu_pm_ops();
>
> bus_set_iommu(_bus_type, _iommu_ops);
> -
> bus_register_notifier(_bus_type, _nb);
> +   if (si_domain)
> +   register_memory_notifier(_iommu_memory_nb);
>
> intel_iommu_enabled = 1;
>
> --
> 1.7.10.4
>
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
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: [PATCHv9 2/4] ARM: dts: Add Freescale FTM PWM node for VF610.

[li.xi...@freescale.com]

> Has the FTM PWM device tree bindings been accepted/merged?  Please only
> send me DTS changes after that.  Also when you send me the DTS changes,
> please base on imx/dt or for-next branch of my git tree below.
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git
> 

Yes, I will resend these dt patches after the FTM driver has been merged
bases on this tree.

Thanks,

Xiubo
--
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] pwm: core: Use devm_kzalloc instead of kzalloc

[li.xi...@freescale.com]

> >  drivers/pwm/core.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> > index 2ca9504..74c9f9a 100644
> > --- a/drivers/pwm/core.c
> > +++ b/drivers/pwm/core.c
> > @@ -80,7 +80,6 @@ static void free_pwms(struct pwm_chip *chip)
> >
> > bitmap_clear(allocated_pwms, chip->base, chip->npwm);
> >
> > -   kfree(chip->pwms);
> > chip->pwms = NULL;
> >  }
> >
> > @@ -245,7 +244,9 @@ int pwmchip_add(struct pwm_chip *chip)
> > if (ret < 0)
> > goto out;
> >
> > -   chip->pwms = kzalloc(chip->npwm * sizeof(*pwm), GFP_KERNEL);
> > +   chip->pwms = devm_kzalloc(chip->dev,
> > + chip->npwm * sizeof(*pwm),
> > + GFP_KERNEL);
> > if (!chip->pwms) {
> > ret = -ENOMEM;
> > goto out;
> 
> Is it guaranteed that pwmchip_add()/free_pwms() will only be called in
> probe() and remove() paths? It is probably safe assumption, but maybe it
> should be mentioned in comments now that we definitely have this
> restricion.
>

Yes, for now they are.
 
Thanks.

--
Best Regards,
Xiubo
--
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] lib/percpu_counter.c: disable local irq when updating percpu couter

[Ming Lei]

On Wed, Jan 8, 2014 at 11:29 AM, Ming Lei  wrote:
> Hi Andrew,
>
> On Wed, Jan 8, 2014 at 9:36 AM, Andrew Morton  
> wrote:
>>> I am wondering if the above patch is more efficient, because:
>>>
>>> - raw_local_irq_save()/raw_local_irq_restore() should be cheaper
>>> than preempt_enable() in theory
>>
>> Don't think so - local_irq_disable() requires quite some internal
>> synchronization in the CPU and is expensive.  preempt_disable() is just
>
> Yes, it might be a little expensive on some CPUs, but should be
> arch-dependent(CPU inside things are involved)
>
>> an add+barrier, minus the add if the kernel is non-preemptable.
>
> IMO, generally, from software view, local_irq_save() only save the
> CPU's interrupt mask to the local variable 'flag', and sets irq mask
> to register, considered local variable can be thought to be in cache,
> so I think it might be cheaper than preempt_enable() because
> preempt counter may not be in cache.
>
> Also this_cpu_add() won't work in batch path(slow path), we still
> need to avoid interrupt coming between reading the percpu counter
> and resetting it, otherwise counts might be lost too, :-)

Sorry, I miss the __this_cpu_sub() in slow path, so it is correct, and
even preempt_enable() and preempt_disable() can be removed.


Thanks,
-- 
Ming Lei
--
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 V7] ARM : unwinder : Prevent data abort due to stack overflow

[Anurag Aggarwal]

While unwinding backtrace, stack overflow is possible. This stack
overflow can sometimes lead to data abort in system if the area after
stack is not mapped to physical memory.

To prevent this problem from happening, execute the instructions that
can cause a data abort in separate helper functions, where a check for
feasibility is made before reading each word from the stack.

Signed-off-by: Anurag Aggarwal 
Reviewed-by: Dave Martin 
---
 arch/arm/kernel/unwind.c |  137 +-
 1 file changed, 100 insertions(+), 37 deletions(-)

diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..3c21769 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -68,6 +68,12 @@ EXPORT_SYMBOL(__aeabi_unwind_cpp_pr2);
 struct unwind_ctrl_block {
unsigned long vrs[16];  /* virtual register set */
const unsigned long *insn;  /* pointer to the current instructions 
word */
+   unsigned long sp_high;  /* highest value of sp allowed */
+   /*
+* 1 : check for stack overflow for each register pop.
+* 0 : save overhead if there is plenty of stack remaining.
+*/
+   int check_each_pop;
int entries;/* number of entries left to interpret 
*/
int byte;   /* current byte number in the 
instructions word */
 };
@@ -235,12 +241,85 @@ static unsigned long unwind_get_byte(struct 
unwind_ctrl_block *ctrl)
return ret;
 }
 
+/* Before poping a register check whether it is feasible or not */
+static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
+   unsigned long **vsp, unsigned int reg)
+{
+   if (unlikely(ctrl->check_each_pop))
+   if (*vsp >= (unsigned long *)ctrl->sp_high)
+   return -URC_FAILURE;
+
+   ctrl->vrs[reg] = *(*vsp)++;
+   return URC_OK;
+}
+
+/* Helper functions to execute the instructions */
+static int unwind_exec_pop_subset_r4_to_r13(struct unwind_ctrl_block *ctrl,
+   unsigned long mask)
+{
+   unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+   int load_sp, reg = 4;
+
+   load_sp = mask & (1 << (13 - 4));
+   while (mask) {
+   if (mask & 1)
+   if (unwind_pop_register(ctrl, , reg))
+   return -URC_FAILURE;
+   mask >>= 1;
+   reg++;
+   }
+   if (!load_sp)
+   ctrl->vrs[SP] = (unsigned long)vsp;
+
+   return URC_OK;
+}
+
+static int unwind_exec_pop_r4_to_rN(struct unwind_ctrl_block *ctrl,
+   unsigned long insn)
+{
+   unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+   int reg;
+
+   /* pop R4-R[4+bbb] */
+   for (reg = 4; reg <= 4 + (insn & 7); reg++)
+   if (unwind_pop_register(ctrl, , reg))
+   return -URC_FAILURE;
+
+   if (insn & 0x80)
+   if (unwind_pop_register(ctrl, , 14))
+   return -URC_FAILURE;
+
+   ctrl->vrs[SP] = (unsigned long)vsp;
+
+   return URC_OK;
+}
+
+static int unwind_exec_pop_subset_r0_to_r3(struct unwind_ctrl_block *ctrl,
+   unsigned long mask)
+{
+   unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+   int reg = 0;
+
+   /* pop R0-R3 according to mask */
+   while (mask) {
+   if (mask & 1)
+   if (unwind_pop_register(ctrl, , reg))
+   return -URC_FAILURE;
+   mask >>= 1;
+   reg++;
+   }
+   ctrl->vrs[SP] = (unsigned long)vsp;
+
+   return URC_OK;
+}
+
 /*
  * Execute the current unwind instruction.
  */
 static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
 {
unsigned long insn = unwind_get_byte(ctrl);
+   int ret = URC_OK;
 
pr_debug("%s: insn = %08lx\n", __func__, insn);
 
@@ -250,8 +329,6 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
ctrl->vrs[SP] -= ((insn & 0x3f) << 2) + 4;
else if ((insn & 0xf0) == 0x80) {
unsigned long mask;
-   unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
-   int load_sp, reg = 4;
 
insn = (insn << 8) | unwind_get_byte(ctrl);
mask = insn & 0x0fff;
@@ -261,29 +338,16 @@ static int unwind_exec_insn(struct unwind_ctrl_block 
*ctrl)
return -URC_FAILURE;
}
 
-   /* pop R4-R15 according to mask */
-   load_sp = mask & (1 << (13 - 4));
-   while (mask) {
-   if (mask & 1)
-   ctrl->vrs[reg] = *vsp++;
-   mask >>= 1;
-   reg++;
-   }
-   if (!load_sp)
-   

Re: [PATCH] powerpc: Fix alignment of secondary cpu spin vars

[Benjamin Herrenschmidt]

On Wed, 2014-01-08 at 15:09 +1100, Michael Ellerman wrote:
> > Of course, main worry is that this is just hiding some latent NULL
> deref in
> > the kernel now... :-/
> 
> Wow, that would have to come close to winning the
> grossest-hack-in-arch-powerpc
> award :)
> 
> Have you tried changing the value at 8 to point to a reserved page?
> 
> Some other possibilities:
> 
>  * Change the #define so FIXUP_ENDIAN is empty for PASEMI, that would
> mean
>you'd only be able to boot pasemi_defconfig.
>  * Move the hack into FIXUP_ENDIAN

We actually found the root cause on irc the other day, I was waiting for
Olof to send a fix :-)

Olof: Can you try this totally untested patch ?

--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1986,8 +1986,6 @@ static void __init prom_init_stdout(void)
/* Get the full OF pathname of the stdout device */
memset(path, 0, 256);
call_prom("instance-to-path", 3, 1, prom.stdout, path, 255);
-   stdout_node = call_prom("instance-to-package", 1, 1, prom.stdout);
-   val = cpu_to_be32(stdout_node);
prom_setprop(prom.chosen, "/chosen", "linux,stdout-package",
 , sizeof(val));
prom_printf("OF stdout device is: %s\n", of_stdout_device);
@@ -1995,10 +1993,14 @@ static void __init prom_init_stdout(void)
 path, strlen(path) + 1);
 
/* If it's a display, note it */
-   memset(type, 0, sizeof(type));
-   prom_getprop(stdout_node, "device_type", type, sizeof(type));
-   if (strcmp(type, "display") == 0)
-   prom_setprop(stdout_node, path, "linux,boot-display", NULL, 0);
+   stdout_node = call_prom("instance-to-package", 1, 1, prom.stdout);
+   if (stdout_node != PROM_ERROR) {
+   val = cpu_to_be32(stdout_node);
+   memset(type, 0, sizeof(type));
+   prom_getprop(stdout_node, "device_type", type, sizeof(type));
+   if (strcmp(type, "display") == 0)
+   prom_setprop(stdout_node, path, "linux,boot-display", NU
+   }
 }


--
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/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Jan 08, 2014 at 03:49:07AM +, Tang, Jianqiang wrote:
> Hi,
>  1) I met this issue one time just boot up our Linux Platform(Kernel3.10) 
> with XHCI driver, then kernel panic happen.
> 
>And this issue reported once by other internal team.
> 
>Nothing special of reproduce step and do not need special Hardware I think.
> 
>Just random issue which will happen when meet the timing condition.
> 
>  2) This issue is introduced by this patch:
> 
>  
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=596d789a211d134dc5f94d1e5957248c204ef850
> 
>which set all hub autosuspend delay to 0.

That patch was released in a kernel almost a full year ago, yet we have
never had a report of this happening before, so are you sure this patch
is the root cause?

>This causes race condition during XHCI driver initialization,
> 
> After USB2 hcd and USB2 root hub finish the initialization, USB2 root hub 
> is functional and auto suspend right now, hence trigger XHCI runtime suspend 
> flow;
> 
> At the same time, XHCI driver continue to initialize the USB3 hcd and 
> assign to xhci->shared_hcd after finish the initialization;
> 
> Since xhci_suspend() use the xhci->shared_hcd, so there is race condition 
> that when XHCI runtime suspend called, xhci->shared_hcd still NULL.
> 
> I think this patch is a fix solution since before XHCI finish the whole 
> initialization, USB2 root hub triggered runtime suspend is mean less and do 
> not need to handle.

With this patch applied, does the crash go away?

--
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: [PATCHv9 02/20] thermal: introduce device tree parser

[Wei Ni]

On 01/08/2014 11:24 AM, Hu Yaohui wrote:
> I am new here. How can I could not mail a new message to this mail list?
> TIA

I use Thunderbird, it's a pretty good mail client :)

> 
> 
> On Tue, Jan 7, 2014 at 10:19 PM, Wei Ni  > wrote:
> 
> On 01/07/2014 07:17 PM, Eduardo Valentin wrote:
> > * PGP Signed by an unknown key
> >
> > On 06-01-2014 22:48, Wei Ni wrote:
> >> Hi, Eduardo
> >> Will you consider my comments :)
> >
> > By now Wei, it is better if you start a new thread, by sending a patch
> > on top of it, as this thread has been already merged by Rui.
> 
> Ok, I will send it.
> 
> Thanks.
> Wei.
> >
> >>
> >> Thanks.
> >> Wei.
> >>
> >> On 12/31/2013 06:17 PM, Wei Ni wrote:
> >>> On 11/13/2013 03:46 AM, Eduardo Valentin wrote:
>  This patch introduces a device tree bindings for
>  describing the hardware thermal behavior and limits.
>  Also a parser to read and interpret the data and feed
>  it in the thermal framework is presented.
> 
>  This patch introduces a thermal data parser for device
>  tree. The parsed data is used to build thermal zones
>  and thermal binding parameters. The output data
>  can then be used to deploy thermal policies.
> 
>  This patch adds also documentation regarding this
>  API and how to define tree nodes to use
>  this infrastructure.
> 
>  Note that, in order to be able to have control
>  on the sensor registration on the DT thermal zone,
>  it was required to allow changing the thermal zone
>  .get_temp callback. For this reason, this patch
>  also removes the 'const' modifier from the .ops
>  field of thermal zone devices.
> 
>  ...
>  +
>  +static int of_thermal_get_trend(struct thermal_zone_device
> *tz, int trip,
>  +  enum thermal_trend *trend)
>  +{
>  +  struct __thermal_zone *data = tz->devdata;
>  +  long dev_trend;
>  +  int r;
>  +
>  +  if (!data->get_trend)
>  +  return -EINVAL;
>  +
>  +  r = data->get_trend(data->sensor_data, _trend);
> >>> I think the ->get_trend should be defined as:
> >>> .get_trend(*dev, int, *long)
> >>> so that the "trip" can be passed into it, otherwise the "trip"
> can't be
> >>> used.
> >>> And the dev_trend should be returned as THERMAL_TREND_XXX directly.
> >>> because the THERM_TREND_xx is more than three states.
> >>>
> >>> The code may be something like:
> >>> r = data->get_trend(data->sensor_data, trip, _trend);
> >>> if (r)
> >>> return r;
> >>> *trend = dev_trend;
> >>> return 0;
>  +  if (r)
>  +  return r;
>  +
>  +  /* TODO: These intervals might have some thresholds, but in
> core code */
>  +  if (dev_trend > 0)
>  +  *trend = THERMAL_TREND_RAISING;
>  +  else if (dev_trend < 0)
>  +  *trend = THERMAL_TREND_DROPPING;
>  +  else
>  +  *trend = THERMAL_TREND_STABLE;
>  +
>  +  return 0;
>  +}
>  +
>  .
>  +
>  +/***   sensor API   ***/
>  +
>  +static struct thermal_zone_device *
>  +thermal_zone_of_add_sensor(struct device_node *zone,
>  + struct device_node *sensor, void *data,
>  + int (*get_temp)(void *, long *),
>  + int (*get_trend)(void *, long *))
>  +{
>  +  struct thermal_zone_device *tzd;
>  +  struct __thermal_zone *tz;
>  +
>  +  tzd = thermal_zone_get_zone_by_name(zone->name);
> >>> I think we could get the thermal zone by node,
> >>> something like:
> >>> thermal_zone_get_zone_by_node(zone);
> >>> so that it can get unique zone.
> >>>
> >>> I think we can add a member "struct device_node *np" in the
> >>> thermal_zone_device,
> >>> and set it after you call thermal_zone_device_register successfully.
> >>> Then add following codes:
> >>> thermal_zone_get_zone_by_node(struct device_node *node)
> >>> {
> >>> struct thermal_zone_device *pos = NULL, *ref =
> ERR_PTR(-ENODEV);
> >>> bool found = false;
> >>>
> >>> if (!node)
> >>> return ERR_PTR(-EINVAL);
> >>>
> >>> mutex_lock(_list_lock);
> >>> list_for_each_entry(pos, _tz_list, node)
> >>> if (node == pos->np) {
> >>> ref = pos;
> >>> found = true;
> >>> break;
> >>> }
> >>> mutex_unlock(_list_lock);
> >>>

linux-next: manual merge of the gpio tree with the xtensa tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the gpio tree got a conflict in
arch/xtensa/Kconfig between commit dbacef090841 ("xtensa: add SMP
support") from the xtensa tree and commit a1a2bdec4772 ("gpio: xtensa:
depend on HAVE_XTENSA_GPIO32") from the gpio tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/xtensa/Kconfig
index 70a160be3464,f8df0cc70cb6..
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@@ -64,9 -64,9 +64,12 @@@ config MM
  config VARIANT_IRQ_SWITCH
def_bool n
  
 +config MAY_HAVE_SMP
 +  def_bool n
 +
+ config HAVE_XTENSA_GPIO32
+   def_bool n
+ 
  menu "Processor type and features"
  
  choice


pgpfluchw2fSn.pgp
Description: PGP signature

Re: [PATCH] powerpc: Fix alignment of secondary cpu spin vars

[Michael Ellerman]

On Fri, 2014-01-03 at 00:12 -0800, Olof Johansson wrote:
> On Thu, Jan 02, 2014 at 11:56:04PM -0800, Olof Johansson wrote:
> 
> > This makes things interesting though. The BE/LE trampoline code
> > assumes at least 3 consecutive instructions. What was the reasoning
> > behind entering the kernel LE instead of keeping the old boot protocol
> > and just switching to LE once kernel is loaded? Is it actually used on
> > some platforms or is this just a theoretical thing?
> 
> Actually, adding a little hack that zeroes out the memory once we're done
> executing it will work just fine too. I know this is sort of icky, but maybe
> it'll be good enough for now?
> 
> Of course, main worry is that this is just hiding some latent NULL deref in
> the kernel now... :-/

Wow, that would have to come close to winning the grossest-hack-in-arch-powerpc
award :)

Have you tried changing the value at 8 to point to a reserved page?

Some other possibilities:

 * Change the #define so FIXUP_ENDIAN is empty for PASEMI, that would mean
   you'd only be able to boot pasemi_defconfig.
 * Move the hack into FIXUP_ENDIAN

cheers


--
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] mm: free memblock.memory in free_all_bootmem

[Jianguo Wu]

On 2014/1/7 23:16, Philipp Hachtmann wrote:

> When calling free_all_bootmem() the free areas under memblock's
> control are released to the buddy allocator. Additionally the
> reserved list is freed if it was reallocated by memblock.
> The same should apply for the memory list.
> 
> Signed-off-by: Philipp Hachtmann 
> ---
>  include/linux/memblock.h |  1 +
>  mm/memblock.c| 12 
>  mm/nobootmem.c   |  7 ++-
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 77c60e5..d174922 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -52,6 +52,7 @@ phys_addr_t memblock_find_in_range_node(phys_addr_t start, 
> phys_addr_t end,
>  phys_addr_t memblock_find_in_range(phys_addr_t start, phys_addr_t end,
>  phys_addr_t size, phys_addr_t align);
>  phys_addr_t get_allocated_memblock_reserved_regions_info(phys_addr_t *addr);
> +phys_addr_t get_allocated_memblock_memory_regions_info(phys_addr_t *addr);
>  void memblock_allow_resize(void);
>  int memblock_add_node(phys_addr_t base, phys_addr_t size, int nid);
>  int memblock_add(phys_addr_t base, phys_addr_t size);
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 53e477b..1a11d04 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -271,6 +271,18 @@ phys_addr_t __init_memblock 
> get_allocated_memblock_reserved_regions_info(
> memblock.reserved.max);
>  }
>  
> +phys_addr_t __init_memblock get_allocated_memblock_memory_regions_info(
> + phys_addr_t *addr)
> +{
> + if (memblock.memory.regions == memblock_memory_init_regions)
> + return 0;
> +
> + *addr = __pa(memblock.memory.regions);
> +
> + return PAGE_ALIGN(sizeof(struct memblock_region) *
> +   memblock.memory.max);
> +}
> +
>  /**
>   * memblock_double_array - double the size of the memblock regions array
>   * @type: memblock type of the regions array being doubled
> diff --git a/mm/nobootmem.c b/mm/nobootmem.c
> index 3a7e14d..83f36d3 100644
> --- a/mm/nobootmem.c
> +++ b/mm/nobootmem.c
> @@ -122,11 +122,16 @@ static unsigned long __init 
> free_low_memory_core_early(void)
>   for_each_free_mem_range(i, MAX_NUMNODES, , , NULL)
>   count += __free_memory_core(start, end);
>  
> - /* free range that is used for reserved array if we allocate it */
> + /* Free memblock.reserved array if it was allocated */
>   size = get_allocated_memblock_reserved_regions_info();
>   if (size)
>   count += __free_memory_core(start, start + size);
>  
> + /* Free memblock.memory array if it was allocated */
> + size = get_allocated_memblock_memory_regions_info();
> + if (size)
> + count += __free_memory_core(start, start + size);
> +

Hi Philipp,

For some archs, like arm64, would use memblock.memory after system booting,
so we can not simply released to the buddy allocator, maybe need 
!defined(CONFIG_ARCH_DISCARD_MEMBLOCK).

#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
return memblock_is_memory(pfn << PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);

Thanks,
Jianguo Wu

>   return count;
>  }
>  



--
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 0/2] gpio: davinci: reuse for keystone arch

[Sekhar Nori]

On Tuesday 07 January 2014 11:22 PM, Santosh Shilimkar wrote:
> Sekhar,
> 
> On Tuesday 24 December 2013 06:41 AM, Grygorii Strashko wrote:
>> This series is intended to update Davinci GPIO driver and reuse
>> it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
>> Keystone GPIO IP: supports:
>> - up to 32 GPIO lines;
>> - only unbanked irqs;
>>
>> See Documentation:
>> Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> This series based on:
>> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio
>>
>> Changes in v3:
>> - fixed code, changed by mistake; fixed sparse warning 
>> Changes in v2:
>> - minor comments applied, no functional changes
>>
>> v2: https://lkml.org/lkml/2013/12/18/135
>> v1: https://lkml.org/lkml/2013/12/12/366
>>
>> Cc: Linus Walleij 
>> Cc: Alexandre Courbot 
>> Cc: Sekhar Nori 
>> Cc: Santosh Shilimkar 
>>
>> Grygorii Strashko (2):
>>   gpio: davinci: don't create irq_domain in case of unbanked irqs
>>   gpio: davinci: reuse for Keystone SoC
>>
>>  .../devicetree/bindings/gpio/gpio-davinci.txt  |4 +-
>>  drivers/gpio/gpio-davinci.c|   82 
>> ++--
>>  2 files changed, 61 insertions(+), 25 deletions(-)
>>
> Have you picked up the $subject series in your queue ?

Not yet, at least on the new compatible introduction, I need an ack from
DT folks.

I am happy with the patches though and have tested them as well, In case
I do not get an ack from 2/2 in time, I can at least send 1/2 for
inclusion after my first gpio pull request to ARM-SoC gets pulled.

Thanks,
Sekhar

--
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/5] tools lib traceevent: Add state member to struct trace_seq

[Namhyung Kim]

Hi Jiri,

On Tue, 7 Jan 2014 14:05:58 +0100, Jiri Olsa wrote:
> On Tue, Jan 07, 2014 at 12:00:09PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>>  void trace_seq_init(struct trace_seq *s);
>> diff --git a/tools/lib/traceevent/trace-seq.c 
>> b/tools/lib/traceevent/trace-seq.c
>> index d7f2e68bc5b9..1747aa50ecb0 100644
>> --- a/tools/lib/traceevent/trace-seq.c
>> +++ b/tools/lib/traceevent/trace-seq.c
>> @@ -32,8 +32,9 @@
>>  #define TRACE_SEQ_POISON((void *)0xdeadbeef)
>>  #define TRACE_SEQ_CHECK(s)  \
>>  do {
>> \
>> -if ((s)->buffer == TRACE_SEQ_POISON)\
>> -die("Usage of trace_seq after it was destroyed");   \
>> +if (WARN_ONCE((s)->buffer == TRACE_SEQ_POISON,  \
>> +  "Usage of trace_seq after it was destroyed")) \
>> +(s)->state = TRACE_SEQ__BUFFER_POISONED;\
>>  } while (0)
>>  
>>  /**
>> @@ -46,6 +47,7 @@ void trace_seq_init(struct trace_seq *s)
>>  s->readpos = 0;
>>  s->buffer_size = TRACE_SEQ_BUF_SIZE;
>>  s->buffer = malloc_or_die(s->buffer_size);
>> +s->state = TRACE_SEQ__GOOD;
>>  }
>>  
>>  /**
>> @@ -81,7 +83,7 @@ static void expand_buffer(struct trace_seq *s)
>>  s->buffer_size += TRACE_SEQ_BUF_SIZE;
>>  s->buffer = realloc(s->buffer, s->buffer_size);
>>  if (!s->buffer)
>> -die("Can't allocate trace_seq buffer memory");
>> +s->state = TRACE_SEQ__MEM_ALLOC_FAILED;
>
> and also here?
>
>   if (WARN_ONCE(!s->buffer))
>   s->state = TRACE_SEQ__MEM_ALLOC_FAILED;

Ah, will fix.

>
> otherwise the whole series seems ok,

Thanks for your review!
Namhyung
--
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] usbcore: fix BABBLE failed enumeration of legacy USB2 devices on USB3 bus

[Marius Silaghi]

Great observation,
Sarah located a patch that is queued for the 3.14 kernel and that has a similar 
effect. So future kernels could work with that one as well.

The patch I provided (being very small and safe) can still be suggested for 
maintainers of older kernels in various long-term maintained distributions (if 
you know who is doing that).

Here are some versions of the patch I made for current kernels:

The next one was tested on Ubuntu, applied to the source for 3.5.0-17-generic 
(Ubuntu)

--- linux-3.5.0/drivers/usb/core/hub.c.orig 2014-01-07 18:16:01.997031650 
-0500
+++ linux-3.5.0/drivers/usb/core/hub.c  2014-01-07 18:19:41.617022465 -0500
@@ -4043,7 +4043,11 @@
break;
}
 
-   retval = usb_get_device_descriptor(udev, 8);
+   if (!USE_NEW_SCHEME(retry_counter))
+ retval = usb_get_device_descriptor(udev, 8);
+   else
+ retval = usb_get_device_descriptor(udev,
+   sizeof(struct usb_device_descriptor));
if (retval < 8) {
dev_err(>dev,
"device descriptor read/8, error %d\n",



For kernel 3.9.0-0.4

--- linux-3.5.0/drivers/usb/core/hub.c.orig 2014-01-07 18:16:01.997031650 
-0500
+++ linux-3.5.0/drivers/usb/core/hub.c  2014-01-07 18:19:41.617022465 -0500
@@ -4043,7 +4043,11 @@
break;
}
 
-   retval = usb_get_device_descriptor(udev, 8);
+   if (!USE_NEW_SCHEME(retry_counter))
+ retval = usb_get_device_descriptor(udev, 8);
+   else
+ retval = usb_get_device_descriptor(udev,
+   sizeof(struct usb_device_descriptor));
if (retval < 8) {
dev_err(>dev,
"device descriptor read/8, error %d\n",



For kernel 3.10.0-5.15

--- ubuntu-saucy/drivers/usb/core/hub.c.orig2014-01-07 16:52:41.300835262 
-0500
+++ ubuntu-saucy/drivers/usb/core/hub.c 2014-01-07 16:54:53.612829730 -0500
@@ -4126,8 +4126,11 @@
if (USE_NEW_SCHEME(retry_counter) && 
!(hcd->driver->flags & HCD_USB3))
break;
}
-
-   retval = usb_get_device_descriptor(udev, 8);
+   if (!USE_NEW_SCHEME(retry_counter))
+ retval = usb_get_device_descriptor(udev, 8);
+   else
+ retval = usb_get_device_descriptor(udev,
+   sizeof(struct usb_device_descriptor));
if (retval < 8) {
if (retval != -ENODEV)
dev_err(>dev,


For kernel 3.11
--- linux-3.11/drivers/usb/core/hub.c.orig  2014-01-07 16:57:16.352823760 
-0500
+++ linux-3.11/drivers/usb/core/hub.c   2014-01-07 16:58:10.168821508 -0500
@@ -4161,7 +4161,11 @@
break;
}
 
-   retval = usb_get_device_descriptor(udev, 8);
+   if (!USE_NEW_SCHEME(retry_counter))
+ retval = usb_get_device_descriptor(udev, 8);
+   else
+ retval = usb_get_device_descriptor(udev,
+   sizeof(struct usb_device_descriptor));
if (retval < 8) {
if (retval != -ENODEV)
dev_err(>dev,



From: linux-usb-ow...@vger.kernel.org [linux-usb-ow...@vger.kernel.org] on 
behalf of Greg Kroah-Hartman [gre...@linuxfoundation.org]
Sent: Tuesday, January 07, 2014 19:32
To: Marius  Silaghi
Cc: Sarah Sharp; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Alan 
Stern; Lan Tianyu; Xenia Ragiadakou; Jiri Kosina
Subject: Re: [PATCH] usbcore: fix BABBLE failed enumeration of legacy USB2 
devices on USB3 bus

On Tue, Dec 24, 2013 at 04:19:18AM +, Marius  Silaghi wrote:
> From: Marius C Silaghi 
>
> This patch is generated against the last kernel version in the github kernel 
> repository.

We work off of the git.kernel.org trees, not github :)


> Some older families of USB2 cameras (STC-XUSB) do not support querying 
> only the first 8 bytes of their
> device descriptor and therefore fail at enumeration on USB3 HCDs, with babble 
> error -75 as they send more than
> the expected 8 bytes. The proposed patch extends the mechanism used for non 
> USB3 HCDs in the first part of
> the same function, and  successively tries to query both the 8 byte prefix of 
> the device descriptor, as well as
> the whole device descriptor (in case the old style query of the 8 byte prefix 
> fails).
> In fact, for the cameras I try to fix, the preferred condition is the 
> negation of the one in the proposed patch,
> "if 

Re: [RFC] mm: show message when updating min_free_kbytes in thp

[Han Pingtian]

On Mon, Jan 06, 2014 at 05:46:04PM +0100, Michal Hocko wrote:
> On Sun 05-01-14 08:35:01, Han Pingtian wrote:
> [...]
> > From f4d085a880dfae7638b33c242554efb0afc0852b Mon Sep 17 00:00:00 2001
> > From: Han Pingtian 
> > Date: Fri, 3 Jan 2014 11:10:49 +0800
> > Subject: [PATCH] mm: show message when raising min_free_kbytes in THP
> > 
> > min_free_kbytes may be raised during THP's initialization. Sometimes,
> > this will change the value being set by user. Showing message will
> > clarify this confusion.
> 
> I do not have anything against informing about changing value
> set by user but this will inform also when the default value is
> updated. Is this what you want? Don't you want to check against
> user_min_free_kbytes? (0 if not set by user)
> 
But looks like the user can set min_free_kbytes to 0 by

echo 0 > /proc/sys/vm/min_free_kbytes

and even set it to -1 the same way. So I think we need to restrict the
value of min_free_kbytes > 0 first?

> Btw. Do we want to restore the original value when khugepaged is
> disabled?
> 

--
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/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

[Tang, Jianqiang]

Hi,
 1) I met this issue one time just boot up our Linux Platform(Kernel3.10) with 
XHCI driver, then kernel panic happen.

   And this issue reported once by other internal team.

   Nothing special of reproduce step and do not need special Hardware I think.

   Just random issue which will happen when meet the timing condition.

 2) This issue is introduced by this patch:

 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=596d789a211d134dc5f94d1e5957248c204ef850

   which set all hub autosuspend delay to 0.

   This causes race condition during XHCI driver initialization,

After USB2 hcd and USB2 root hub finish the initialization, USB2 root hub 
is functional and auto suspend right now, hence trigger XHCI runtime suspend 
flow;

At the same time, XHCI driver continue to initialize the USB3 hcd and 
assign to xhci->shared_hcd after finish the initialization;

Since xhci_suspend() use the xhci->shared_hcd, so there is race condition 
that when XHCI runtime suspend called, xhci->shared_hcd still NULL.

I think this patch is a fix solution since before XHCI finish the whole 
initialization, USB2 root hub triggered runtime suspend is mean less and do not 
need to handle.


Thanks!

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Wednesday, January 08, 2014 9:47 AM
To: David Cohen
Cc: st...@rowland.harvard.edu; sarah.a.sh...@linux.intel.com; 
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Tang, Jianqiang
Subject: Re: [RFC/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

On Tue, Jan 07, 2014 at 05:44:26PM -0800, David Cohen wrote:
> From: jianqian 
> 
> There is a possible kernel panic faced on xhci_suspend().
> Due to kernel modified the hub autosupend_delay to 0s, after usb1 root 
> hub finishes initialization, it will trigger runtime_suspend and then 
> it will trigger xhci runtime suspend. But at that time, if
> xhci->shared_hcd is still doing initialization, it is possible to face
> null pointer kernel panic in xhci_suspend() function.
> 
> This patch checks if xhci->shared_hcd is null to avoid panic.
> 
> Signed-off-by: jianqian 
> Signed-off-by: David Cohen 
> ---
> 
> This is the kernel panic. The bug was discovered on current LTS kernel 
> 3.10, as showed on logs. But the problem does not seem to be fixed so far.
> Maybe we should consider apply it on kernel >= 3.10?

How do you trigger this?  I've never seen anyone report this problem before, is 
there something different in the hardware you are using that enables this to be 
triggered easier?

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: [PATCH 3/4] tty/serial: at91: prevent null dereference in tasklet function

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Tue, Jan 07, 2014 at 08:52:34PM -0500, Mark Roszko wrote:
> This patch I was somewhat hesitant to pushing to Atmel when I did the other 
> two
> patches.

Then why did you?  :)

> The main issue is the use of systemd causes the serial driver to somehow get
> out of sync on startups randomly. i.e. on one bootup it's fine, and on other
> it'll kernel panic. 
> It occurs because systemd causes the startup and shutdown driver ops to be
> fired in rapid succession. 

How does systemd cause this?  Is this when the serial port is being used
as a console or something else?

> Every single service start message causes the _startup callback first, then 
> the
> message prints and _shutdown callbacks fires. 

So something is opening and closing the port quickly?  That should be
easy to test without systemd.

Any console involved?

> And a kernel panic always occurs somewhere during the service status output,
> never before when it's just the kernel startup and never after once systemd
> finishes and getty for example takes over. 
> 
> The stacktrace looked like this:
> Unable to handle kernel NULL pointer dereference at virtual address 0088
> pgd = c0004000
> [0088] *pgd=
> Internal error: Oops: 17 [#1] ARM
> Modules linked in: autofs4
> CPU: 0    Not tainted  (3.6.9-yocto-standard #1)

3.6.9 is _very_ old, loads of things have happened in the tty layer
since then, can you duplicate this on 3.12 or 3.13-rc?


> PC is at tty_wakeup+0x8/0x58
> LR is at atmel_tasklet_func+0x238/0x80c
> pc : []    lr : []    psr: a00f0013
> sp : df84ff28  ip :   fp : 0100
> r10: c05d1ec0  r9 : 04208040  r8 : c05d1e80
> r7 : 000a  r6 :   r5 : dedf7c00  r4 : 
> r3 : dedf7c00  r2 :   r1 : 600f0013  r0 : 
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c53c7d  Table: 3fb0c059  DAC: 0015
> Process ksoftirqd/0 (pid: 3, stack limit = 0xdf84e2f0)
> Stack: (0xdf84ff28 to 0xdf85)
> ff20:                   c05e4378 dedf7c00  c0208fc0 c05aa458 df8496b0
> ff40: df849680 c05aa458 df8496b0 c00394a8 c0039420 c05a8d04  
> ff60: 000a c05d1e80 04208040 c05d1ec0 0100 c001fd34 0009 0018
> ff80: df84e000 c001f60c df84ffbc c03f8e60 0013 0006  c05d1e80
> ffa0: df84e000  0013     c001f728
> ffc0: df84bf3c  c001f6c0 c0030870    
> ffe0: df84ffe0 df84ffe0 df84bf3c c00307f0 c000e348 c000e348 fff73fbf 3fbe
> [] (tty_wakeup+0x8/0x58) from [] 
> (atmel_tasklet_func+0x238/
> 0x80c)
> [] (atmel_tasklet_func+0x238/0x80c) from []
> (tasklet_action+0x70/0xa8)
> [] (tasklet_action+0x70/0xa8) from [] (__do_softirq+0x90/
> 0x144)
> [] (__do_softirq+0x90/0x144) from [] (run_ksoftirqd+0x68/
> 0x104)
> [] (run_ksoftirqd+0x68/0x104) from [] (kthread+0x80/0x90)
> [] (kthread+0x80/0x90) from [] 
> (kernel_thread_exit+0x0/0x8)
> Code: e8bd8070 c05ac0b8 e92d4070 e1a04000 (e5903088)
> ---[ end trace 15b8a9aeaf7b457f ]---
> 
> 
> Testing wise I originally used a BUG_ON statement in atmel_tasklet_func to
> panic before the null deference hit. BUG_ON confirmed that tty was NULL at the
> very start of the tasklet being called. 

And did you test that this patch actually fixed it?

> The atmel_shutdown function should be killing the tasklet (after patch "Handle
> shutdown more safely") and does disable interrupts so I've been at a loss at
> where the race condition was occurring that a tasklet could escape beyond
> shutdown.

Are you sure you aren't just racing with shutdown?  Need a lock
somewhere?

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/2] audit: print error message when fail to create audit socket

[Richard Guy Briggs]

On 14/01/08, Gao feng wrote:
> On 01/08/2014 08:53 AM, Andrew Morton wrote:
> > On Tue, 17 Dec 2013 11:10:41 +0800 Gao feng  wrote:
> > 
> >> print the error message and then return -ENOMEM.
> >>
> >> ...
> >>
> >> --- a/kernel/audit.c
> >> +++ b/kernel/audit.c
> >> @@ -1083,12 +1083,11 @@ static int __net_init audit_net_init(struct net 
> >> *net)
> >>pr_info("audit: initializing netlink socket in namespace\n");
> >>  
> >>aunet->nlsk = netlink_kernel_create(net, NETLINK_AUDIT, );
> >> -  if (aunet->nlsk == NULL)
> >> -  return -ENOMEM;
> >> -  if (!aunet->nlsk)
> >> +  if (aunet->nlsk == NULL) {
> >>audit_panic("cannot initialize netlink socket in namespace");
> >> -  else
> >> -  aunet->nlsk->sk_sndtimeo = MAX_SCHEDULE_TIMEOUT;
> >> +  return -ENOMEM;
> >> +  }
> >> +  aunet->nlsk->sk_sndtimeo = MAX_SCHEDULE_TIMEOUT;
> >>return 0;
> >>  }
> > 
> > What kernel version are these against?  Something ancient, I expect -
> > audit_net_init() doesn't exist.
> > 
> > Please check current kernels, redo and resend the patches if anything
> > needs changing?
> 
> This patch is against Richard Guy Briggs's audit tree. the current kernel
> doesn't have this problem.
> 
> BTW, Richard & Eric, when do you plan to push these changes to the upstream?
> there are a lot of changes in Richard's tree.

Planning for this merge window.

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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] lib/percpu_counter.c: disable local irq when updating percpu couter

[Ming Lei]

Hi Andrew,

On Wed, Jan 8, 2014 at 9:36 AM, Andrew Morton  wrote:
>> I am wondering if the above patch is more efficient, because:
>>
>> - raw_local_irq_save()/raw_local_irq_restore() should be cheaper
>> than preempt_enable() in theory
>
> Don't think so - local_irq_disable() requires quite some internal
> synchronization in the CPU and is expensive.  preempt_disable() is just

Yes, it might be a little expensive on some CPUs, but should be
arch-dependent(CPU inside things are involved)

> an add+barrier, minus the add if the kernel is non-preemptable.

IMO, generally, from software view, local_irq_save() only save the
CPU's interrupt mask to the local variable 'flag', and sets irq mask
to register, considered local variable can be thought to be in cache,
so I think it might be cheaper than preempt_enable() because
preempt counter may not be in cache.

Also this_cpu_add() won't work in batch path(slow path), we still
need to avoid interrupt coming between reading the percpu counter
and resetting it, otherwise counts might be lost too, :-)

Thanks,
-- 
Ming Lei
--
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 2/2] net: core: explicitly select a txq before doing l2 forwarding

[Jason Wang]

On 01/07/2014 09:17 PM, Neil Horman wrote:
> On Tue, Jan 07, 2014 at 11:42:24AM +0800, Jason Wang wrote:
>> On 01/06/2014 08:42 PM, Neil Horman wrote:
>>> On Mon, Jan 06, 2014 at 11:21:07AM +0800, Jason Wang wrote:
 Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). 
 The
 will cause several issues:

 - NETIF_F_LLTX was forced for macvlan device in this case which lead extra 
 lock
   contention.
 - dev_hard_start_xmit() was called with NULL txq which bypasses the net 
 device
   watchdog
 - dev_hard_start_xmit() does not check txq everywhere which will lead a 
 crash
   when tso is disabled for lower device.

 Fix this by explicitly introducing a select queue method just for l2 
 forwarding
 offload (ndo_dfwd_select_queue), and introducing dfwd_direct_xmit() to do 
 the
 queue selecting and transmitting for l2 forwarding.

 With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's 
 no need
 to check txq against NULL in dev_hard_start_xmit().

 In the future, it was also required for macvtap l2 forwarding support 
 since it
 provides a necessary synchronization method.

 Cc: John Fastabend 
 Cc: Neil Horman 
 Cc: e1000-de...@lists.sourceforge.net
 Signed-off-by: Jason Wang 
>>> Instead of creating another operation here to do special queue selection, 
>>> why
>>> not just have ndo_dfwd_start_xmit include a pointer to a pointer in its 
>>> argument
>>> list, so it can pass the txq it used back to the caller 
>>> (dev_hard_start_xmit)?
>>> ndo_dfwd_start_xmit already knows which queue set to pick from (since their
>>> reserved for the device doing the transmitting).  It seems more clear to me 
>>> than
>>> creating a new netdevice operation.  
>> See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
>> tx path"). The point is keep the tx path lockless to be efficient and
>> simplicity for management. And macvtap multiqueue was also implemented
>> with this assumption. The real contention should be done in the txq of
>> lower device instead of macvlan itself. This is also needed for
>> multiqueue macvtap.
> Ok, I see how you're preserving LLTX here, and thats great, but it doesn't
> really buy us anything that I can see.  If a macvlan is using hardware
> acceleration, it needs to arbitrate access to that hardware.  Weather thats 
> done
> by locking the lowerdev's tx queue lock or by enforcing locking on the macvlan
> itself is equivalent.  The decision to use dfwd hardware acceleration is made 
> on
> open, so its not like theres any traffic that can avoid the lock, as it all 
> goes
> through the hardware.  All I see that this has bought us is an extra 
> net_device
> method (which isn't a big deal, but not necessecary as I see it).

As I replied to patch 1/2, looking at the code itself again. The locking
on the lowerdev's tx queue is really need since we need synchronize with
other control path. Two examples are dev watchdog and ixgbe_down() both
of which will try to hold tx lock to synchronize the with transmission.
Without holding the lowerdev tx lock, we may have more serious issues.
Also, it's a little strange for a net device has two modes. Future
developers need to care about two different tx lock paths which is sub
optimal.

For the issue of an extra net_device method,  if you don't like we can
reuse the ndo_select_queue by also passing the accel_priv to that method.
>
> It seems like the right solution here is to use ethtool to disable the dfwd
> acceleration feature on the hardware if you don't want to incur the additional
> locking.
>
>>> As for the crash issue, I'm not sure what you mean.  Where in
>>> dev_hard_start_xmit would we need to check txq that we're not currently, and
>>> what crash results?
>> Well, see current dev_hard_start_xmit(), if lower device does not
>> support tso or tso is disabled, in gso path:
>>
>> gso:
>> ...
>> txq_trans_update(txq);
>> if (unlikely(netif_xmit_stopped(txq) && skb->next))
>>
>> There's an obvious NULL pointer dereference.
> Yeah, I saw that after I wrote my note, sorry about that.  However, it doesn't
> change what I said above.  i don't think theres a need to add an additional
> select_queue method here, just add a pointer to a pointer arg to the dfwd xmit
> routine to fill in the queue that was selected on transmit.  That should 
> resolve
> all the potential NULL pointers without the need to ad additional methods to
> net_device_ops.
>
>>> Also, can you elaborate on what you mean by additional lock contention? 
>> If the lower device has NETIF_F_LLTX, then both macvlan txq lock and the
>> lock of device itself must be held before doing transmission. In the
>> case, the macvlan txq lock contention is obvious unnecessary.
> Not in its current implementation.  The lowerdevice's NETIF_F_LLTX are ignored
> during transmit because we're using a privately 

Re: [PATCHv9 02/20] thermal: introduce device tree parser

[Wei Ni]

On 01/07/2014 07:17 PM, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On 06-01-2014 22:48, Wei Ni wrote:
>> Hi, Eduardo
>> Will you consider my comments :)
> 
> By now Wei, it is better if you start a new thread, by sending a patch
> on top of it, as this thread has been already merged by Rui.

Ok, I will send it.

Thanks.
Wei.
> 
>>
>> Thanks.
>> Wei.
>>
>> On 12/31/2013 06:17 PM, Wei Ni wrote:
>>> On 11/13/2013 03:46 AM, Eduardo Valentin wrote:
 This patch introduces a device tree bindings for
 describing the hardware thermal behavior and limits.
 Also a parser to read and interpret the data and feed
 it in the thermal framework is presented.

 This patch introduces a thermal data parser for device
 tree. The parsed data is used to build thermal zones
 and thermal binding parameters. The output data
 can then be used to deploy thermal policies.

 This patch adds also documentation regarding this
 API and how to define tree nodes to use
 this infrastructure.

 Note that, in order to be able to have control
 on the sensor registration on the DT thermal zone,
 it was required to allow changing the thermal zone
 .get_temp callback. For this reason, this patch
 also removes the 'const' modifier from the .ops
 field of thermal zone devices.

 ...
 +
 +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
 +  enum thermal_trend *trend)
 +{
 +  struct __thermal_zone *data = tz->devdata;
 +  long dev_trend;
 +  int r;
 +
 +  if (!data->get_trend)
 +  return -EINVAL;
 +
 +  r = data->get_trend(data->sensor_data, _trend);
>>> I think the ->get_trend should be defined as:
>>> .get_trend(*dev, int, *long)
>>> so that the "trip" can be passed into it, otherwise the "trip" can't be
>>> used.
>>> And the dev_trend should be returned as THERMAL_TREND_XXX directly.
>>> because the THERM_TREND_xx is more than three states.
>>>
>>> The code may be something like:
>>> r = data->get_trend(data->sensor_data, trip, _trend);
>>> if (r)
>>> return r;
>>> *trend = dev_trend;
>>> return 0;
 +  if (r)
 +  return r;
 +
 +  /* TODO: These intervals might have some thresholds, but in core code */
 +  if (dev_trend > 0)
 +  *trend = THERMAL_TREND_RAISING;
 +  else if (dev_trend < 0)
 +  *trend = THERMAL_TREND_DROPPING;
 +  else
 +  *trend = THERMAL_TREND_STABLE;
 +
 +  return 0;
 +}
 +
 .
 +
 +/***   sensor API   ***/
 +
 +static struct thermal_zone_device *
 +thermal_zone_of_add_sensor(struct device_node *zone,
 + struct device_node *sensor, void *data,
 + int (*get_temp)(void *, long *),
 + int (*get_trend)(void *, long *))
 +{
 +  struct thermal_zone_device *tzd;
 +  struct __thermal_zone *tz;
 +
 +  tzd = thermal_zone_get_zone_by_name(zone->name);
>>> I think we could get the thermal zone by node,
>>> something like:
>>> thermal_zone_get_zone_by_node(zone);
>>> so that it can get unique zone.
>>>
>>> I think we can add a member "struct device_node *np" in the
>>> thermal_zone_device,
>>> and set it after you call thermal_zone_device_register successfully.
>>> Then add following codes:
>>> thermal_zone_get_zone_by_node(struct device_node *node)
>>> {
>>> struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-ENODEV);
>>> bool found = false;
>>>
>>> if (!node)
>>> return ERR_PTR(-EINVAL);
>>>
>>> mutex_lock(_list_lock);
>>> list_for_each_entry(pos, _tz_list, node)
>>> if (node == pos->np) {
>>> ref = pos;
>>> found = true;
>>> break;
>>> }
>>> mutex_unlock(_list_lock);
>>>
>>> return ref;
>>> }
>>>
>>> Thanks.
>>> Wei.
 +  if (IS_ERR(tzd))
 +  return ERR_PTR(-EPROBE_DEFER);
 +
 +  tz = tzd->devdata;
 +
 +  mutex_lock(>lock);
 +  tz->get_temp = get_temp;
 +  tz->get_trend = get_trend;
 +  tz->sensor_data = data;
 +
 +  tzd->ops->get_temp = of_thermal_get_temp;
 +  tzd->ops->get_trend = of_thermal_get_trend;
 +  mutex_unlock(>lock);
 +
 +  return tzd;
 +}
 +

>>>
>>
>>
>>
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: imx: select PM_OPP for iMX6SL

[John Tobias]

The PM_OPP is required if the user wants to use the imx6q-cpufreq driver.

Signed-off-by: John Tobias 
---
 arch/arm/mach-imx/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 704e5ae..5e73596 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -823,6 +823,7 @@ config SOC_IMX6SL
select PL310_ERRATA_588369 if CACHE_PL310
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
+   select PM_OPP if PM
 
help
  This enables support for Freescale i.MX6 SoloLite processor.
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

YOU HAVE RECEIVED A DONATION

[III Seminario Internacional de Actualización en Agroindustria]

Hello,

This message is to inform you that you have just received a cash
donation
of $460,000 from us. You are advised to write us an email once you get
this message through the following Email: dawesda...@hotmail.com for
more
information on how you can redeem your donated sum.

Best of luck.

Dave & Angela Dawes.
Email: dawesda...@gmail.com


Correo Electrónico - Universidad de Nariño
Pasto - Nariño - Colombia
www.udenar.edu.co
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 v3.6 19/19] wireless: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal or
ether_addr_equal_unaligned instead of memcmp.

Cc: John W. Linville 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen 
Signed-off-by: Ding Tianhong 
---
 drivers/net/wireless/adm8211.c| 2 +-
 drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 7 +++
 drivers/net/wireless/hostap/hostap_80211_rx.c | 8 
 drivers/net/wireless/prism54/isl_ioctl.c  | 3 ++-
 drivers/net/wireless/ti/wl1251/main.c | 2 +-
 drivers/net/wireless/wl3501_cs.c  | 4 ++--
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index cfce83e..1d40c69 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -1314,7 +1314,7 @@ static void adm8211_bss_info_changed(struct ieee80211_hw 
*dev,
if (!(changes & BSS_CHANGED_BSSID))
return;
 
-   if (memcmp(conf->bssid, priv->bssid, ETH_ALEN)) {
+   if (!ether_addr_equal(conf->bssid, priv->bssid)) {
adm8211_set_bssid(dev, conf->bssid);
memcpy(priv->bssid, conf->bssid, ETH_ALEN);
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
index d318036..185af8a 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
@@ -1243,7 +1243,7 @@ bool brcmf_p2p_scan_finding_common_channel(struct 
brcmf_cfg80211_info *cfg,
IEEE80211_P2P_ATTR_DEVICE_ID,
p2p_dev_addr, sizeof(p2p_dev_addr));
if ((err >= 0) &&
-   (!memcmp(p2p_dev_addr, afx_hdl->tx_dst_addr, ETH_ALEN))) {
+   (ether_addr_equal(p2p_dev_addr, afx_hdl->tx_dst_addr))) {
if (!bi->ctl_ch) {
ch.chspec = le16_to_cpu(bi->chanspec);
cfg->d11inf.decchspec();
@@ -1380,8 +1380,7 @@ int brcmf_p2p_notify_action_frame_rx(struct brcmf_if *ifp,
(brcmf_p2p_gon_req_collision(p2p, (u8 *)e->addr))) {
if (test_bit(BRCMF_P2P_STATUS_FINDING_COMMON_CHANNEL,
 >status) &&
-   (memcmp(afx_hdl->tx_dst_addr, e->addr,
-   ETH_ALEN) == 0)) {
+   (ether_addr_equal(afx_hdl->tx_dst_addr, e->addr))) {
afx_hdl->peer_chan = ch.chnum;
brcmf_dbg(INFO, "GON request: Peer found, 
channel=%d\n",
  afx_hdl->peer_chan);
@@ -1865,7 +1864,7 @@ s32 brcmf_p2p_notify_rx_mgmt_p2p_probereq(struct brcmf_if 
*ifp,
cfg->d11inf.decchspec();
 
if (test_bit(BRCMF_P2P_STATUS_FINDING_COMMON_CHANNEL, >status) &&
-   (memcmp(afx_hdl->tx_dst_addr, e->addr, ETH_ALEN) == 0)) {
+   (ether_addr_equal(afx_hdl->tx_dst_addr, e->addr))) {
afx_hdl->peer_chan = ch.chnum;
brcmf_dbg(INFO, "PROBE REQUEST: Peer found, channel=%d\n",
  afx_hdl->peer_chan);
diff --git a/drivers/net/wireless/hostap/hostap_80211_rx.c 
b/drivers/net/wireless/hostap/hostap_80211_rx.c
index d39e3e2..599f30f 100644
--- a/drivers/net/wireless/hostap/hostap_80211_rx.c
+++ b/drivers/net/wireless/hostap/hostap_80211_rx.c
@@ -563,7 +563,7 @@ hostap_rx_frame_wds(local_info_t *local, struct 
ieee80211_hdr *hdr, u16 fc,
 
/* Possible WDS frame: either IEEE 802.11 compliant (if FromDS)
 * or own non-standard frame with 4th address after payload */
-   if (memcmp(hdr->addr1, local->dev->dev_addr, ETH_ALEN) != 0 &&
+   if (!ether_addr_equal(hdr->addr1, local->dev->dev_addr) &&
(hdr->addr1[0] != 0xff || hdr->addr1[1] != 0xff ||
 hdr->addr1[2] != 0xff || hdr->addr1[3] != 0xff ||
 hdr->addr1[4] != 0xff || hdr->addr1[5] != 0xff)) {
@@ -622,12 +622,12 @@ static int hostap_is_eapol_frame(local_info_t *local, 
struct sk_buff *skb)
/* check that the frame is unicast frame to us */
if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) ==
IEEE80211_FCTL_TODS &&
-   memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 &&
-   memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) {
+   ether_addr_equal(hdr->addr1, dev->dev_addr) &&
+   ether_addr_equal(hdr->addr3, dev->dev_addr)) {
/* ToDS frame with own addr BSSID and DA */
} else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) ==
   IEEE80211_FCTL_FROMDS &&
-  memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) {
+  ether_addr_equal(hdr->addr1, dev->dev_addr)) {
/* FromDS frame with own addr as DA */
} else
return 0;
diff --git 

Re: [PATCH v3.5 17/19] mwifiex: slight optimization of addr compare

[Ding Tianhong]

On 2014/1/8 10:50, Bing Zhao wrote:
> Hi Ding,
> 
>> Use possibly more efficient ether_addr_equal
>> instead of memcmp.
> 
>> @@ -782,8 +782,7 @@ static int mwifiex_ret_ibss_coalescing_status(struct 
>> mwifiex_private *priv,
>>  }
>>
>>  /* If BSSID is diff, modify current BSS parameters */
>> -if (memcmp(priv->curr_bss_params.bss_descriptor.mac_address,
>> -   ibss_coal_resp->bssid, ETH_ALEN)) {
>> +if (!ether_addr_equal(priv->curr_bss_params.bss_descriptor.mac_address, 
>> ibss_coal_resp->bssid))
> 
> Could you break the line?
> If you run "checkpatch.pl" you will spot this warning.
> 
>>  if (!IS_11N_ENABLED(priv) ||
>> -memcmp(priv->curr_addr, rx_pkt_hdr->eth803_hdr.h_dest, ETH_ALEN)) {
>> +!ether_addr_equal_unaligned(priv->curr_addr, 
>> rx_pkt_hdr->eth803_hdr.h_dest)) {
> 
> Also over 80 characters here.
> 
> Thanks,
> Bing
> 

Ok, thanks

Regards
Ding

--
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.6 01/19] net: freescale: remove unused compare_addr()

[Ding Tianhong]

The function did not be used any more, so remove it.

Cc: Li Yang 
Cc: net...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong 
---
 drivers/net/ethernet/freescale/ucc_geth.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index 5548b6d..72291a8 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -435,11 +435,6 @@ static void hw_add_addr_in_hash(struct ucc_geth_private 
*ugeth,
 QE_CR_PROTOCOL_ETHERNET, 0);
 }
 
-static inline int compare_addr(u8 **addr1, u8 **addr2)
-{
-   return memcmp(addr1, addr2, ETH_ALEN);
-}
-
 #ifdef DEBUG
 static void get_statistics(struct ucc_geth_private *ugeth,
   struct ucc_geth_tx_firmware_statistics *
-- 
1.8.0


--
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.6 17/19] mwifiex: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Bing Zhao 
Cc: John W. Linville 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen 
Signed-off-by: Ding Tianhong 
---
 drivers/net/wireless/mwifiex/11n.c | 2 +-
 drivers/net/wireless/mwifiex/sta_cmdresp.c | 3 +--
 drivers/net/wireless/mwifiex/sta_rx.c  | 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/11n.c 
b/drivers/net/wireless/mwifiex/11n.c
index 0b803c0..6261f8c 100644
--- a/drivers/net/wireless/mwifiex/11n.c
+++ b/drivers/net/wireless/mwifiex/11n.c
@@ -483,7 +483,7 @@ mwifiex_get_ba_tbl(struct mwifiex_private *priv, int tid, 
u8 *ra)
 
spin_lock_irqsave(>tx_ba_stream_tbl_lock, flags);
list_for_each_entry(tx_ba_tsr_tbl, >tx_ba_stream_tbl_ptr, list) {
-   if (!memcmp(tx_ba_tsr_tbl->ra, ra, ETH_ALEN) &&
+   if (ether_addr_equal_unaligned(tx_ba_tsr_tbl->ra, ra) &&
tx_ba_tsr_tbl->tid == tid) {
spin_unlock_irqrestore(>tx_ba_stream_tbl_lock,
   flags);
diff --git a/drivers/net/wireless/mwifiex/sta_cmdresp.c 
b/drivers/net/wireless/mwifiex/sta_cmdresp.c
index 5511946..24523e4 100644
--- a/drivers/net/wireless/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/mwifiex/sta_cmdresp.c
@@ -782,8 +782,7 @@ static int mwifiex_ret_ibss_coalescing_status(struct 
mwifiex_private *priv,
}
 
/* If BSSID is diff, modify current BSS parameters */
-   if (memcmp(priv->curr_bss_params.bss_descriptor.mac_address,
-  ibss_coal_resp->bssid, ETH_ALEN)) {
+   if (!ether_addr_equal(priv->curr_bss_params.bss_descriptor.mac_address, 
ibss_coal_resp->bssid)) {
/* BSSID */
memcpy(priv->curr_bss_params.bss_descriptor.mac_address,
   ibss_coal_resp->bssid, ETH_ALEN);
diff --git a/drivers/net/wireless/mwifiex/sta_rx.c 
b/drivers/net/wireless/mwifiex/sta_rx.c
index 0bb510d..4651d67 100644
--- a/drivers/net/wireless/mwifiex/sta_rx.c
+++ b/drivers/net/wireless/mwifiex/sta_rx.c
@@ -224,7 +224,7 @@ int mwifiex_process_sta_rx_packet(struct mwifiex_private 
*priv,
 * directly to os. Don't pass thru rx reordering
 */
if (!IS_11N_ENABLED(priv) ||
-   memcmp(priv->curr_addr, rx_pkt_hdr->eth803_hdr.h_dest, ETH_ALEN)) {
+   !ether_addr_equal_unaligned(priv->curr_addr, 
rx_pkt_hdr->eth803_hdr.h_dest)) {
mwifiex_process_rx_packet(priv, skb);
return ret;
}
-- 
1.8.0


--
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.6 03/19] net: atl1: slight optimization of addr compare

[Ding Tianhong]

Use the recently added and possibly more efficient
ether_addr_equal_unaligned to instead of memcmp.

Cc: Jay Cliburn 
Cc: Chris Snook 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen 
Signed-off-by: Ding Tianhong 
---
 drivers/net/ethernet/atheros/atlx/atl1.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c 
b/drivers/net/ethernet/atheros/atlx/atl1.c
index 538211d..55d86ec 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -3122,7 +3122,8 @@ static void atl1_remove(struct pci_dev *pdev)
 * from the BIOS during POST.  If we've been messing with the MAC
 * address, we need to save the permanent one.
 */
-   if (memcmp(adapter->hw.mac_addr, adapter->hw.perm_mac_addr, ETH_ALEN)) {
+   if (!ether_addr_equal_unaligned(adapter->hw.mac_addr,
+   adapter->hw.perm_mac_addr)) {
memcpy(adapter->hw.mac_addr, adapter->hw.perm_mac_addr,
ETH_ALEN);
atl1_set_mac_addr(>hw);
-- 
1.8.0


--
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.6 15/19] cw1200: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Solomon Peachy 
Cc: John W. Linville 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen 
Signed-off-by: Ding Tianhong 
---
 drivers/net/wireless/cw1200/sta.c  | 5 +++--
 drivers/net/wireless/cw1200/txrx.c | 3 +--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/cw1200/sta.c 
b/drivers/net/wireless/cw1200/sta.c
index 010b252..103f7bc 100644
--- a/drivers/net/wireless/cw1200/sta.c
+++ b/drivers/net/wireless/cw1200/sta.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cw1200.h"
 #include "sta.h"
@@ -555,8 +556,8 @@ u64 cw1200_prepare_multicast(struct ieee80211_hw *hw,
pr_debug("[STA] multicast: %pM\n", ha->addr);
memcpy(>multicast_filter.macaddrs[count],
   ha->addr, ETH_ALEN);
-   if (memcmp(ha->addr, broadcast_ipv4, ETH_ALEN) &&
-   memcmp(ha->addr, broadcast_ipv6, ETH_ALEN))
+   if (!ether_addr_equal(ha->addr, broadcast_ipv4) &&
+   !ether_addr_equal(ha->addr, broadcast_ipv6))
priv->has_multicast_subscription = true;
count++;
}
diff --git a/drivers/net/wireless/cw1200/txrx.c 
b/drivers/net/wireless/cw1200/txrx.c
index e824d4d..0bd5411 100644
--- a/drivers/net/wireless/cw1200/txrx.c
+++ b/drivers/net/wireless/cw1200/txrx.c
@@ -1166,8 +1166,7 @@ void cw1200_rx_cb(struct cw1200_common *priv,
return;
} else if (ieee80211_is_beacon(frame->frame_control) &&
   !arg->status && priv->vif &&
-  !memcmp(ieee80211_get_SA(frame), priv->vif->bss_conf.bssid,
-  ETH_ALEN)) {
+  ether_addr_equal(ieee80211_get_SA(frame), 
priv->vif->bss_conf.bssid)) {
const u8 *tim_ie;
u8 *ies = ((struct ieee80211_mgmt *)
  (skb->data))->u.beacon.variable;
-- 
1.8.0


--
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.6 11/19] atm: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Chas Williams 
Cc: linux-atm-gene...@lists.sourceforge.net
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Yang Yingliang 
Signed-off-by: Ding Tianhong 
---
 drivers/atm/nicstar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index 5aca5f4..9587e95 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "nicstar.h"
 #ifdef CONFIG_ATM_NICSTAR_USE_SUNI
 #include "suni.h"
@@ -781,8 +782,7 @@ static int ns_init_card(int i, struct pci_dev *pcidev)
if (mac[i] == NULL || !mac_pton(mac[i], card->atmdev->esi)) {
nicstar_read_eprom(card->membase, NICSTAR_EPROM_MAC_ADDR_OFFSET,
   card->atmdev->esi, 6);
-   if (memcmp(card->atmdev->esi, "\x00\x00\x00\x00\x00\x00", 6) ==
-   0) {
+   if (ether_addr_equal(card->atmdev->esi, 
"\x00\x00\x00\x00\x00\x00")) {
nicstar_read_eprom(card->membase,
   NICSTAR_EPROM_MAC_ADDR_OFFSET_ALT,
   card->atmdev->esi, 6);
-- 
1.8.0


--
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.6 16/19] ipw2x00: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Stanislav Yakovlev 
Cc: John W. Linville 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen 
Signed-off-by: Ding Tianhong 
---
 drivers/net/wireless/ipw2x00/ipw2200.c   | 34 
 drivers/net/wireless/ipw2x00/libipw_rx.c | 10 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c 
b/drivers/net/wireless/ipw2x00/ipw2200.c
index 9244b36..1393260 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -3012,7 +3012,7 @@ static void ipw_remove_current_network(struct ipw_priv 
*priv)
spin_lock_irqsave(>ieee->lock, flags);
list_for_each_safe(element, safe, >ieee->network_list) {
network = list_entry(element, struct libipw_network, list);
-   if (!memcmp(network->bssid, priv->bssid, ETH_ALEN)) {
+   if (ether_addr_equal(network->bssid, priv->bssid)) {
list_del(element);
list_add_tail(>list,
  >ieee->network_free_list);
@@ -3921,7 +3921,7 @@ static u8 ipw_add_station(struct ipw_priv *priv, u8 * 
bssid)
int i;
 
for (i = 0; i < priv->num_stations; i++) {
-   if (!memcmp(priv->stations[i], bssid, ETH_ALEN)) {
+   if (ether_addr_equal(priv->stations[i], bssid)) {
/* Another node is active in network */
priv->missed_adhoc_beacons = 0;
if (!(priv->config & CFG_STATIC_CHANNEL))
@@ -3953,7 +3953,7 @@ static u8 ipw_find_station(struct ipw_priv *priv, u8 * 
bssid)
int i;
 
for (i = 0; i < priv->num_stations; i++)
-   if (!memcmp(priv->stations[i], bssid, ETH_ALEN))
+   if (ether_addr_equal(priv->stations[i], bssid))
return i;
 
return IPW_INVALID_STATION;
@@ -5622,7 +5622,7 @@ static int ipw_find_adhoc_network(struct ipw_priv *priv,
return 0;
}
 
-   if (!memcmp(network->bssid, priv->bssid, ETH_ALEN)) {
+   if (ether_addr_equal(network->bssid, priv->bssid)) {
IPW_DEBUG_MERGE("Network '%s (%pM)' excluded "
"because of the same BSSID match: %pM"
".\n", print_ssid(ssid, network->ssid,
@@ -5849,7 +5849,7 @@ static int ipw_best_network(struct ipw_priv *priv,
}
 
if ((priv->config & CFG_STATIC_BSSID) &&
-   memcmp(network->bssid, priv->bssid, ETH_ALEN)) {
+   !ether_addr_equal(network->bssid, priv->bssid)) {
IPW_DEBUG_ASSOC("Network '%s (%pM)' excluded "
"because of BSSID mismatch: %pM.\n",
print_ssid(ssid, network->ssid,
@@ -6988,7 +6988,7 @@ static int ipw_qos_handle_probe_response(struct ipw_priv 
*priv,
}
if ((priv->status & STATUS_ASSOCIATED) &&
(priv->ieee->iw_mode == IW_MODE_ADHOC) && (active_network == 0)) {
-   if (memcmp(network->bssid, priv->bssid, ETH_ALEN))
+   if (!ether_addr_equal(network->bssid, priv->bssid))
if (network->capability & WLAN_CAPABILITY_IBSS)
if ((network->ssid_len ==
 priv->assoc_network->ssid_len) &&
@@ -8210,29 +8210,29 @@ static int is_network_packet(struct ipw_priv *priv,
switch (priv->ieee->iw_mode) {
case IW_MODE_ADHOC: /* Header: Dest. | Source| BSSID */
/* packets from our adapter are dropped (echo) */
-   if (!memcmp(header->addr2, priv->net_dev->dev_addr, ETH_ALEN))
+   if (ether_addr_equal(header->addr2, priv->net_dev->dev_addr))
return 0;
 
/* {broad,multi}cast packets to our BSSID go through */
if (is_multicast_ether_addr(header->addr1))
-   return !memcmp(header->addr3, priv->bssid, ETH_ALEN);
+   return ether_addr_equal(header->addr3, priv->bssid);
 
/* packets to our adapter go through */
-   return !memcmp(header->addr1, priv->net_dev->dev_addr,
-  ETH_ALEN);
+   return ether_addr_equal(header->addr1,
+   priv->net_dev->dev_addr);
 
case IW_MODE_INFRA: /* Header: Dest. | BSSID | Source */
/* packets from our adapter are dropped (echo) */
-   if (!memcmp(header->addr3, priv->net_dev->dev_addr, ETH_ALEN))
+   if (ether_addr_equal(header->addr3, priv->net_dev->dev_addr))
return 0;
 
/* {broad,multi}cast packets to our BSS go through */
if 

RE: [PATCH v3.6 17/19] mwifiex: slight optimization of addr compare

[Bing Zhao]

Hi Ding,

> - if (memcmp(priv->curr_bss_params.bss_descriptor.mac_address,
> -ibss_coal_resp->bssid, ETH_ALEN)) {
> + if (!ether_addr_equal(priv->curr_bss_params.bss_descriptor.mac_address, 
> ibss_coal_resp->bssid))

Still wrong... ;)

Have you actually run the checkpatch.pl script?

By the way, your subject prefix "PATCH v3.6" is confusing. It ought to be 
"PATCH v6", I guess.

Thanks,
Bing

[PATCH v3.6 09/19] infiniband: slight optimization of addr compare

[Ding Tianhong]

Use the possibly more efficient ether_addr_equal
to instead of memcmp.

Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: Faisal Latif 
Cc: linux-r...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Wang Weidong 
Signed-off-by: Ding Tianhong 
---
 drivers/infiniband/hw/nes/nes_cm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/nes/nes_cm.c 
b/drivers/infiniband/hw/nes/nes_cm.c
index 6b29249..9c9f2f5 100644
--- a/drivers/infiniband/hw/nes/nes_cm.c
+++ b/drivers/infiniband/hw/nes/nes_cm.c
@@ -1354,8 +1354,7 @@ static int nes_addr_resolve_neigh(struct nes_vnic 
*nesvnic, u32 dst_ip, int arpi
  neigh->ha, ntohl(rt->rt_gateway));
 
if (arpindex >= 0) {
-   if 
(!memcmp(nesadapter->arp_table[arpindex].mac_addr,
-   neigh->ha, ETH_ALEN)) {
+   if 
(ether_addr_equal(nesadapter->arp_table[arpindex].mac_addr, neigh->ha)) {
/* Mac address same as in nes_arp_table 
*/
goto out;
}
-- 
1.8.0


--
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.6 10/19] mac8011: slight optimization of addr compare

[Ding Tianhong]

Use the possibly more efficient ether_addr_equal
to instead of memcmp.

Cc: Johannes Berg 
Cc: John W. Linville 
Cc: David Miller 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Wang Weidong 
Signed-off-by: Ding Tianhong 
---
 net/mac80211/iface.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 7aa9f9d..a4f9812 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1497,8 +1497,8 @@ static void ieee80211_assign_perm_addr(struct 
ieee80211_local *local,
bool used = false;
 
list_for_each_entry(sdata, >interfaces, list) {
-   if (memcmp(local->hw.wiphy->addresses[i].addr,
-  sdata->vif.addr, ETH_ALEN) == 0) {
+   if 
(ether_addr_equal(local->hw.wiphy->addresses[i].addr,
+sdata->vif.addr)) {
used = true;
break;
}
@@ -1558,8 +1558,7 @@ static void ieee80211_assign_perm_addr(struct 
ieee80211_local *local,
val += inc;
 
list_for_each_entry(sdata, >interfaces, list) {
-   if (memcmp(tmp_addr, sdata->vif.addr,
-   ETH_ALEN) == 0) {
+   if (ether_addr_equal(tmp_addr, 
sdata->vif.addr)) {
used = true;
break;
}
-- 
1.8.0


--
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.6 00/19] slight optimization of addr compare for some modules

[Ding Tianhong]

Joe Perches add ether_addr_equal_unaligned to test if
possibly unaligned to u16 Ethernet addresses are equal.

If CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set, this uses
the slightly faster generic routine ether_addr_equal,
otherwise this uses memcmp.

So I use the recently added and possibly more efficient
ether_addr_equal_unaligned to instead of memcmp for slight
optimization.

v2: Because a lot of places are already using 16b aligned MAC
address for both operands, so use the ether_addr_equal to
instead of ether_addr_equal_unaligned.Thanks for Joe, Alex
and Antonio's opinions.
Also remove the patch for bridge.

v3: According Joe's suggestion, the patch
(net: slight optimization of addr compare for some modules)
should be broken into several patches, and it will be good
to review for maintainers. So I will send rest of the patches
for first step, and next step, I will seperate the netdev patch
and send them by another patchset for net-next.
also fix some changelog.

v3.5 Change some style for patch 8 and patch 13. Thanks for
 Sergei's suggestion.

v3.6 Change some style for patch 13 and add 
 Acked-by: Mauro Carvalho Chehab 

Best Regards
Ding 
 
Ding Tianhong (5):
  net: freescale: remove unused compare_addr()
  net: pcnet: slight optimization of addr compare
  net: atl1: slight optimization of addr compare
  hamradio: slight optimization of addr compare
  ppp: slight optimization of addr compare

Tan Xiaojun (3):
  batman-adv: use batadv_compare_eth for concise
  zd1211rw: slight optimization of addr compare
  ozwpan: slight optimization of addr compare

Wang Weidong (2):
  infiniband: slight optimization of addr compare
  mac8011: slight optimization of addr compare

Weilong Chen (6):
  hostap: slight optimization of addr compare
  cw1200: slight optimization of addr compare
  ipw2x00: slight optimization of addr compare
  mwifiex: slight optimization of addr compare
  rtlwifi: slight optimization of addr compare
  wireless: slight optimization of addr compare

Yang Yingliang (3):
  atm: slight optimization of addr compare
  isdn: slight optimization of addr compare
  media: dvb_core: slight optimization of addr compare

 drivers/atm/nicstar.c |  4 ++--
 drivers/infiniband/hw/nes/nes_cm.c|  3 +--
 drivers/isdn/i4l/isdn_net.c   |  4 ++--
 drivers/media/dvb-core/dvb_net.c  |  8 +++
 drivers/net/ethernet/amd/pcnet32.c|  2 +-
 drivers/net/ethernet/atheros/atlx/atl1.c  |  3 ++-
 drivers/net/ethernet/freescale/ucc_geth.c |  5 
 drivers/net/hamradio/bpqether.c   |  2 +-
 drivers/net/ppp/pppoe.c   |  4 ++--
 drivers/net/wireless/adm8211.c|  2 +-
 drivers/net/wireless/brcm80211/brcmfmac/p2p.c |  7 +++---
 drivers/net/wireless/cw1200/sta.c |  5 ++--
 drivers/net/wireless/cw1200/txrx.c|  3 +--
 drivers/net/wireless/hostap/hostap_80211_rx.c |  8 +++
 drivers/net/wireless/hostap/hostap_80211_tx.c |  4 ++--
 drivers/net/wireless/hostap/hostap_ap.c   | 28 +++---
 drivers/net/wireless/hostap/hostap_hw.c   |  2 +-
 drivers/net/wireless/hostap/hostap_ioctl.c|  4 ++--
 drivers/net/wireless/hostap/hostap_main.c |  8 +++
 drivers/net/wireless/ipw2x00/ipw2200.c| 34 +--
 drivers/net/wireless/ipw2x00/libipw_rx.c  | 10 
 drivers/net/wireless/mwifiex/11n.c|  2 +-
 drivers/net/wireless/mwifiex/sta_cmdresp.c|  3 +--
 drivers/net/wireless/mwifiex/sta_rx.c |  2 +-
 drivers/net/wireless/prism54/isl_ioctl.c  |  3 ++-
 drivers/net/wireless/rtlwifi/cam.c|  4 ++--
 drivers/net/wireless/ti/wl1251/main.c |  2 +-
 drivers/net/wireless/wl3501_cs.c  |  4 ++--
 drivers/net/wireless/zd1211rw/zd_mac.c|  5 ++--
 drivers/staging/ozwpan/ozcdev.c   |  2 +-
 drivers/staging/ozwpan/ozproto.c  |  5 ++--
 net/batman-adv/originator.c   |  2 +-
 net/batman-adv/translation-table.c|  2 +-
 net/mac80211/iface.c  |  7 +++---
 34 files changed, 92 insertions(+), 101 deletions(-)

-- 
1.8.0



--
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.6 06/19] batman-adv: use batadv_compare_eth for concise

[Ding Tianhong]

It is better to use batadv_compate_eth instead of memcpy for
concise style.

Cc: Marek Lindner 
Cc: Simon Wunderlich 
Cc: Antonio Quartulli 
Cc: "David S. Miller" 
Cc: b.a.t.m@lists.open-mesh.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tan Xiaojun 
Signed-off-by: Ding Tianhong 
Acked-by: Antonio Quartulli 
---
 net/batman-adv/originator.c| 2 +-
 net/batman-adv/translation-table.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c
index 8ab1434..803ab4b 100644
--- a/net/batman-adv/originator.c
+++ b/net/batman-adv/originator.c
@@ -41,7 +41,7 @@ int batadv_compare_orig(const struct hlist_node *node, const 
void *data2)
const void *data1 = container_of(node, struct batadv_orig_node,
 hash_entry);
 
-   return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0);
+   return batadv_compare_eth(data1, data2);
 }
 
 /**
diff --git a/net/batman-adv/translation-table.c 
b/net/batman-adv/translation-table.c
index 4add57d..06506e6 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -51,7 +51,7 @@ static int batadv_compare_tt(const struct hlist_node *node, 
const void *data2)
const void *data1 = container_of(node, struct batadv_tt_common_entry,
 hash_entry);
 
-   return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0);
+   return batadv_compare_eth(data1, data2);
 }
 
 /**
-- 
1.8.0


--
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.6 04/19] hamradio: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
to instead of memcmp.

Cc: Joerg Reuter 
Cc: linux-h...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong 
---
 drivers/net/hamradio/bpqether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c
index f91bf0d..d50b23c 100644
--- a/drivers/net/hamradio/bpqether.c
+++ b/drivers/net/hamradio/bpqether.c
@@ -208,7 +208,7 @@ static int bpq_rcv(struct sk_buff *skb, struct net_device 
*dev, struct packet_ty
eth = eth_hdr(skb);
 
if (!(bpq->acpt_addr[0] & 0x01) &&
-   memcmp(eth->h_source, bpq->acpt_addr, ETH_ALEN))
+   !ether_addr_equal(eth->h_source, bpq->acpt_addr))
goto drop_unlock;
 
if (skb_cow(skb, sizeof(struct ethhdr)))
-- 
1.8.0


--
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.6 05/19] ppp: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
to instead of memcmp.

Cc: Michal Ostrowski 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong 
---
 drivers/net/ppp/pppoe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 82ee6ed..2ea7efd 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -131,12 +131,12 @@ static inline struct pppoe_net *pppoe_pernet(struct net 
*net)
 
 static inline int cmp_2_addr(struct pppoe_addr *a, struct pppoe_addr *b)
 {
-   return a->sid == b->sid && !memcmp(a->remote, b->remote, ETH_ALEN);
+   return a->sid == b->sid && ether_addr_equal(a->remote, b->remote);
 }
 
 static inline int cmp_addr(struct pppoe_addr *a, __be16 sid, char *addr)
 {
-   return a->sid == sid && !memcmp(a->remote, addr, ETH_ALEN);
+   return a->sid == sid && ether_addr_equal(a->remote, addr);
 }
 
 #if 8 % PPPOE_HASH_BITS
-- 
1.8.0


--
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.6 07/19] zd1211rw: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Daniel Drake 
Cc: Ulrich Kunitz 
Cc: "John W. Linville" 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tan Xiaojun 
Signed-off-by: Ding Tianhong 
---
 drivers/net/wireless/zd1211rw/zd_mac.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c 
b/drivers/net/wireless/zd1211rw/zd_mac.c
index eff79a3..e7af261 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -532,9 +532,8 @@ void zd_mac_tx_failed(struct urb *urb)
tx_hdr = (struct ieee80211_hdr *)skb->data;
 
/* we skip all frames not matching the reported destination */
-   if (unlikely(memcmp(tx_hdr->addr1, tx_status->mac, ETH_ALEN))) {
+   if (unlikely(!ether_addr_equal(tx_hdr->addr1, tx_status->mac)))
continue;
-   }
 
/* we skip all frames not matching the reported final rate */
 
@@ -997,7 +996,7 @@ static int filter_ack(struct ieee80211_hw *hw, struct 
ieee80211_hdr *rx_hdr,
continue;
 
tx_hdr = (struct ieee80211_hdr *)skb->data;
-   if (likely(!memcmp(tx_hdr->addr2, rx_hdr->addr1, ETH_ALEN)))
+   if (likely(ether_addr_equal(tx_hdr->addr2, rx_hdr->addr1)))
{
found = 1;
break;
-- 
1.8.0


--
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.6 12/19] isdn: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Karsten Keil 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Yang Yingliang 
Signed-off-by: Ding Tianhong 
---
 drivers/isdn/i4l/isdn_net.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/isdn/i4l/isdn_net.c b/drivers/isdn/i4l/isdn_net.c
index 8b98d53..d9aebbc 100644
--- a/drivers/isdn/i4l/isdn_net.c
+++ b/drivers/isdn/i4l/isdn_net.c
@@ -1371,7 +1371,7 @@ isdn_net_type_trans(struct sk_buff *skb, struct 
net_device *dev)
eth = eth_hdr(skb);
 
if (*eth->h_dest & 1) {
-   if (memcmp(eth->h_dest, dev->broadcast, ETH_ALEN) == 0)
+   if (ether_addr_equal(eth->h_dest, dev->broadcast))
skb->pkt_type = PACKET_BROADCAST;
else
skb->pkt_type = PACKET_MULTICAST;
@@ -1382,7 +1382,7 @@ isdn_net_type_trans(struct sk_buff *skb, struct 
net_device *dev)
 */
 
else if (dev->flags & (IFF_PROMISC /*| IFF_ALLMULTI*/)) {
-   if (memcmp(eth->h_dest, dev->dev_addr, ETH_ALEN))
+   if (!ether_addr_equal(eth->h_dest, dev->dev_addr))
skb->pkt_type = PACKET_OTHERHOST;
}
if (ntohs(eth->h_proto) >= ETH_P_802_3_MIN)
-- 
1.8.0


--
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.6 13/19] media: dvb_core: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Mauro Carvalho Chehab 
Cc: linux-me...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Yang Yingliang 
Signed-off-by: Ding Tianhong 
Acked-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_net.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index f91c80c..8a86b30 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -179,7 +179,7 @@ static __be16 dvb_net_eth_type_trans(struct sk_buff *skb,
eth = eth_hdr(skb);
 
if (*eth->h_dest & 1) {
-   if(memcmp(eth->h_dest,dev->broadcast, ETH_ALEN)==0)
+   if (ether_addr_equal(eth->h_dest,dev->broadcast))
skb->pkt_type=PACKET_BROADCAST;
else
skb->pkt_type=PACKET_MULTICAST;
@@ -674,11 +674,13 @@ static void dvb_net_ule( struct net_device *dev, const u8 
*buf, size_t buf_len )
if (priv->rx_mode != RX_MODE_PROMISC) {
if (priv->ule_skb->data[0] & 
0x01) {
/* multicast or 
broadcast */
-   if 
(memcmp(priv->ule_skb->data, bc_addr, ETH_ALEN)) {
+   if 
(!ether_addr_equal(priv->ule_skb->data, bc_addr)) {
/* multicast */
if 
(priv->rx_mode == RX_MODE_MULTI) {
int i;
-   for(i = 
0; i < priv->multi_num && memcmp(priv->ule_skb->data, priv->multi_macs[i], 
ETH_ALEN); i++)
+   for (i 
= 0; i < priv->multi_num &&
+   
!ether_addr_equal(priv->ule_skb->data,
+   
  priv->multi_macs[i]); i++)

;
if (i 
== priv->multi_num)

drop = 1;
@@ -688,7 +690,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 
*buf, size_t buf_len )
}
/* else: broadcast */
}
-   else if 
(memcmp(priv->ule_skb->data, dev->dev_addr, ETH_ALEN))
+   else if 
(!ether_addr_equal(priv->ule_skb->data, dev->dev_addr))
drop = 1;
/* else: destination address 
matches the MAC address of our receiver device */
}
-- 
1.8.0


--
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.6 14/19] hostap: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Jouni Malinen 
Cc: John W. Linville 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen 
Signed-off-by: Ding Tianhong 
---
 drivers/net/wireless/hostap/hostap_80211_tx.c |  4 ++--
 drivers/net/wireless/hostap/hostap_ap.c   | 28 +--
 drivers/net/wireless/hostap/hostap_hw.c   |  2 +-
 drivers/net/wireless/hostap/hostap_ioctl.c|  4 ++--
 drivers/net/wireless/hostap/hostap_main.c |  8 +++-
 5 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/hostap/hostap_80211_tx.c 
b/drivers/net/wireless/hostap/hostap_80211_tx.c
index 344a981..8bde776 100644
--- a/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ b/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 
 #include "hostap_80211.h"
 #include "hostap_common.h"
@@ -103,8 +104,7 @@ netdev_tx_t hostap_data_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
} else if (local->iw_mode == IW_MODE_INFRA &&
   (local->wds_type & HOSTAP_WDS_AP_CLIENT) &&
-  memcmp(skb->data + ETH_ALEN, dev->dev_addr,
- ETH_ALEN) != 0) {
+  !ether_addr_equal(skb->data + ETH_ALEN, 
dev->dev_addr)) {
/* AP client mode: send frames with foreign src addr
 * using 4-addr WDS frames */
use_wds = WDS_COMPLIANT_FRAME;
diff --git a/drivers/net/wireless/hostap/hostap_ap.c 
b/drivers/net/wireless/hostap/hostap_ap.c
index d6033a8..d36e252 100644
--- a/drivers/net/wireless/hostap/hostap_ap.c
+++ b/drivers/net/wireless/hostap/hostap_ap.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hostap_wlan.h"
 #include "hostap.h"
@@ -106,13 +107,12 @@ static void ap_sta_hash_del(struct ap_data *ap, struct 
sta_info *sta)
 
s = ap->sta_hash[STA_HASH(sta->addr)];
if (s == NULL) return;
-   if (memcmp(s->addr, sta->addr, ETH_ALEN) == 0) {
+   if (ether_addr_equal(s->addr, sta->addr)) {
ap->sta_hash[STA_HASH(sta->addr)] = s->hnext;
return;
}
 
-   while (s->hnext != NULL && memcmp(s->hnext->addr, sta->addr, ETH_ALEN)
-  != 0)
+   while (s->hnext != NULL && !ether_addr_equal(s->hnext->addr, sta->addr))
s = s->hnext;
if (s->hnext != NULL)
s->hnext = s->hnext->hnext;
@@ -435,7 +435,7 @@ int ap_control_del_mac(struct mac_restrictions 
*mac_restrictions, u8 *mac)
 ptr != _restrictions->mac_list; ptr = ptr->next) {
entry = list_entry(ptr, struct mac_entry, list);
 
-   if (memcmp(entry->addr, mac, ETH_ALEN) == 0) {
+   if (ether_addr_equal(entry->addr, mac)) {
list_del(ptr);
kfree(entry);
mac_restrictions->entries--;
@@ -459,7 +459,7 @@ static int ap_control_mac_deny(struct mac_restrictions 
*mac_restrictions,
 
spin_lock_bh(_restrictions->lock);
list_for_each_entry(entry, _restrictions->mac_list, list) {
-   if (memcmp(entry->addr, mac, ETH_ALEN) == 0) {
+   if (ether_addr_equal(entry->addr, mac)) {
found = 1;
break;
}
@@ -957,7 +957,7 @@ static struct sta_info* ap_get_sta(struct ap_data *ap, u8 
*sta)
struct sta_info *s;
 
s = ap->sta_hash[STA_HASH(sta)];
-   while (s != NULL && memcmp(s->addr, sta, ETH_ALEN) != 0)
+   while (s != NULL && !ether_addr_equal(s->addr, sta))
s = s->hnext;
return s;
 }
@@ -1391,7 +1391,7 @@ static void handle_authen(local_info_t *local, struct 
sk_buff *skb,
status_code = __le16_to_cpu(*pos);
pos++;
 
-   if (memcmp(dev->dev_addr, hdr->addr2, ETH_ALEN) == 0 ||
+   if (ether_addr_equal(dev->dev_addr, hdr->addr2) ||
ap_control_mac_deny(>mac_restrictions, hdr->addr2)) {
txt = "authentication denied";
resp = WLAN_STATUS_UNSPECIFIED_FAILURE;
@@ -1935,7 +1935,7 @@ static void handle_pspoll(local_info_t *local,
PDEBUG(DEBUG_PS2, "handle_pspoll: BSSID=%pM, TA=%pM PWRMGT=%d\n",
   hdr->addr1, hdr->addr2, !!ieee80211_has_pm(hdr->frame_control));
 
-   if (memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN)) {
+   if (!ether_addr_equal(hdr->addr1, dev->dev_addr)) {
PDEBUG(DEBUG_AP,
   "handle_pspoll - addr1(BSSID)=%pM not own MAC\n",
   hdr->addr1);
@@ -2230,7 +2230,7 @@ static void handle_ap_item(local_info_t *local, struct 
sk_buff *skb,
goto done;
}
 
-   if (memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN)) {
+ 

[PATCH v3.6 08/19] ozwpan: slight optimization of addr compare

[Ding Tianhong]

Use possibly more efficient ether_addr_equal
instead of memcmp.

Cc: Rupesh Gujare 
Cc: Greg Kroah-Hartman 
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tan Xiaojun 
Signed-off-by: Ding Tianhong 
---
 drivers/staging/ozwpan/ozcdev.c  | 2 +-
 drivers/staging/ozwpan/ozproto.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 6ce0af9..c363f66 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -448,7 +448,7 @@ int oz_cdev_start(struct oz_pd *pd, int resume)
}
spin_lock(_cdev.lock);
if ((g_cdev.active_pd == NULL) &&
-   (memcmp(pd->mac_addr, g_cdev.active_addr, ETH_ALEN) == 0)) {
+   ether_addr_equal(pd->mac_addr, g_cdev.active_addr)) {
oz_pd_get(pd);
g_cdev.active_pd = pd;
oz_dbg(ON, "Active PD arrived\n");
diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index 88714ec..19a2521 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "ozdbg.h"
@@ -180,7 +181,7 @@ static struct oz_pd *oz_connect_req(struct oz_pd *cur_pd, 
struct oz_elt *elt,
spin_lock_bh(_polling_lock);
list_for_each(e, _pd_list) {
pd2 = container_of(e, struct oz_pd, link);
-   if (memcmp(pd2->mac_addr, pd_addr, ETH_ALEN) == 0) {
+   if (ether_addr_equal(pd2->mac_addr, pd_addr)) {
free_pd = pd;
pd = pd2;
break;
@@ -597,7 +598,7 @@ struct oz_pd *oz_pd_find(const u8 *mac_addr)
spin_lock_bh(_polling_lock);
list_for_each(e, _pd_list) {
pd = container_of(e, struct oz_pd, link);
-   if (memcmp(pd->mac_addr, mac_addr, ETH_ALEN) == 0) {
+   if (ether_addr_equal(pd->mac_addr, mac_addr)) {
atomic_inc(>ref_count);
spin_unlock_bh(_polling_lock);
return pd;
-- 
1.8.0


--
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/