Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote:
> From: Micky Ching
>
> Add helper function to write u32 to registers, if we want to put u32
> value to 4 continuous register, this can help us reduce tedious work.
>
> Signed-off-by: Micky Ching
> Acked-by: Lee Jones
> ---
> include/linux/mfd/rtsx_pci.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
> index 74346d5..9234449 100644
> --- a/include/linux/mfd/rtsx_pci.h
> +++ b/include/linux/mfd/rtsx_pci.h
> @@ -558,6 +558,7 @@
> #define SD_SAMPLE_POINT_CTL 0xFDA7
> #define SD_PUSH_POINT_CTL0xFDA8
> #define SD_CMD0 0xFDA9
> +#define SD_CMD_START 0x40
This is a different format at the others in the group on two counts;
firstly you have 3 whitespace characters after the #define and
secondly all of the other hex digits in the set are 4 a breast.
Please add the leading zeros to conform to this format.
> #define SD_CMD1 0xFDAA
> #define SD_CMD2 0xFDAB
> #define SD_CMD3 0xFDAC
> @@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
> *pcr)
> return (u8 *)(pcr->host_cmds_ptr);
> }
>
> +static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
> val)
> +{
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val >> 24);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 16);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 8);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
> +}
> +
> #endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On 12/08/2014 04:49 PM, Lee Jones wrote: >> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h >> >index 74346d5..9234449 100644 >> >--- a/include/linux/mfd/rtsx_pci.h >> >+++ b/include/linux/mfd/rtsx_pci.h >> >@@ -558,6 +558,7 @@ >> > #define SD_SAMPLE_POINT_CTL 0xFDA7 >> > #define SD_PUSH_POINT_CTL 0xFDA8 >> > #define SD_CMD0 0xFDA9 >> >+#define SD_CMD_START 0x40 > This is a different format at the others in the group on two counts; > firstly you have 3 whitespace characters after the #define and > secondly all of the other hex digits in the set are 4 a breast. > Please add the leading zeros to conform to this format. > Hi lee, This format is more readable, add 2 space means this value is in groups under register SD_CMD0, and each register value is u8 type, so use 2 hex digits is right. The original file make register address and its related value separated, and group register together. But I like to write register address and value together, add 2 space for value to indicate this value is related to above register. If we add new address/value, I recommend write register define format as below: #define REGISTERaddr #define REG_VAL1 val1 #define REG_VAL2 val2 regards. micky. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging:lustre:lustre:ptlrpc: fix sparse warnings in lproc_ptlrpc.c
From: Fred Chou
Fixed the below warning in sparse:
drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c:184:6:
warning: symbol 'ptlrpc_lprocfs_register' was not declared.
Should it be static?
Signed-off-by: Fred Chou
---
drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
b/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
index 4011e00..4c0d48e 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
@@ -181,9 +181,10 @@ const char *ll_eopcode2str(__u32 opcode)
return ll_eopcode_table[opcode].opname;
}
#if defined (CONFIG_PROC_FS)
-void ptlrpc_lprocfs_register(struct proc_dir_entry *root, char *dir,
-char *name, struct proc_dir_entry **procroot_ret,
-struct lprocfs_stats **stats_ret)
+static void ptlrpc_lprocfs_register(struct proc_dir_entry *root, char *dir,
+ char *name,
+ struct proc_dir_entry **procroot_ret,
+ struct lprocfs_stats **stats_ret)
{
struct proc_dir_entry *svc_procroot;
struct lprocfs_stats *svc_stats;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote:
> From: Micky Ching
>
> Add helper function to write u32 to registers, if we want to put u32
> value to 4 continuous register, this can help us reduce tedious work.
>
> Signed-off-by: Micky Ching
> Acked-by: Lee Jones
> ---
> include/linux/mfd/rtsx_pci.h | 9 +
> 1 file changed, 9 insertions(+)
Applied, thanks.
> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
> index 74346d5..9234449 100644
> --- a/include/linux/mfd/rtsx_pci.h
> +++ b/include/linux/mfd/rtsx_pci.h
> @@ -558,6 +558,7 @@
> #define SD_SAMPLE_POINT_CTL 0xFDA7
> #define SD_PUSH_POINT_CTL0xFDA8
> #define SD_CMD0 0xFDA9
> +#define SD_CMD_START 0x40
> #define SD_CMD1 0xFDAA
> #define SD_CMD2 0xFDAB
> #define SD_CMD3 0xFDAC
> @@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
> *pcr)
> return (u8 *)(pcr->host_cmds_ptr);
> }
>
> +static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
> val)
> +{
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val >> 24);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 16);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 8);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
> +}
> +
> #endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Mon, 08 Dec 2014, 敬锐 wrote: > > On 12/08/2014 04:49 PM, Lee Jones wrote: > >> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h > >> >index 74346d5..9234449 100644 > >> >--- a/include/linux/mfd/rtsx_pci.h > >> >+++ b/include/linux/mfd/rtsx_pci.h > >> >@@ -558,6 +558,7 @@ > >> > #define SD_SAMPLE_POINT_CTL 0xFDA7 > >> > #define SD_PUSH_POINT_CTL 0xFDA8 > >> > #define SD_CMD0 0xFDA9 > >> >+#define SD_CMD_START 0x40 > > This is a different format at the others in the group on two counts; > > firstly you have 3 whitespace characters after the #define and > > secondly all of the other hex digits in the set are 4 a breast. > > Please add the leading zeros to conform to this format. > > > Hi lee, > > This format is more readable, add 2 space means this value is > in groups under register SD_CMD0, and each register value is u8 type, > so use 2 hex digits is right. > > The original file make register address and its related value separated, > and group register together. > > But I like to write register address and value together, > add 2 space for value to indicate this value is related to above register. > > If we add new address/value, I recommend write register define format as > below: > > #define REGISTERaddr > #define REG_VAL1 val1 > #define REG_VAL2 val2 Okay, I see that there are other occurrences using this format in that file. Please consider converting the entire file into this format. I don't mind it either way, but it looks odd if they are mixed. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On 12/08/2014 05:57 PM, Lee Jones wrote: > On Mon, 08 Dec 2014, 敬锐 wrote: > >> On 12/08/2014 04:49 PM, Lee Jones wrote: diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h > index 74346d5..9234449 100644 > --- a/include/linux/mfd/rtsx_pci.h > +++ b/include/linux/mfd/rtsx_pci.h > @@ -558,6 +558,7 @@ > #define SD_SAMPLE_POINT_CTL 0xFDA7 > #define SD_PUSH_POINT_CTL 0xFDA8 > #define SD_CMD0 0xFDA9 > +#define SD_CMD_START 0x40 >>> This is a different format at the others in the group on two counts; >>> firstly you have 3 whitespace characters after the #define and >>> secondly all of the other hex digits in the set are 4 a breast. >>> Please add the leading zeros to conform to this format. >>> >> Hi lee, >> >> This format is more readable, add 2 space means this value is >> in groups under register SD_CMD0, and each register value is u8 type, >> so use 2 hex digits is right. >> >> The original file make register address and its related value separated, >> and group register together. >> >> But I like to write register address and value together, >> add 2 space for value to indicate this value is related to above register. >> >> If we add new address/value, I recommend write register define format as >> below: >> >> #define REGISTERaddr >> #define REG_VAL1 val1 >> #define REG_VAL2 val2 > Okay, I see that there are other occurrences using this format in that > file. Please consider converting the entire file into this format. I > don't mind it either way, but it looks odd if they are mixed. > we will reformat it in the near future. regards. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On 8 December 2014 at 10:57, Lee Jones wrote: > On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote: >> From: Micky Ching >> >> Add helper function to write u32 to registers, if we want to put u32 >> value to 4 continuous register, this can help us reduce tedious work. >> >> Signed-off-by: Micky Ching >> Acked-by: Lee Jones >> --- >> include/linux/mfd/rtsx_pci.h | 9 + >> 1 file changed, 9 insertions(+) > > Applied, thanks. Lee, I suppose you queued this for 3.19? I don't intend to queue anything more before the merge window and thus the mmc patches can later be handled without any dependence to mfd, I guess!? Kind regards Uffe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Use ether_addr_copy() in vnt_fill_ieee80211_rts.
Both struct ieee80211_rts and struct ieee80211_hdr defined in linux/ieee80211.h are declared as __aligned(2) so it is safe to use ether_addr_copy() instead of memcpy(). Signed-off-by: Krzysztof Adamski --- drivers/staging/vt6656/rxtx.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c index ea5140a..280c923 100644 --- a/drivers/staging/vt6656/rxtx.c +++ b/drivers/staging/vt6656/rxtx.c @@ -36,6 +36,7 @@ * */ +#include #include "device.h" #include "rxtx.h" #include "card.h" @@ -392,8 +393,8 @@ static int vnt_fill_ieee80211_rts(struct vnt_usb_send_context *tx_context, rts->frame_control = cpu_to_le16(IEEE80211_FTYPE_CTL | IEEE80211_STYPE_RTS); - memcpy(rts->ra, hdr->addr1, ETH_ALEN); - memcpy(rts->ta, hdr->addr2, ETH_ALEN); + ether_addr_copy(rts->ra, hdr->addr1); + ether_addr_copy(rts->ta, hdr->addr2); return 0; } -- 1.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Mon, 08 Dec 2014, Ulf Hansson wrote: > On 8 December 2014 at 10:57, Lee Jones wrote: > > On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote: > >> From: Micky Ching > >> > >> Add helper function to write u32 to registers, if we want to put u32 > >> value to 4 continuous register, this can help us reduce tedious work. > >> > >> Signed-off-by: Micky Ching > >> Acked-by: Lee Jones > >> --- > >> include/linux/mfd/rtsx_pci.h | 9 + > >> 1 file changed, 9 insertions(+) > > > > Applied, thanks. > > Lee, > > I suppose you queued this for 3.19? > > I don't intend to queue anything more before the merge window and thus > the mmc patches can later be handled without any dependence to mfd, I > guess!? All correct. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code
On Fri 05-12-14 16:41:38, K. Y. Srinivasan wrote:
> Andy Whitcroft initially saw this deadlock. We
> have seen this as well. Here is the original description of the
> problem (and a potential solution) from Andy:
>
> https://lkml.org/lkml/2014/3/14/451
>
> Here is an excerpt from that mail:
>
> "We are seeing machines lockup with what appears to be an ABBA
> deadlock in the memory hotplug system. These are from the 3.13.6 based
> Ubuntu kernels.
> The hv_balloon driver is adding memory using add_memory() which takes
> the hotplug lock
Do you mean mem_hotplug_begin?
> and then emits a udev event, and then attempts to
> lock the sysfs device. In response to the udev event udev opens the
> sysfs device and locks it, then attempts to grab the hotplug lock to online
> the memory.
Cannot we simply teach online_pages to fail with EBUSY when the memory
hotplug is on the way. We shouldn't try to online something that is not
initialized yet, no? The memory hotplug log is global so we can get
false positives but that should be easier to deal with than exporting
lock_device_hotplug and adding yet another lock dependency.
> This seems to be inverted nesting in the two cases, leading to the hangs
> below:
>
> [ 240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
> [ 240.608705] INFO: task systemd-udevd:1906 blocked for more than 120
> seconds.
>
> I note that the device hotplug locking allows complete retries (via
> ERESTARTSYS) and if we could detect this at the online stage it could
> be used to get us out.
I am not sure I understand this but it suggests EBUSY above?
> But before I go down this road I wanted to
> make sure I am reading this right. Or indeed if the hv_balloon driver
> is just doing this wrong."
>
> This patch is based on the suggestion from
> Yasuaki Ishimatsu
This changelog doesn't explain us much. And boy this whole thing is so
convoluted. E.g. I have hard time to see why ACPI hotplug is working
correctly. My trail got lost at acpi_memory_device_add level which is
a callback while acpi_device_hotplug is holding lock_device_hotplug but
then again the rest is hidden by callbacks. I cannot seem to find any
documentation which would explain all the locking here.
So why other callers of add_memory don't need the same treatment and if
they do then why don't we use the lock at add_memory level?
> Signed-off-by: K. Y. Srinivasan
Nak to this without proper explanation and I really think that it should
be the onlining code which should deal with the parallel add_memory and
back off until the full initialization is done.
> ---
> drivers/hv/hv_balloon.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index afdb0d5..f525a62 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -649,8 +650,11 @@ static void hv_mem_hot_add(unsigned long start, unsigned
> long size,
>
> release_region_mutex(false);
> nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
> +
> + lock_device_hotplug();
> ret = add_memory(nid, PFN_PHYS((start_pfn)),
> (HA_CHUNK << PAGE_SHIFT));
> + unlock_device_hotplug();
>
> if (ret) {
> pr_info("hot_add memory failed error is %d\n", ret);
> --
> 1.7.4.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Clocking-wizard: Fixed missing blank line warning
On Sun, 2014-12-07 at 02:35PM +0530, Athira Lekshmi wrote: > Added a new line after declaration to remove the warning > 'Missing a blank line after declarations' > > Signed-off-by: Athira Lekshmi Acked-by: Soren Brinkmann Soren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging:board: fix build errors and warnings
Add dummy implementation of 'of_find_all_nodes',
and remove the unnecessary 'of_can_translate_address',
which is already removed in commit
d9c6866be8a145e32da616d8dcbae806032d75b5 ("of: kill off
of_can_translate_address"), to fix the build errors and warnings
found by sparse.
Signed-off-by: Tsung-Han Lin
---
drivers/staging/board/board.c | 3 +--
include/linux/of.h| 5 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/board/board.c b/drivers/staging/board/board.c
index 6050fbdfd31f..d5a6abc84519 100644
--- a/drivers/staging/board/board.c
+++ b/drivers/staging/board/board.c
@@ -11,8 +11,7 @@ static bool find_by_address(u64 base_address)
struct resource res;
while (dn) {
- if (of_can_translate_address(dn)
- && !of_address_to_resource(dn, 0, &res)) {
+ if (!of_address_to_resource(dn, 0, &res)) {
if (res.start == base_address) {
of_node_put(dn);
return true;
diff --git a/include/linux/of.h b/include/linux/of.h
index dfde07e77a63..c2c5021c1ee4 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -616,6 +616,11 @@ static inline const char *of_prop_next_string(struct
property *prop,
return NULL;
}
+static inline struct device_node *of_find_all_nodes(struct device_node *prev)
+{
+ return NULL;
+}
+
#define of_match_ptr(_ptr) NULL
#define of_match_node(_matches, _node) NULL
#endif /* CONFIG_OF */
--
2.1.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: lustre: obd: Fix a coding style issue
From: Dean Ancajas
Fixed a brace coding style issue for functions.
Signed-off-by: Dean Michael Ancajas
---
drivers/staging/lustre/lustre/obdclass/cl_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index ce96bd2..c40bb6c 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -662,7 +662,8 @@ static int cl_env_store_init(void) {
return cl_env_hash != NULL ? 0 :-ENOMEM;
}
-static void cl_env_store_fini(void) {
+static void cl_env_store_fini(void)
+{
cfs_hash_putref(cl_env_hash);
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8723au: os_dep: Fixed a coding style issue.
Fixed a coding style issue for braces.
Signed-off-by: Dean Michael Ancajas
---
drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
index bd6953a..ba0c1e7 100644
--- a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
@@ -1469,9 +1469,8 @@ static int rtw_cfg80211_set_wpa_version(struct
security_priv *psecuritypriv,
return 0;
}
- if (wpa_version & (NL80211_WPA_VERSION_1 | NL80211_WPA_VERSION_2)) {
+ if (wpa_version & (NL80211_WPA_VERSION_1 | NL80211_WPA_VERSION_2))
psecuritypriv->ndisauthtype = Ndis802_11AuthModeWPAPSK;
- }
/*
if (wpa_version & NL80211_WPA_VERSION_2)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: ft1000: ft1000-pcmcia: Fixed a coding style issue
Fixed a coding style issue for braces.
Signed-off-by: Dean Michael Ancajas
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 44575c7..45960b2 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -176,11 +176,11 @@ u16 ft1000_read_dpram_mag_16(struct net_device *dev, int
offset, int Index)
spin_lock_irqsave(&info->dpram_lock, flags);
ft1000_write_reg(dev, FT1000_REG_DPRAM_ADDR, offset);
/* check if we want to read upper or lower 32-bit word */
- if (Index) {
+ if (Index)
data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAL);
- } else {
+ else
data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAH);
- }
+
spin_unlock_irqrestore(&info->dpram_lock, flags);
return data;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: lustre: Fix sparse non-static symbol warnings
Fixes the following sparse warnings:
drivers/staging/lustre/lnet/lnet/lib-move.c:565:1: warning:
symbol 'lnet_ni_recv' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:603:1: warning:
symbol 'lnet_setpayloadbuffer' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:643:1: warning:
symbol 'lnet_ni_send' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:658:1: warning:
symbol 'lnet_ni_eager_recv' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:683:1: warning:
symbol 'lnet_ni_query_locked' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:735:1: warning:
symbol 'lnet_peer_alive_locked' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:874:19: warning:
symbol 'lnet_msg2bufpool' was not declared. Should it be static?
drivers/staging/lustre/lnet/lnet/lib-move.c:895:1: warning:
symbol 'lnet_post_routed_recv_locked' was not declared. Should it be static?
Signed-off-by: Tom Wales
---
drivers/staging/lustre/lnet/lnet/lib-move.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index 4b9567d..5754725 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -561,7 +561,7 @@ lnet_extract_kiov(int dst_niov, lnet_kiov_t *dst,
}
EXPORT_SYMBOL(lnet_extract_kiov);
-void
+static void
lnet_ni_recv(lnet_ni_t *ni, void *private, lnet_msg_t *msg, int delayed,
unsigned int offset, unsigned int mlen, unsigned int rlen)
{
@@ -599,7 +599,7 @@ lnet_ni_recv(lnet_ni_t *ni, void *private, lnet_msg_t *msg,
int delayed,
lnet_finalize(ni, msg, rc);
}
-void
+static void
lnet_setpayloadbuffer(lnet_msg_t *msg)
{
lnet_libmd_t *md = msg->msg_md;
@@ -639,7 +639,7 @@ lnet_prep_send(lnet_msg_t *msg, int type, lnet_process_id_t
target,
msg->msg_hdr.payload_length = cpu_to_le32(len);
}
-void
+static void
lnet_ni_send(lnet_ni_t *ni, lnet_msg_t *msg)
{
void *priv = msg->msg_private;
@@ -654,7 +654,7 @@ lnet_ni_send(lnet_ni_t *ni, lnet_msg_t *msg)
lnet_finalize(ni, msg, rc);
}
-int
+static int
lnet_ni_eager_recv(lnet_ni_t *ni, lnet_msg_t *msg)
{
int rc;
@@ -679,7 +679,7 @@ lnet_ni_eager_recv(lnet_ni_t *ni, lnet_msg_t *msg)
}
/* NB: caller shall hold a ref on 'lp' as I'd drop lnet_net_lock */
-void
+static void
lnet_ni_query_locked(lnet_ni_t *ni, lnet_peer_t *lp)
{
unsigned long last_alive = 0;
@@ -731,7 +731,7 @@ lnet_peer_is_alive(lnet_peer_t *lp, unsigned long now)
/* NB: returns 1 when alive, 0 when dead, negative when error;
* may drop the lnet_net_lock */
-int
+static int
lnet_peer_alive_locked(lnet_peer_t *lp)
{
unsigned long now = cfs_time_current();
@@ -871,7 +871,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
}
-lnet_rtrbufpool_t *
+static lnet_rtrbufpool_t *
lnet_msg2bufpool(lnet_msg_t *msg)
{
lnet_rtrbufpool_t *rbp;
@@ -891,7 +891,7 @@ lnet_msg2bufpool(lnet_msg_t *msg)
return rbp;
}
-int
+static int
lnet_post_routed_recv_locked(lnet_msg_t *msg, int do_recv)
{
/* lnet_parse is going to lnet_net_unlock immediately after this, so it
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: ion: ion_cma_heap: remove ion_cma_get_sgtable
Remove the temporary code ion_cma_get_sgtable,
use dma_common_get_sgtable instead
Signed-off-by: Zeng Tao
---
drivers/staging/android/ion/ion_cma_heap.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index f8cabcb..f4211f1 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,24 +39,6 @@ struct ion_cma_buffer_info {
struct sg_table *table;
};
-/*
- * Create scatter-list for the already allocated DMA buffer.
- * This function could be replaced by dma_common_get_sgtable
- * as soon as it will avalaible.
- */
-static int ion_cma_get_sgtable(struct device *dev, struct sg_table *sgt,
- void *cpu_addr, dma_addr_t handle, size_t size)
-{
- struct page *page = virt_to_page(cpu_addr);
- int ret;
-
- ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
- if (unlikely(ret))
- return ret;
-
- sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
- return 0;
-}
/* ION CMA heap operations functions */
static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -91,7 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
ion_buffer *buffer,
if (!info->table)
goto free_mem;
- if (ion_cma_get_sgtable
+ if (dma_common_get_sgtable
(dev, info->table, info->cpu_addr, info->handle, len))
goto free_table;
/* keep this for memory release */
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hyperv: Add support for vNIC hot removal
From: Haiyang Zhang Date: Mon, 1 Dec 2014 13:28:39 -0800 > This patch adds proper handling of the vNIC hot removal event, which includes > a rescind-channel-offer message from the host side that triggers vNIC close > and > removal. In this case, the notices to the host during close and removal is not > necessary because the channel is rescinded. This patch blocks these > unnecessary > messages, and lets vNIC removal process complete normally. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied, thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code
(2014/12/09 0:04), Michal Hocko wrote:
On Fri 05-12-14 16:41:38, K. Y. Srinivasan wrote:
Andy Whitcroft initially saw this deadlock. We
have seen this as well. Here is the original description of the
problem (and a potential solution) from Andy:
https://lkml.org/lkml/2014/3/14/451
Here is an excerpt from that mail:
"We are seeing machines lockup with what appears to be an ABBA
deadlock in the memory hotplug system. These are from the 3.13.6 based Ubuntu
kernels.
The hv_balloon driver is adding memory using add_memory() which takes
the hotplug lock
Do you mean mem_hotplug_begin?
and then emits a udev event, and then attempts to
lock the sysfs device. In response to the udev event udev opens the
sysfs device and locks it, then attempts to grab the hotplug lock to online the
memory.
Cannot we simply teach online_pages to fail with EBUSY when the memory
hotplug is on the way. We shouldn't try to online something that is not
initialized yet, no?
Yes. Memory online shouldn't try before initializing it. Then memory online
should wait for initializing it, not easily fails. Generally, kernel sends
memory ONLINE event to userland by kobject_uevent() during initializing memory
and udev makes memory online after catching the event. Onlining memory by
udev almost run during initializing memory. So if memory online easily
fails, onlining memory by udev almost fails.
The memory hotplug log is global so we can get
false positives but that should be easier to deal with than exporting
lock_device_hotplug and adding yet another lock dependency.
This seems to be inverted nesting in the two cases, leading to the hangs below:
[ 240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
[ 240.608705] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.
I note that the device hotplug locking allows complete retries (via
ERESTARTSYS) and if we could detect this at the online stage it could
be used to get us out.
I am not sure I understand this but it suggests EBUSY above?
But before I go down this road I wanted to
make sure I am reading this right. Or indeed if the hv_balloon driver
is just doing this wrong."
This patch is based on the suggestion from
Yasuaki Ishimatsu
This changelog doesn't explain us much. And boy this whole thing is so
convoluted. E.g. I have hard time to see why ACPI hotplug is working
correctly. My trail got lost at acpi_memory_device_add level which is
a callback while acpi_device_hotplug is holding lock_device_hotplug but
then again the rest is hidden by callbacks.
Commit 0f1cfe9d0d06 (mm/hotplug: remove stop_machine() from try_offline_node())
said:
---
lock_device_hotplug() serializes hotplug & online/offline operations. The
lock is held in common sysfs online/offline interfaces and ACPI hotplug
code paths.
And here are the code paths:
- CPU & Mem online/offline via sysfs online
store_online()->lock_device_hotplug()
- Mem online via sysfs state:
store_mem_state()->lock_device_hotplug()
- ACPI CPU & Mem hot-add:
acpi_scan_bus_device_check()->lock_device_hotplug()
- ACPI CPU & Mem hot-delete:
acpi_scan_hot_remove()->lock_device_hotplug()
---
CPU & Memory online/offline/hotplug are serialized by lock_device_hotplug().
I cannot seem to find any
documentation which would explain all the locking here.
Yes. I need the documentation.
Thanks,
Yasuaki Ishimatsu
So why other callers of add_memory don't need the same treatment and if
they do then why don't we use the lock at add_memory level?
Signed-off-by: K. Y. Srinivasan
Nak to this without proper explanation and I really think that it should
be the onlining code which should deal with the parallel add_memory and
back off until the full initialization is done.
---
drivers/hv/hv_balloon.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index afdb0d5..f525a62 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -649,8 +650,11 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
release_region_mutex(false);
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
+
+ lock_device_hotplug();
ret = add_memory(nid, PFN_PHYS((start_pfn)),
(HA_CHUNK << PAGE_SHIFT));
+ unlock_device_hotplug();
if (ret) {
pr_info("hot_add memory failed error is %d\n", ret);
--
1.7.4.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org";> em...@kvack.org
___
devel mailing list
de...@linu
Re: [PATCH] staging: ion: ion_cma_heap: remove ion_cma_get_sgtable
On Tue, 2014-12-09 at 09:19 +0800, Zeng Tao wrote: > Remove the temporary code ion_cma_get_sgtable, > use dma_common_get_sgtable instead [] > diff --git a/drivers/staging/android/ion/ion_cma_heap.c > b/drivers/staging/android/ion/ion_cma_heap.c [] > @@ -91,7 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct > ion_buffer *buffer, > if (!info->table) > goto free_mem; > > - if (ion_cma_get_sgtable > + if (dma_common_get_sgtable > (dev, info->table, info->cpu_addr, info->handle, len)) > goto free_table; > /* keep this for memory release */ somewhat unrelated trivia: It'd conform a bit more to kernel style to write this with at least one argument on the same line as the function like: if (dma_common_get_sgtable(dev, info->table, info->cpu_addr, info->handle, len)) goto free_table; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
