[staging:staging-testing 190/192] undefined reference to `dmam_alloc_coherent'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing head: b5596d52a3715a37d6d0875791d93ae5b73c6f21 commit: ecbc62fd441210e54e25fa9683422bbc0143049d [190/192] staging: vc04_services: add CONFIG_COMPILE_TEST ability config: m32r-allyesconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 6.2.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout ecbc62fd441210e54e25fa9683422bbc0143049d # save the attached .config to linux build tree make.cross ARCH=m32r All errors (new ones prefixed by >>): drivers/built-in.o: In function `stm32_serial_remove': stm32-usart.c:(.text+0xe3044): undefined reference to `bad_dma_ops' stm32-usart.c:(.text+0xe304c): undefined reference to `bad_dma_ops' stm32-usart.c:(.text+0xe30e8): undefined reference to `bad_dma_ops' stm32-usart.c:(.text+0xe30f0): undefined reference to `bad_dma_ops' drivers/built-in.o: In function `vpu_free_ext_mem': mtk_vpu.c:(.text+0xa321a8): undefined reference to `bad_dma_ops' drivers/built-in.o:mtk_vpu.c:(.text+0xa321b0): more undefined references to `bad_dma_ops' follow drivers/built-in.o: In function `vchiq_platform_init': >> (.text+0xee0028): undefined reference to `dmam_alloc_coherent' drivers/built-in.o: In function `vchiq_platform_init': (.text+0xee0028): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `dmam_alloc_coherent' sound/built-in.o: In function `snd_pcm_lib_default_mmap': (.text+0xfce0): undefined reference to `bad_dma_ops' sound/built-in.o: In function `snd_pcm_lib_default_mmap': (.text+0xfce4): undefined reference to `bad_dma_ops' sound/built-in.o: In function `snd_pcm_lib_default_mmap': (.text+0xfd34): undefined reference to `dma_common_mmap' sound/built-in.o: In function `snd_pcm_lib_default_mmap': (.text+0xfd34): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `dma_common_mmap' sound/built-in.o: In function `cygnus_pcm_preallocate_dma_buffer': cygnus-pcm.c:(.text+0x115880): undefined reference to `bad_dma_ops' cygnus-pcm.c:(.text+0x115884): undefined reference to `bad_dma_ops' cygnus-pcm.c:(.text+0x1158b8): undefined reference to `bad_dma_ops' sound/built-in.o: In function `cygnus_dma_free_dma_buffers': cygnus-pcm.c:(.text+0x1159b8): undefined reference to `bad_dma_ops' cygnus-pcm.c:(.text+0x1159c0): undefined reference to `bad_dma_ops' sound/built-in.o:cygnus-pcm.c:(.text+0x115a58): more undefined references to `bad_dma_ops' follow --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: fbtft: Fix too many leading tabs warning
This is a patch to the fb_agm1264k-fl.c file that fixes up the following
issue:
WARNING: Too many leading tabs - consider code refactoring
Add new function iterate_diffusion_matrix() to refactor a piece of code
inside write_vmem().
Signed-off-by: Gustavo A. R. Silva
---
drivers/staging/fbtft/fb_agm1264k-fl.c | 68 ++
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 7561385..a6e3af7 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -264,6 +264,39 @@ construct_line_bitmap(struct fbtft_par *par, u8 *dest,
signed short *src,
}
}
+static void iterate_diffusion_matrix(u32 xres, u32 yres, int x,
+int y, signed short *convert_buf,
+signed short pixel, signed short error)
+{
+ u16 i, j;
+
+ /* diffusion matrix row */
+ for (i = 0; i < DIFFUSING_MATRIX_WIDTH; ++i)
+ /* diffusion matrix column */
+ for (j = 0; j < DIFFUSING_MATRIX_HEIGHT; ++j) {
+ signed short *write_pos;
+ signed char coeff;
+
+ /* skip pixels out of zone */
+ if (x + i < 0 || x + i >= xres || y + j >= yres)
+ continue;
+ write_pos = &convert_buf[(y + j) * xres + x + i];
+ coeff = diffusing_matrix[i][j];
+ if (-1 == coeff)
+ /* pixel itself */
+ *write_pos = pixel;
+ else {
+ signed short p = *write_pos + error * coeff;
+
+ if (p > WHITE)
+ p = WHITE;
+ if (p < BLACK)
+ p = BLACK;
+ *write_pos = p;
+ }
+ }
+}
+
static int write_vmem(struct fbtft_par *par, size_t offset, size_t len)
{
u16 *vmem16 = (u16 *)par->info->screen_buffer;
@@ -303,7 +336,6 @@ static int write_vmem(struct fbtft_par *par, size_t offset,
size_t len)
signed short error_b = pixel - BLACK;
signed short error_w = pixel - WHITE;
signed short error;
- u16 i, j;
/* what color close? */
if (abs(error_b) >= abs(error_w)) {
@@ -318,36 +350,10 @@ static int write_vmem(struct fbtft_par *par, size_t
offset, size_t len)
error /= 8;
- /* diffusion matrix row */
- for (i = 0; i < DIFFUSING_MATRIX_WIDTH; ++i)
- /* diffusion matrix column */
- for (j = 0; j < DIFFUSING_MATRIX_HEIGHT; ++j) {
- signed short *write_pos;
- signed char coeff;
-
- /* skip pixels out of zone */
- if (x + i < 0 ||
- x + i >= par->info->var.xres
- || y + j >= par->info->var.yres)
- continue;
- write_pos = &convert_buf[
- (y + j) * par->info->var.xres +
- x + i];
- coeff = diffusing_matrix[i][j];
- if (coeff == -1)
- /* pixel itself */
- *write_pos = pixel;
- else {
- signed short p = *write_pos +
- error * coeff;
-
- if (p > WHITE)
- p = WHITE;
- if (p < BLACK)
- p = BLACK;
- *write_pos = p;
- }
- }
+ iterate_diffusion_matrix(par->info->var.xres,
+par->info->var.yres,
+x, y, convert_buf,
+pixel, error);
}
/* 1 string = 2 pages */
--
2.5.0
___
devel mailing list
de...@linuxdriverproject
[bug report] staging: lustre: fix comparison between signed and unsigned
Hello Dmitry Eremin,
The patch 97cba1302d89: "staging: lustre: fix comparison between
signed and unsigned" from Sep 18, 2016, leads to the following static
checker warning:
drivers/staging/lustre/lustre/osc/osc_request.c:973 osc_init_grant()
warn: unsigned 'cli->cl_avail_grant' is never less than zero.
drivers/staging/lustre/lustre/osc/osc_request.c
955 static void osc_init_grant(struct client_obd *cli, struct
obd_connect_data *ocd)
956 {
957 /*
958 * ocd_grant is the total grant amount we're expect to hold: if
we've
959 * been evicted, it's the new avail_grant amount,
cl_dirty_pages will
960 * drop to 0 as inflight RPCs fail out; otherwise, it's
avail_grant +
961 * dirty.
962 *
963 * race is tolerable here: if we're evicted, but imp_state
already
964 * left EVICTED state, then cl_dirty_pages must be 0 already.
965 */
966 spin_lock(&cli->cl_loi_list_lock);
967 if (cli->cl_import->imp_state == LUSTRE_IMP_EVICTED)
968 cli->cl_avail_grant = ocd->ocd_grant;
969 else
970 cli->cl_avail_grant = ocd->ocd_grant -
971(cli->cl_dirty_pages <<
PAGE_SHIFT);
972
973 if (cli->cl_avail_grant < 0) {
This used to be long but we made it unsigned long.
974 CWARN("%s: available grant < 0: avail/ocd/dirty
%ld/%u/%ld\n",
975cli->cl_import->imp_obd->obd_name,
cli->cl_avail_grant,
976ocd->ocd_grant, cli->cl_dirty_pages <<
PAGE_SHIFT);
977 /* workaround for servers which do not have the patch
from
978 * LU-2679
979 */
980 cli->cl_avail_grant = ocd->ocd_grant;
981 }
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: iio: fix a MAINTAINERS entry
The "drivers/" part of the path name was missing. Signed-off-by: Dan Carpenter diff --git a/MAINTAINERS b/MAINTAINERS index 0c7d973..63f15c9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -779,7 +779,7 @@ S: Supported F: drivers/iio/*/ad* X: drivers/iio/*/adjd* F: drivers/staging/iio/*/ad* -F: staging/iio/trigger/iio-trig-bfin-timer.c +F: drivers/staging/iio/trigger/iio-trig-bfin-timer.c ANALOG DEVICES INC DMA DRIVERS M: Lars-Peter Clausen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[bug report] staging: lustre: lmv: try all stripes for unknown hash functions
Hello wang di,
The patch 893ab7479263: "staging: lustre: lmv: try all stripes for
unknown hash functions" from Aug 16, 2016, leads to the following
static checker warning:
drivers/staging/lustre/lustre/lmv/lmv_intent.c:397 lmv_intent_lookup()
error: 'tgt' dereferencing possible ERR_PTR()
drivers/staging/lustre/lustre/lmv/lmv_intent.c
361 struct ptlrpc_request **reqp,
362 ldlm_blocking_callback cb_blocking,
363 __u64 extra_lock_flags)
364 {
365 struct lmv_stripe_md *lsm = op_data->op_mea1;
366 struct obd_device *obd = exp->exp_obd;
367 struct lmv_obd *lmv = &obd->u.lmv;
368 struct lmv_tgt_desc*tgt = NULL;
369 struct mdt_body *body;
370 int rc = 0;
371
372 /*
373 * If it returns ERR_PTR(-EBADFD) then it is an unknown hash
type
374 * it will try all stripes to locate the object
375 */
I have read this comment so I assume that this warning is a false
positive.
376 tgt = lmv_locate_mds(lmv, op_data, &op_data->op_fid1);
377 if (IS_ERR(tgt) && (PTR_ERR(tgt) != -EBADFD))
378 return PTR_ERR(tgt);
379
380 /*
381 * Both migrating dir and unknown hash dir need to try
382 * all of sub-stripes
383 */
384 if (lsm && !lmv_is_known_hash_type(lsm->lsm_md_hash_type)) {
But really, it's pretty ugly to assume that -EBADFD implies that lsm is
non-NULL and lmv_is_known_hash_type() will return false.
385 struct lmv_oinfo *oinfo = &lsm->lsm_md_oinfo[0];
386
387 op_data->op_fid1 = oinfo->lmo_fid;
388 op_data->op_mds = oinfo->lmo_mds;
389 tgt = lmv_get_target(lmv, oinfo->lmo_mds, NULL);
390 if (IS_ERR(tgt))
391 return PTR_ERR(tgt);
392 }
393
394 if (!fid_is_sane(&op_data->op_fid2))
395 fid_zero(&op_data->op_fid2);
396
397 CDEBUG(D_INODE, "LOOKUP_INTENT with fid1=" DFID ", fid2=" DFID
", name='%s' -> mds #%u lsm=%p lsm_magic=%x\n",
398 PFID(&op_data->op_fid1), PFID(&op_data->op_fid2),
399 op_data->op_name ? op_data->op_name : "",
400 tgt->ltd_idx, lsm, !lsm ? -1 : lsm->lsm_md_magic);
401
402 op_data->op_bias &= ~MDS_CROSS_REF;
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[bug report] staging: lustre: create striped directory
Hello wang di,
The patch 2de353860782: "staging: lustre: create striped directory"
from Aug 16, 2016, leads to the following static checker warning:
drivers/staging/lustre/lustre/llite/namei.c:294 ll_md_blocking_ast()
warn: 'master_inode' isn't an ERR_PTR
drivers/staging/lustre/lustre/llite/namei.c
287
288 hash = cl_fid_build_ino(&lli->lli_pfid,
289
ll_need_32bit_api(ll_i2sbi(inode)));
290
291 master_inode = ilookup5(inode->i_sb,
hash,
292
ll_test_inode_by_fid,
293 (void
*)&lli->lli_pfid);
294 if (master_inode &&
!IS_ERR(master_inode)) {
ilookup5() never returns ERR_PTRs.
295
ll_invalidate_negative_children(master_inode);
296 iput(master_inode);
297 }
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [bug report] staging: lustre: lmv: try all stripes for unknown hash functions
Hello,
>
> 376 tgt = lmv_locate_mds(lmv, op_data, &op_data->op_fid1);
> 377 if (IS_ERR(tgt) && (PTR_ERR(tgt) != -EBADFD))
> 378 return PTR_ERR(tgt);
> 379
> 380 /*
> 381 * Both migrating dir and unknown hash dir need to try
> 382 * all of sub-stripes
> 383 */
> 384 if (lsm &&
>!lmv_is_known_hash_type(lsm->lsm_md_hash_type)) {
>
>But really, it's pretty ugly to assume that -EBADFD implies that lsm is
>non-NULL and lmv_is_known_hash_type() will return false.
>
Yes, it might be a bit improper to use -EBADFD here to indicate this
special scenario, or it can be
if (IS_ERR(tgt)) {
if (PTR_ERR(tgt) != -EBADFD) /* hmm, this might not needed, needs
further check */
return PTR_ERR(tgt);
if (lsm && !lmv_is_known_hash_type(lsm->lsm_md_hash_type)) {
ŠŠ..
} else {
return PTR_ERR(tgt);
}
}
Thanks
WangDi
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [bug report] staging: lustre: create striped directory
Hello,
On 10/11/16, 4:37 AM, "Dan Carpenter" wrote:
>Hello wang di,
>
>The patch 2de353860782: "staging: lustre: create striped directory"
>from Aug 16, 2016, leads to the following static checker warning:
>
> drivers/staging/lustre/lustre/llite/namei.c:294 ll_md_blocking_ast()
> warn: 'master_inode' isn't an ERR_PTR
>
>drivers/staging/lustre/lustre/llite/namei.c
> 287
> 288 hash =
>cl_fid_build_ino(&lli->lli_pfid,
> 289
>ll_need_32bit_api(ll_i2sbi(inode)));
> 290
> 291 master_inode =
>ilookup5(inode->i_sb, hash,
> 292
>ll_test_inode_by_fid,
> 293 (void
>*)&lli->lli_pfid);
> 294 if (master_inode &&
>!IS_ERR(master_inode)) {
>
>
>ilookup5() never returns ERR_PTRs.
Yes, only master_inode != NULL should be enough here.
Thanks
WangDi
>
> 295
>ll_invalidate_negative_children(master_inode);
> 296 iput(master_inode);
> 297 }
>
>regards,
>dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: iio: fix a MAINTAINERS entry
On 11/10/16 12:12, Dan Carpenter wrote: > The "drivers/" part of the path name was missing. > > Signed-off-by: Dan Carpenter Applied - thanks. Jonathan > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0c7d973..63f15c9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -779,7 +779,7 @@ S:Supported > F: drivers/iio/*/ad* > X: drivers/iio/*/adjd* > F: drivers/staging/iio/*/ad* > -F: staging/iio/trigger/iio-trig-bfin-timer.c > +F: drivers/staging/iio/trigger/iio-trig-bfin-timer.c > > ANALOG DEVICES INC DMA DRIVERS > M: Lars-Peter Clausen > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging:greybus:arche-apb-ctrl: fixed some coding style issue
fixed trailing */ Block comments and 80 character line limit coding style issue
Signed-off-by: Nadim Almas
---
drivers/staging/greybus/arche-apb-ctrl.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/arche-apb-ctrl.c
b/drivers/staging/greybus/arche-apb-ctrl.c
index 70323aa..eeba912 100644
--- a/drivers/staging/greybus/arche-apb-ctrl.c
+++ b/drivers/staging/greybus/arche-apb-ctrl.c
@@ -168,7 +168,10 @@ static int standby_boot_seq(struct platform_device *pdev)
if (apb->init_disabled)
return 0;
- /* Even if it is in OFF state, then we do not want to change the state
*/
+ /*
+* Even if it is in OFF state,
+* then we do not want to change the state
+*/
if (apb->state == ARCHE_PLATFORM_STATE_STANDBY ||
apb->state == ARCHE_PLATFORM_STATE_OFF)
return 0;
@@ -183,7 +186,7 @@ static int standby_boot_seq(struct platform_device *pdev)
* Pasted from WDM spec,
* - A falling edge on POWEROFF_L is detected (a)
* - WDM enters standby mode, but no output signals are changed
-* */
+*/
/* TODO: POWEROFF_L is input to WDM module */
apb->state = ARCHE_PLATFORM_STATE_STANDBY;
@@ -286,7 +289,8 @@ static ssize_t state_store(struct device *dev,
return count;
/* First we want to make sure we power off everything
-* and then enter FW flashing state */
+* and then enter FW flashing state
+*/
poweroff_seq(pdev);
ret = fw_flashing_seq(pdev);
} else {
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace
Adding led support for phy causes namespace conflicts for some
phy drivers.
The marvel skge driver declared an enum for representing the states of
Link LED Register. The enum contained constant LED_OFF which conflicted
with declartation found in linux/leds.h.
LED_OFF changed to LED_REG_OFF
Also changed LED_ON to LED_REG_ON to avoid possible future conflict and
for consistency.
Signed-off-by: Zach Brown
---
drivers/net/ethernet/marvell/skge.c | 6 +++---
drivers/net/ethernet/marvell/skge.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c
b/drivers/net/ethernet/marvell/skge.c
index 7173836..783df01 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -1048,7 +1048,7 @@ static const char *skge_pause(enum pause_status status)
static void skge_link_up(struct skge_port *skge)
{
skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG),
- LED_BLK_OFF|LED_SYNC_OFF|LED_ON);
+ LED_BLK_OFF|LED_SYNC_OFF|LED_REG_ON);
netif_carrier_on(skge->netdev);
netif_wake_queue(skge->netdev);
@@ -1062,7 +1062,7 @@ static void skge_link_up(struct skge_port *skge)
static void skge_link_down(struct skge_port *skge)
{
- skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+ skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
netif_carrier_off(skge->netdev);
netif_stop_queue(skge->netdev);
@@ -2668,7 +2668,7 @@ static int skge_down(struct net_device *dev)
if (hw->ports == 1)
free_irq(hw->pdev->irq, hw);
- skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+ skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
if (is_genesis(hw))
genesis_stop(skge);
else
diff --git a/drivers/net/ethernet/marvell/skge.h
b/drivers/net/ethernet/marvell/skge.h
index a2eb341..3ea151f 100644
--- a/drivers/net/ethernet/marvell/skge.h
+++ b/drivers/net/ethernet/marvell/skge.h
@@ -662,8 +662,8 @@ enum {
LED_BLK_OFF = 1<<4, /* Link LED Blinking Off */
LED_SYNC_ON = 1<<3, /* Use Sync Wire to switch LED */
LED_SYNC_OFF= 1<<2, /* Disable Sync Wire Input */
- LED_ON = 1<<1, /* switch LED on */
- LED_OFF = 1<<0, /* switch LED off */
+ LED_REG_ON = 1<<1, /* switch LED on */
+ LED_REG_OFF = 1<<0, /* switch LED off */
};
/* Receive GMAC FIFO (YUKON) */
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change
From: Josh Cartwright
Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
create a set of led triggers for each instantiated PHY device. There is
one LED trigger per link-speed, per-phy.
This allows for a user to configure their system to allow a set of LEDs
to represent link state changes on the phy.
Signed-off-by: Josh Cartwright
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 13 +++-
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_device.c | 4 ++
drivers/net/phy/phy_led_triggers.c | 121 +
include/linux/phy.h| 9 +++
include/linux/phy_led_triggers.h | 52
7 files changed, 200 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/phy_led_triggers.c
create mode 100644 include/linux/phy_led_triggers.h
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d..4fd912d 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -25,6 +25,18 @@ config MDIO_BCM_IPROC
This module provides a driver for the MDIO busses found in the
Broadcom iProc SoC's.
+config LED_TRIGGER_PHY
+ bool "Support LED triggers for tracking link state"
+ depends on LEDS_TRIGGERS
+ ---help---
+ Adds support for a set of LED trigger events per-PHY. Link
+ state change will trigger the events, for consumption by an
+ LED class driver. There are triggers for each link speed,
+ and are of the form:
+ ::
+
+ Where speed is one of: 10Mbps, 100Mbps, 1Gbps, 2.5Gbps, or 10Gbps.
+
config MDIO_BCM_UNIMAC
tristate "Broadcom UniMAC MDIO bus controller"
depends on HAS_IOMEM
@@ -40,7 +52,6 @@ config MDIO_BITBANG
This module implements the MDIO bus protocol in software,
for use by low level drivers that export the ability to
drive the relevant pins.
-
If in doubt, say N.
config MDIO_BUS_MUX
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..86d12cd 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,6 +2,7 @@
libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o
libphy-$(CONFIG_SWPHY) += swphy.o
+libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
obj-$(CONFIG_PHYLIB) += libphy.o
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f5721db..e5f9fee7 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -896,6 +896,7 @@ EXPORT_SYMBOL(phy_start);
static void phy_adjust_link(struct phy_device *phydev)
{
phydev->adjust_link(phydev->attached_dev);
+ phy_led_trigger_change_speed(phydev);
}
/**
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e977ba9..4671c13 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +58,7 @@ static void phy_mdio_device_free(struct mdio_device *mdiodev)
static void phy_device_release(struct device *dev)
{
+ phy_led_triggers_unregister(to_phy_device(dev));
kfree(to_phy_device(dev));
}
@@ -345,6 +347,8 @@ struct phy_device *phy_device_create(struct mii_bus *bus,
int addr, int phy_id,
dev->state = PHY_DOWN;
+ phy_led_triggers_register(dev);
+
mutex_init(&dev->lock);
INIT_DELAYED_WORK(&dev->state_queue, phy_state_machine);
INIT_WORK(&dev->phy_queue, phy_change);
diff --git a/drivers/net/phy/phy_led_triggers.c
b/drivers/net/phy/phy_led_triggers.c
new file mode 100644
index 000..32326d7
--- /dev/null
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -0,0 +1,121 @@
+/* Copyright (C) 2016 National Instruments Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+
+static struct phy_led_trigger *phy_speed_to_led_trigger(struct phy_device *phy,
+ unsigned int speed)
+{
+ switch (speed) {
+ case SPEED_10:
+ return &phy->phy_led_trigger[0];
+ case SPEED_100:
+ return &phy->phy_led_trigger[1];
+ case SPEED_1000:
+ return &phy->phy_led_trigger[2];
+ case SPEED_2500:
+ return &phy->phy_led_trigger[3];
+ case SPEED_1:
+
[PATCH v4 0/3] Add support for led triggers on phy link state change
Fix skge driver that declared enum contants that conflicted with enum constants in linux/leds.h Create function that encapsulates actions taken during the adjust phy link step of phy state changes. Add support for led triggers on phy link state changes by adding a config option. When set the config option will create a set of led triggers for each phy device. Users can use the led triggers to represent link state changes on the phy. v2: * New patch that creates phy_adjust_link function to encapsulate actions taken when adjusting phy link during phy state changes * led trigger speed strings changed to match existing phy speed strings * New function that maps speeds to led triggers * Replace magic constants with definitions when declaring trigger name buffer and number of triggers. v3: * Changed LED_ON to LED_REG_ON in skge driver to avoid possible future conflict and improve consistency. * Dropped rtl8712 patch that was accepted separately. v4: * tweaked commit message Josh Cartwright (1): net: phy: leds: add support for led triggers on phy link state change Zach Brown (2): skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace net: phy: Encapsulate actions performed during link state changes into function phy_adjust_link drivers/net/ethernet/marvell/skge.c | 6 +- drivers/net/ethernet/marvell/skge.h | 4 +- drivers/net/phy/Kconfig | 13 +++- drivers/net/phy/Makefile| 1 + drivers/net/phy/phy.c | 22 --- drivers/net/phy/phy_device.c| 4 ++ drivers/net/phy/phy_led_triggers.c | 121 include/linux/phy.h | 9 +++ include/linux/phy_led_triggers.h| 52 9 files changed, 218 insertions(+), 14 deletions(-) create mode 100644 drivers/net/phy/phy_led_triggers.c create mode 100644 include/linux/phy_led_triggers.h -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 2/3] net: phy: Encapsulate actions performed during link state changes into function phy_adjust_link
During phy state machine state transitions some set of actions should
occur whenever the link state changes. These actions should be
encapsulated into a single function
This patch adds the phy_adjust_link function, which is called whenever
phydev->adjust_link would have been called before. Actions that should
occur whenever the phy link is adjusted can now be added to the
phy_adjust_link function.
Signed-off-by: Zach Brown
---
drivers/net/phy/phy.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c6f6683..f5721db 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -893,6 +893,11 @@ void phy_start(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_start);
+static void phy_adjust_link(struct phy_device *phydev)
+{
+ phydev->adjust_link(phydev->attached_dev);
+}
+
/**
* phy_state_machine - Handle the state machine
* @work: work_struct that describes the work to be done
@@ -935,7 +940,7 @@ void phy_state_machine(struct work_struct *work)
if (!phydev->link) {
phydev->state = PHY_NOLINK;
netif_carrier_off(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
break;
}
@@ -948,7 +953,7 @@ void phy_state_machine(struct work_struct *work)
if (err > 0) {
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
} else if (0 == phydev->link_timeout--)
needs_aneg = true;
@@ -975,7 +980,7 @@ void phy_state_machine(struct work_struct *work)
}
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
}
break;
case PHY_FORCING:
@@ -991,7 +996,7 @@ void phy_state_machine(struct work_struct *work)
needs_aneg = true;
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
break;
case PHY_RUNNING:
/* Only register a CHANGE if we are polling and link changed
@@ -1020,7 +1025,7 @@ void phy_state_machine(struct work_struct *work)
netif_carrier_off(phydev->attached_dev);
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
if (phy_interrupt_is_valid(phydev))
err = phy_config_interrupt(phydev,
@@ -1030,7 +1035,7 @@ void phy_state_machine(struct work_struct *work)
if (phydev->link) {
phydev->link = 0;
netif_carrier_off(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
do_suspend = true;
}
break;
@@ -1054,7 +1059,7 @@ void phy_state_machine(struct work_struct *work)
} else {
phydev->state = PHY_NOLINK;
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
} else {
phydev->state = PHY_AN;
phydev->link_timeout = PHY_AN_TIMEOUT;
@@ -1070,7 +1075,7 @@ void phy_state_machine(struct work_struct *work)
} else {
phydev->state = PHY_NOLINK;
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
}
break;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace
On Tue, 11 Oct 2016 15:26:18 -0500 Zach Brown wrote: > Adding led support for phy causes namespace conflicts for some > phy drivers. > > The marvel skge driver declared an enum for representing the states of > Link LED Register. The enum contained constant LED_OFF which conflicted > with declartation found in linux/leds.h. > LED_OFF changed to LED_REG_OFF > Also changed LED_ON to LED_REG_ON to avoid possible future conflict and > for consistency. > > Signed-off-by: Zach Brown Sure, that's fine but not sure why skge would be including linux/leds.h anyway. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC v3 3/3] phy,leds: add support for led triggers on phy link state change
> Andrew, are you happy with this implementation? Sorry, been to busy with other things to follow the discussion. What would be nice to see is a comment about how the link to LEDs in the PHYs is made. Often there is a couple of LEDs in the RJ45 socket driven by the PHY. They can show link, speed, packet Rx/Tx, etc. How are these triggers related to these LEDs? Andrew ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace
On Tue, Oct 11, 2016 at 02:14:07PM -0700, Stephen Hemminger wrote: > On Tue, 11 Oct 2016 15:26:18 -0500 > Zach Brown wrote: > > > Adding led support for phy causes namespace conflicts for some > > phy drivers. > > > > The marvel skge driver declared an enum for representing the states of > > Link LED Register. The enum contained constant LED_OFF which conflicted > > with declartation found in linux/leds.h. > > LED_OFF changed to LED_REG_OFF > > Also changed LED_ON to LED_REG_ON to avoid possible future conflict and > > for consistency. > > > > Signed-off-by: Zach Brown > > Sure, that's fine but not sure why skge would be including linux/leds.h > anyway. It's pretty convoluted. Here's the chain of includes. skge -> netdevice -> dsa -> phy -> phy_led_triggers -> leds ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 32/41] staging: lustre: llite: restart short read/write for normal IO
> On Sun, Oct 02, 2016 at 10:28:28PM -0400, James Simmons wrote: > > From: Bobi Jam > > > > If normal IO got short read/write, we'd restart the IO from where > > we've accomplished until we meet EOF or error happens. > > > > Signed-off-by: Bobi Jam > > Signed-off-by: Jinshan Xiong > > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6389 > > Reviewed-on: http://review.whamcloud.com/14123 > > Reviewed-by: Andreas Dilger > > Reviewed-by: Oleg Drokin > > Signed-off-by: James Simmons > > --- > > drivers/staging/lustre/lnet/libcfs/fail.c |1 + > > .../staging/lustre/lustre/include/obd_support.h|2 + > > drivers/staging/lustre/lustre/llite/file.c | 41 > > > > drivers/staging/lustre/lustre/llite/vvp_io.c | 19 - > > 4 files changed, 45 insertions(+), 18 deletions(-) > > Due to other changes in the filesystem tree, this patch no longer > applies :( > > Can you rebase it and resend? How long will you be accepting patches to merge for? If its going to be a few weeks like to just include the missing two patches with the next batch. Another issue I need to look at is the IB changes. That's going to require some heavy surgery to the ko2iblnd driver so its going to take time for me to port this to the new RDMA RW api. That will need to be push to linus so ko2iblnd can work with the 4.9 tree if that is okay with you. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: staging: greybus: audio_manager_sysfs.c: Fixed CHECK for brace issue
Added braces to else and else if statements where checkpatch complained.
Signed-off-by: Chase Metzger
---
drivers/staging/greybus/audio_manager_sysfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/audio_manager_sysfs.c
b/drivers/staging/greybus/audio_manager_sysfs.c
index d8bf859..376e17c 100644
--- a/drivers/staging/greybus/audio_manager_sysfs.c
+++ b/drivers/staging/greybus/audio_manager_sysfs.c
@@ -71,10 +71,11 @@ static ssize_t manager_sysfs_dump_store(
num = gb_audio_manager_dump_module(id);
if (num)
return num;
- } else if (!strncmp("all", buf, 3))
+ } else if (!strncmp("all", buf, 3)) {
gb_audio_manager_dump_all();
- else
+ } else {
return -EINVAL;
+ }
return count;
}
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: staging: greybus: audio_topology.c: Fixed CHECKS for brace issues
Added braces for else and else if statements where checkpatch complained.
Signed-off-by: Chase Metzger
---
drivers/staging/greybus/audio_topology.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/audio_topology.c
b/drivers/staging/greybus/audio_topology.c
index b625169..3a2678e 100644
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -1044,8 +1044,10 @@ static int gbaudio_tplg_create_widget(struct
gbaudio_module_info *module,
control->texts = (const char * const *)
gb_generate_enum_strings(module, gbenum);
control->items = gbenum->items;
- } else
+ } else {
csize = sizeof(struct gb_audio_control);
+ }
+
*w_size += csize;
curr = (void *)curr + csize;
list_add(&control->list, &module->widget_ctl_list);
@@ -1190,8 +1192,9 @@ static int gbaudio_tplg_process_kcontrols(struct
gbaudio_module_info *module,
control->texts = (const char * const *)
gb_generate_enum_strings(module, gbenum);
control->items = gbenum->items;
- } else
+ } else {
csize = sizeof(struct gb_audio_control);
+ }
list_add(&control->list, &module->ctl_list);
dev_dbg(module->dev, "%d:%s created of type %d\n", curr->id,
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC 1/6] fs: add installed and uninstalled file_operations
These optional file_operations notify a file implementation when it is
installed or uninstalled from a task's fd table. This can be used for
accounting of file-backed shared resources like dma-buf.
This involves some changes to the __fd_install() and __close_fd() APIs
to actually pass along the responsible task_struct. These are low-level
APIs with only two in-tree callers, both adjusted in this patch.
Signed-off-by: Greg Hackmann
Signed-off-by: Ruchi Kandoi
---
drivers/android/binder.c | 4 ++--
fs/file.c| 38 +-
fs/open.c| 2 +-
include/linux/fdtable.h | 4 ++--
include/linux/fs.h | 2 ++
5 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 562af94..0bb174e 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -398,7 +398,7 @@ static void task_fd_install(
struct binder_proc *proc, unsigned int fd, struct file *file)
{
if (proc->files)
- __fd_install(proc->files, fd, file);
+ __fd_install(proc->tsk, fd, file);
}
/*
@@ -411,7 +411,7 @@ static long task_close_fd(struct binder_proc *proc,
unsigned int fd)
if (proc->files == NULL)
return -ESRCH;
- retval = __close_fd(proc->files, fd);
+ retval = __close_fd(proc->tsk, fd);
/* can't restart close syscall because file table entry was cleared */
if (unlikely(retval == -ERESTARTSYS ||
retval == -ERESTARTNOINTR ||
diff --git a/fs/file.c b/fs/file.c
index 69d6990..19c5fad 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -282,6 +282,24 @@ static unsigned int count_open_files(struct fdtable *fdt)
return i;
}
+static inline void fdt_install(struct fdtable *fdt, int fd, struct file *file,
+ struct task_struct *task)
+{
+ if (file->f_op->installed)
+ file->f_op->installed(file, task);
+ rcu_assign_pointer(fdt->fd[fd], file);
+}
+
+static inline void fdt_uninstall(struct fdtable *fdt, int fd,
+ struct task_struct *task)
+{
+ struct file *old_file = fdt->fd[fd];
+
+ if (old_file->f_op->uninstalled)
+ old_file->f_op->uninstalled(old_file, task);
+ rcu_assign_pointer(fdt->fd[fd], NULL);
+}
+
/*
* Allocate a new files structure and copy contents from the
* passed in files structure.
@@ -543,7 +561,7 @@ int __alloc_fd(struct files_struct *files,
/* Sanity check */
if (rcu_access_pointer(fdt->fd[fd]) != NULL) {
printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd);
- rcu_assign_pointer(fdt->fd[fd], NULL);
+ fdt_uninstall(fdt, fd, current);
}
#endif
@@ -601,10 +619,11 @@ EXPORT_SYMBOL(put_unused_fd);
* fd_install() instead.
*/
-void __fd_install(struct files_struct *files, unsigned int fd,
+void __fd_install(struct task_struct *task, unsigned int fd,
struct file *file)
{
struct fdtable *fdt;
+ struct files_struct *files = task->files;
might_sleep();
rcu_read_lock_sched();
@@ -618,13 +637,13 @@ void __fd_install(struct files_struct *files, unsigned
int fd,
smp_rmb();
fdt = rcu_dereference_sched(files->fdt);
BUG_ON(fdt->fd[fd] != NULL);
- rcu_assign_pointer(fdt->fd[fd], file);
+ fdt_install(fdt, fd, file, task);
rcu_read_unlock_sched();
}
void fd_install(unsigned int fd, struct file *file)
{
- __fd_install(current->files, fd, file);
+ __fd_install(current, fd, file);
}
EXPORT_SYMBOL(fd_install);
@@ -632,10 +651,11 @@ EXPORT_SYMBOL(fd_install);
/*
* The same warnings as for __alloc_fd()/__fd_install() apply here...
*/
-int __close_fd(struct files_struct *files, unsigned fd)
+int __close_fd(struct task_struct *task, unsigned fd)
{
struct file *file;
struct fdtable *fdt;
+ struct files_struct *files = task->files;
spin_lock(&files->file_lock);
fdt = files_fdtable(files);
@@ -644,7 +664,7 @@ int __close_fd(struct files_struct *files, unsigned fd)
file = fdt->fd[fd];
if (!file)
goto out_unlock;
- rcu_assign_pointer(fdt->fd[fd], NULL);
+ fdt_uninstall(fdt, fd, task);
__clear_close_on_exec(fd, fdt);
__put_unused_fd(files, fd);
spin_unlock(&files->file_lock);
@@ -679,7 +699,7 @@ void do_close_on_exec(struct files_struct *files)
file = fdt->fd[fd];
if (!file)
continue;
- rcu_assign_pointer(fdt->fd[fd], NULL);
+ fdt_uninstall(fdt, fd, current);
__put_unused_fd(files, fd);
spin_unlock(&files->file_lock);
filp_close(file, files);
@@ -846,7 +866,7 @@ __releases(&files->file_lock)
if (!tofree && fd_is_ope
[RFC 0/6] Module for tracking/accounting shared memory buffers
This patchstack introduces a new "memtrack" module for tracking and accounting
memory exported to userspace as shared buffers, like dma-buf fds or GEM handles.
Any process holding a reference to these buffers will keep the kernel from
reclaiming its backing pages. mm counters don't provide a complete picture of
these allocations, since they only account for pages that are mapped into a
process's address space. This problem is especially bad for systems like
Android that use dma-buf fds to share graphics and multimedia buffers between
processes: these allocations are often large, have complex sharing patterns,
and are rarely mapped into every process that holds a reference to them.
memtrack maintains a per-process list of shared buffer references, which is
exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally
"tagged" with a short string: for example, Android userspace would use this
tag to identify whether buffers were allocated on behalf of the camera stack,
GL, etc. memtrack also exports the VMAs associated with these buffers so
that pages already included in the process's mm counters aren't double-counted.
Shared-buffer allocators can hook into memtrack by embedding
struct memtrack_buffer in their buffer metadata, calling
memtrack_buffer_{init,remove} at buffer allocation and free time, and
memtrack_buffer_{install,uninstall} when a userspace process takes or
drops a reference to the buffer. For fd-backed buffers like dma-bufs, hooks in
fdtable.c and fork.c automatically notify memtrack when references are added or
removed from a process's fd table.
This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream
interest in memtrack, it can be extended to other memory allocators as well,
such as GEM implementations.
Greg Hackmann (1):
drivers: staging: ion: add ION_IOC_TAG ioctl
Ruchi Kandoi (5):
fs: add installed and uninstalled file_operations
drivers: misc: add memtrack
dma-buf: add memtrack support
memtrack: Adds the accounting to keep track of all mmaped/unmapped
pages.
memtrack: Add memtrack accounting for forked processes.
drivers/android/binder.c| 4 +-
drivers/dma-buf/dma-buf.c | 37 +++
drivers/misc/Kconfig| 16 +
drivers/misc/Makefile | 1 +
drivers/misc/memtrack.c | 516
drivers/staging/android/ion/ion-ioctl.c | 17 ++
drivers/staging/android/ion/ion.c | 60 +++-
drivers/staging/android/ion/ion_priv.h | 2 +
drivers/staging/android/uapi/ion.h | 25 ++
fs/file.c | 38 ++-
fs/open.c | 2 +-
fs/proc/base.c | 4 +
include/linux/dma-buf.h | 5 +
include/linux/fdtable.h | 4 +-
include/linux/fs.h | 2 +
include/linux/memtrack.h| 130
include/linux/mm.h | 3 +
include/linux/sched.h | 3 +
kernel/fork.c | 23 +-
19 files changed, 875 insertions(+), 17 deletions(-)
create mode 100644 drivers/misc/memtrack.c
create mode 100644 include/linux/memtrack.h
--
2.8.0.rc3.226.g39d4020
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC 5/6] memtrack: Add memtrack accounting for forked processes.
When a process is forked, all the buffers are shared with the forked
process too. Adds the functionality to add memtrack accounting for the
forked processes.
Forked process gets a copy of the mapped pages of the parent process.
This patch makes sure that the new mapped pages are attributed to the
child process instead of the parent.
Signed-off-by: Ruchi Kandoi
---
drivers/misc/memtrack.c | 45 +++
drivers/staging/android/ion/ion.c | 45 +--
include/linux/memtrack.h | 19 +++--
include/linux/mm.h| 3 +++
kernel/fork.c | 19 +++--
5 files changed, 117 insertions(+), 14 deletions(-)
diff --git a/drivers/misc/memtrack.c b/drivers/misc/memtrack.c
index 4b2d17f..fa2601a 100644
--- a/drivers/misc/memtrack.c
+++ b/drivers/misc/memtrack.c
@@ -204,12 +204,13 @@ EXPORT_SYMBOL(memtrack_buffer_uninstall);
* @buffer: the buffer's memtrack entry
*
* @vma: vma being opened
+ * @task: task which mapped the pages
*/
void memtrack_buffer_vm_open(struct memtrack_buffer *buffer,
- const struct vm_area_struct *vma)
+ const struct vm_area_struct *vma, struct task_struct *task)
{
unsigned long flags;
- struct task_struct *leader = current->group_leader;
+ struct task_struct *leader = task->group_leader;
struct memtrack_vma_list *vma_list;
vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL);
@@ -228,12 +229,13 @@ EXPORT_SYMBOL(memtrack_buffer_vm_open);
*
* @buffer: the buffer's memtrack entry
* @vma: the vma being closed
+ * @task: task that mmaped the pages
*/
void memtrack_buffer_vm_close(struct memtrack_buffer *buffer,
- const struct vm_area_struct *vma)
+ const struct vm_area_struct *vma, struct task_struct *task)
{
unsigned long flags;
- struct task_struct *leader = current->group_leader;
+ struct task_struct *leader = task->group_leader;
write_lock_irqsave(&leader->memtrack_lock, flags);
memtrack_buffer_vm_close_locked(&leader->memtrack_rb, buffer, vma);
@@ -241,6 +243,41 @@ void memtrack_buffer_vm_close(struct memtrack_buffer
*buffer,
}
EXPORT_SYMBOL(memtrack_buffer_vm_close);
+/**
+ * memtrack_buffer_install_fork - Install all parent's handles into
+ * child.
+ *
+ * @parent: parent task
+ * @child: child task
+ */
+void memtrack_buffer_install_fork(struct task_struct *parent,
+ struct task_struct *child)
+{
+ struct task_struct *leader, *leader_child;
+ struct rb_root *root;
+ struct rb_node *node;
+ unsigned long flags;
+
+ if (!child || !parent)
+ return;
+
+ leader = parent->group_leader;
+ leader_child = child->group_leader;
+ write_lock_irqsave(&leader->memtrack_lock, flags);
+ root = &leader->memtrack_rb;
+ node = rb_first(root);
+ while (node) {
+ struct memtrack_handle *handle;
+
+ handle = rb_entry(node, struct memtrack_handle, node);
+ memtrack_buffer_install_locked(&leader_child->memtrack_rb,
+ handle->buffer);
+ node = rb_next(node);
+ }
+ write_unlock_irqrestore(&leader->memtrack_lock, flags);
+}
+EXPORT_SYMBOL(memtrack_buffer_install_fork);
+
static int memtrack_id_alloc(struct memtrack_buffer *buffer)
{
int ret;
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index c32d520..451aa0f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -906,7 +906,7 @@ static void ion_vm_open(struct vm_area_struct *vma)
list_add(&vma_list->list, &buffer->vmas);
mutex_unlock(&buffer->lock);
pr_debug("%s: adding %p\n", __func__, vma);
- memtrack_buffer_vm_open(&buffer->memtrack_buffer, vma);
+ memtrack_buffer_vm_open(&buffer->memtrack_buffer, vma, current);
}
static void ion_vm_close(struct vm_area_struct *vma)
@@ -925,13 +925,51 @@ static void ion_vm_close(struct vm_area_struct *vma)
break;
}
mutex_unlock(&buffer->lock);
- memtrack_buffer_vm_close(&buffer->memtrack_buffer, vma);
+ memtrack_buffer_vm_close(&buffer->memtrack_buffer, vma, current);
+}
+
+void vm_track(struct vm_area_struct *vma, struct task_struct *task)
+{
+ struct ion_buffer *buffer = vma->vm_private_data;
+
+ memtrack_buffer_vm_open(&buffer->memtrack_buffer, vma, task);
+}
+
+void vm_untrack(struct vm_area_struct *vma, struct task_struct *task)
+{
+ struct ion_buffer *buffer = vma->vm_private_data;
+
+ memtrack_buffer_vm_close(&buffer->memtrack_buffer, vma, task);
}
static const struct vm_operations_struct ion_vma_ops = {
.open = ion_vm_open,
.close = ion_vm_close,
.fault = ion_vm_fault,
+ .track = vm_track,
+ .untrack = vm_untrack,
+};
+
Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote:
> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc. memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't
> double-counted.
>
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer. For fd-backed buffers like dma-bufs, hooks
> in
> fdtable.c and fork.c automatically notify memtrack when references are added
> or
> removed from a process's fd table.
>
> This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.
No, with a side of Hell, No. Not to mention anything else,
* descriptor tables do not belong to any specific task_struct and
actions done by one show up in all who share that thing.
* shared descriptor table does not imply belonging to the same
group.
* shared descriptor table can become unshared at any point, invisibly
for that Fine Piece Of Software.
* while we are at it, blocking allocation under several spinlocks
(and with interrupts disabled, for good measure) is generally considered
a bloody bad idea.
That - just from the quick look through that patchset. Bringing task_struct
into the API is already sufficient for a NAK.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
On Tue, Oct 11, 2016 at 7:50 PM, Ruchi Kandoi wrote:
> This patchstack introduces a new "memtrack" module for tracking and accounting
> memory exported to userspace as shared buffers, like dma-buf fds or GEM
> handles.
btw, I wouldn't care much about the non-dmabuf case.. dri2/flink is
kind of legacy and the sharing patterns there are not so complex that
we have found the need for any more elaborate debug infrastructure
than what we already have.
Between existing dmabuf debugfs, and /proc/*/maps (and /proc/*/fd?), I
wonder what is missing? Maybe there is a less intrusive way to get at
the debugging info you want?
BR,
-R
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address space. This problem is especially bad for systems like
> Android that use dma-buf fds to share graphics and multimedia buffers between
> processes: these allocations are often large, have complex sharing patterns,
> and are rarely mapped into every process that holds a reference to them.
>
> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc. memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't
> double-counted.
>
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer. For fd-backed buffers like dma-bufs, hooks
> in
> fdtable.c and fork.c automatically notify memtrack when references are added
> or
> removed from a process's fd table.
>
> This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.
>
> Greg Hackmann (1):
> drivers: staging: ion: add ION_IOC_TAG ioctl
>
> Ruchi Kandoi (5):
> fs: add installed and uninstalled file_operations
> drivers: misc: add memtrack
> dma-buf: add memtrack support
> memtrack: Adds the accounting to keep track of all mmaped/unmapped
> pages.
> memtrack: Add memtrack accounting for forked processes.
>
> drivers/android/binder.c| 4 +-
> drivers/dma-buf/dma-buf.c | 37 +++
> drivers/misc/Kconfig| 16 +
> drivers/misc/Makefile | 1 +
> drivers/misc/memtrack.c | 516
>
> drivers/staging/android/ion/ion-ioctl.c | 17 ++
> drivers/staging/android/ion/ion.c | 60 +++-
> drivers/staging/android/ion/ion_priv.h | 2 +
> drivers/staging/android/uapi/ion.h | 25 ++
> fs/file.c | 38 ++-
> fs/open.c | 2 +-
> fs/proc/base.c | 4 +
> include/linux/dma-buf.h | 5 +
> include/linux/fdtable.h | 4 +-
> include/linux/fs.h | 2 +
> include/linux/memtrack.h| 130
> include/linux/mm.h | 3 +
> include/linux/sched.h | 3 +
> kernel/fork.c | 23 +-
> 19 files changed, 875 insertions(+), 17 deletions(-)
> create mode 100644 drivers/misc/memtrack.c
> create mode 100644 include/linux/memtrack.h
>
> --
> 2.8.0.rc3.226.g39d4020
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] RFC: staging: greybus: shape up greybus GPIO
I was looking to exactly do thanks, thanks for doing it before us :)
On 10-10-16, 10:39, Linus Walleij wrote:
> static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
>const struct gbphy_device_id *id)
> {
> @@ -690,7 +556,6 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
> gpio->get = gb_gpio_get;
> gpio->set = gb_gpio_set;
> gpio->set_debounce = gb_gpio_set_debounce;
> - gpio->to_irq = gb_gpio_to_irq;
> gpio->base = -1;/* Allocate base dynamically */
> gpio->ngpio = ggc->line_max + 1;
> gpio->can_sleep = true;
> @@ -699,26 +564,26 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
> if (ret)
> goto exit_line_free;
>
> - ret = gb_gpio_irqchip_add(gpio, irqc, 0,
> -handle_level_irq, IRQ_TYPE_NONE);
> + ret = devm_gpiochip_add_data(&connection->bundle->dev,
We should be using gbphy_dev->dev here instead.
> + gpio, ggc);
> if (ret) {
> dev_err(&connection->bundle->dev,
And also at these places. I will send a patch to fix these separately though.
> - "failed to add irq chip: %d\n", ret);
> + "failed to add gpio chip: %d\n", ret);
> goto exit_line_free;
> }
>
> - ret = gpiochip_add(gpio);
> + ret = gpiochip_irqchip_add(gpio, irqc,
> +0, handle_level_irq,
> +IRQ_TYPE_NONE);
> if (ret) {
> dev_err(&connection->bundle->dev,
> - "failed to add gpio chip: %d\n", ret);
> - goto exit_gpio_irqchip_remove;
> + "failed to add gpio irqchip: %d\n", ret);
> + goto exit_line_free;
> }
>
> gbphy_runtime_put_autosuspend(gbphy_dev);
> return 0;
>
> -exit_gpio_irqchip_remove:
> - gb_gpio_irqchip_remove(ggc);
> exit_line_free:
> kfree(ggc->lines);
> exit_connection_disable:
> @@ -741,8 +606,6 @@ static void gb_gpio_remove(struct gbphy_device *gbphy_dev)
> gbphy_runtime_get_noresume(gbphy_dev);
>
> gb_connection_disable_rx(connection);
> - gpiochip_remove(&ggc->chip);
This should stay as is, right?
> - gb_gpio_irqchip_remove(ggc);
> gb_connection_disable(connection);
> gb_connection_destroy(connection);
> kfree(ggc->lines);
--
viresh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Staging: greybus: gpio: Use gbphy_dev->dev instead of bundle->dev
Some of the print messages are using the incorrect device pointer, fix
them.
Signed-off-by: Viresh Kumar
---
drivers/staging/greybus/gpio.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 5e06e4229e42..250caa00de5e 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -702,15 +702,13 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
ret = gb_gpio_irqchip_add(gpio, irqc, 0,
handle_level_irq, IRQ_TYPE_NONE);
if (ret) {
- dev_err(&connection->bundle->dev,
- "failed to add irq chip: %d\n", ret);
+ dev_err(&gbphy_dev->dev, "failed to add irq chip: %d\n", ret);
goto exit_line_free;
}
ret = gpiochip_add(gpio);
if (ret) {
- dev_err(&connection->bundle->dev,
- "failed to add gpio chip: %d\n", ret);
+ dev_err(&gbphy_dev->dev, "failed to add gpio chip: %d\n", ret);
goto exit_gpio_irqchip_remove;
}
--
2.7.1.410.g6faf27b
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] Staging: greybus: uart: Use gbphy_dev->dev instead of bundle->dev
Some of the print messages are using the incorrect device pointer, fix
them.
Signed-off-by: Viresh Kumar
---
drivers/staging/greybus/uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 5ee7954bd9f9..2633d2bfb1b4 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -888,7 +888,7 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
minor = alloc_minor(gb_tty);
if (minor < 0) {
if (minor == -ENOSPC) {
- dev_err(&connection->bundle->dev,
+ dev_err(&gbphy_dev->dev,
"no more free minor numbers\n");
retval = -ENODEV;
} else {
--
2.7.1.410.g6faf27b
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl
On Wednesday, October 12, 2016 7:50 AM Ruchi Kandoi wrote:
> +/**
> + * struct ion_fd_data - metadata passed from userspace for a handle
s/fd/tag/ ?
> + * @handle: a handle
> + * @tag: a string describing the buffer
> + *
> + * For ION_IOC_TAG userspace populates the handle field with
> + * the handle returned from ion alloc and type contains the memtrack_type
> which
> + * accurately describes the usage for the memory.
> + */
> +struct ion_tag_data {
> + ion_user_handle_t handle;
> + char tag[ION_MAX_TAG_LEN];
> +};
> +
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: greybus: audio_manager_sysfs.c: Fixed CHECK for brace issue
On Wed, Oct 12, 2016 at 4:52 AM, Chase Metzger wrote:
> Added braces to else and else if statements where checkpatch complained.
>
> Signed-off-by: Chase Metzger
> ---
> drivers/staging/greybus/audio_manager_sysfs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_manager_sysfs.c
> b/drivers/staging/greybus/audio_manager_sysfs.c
> index d8bf859..376e17c 100644
> --- a/drivers/staging/greybus/audio_manager_sysfs.c
> +++ b/drivers/staging/greybus/audio_manager_sysfs.c
> @@ -71,10 +71,11 @@ static ssize_t manager_sysfs_dump_store(
> num = gb_audio_manager_dump_module(id);
> if (num)
> return num;
> - } else if (!strncmp("all", buf, 3))
> + } else if (!strncmp("all", buf, 3)) {
> gb_audio_manager_dump_all();
> - else
> + } else {
> return -EINVAL;
> + }
>
> return count;
> }
> --
> 2.1.4
>
Reviewed-by: Vaibhav Agarwal
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: greybus: audio_topology.c: Fixed CHECKS for brace issues
On Wed, Oct 12, 2016 at 5:19 AM, Chase Metzger wrote:
> Added braces for else and else if statements where checkpatch complained.
>
> Signed-off-by: Chase Metzger
> ---
> drivers/staging/greybus/audio_topology.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_topology.c
> b/drivers/staging/greybus/audio_topology.c
> index b625169..3a2678e 100644
> --- a/drivers/staging/greybus/audio_topology.c
> +++ b/drivers/staging/greybus/audio_topology.c
> @@ -1044,8 +1044,10 @@ static int gbaudio_tplg_create_widget(struct
> gbaudio_module_info *module,
> control->texts = (const char * const *)
> gb_generate_enum_strings(module, gbenum);
> control->items = gbenum->items;
> - } else
> + } else {
> csize = sizeof(struct gb_audio_control);
> + }
> +
> *w_size += csize;
> curr = (void *)curr + csize;
> list_add(&control->list, &module->widget_ctl_list);
> @@ -1190,8 +1192,9 @@ static int gbaudio_tplg_process_kcontrols(struct
> gbaudio_module_info *module,
> control->texts = (const char * const *)
> gb_generate_enum_strings(module, gbenum);
> control->items = gbenum->items;
> - } else
> + } else {
> csize = sizeof(struct gb_audio_control);
> + }
>
> list_add(&control->list, &module->ctl_list);
> dev_dbg(module->dev, "%d:%s created of type %d\n", curr->id,
> --
> 2.1.4
>
You have already submitted a similar patch available on staging-testing branch:
commit b7e0c9eca426 ("drivers: staging: greybus: Fixed CHECKS for brace issues")
--
thanks,
./va
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 32/41] staging: lustre: llite: restart short read/write for normal IO
On Wed, Oct 12, 2016 at 12:22:35AM +0100, James Simmons wrote: > > > On Sun, Oct 02, 2016 at 10:28:28PM -0400, James Simmons wrote: > > > From: Bobi Jam > > > > > > If normal IO got short read/write, we'd restart the IO from where > > > we've accomplished until we meet EOF or error happens. > > > > > > Signed-off-by: Bobi Jam > > > Signed-off-by: Jinshan Xiong > > > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6389 > > > Reviewed-on: http://review.whamcloud.com/14123 > > > Reviewed-by: Andreas Dilger > > > Reviewed-by: Oleg Drokin > > > Signed-off-by: James Simmons > > > --- > > > drivers/staging/lustre/lnet/libcfs/fail.c |1 + > > > .../staging/lustre/lustre/include/obd_support.h|2 + > > > drivers/staging/lustre/lustre/llite/file.c | 41 > > > > > > drivers/staging/lustre/lustre/llite/vvp_io.c | 19 - > > > 4 files changed, 45 insertions(+), 18 deletions(-) > > > > Due to other changes in the filesystem tree, this patch no longer > > applies :( > > > > Can you rebase it and resend? > > How long will you be accepting patches to merge for? If its going > to be a few weeks like to just include the missing two patches with > the next batch. I don't understand the question. I always accept patches, no need to not send them, I'll queue them up to the proper branches as needed. So what do you mean here? > Another issue I need to look at is the IB changes. That's going to > require some heavy surgery to the ko2iblnd driver so its going to > take time for me to port this to the new RDMA RW api. That will > need to be push to linus so ko2iblnd can work with the 4.9 tree > if that is okay with you. Sure, send the patches, but maybe it is a 4.10 thing if it's too much work? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch] staging: android/ion: testing the wrong variable
We're testing "pdev" but we intended to test "heap_pdev". This is a
static checker fix and it's unlikely that anyone is affected by this
bug.
Fixes: 13439479c7de ('staging: ion: Add files for parsing the devicetree')
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/android/ion/ion_of.c
b/drivers/staging/android/ion/ion_of.c
index 15bac92..46b2bb9 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -107,7 +107,7 @@ struct ion_platform_data *ion_parse_dt(struct
platform_device *pdev,
heap_pdev = of_platform_device_create(node, heaps[i].name,
&pdev->dev);
- if (!pdev)
+ if (!heap_pdev)
return ERR_PTR(-ENOMEM);
heap_pdev->dev.platform_data = &heaps[i];
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
