[PATCH] cifs: escape spaces in share names
Commit 653a5efb849a ("cifs: update super_operations to show_devname")
introduced the display of devname for cifs mounts. However, when mounting
a share which has a whitespace in the name, that exact share name is also
displayed in mountinfo. Make sure that all whitespace is escaped.
Signed-off-by: Maciek Borzecki
---
fs/cifs/cifsfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index
099ad9f3660bb28db1b6a9aea9538282b41c6455..3c6cb85b95e207df48f10cc9df937cdda24e
100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -476,7 +476,8 @@ static int cifs_show_devname(struct seq_file *m, struct
dentry *root)
seq_puts(m, "none");
else {
convert_delimiter(devname, '/');
- seq_puts(m, devname);
+ /* escape all spaces in share names */
+ seq_escape(m, devname, " ");
kfree(devname);
}
return 0;
--
2.31.1
[PATCH] staging wlan-ng: fix type mismatch warnings in mkpdrlist()
struct hfa384x_pdrec len and code fields as clearly little endian,
mark both fields as such. pda->buf is also clearly little endian.
Fixes sparse warnings:
drivers/staging/wlan-ng/prism2fw.c:613:16: warning: cast to restricted __le16
drivers/staging/wlan-ng/prism2fw.c:616:21: warning: cast to restricted __le16
drivers/staging/wlan-ng/prism2fw.c:625:21: warning: cast to restricted __le16
Signed-off-by: Maciek Borzecki
---
drivers/staging/wlan-ng/hfa384x.h | 4 ++--
drivers/staging/wlan-ng/prism2fw.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index
ba67b7a54358a884dace85ea10e4909d0ebe0896..310e2c4545907dcf176d862d46dcd4d37fcc8604
100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1078,8 +1078,8 @@ struct hfa384x_pdr_end_of_pda {
} __packed;
struct hfa384x_pdrec {
- u16 len;/* in words */
- u16 code;
+ __le16 len; /* in words */
+ __le16 code;
union pdr {
struct hfa384x_pdr_pcb_partnum pcb_partnum;
struct hfa384x_pdr_pcb_tracenum pcb_tracenum;
diff --git a/drivers/staging/wlan-ng/prism2fw.c
b/drivers/staging/wlan-ng/prism2fw.c
index
2e349f87e73818e3d9714708c345a9633904abea..afd877fb4557b2e1cff9de83870c1dda54c29d83
100644
--- a/drivers/staging/wlan-ng/prism2fw.c
+++ b/drivers/staging/wlan-ng/prism2fw.c
@@ -604,7 +604,7 @@ static int mkimage(struct imgchunk *clist, unsigned int
*ccnt)
*/
static int mkpdrlist(struct pda *pda)
{
- u16 *pda16 = (u16 *)pda->buf;
+ __le16 *pda16 = (__le16 *)pda->buf;
int curroff;/* in 'words' */
pda->nrec = 0;
--
2.9.3
Re: [PATCH] staging wlan-ng: mark PDA buf as __le16
On Sat, Apr 8, 2017 at 3:18 PM, Maciek Borzecki wrote: > On Sat, Apr 8, 2017 at 1:01 PM, Greg Kroah-Hartman > wrote: >> On Fri, Apr 07, 2017 at 02:47:55PM +0200, Maciek Borzecki wrote: >>> PDA buffer contains little-endian data, clearly mark it as such. >>> >>> Fixes sparse warnings: >>> drivers/staging/wlan-ng/hfa384x_usb.c:2359:34: warning: cast to >>> restricted __le16 >>> drivers/staging/wlan-ng/hfa384x_usb.c:2360:35: warning: cast to >>> restricted __le16 >>> drivers/staging/wlan-ng/hfa384x_usb.c:2382:44: warning: cast to >>> restricted __le16 >>> >>> Signed-off-by: Maciek Borzecki >>> --- >>> drivers/staging/wlan-ng/hfa384x_usb.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> This patch does not apply to my tree at all, what did you make it >> against? >> > > It was made on top of: > > commit c02ed2e75ef4c74e41e421acb4ef1494671585e8 > Author: Linus Torvalds > Date: Sun Mar 26 14:15:16 2017 -0700 > > Linux 4.11-rc4 > > Let me rebase on top of staging-next and resend. Please ignore this patch. Turns out there's a similar patch already applied in staging-next. Cheers, -- Maciek Borzecki
Re: [PATCH] staging wlan-ng: mark PDA buf as __le16
On Sat, Apr 8, 2017 at 1:01 PM, Greg Kroah-Hartman wrote: > On Fri, Apr 07, 2017 at 02:47:55PM +0200, Maciek Borzecki wrote: >> PDA buffer contains little-endian data, clearly mark it as such. >> >> Fixes sparse warnings: >> drivers/staging/wlan-ng/hfa384x_usb.c:2359:34: warning: cast to restricted >> __le16 >> drivers/staging/wlan-ng/hfa384x_usb.c:2360:35: warning: cast to restricted >> __le16 >> drivers/staging/wlan-ng/hfa384x_usb.c:2382:44: warning: cast to restricted >> __le16 >> >> Signed-off-by: Maciek Borzecki >> --- >> drivers/staging/wlan-ng/hfa384x_usb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > This patch does not apply to my tree at all, what did you make it > against? > It was made on top of: commit c02ed2e75ef4c74e41e421acb4ef1494671585e8 Author: Linus Torvalds Date: Sun Mar 26 14:15:16 2017 -0700 Linux 4.11-rc4 Let me rebase on top of staging-next and resend. -- Maciek Borzecki
[PATCH] staging wlan-ng: mark PDA buf as __le16
PDA buffer contains little-endian data, clearly mark it as such.
Fixes sparse warnings:
drivers/staging/wlan-ng/hfa384x_usb.c:2359:34: warning: cast to restricted
__le16
drivers/staging/wlan-ng/hfa384x_usb.c:2360:35: warning: cast to restricted
__le16
drivers/staging/wlan-ng/hfa384x_usb.c:2382:44: warning: cast to restricted
__le16
Signed-off-by: Maciek Borzecki
---
drivers/staging/wlan-ng/hfa384x_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index
6134eba5cad4693997faf8d2d77947ff7e8b0713..64848778834cae1d341c59ecce756d11b218b4c8
100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -2316,7 +2316,7 @@ int hfa384x_drvr_ramdl_write(struct hfa384x *hw, u32
daddr, void *buf, u32 len)
int hfa384x_drvr_readpda(struct hfa384x *hw, void *buf, unsigned int len)
{
int result = 0;
- u16 *pda = buf;
+ __le16 *pda = buf;
int pdaok = 0;
int morepdrs = 1;
int currpdr = 0;/* word offset of the current pdr */
--
2.9.3
[PATCH] staging: wlan-ng: prism2sta: replace memcmp with ether_addr_equal
Replace memcmp() with ether_addr_equal(). In every location where the
replacement was done, the addresses accessed are
__aligned(2). Structures accessed either stack or heap allocated, no
direct memory casts to possibly unaligned structs are used.
Involved structures:
typedef struct hfa384x_authenticateStation_data {
u8 address[ETH_ALEN]; /* 0 offset */
...
} __packed hfa384x_authenticateStation_data_t;
struct prism2sta_authlist {
unsigned int cnt;
u8 addr[WLAN_AUTH_MAX][ETH_ALEN]; /* 4 bytes offset,
addresses start
at u16 boundary */
u8 assoc[WLAN_AUTH_MAX];
};
struct prism2sta_accesslist {
unsigned int modify;
unsigned int cnt;
u8 addr[WLAN_ACCESS_MAX][ETH_ALEN]; /* 8 bytes offset,
multiple of u16 */
...
u8 addr1[WLAN_ACCESS_MAX][ETH_ALEN]; /* starts at u32 boundary,
struct not packed */
};
typedef struct hfa384x_AssocStatus {
u16 assocstatus;
u8 sta_addr[ETH_ALEN];/* 2 bytes offset,
struct is packed */
u8 old_ap_addr[ETH_ALEN]; /* 8 bytes offset */
...
} __packed hfa384x_AssocStatus_t;
The patch resolves the following checkpatch warnings:
WARNING: Prefer ether_addr_equal() or ether_addr_equal_unaligned()
over memcmp()
Signed-off-by: Maciek Borzecki
---
drivers/staging/wlan-ng/prism2sta.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2sta.c
b/drivers/staging/wlan-ng/prism2sta.c
index
0329c521d17c5c0ee5baa237c81383021daefe24..2b7efe05cc8f4e30c8b43c27fccda988ad9b756e
100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1483,7 +1483,7 @@ static void prism2sta_inf_assocstatus(wlandevice_t
*wlandev,
*/
for (i = 0; i < hw->authlist.cnt; i++)
- if (memcmp(rec.sta_addr, hw->authlist.addr[i], ETH_ALEN) == 0)
+ if (ether_addr_equal(rec.sta_addr, hw->authlist.addr[i]))
break;
if (i >= hw->authlist.cnt) {
@@ -1565,8 +1565,8 @@ static void prism2sta_inf_authreq_defer(wlandevice_t
*wlandev,
*/
for (i = 0; i < hw->authlist.cnt; i++)
- if (memcmp(rec.address, hw->authlist.addr[i],
- ETH_ALEN) == 0) {
+ if (ether_addr_equal(rec.address,
+hw->authlist.addr[i])) {
rec.status = P80211ENUM_status_successful;
break;
}
@@ -1603,7 +1603,7 @@ static void prism2sta_inf_authreq_defer(wlandevice_t
*wlandev,
}
for (i = 0; i < cnt; i++, addr += ETH_ALEN)
- if (memcmp(rec.address, addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(rec.address, addr)) {
rec.status = P80211ENUM_status_successful;
break;
}
@@ -1633,7 +1633,7 @@ static void prism2sta_inf_authreq_defer(wlandevice_t
*wlandev,
rec.status = P80211ENUM_status_successful;
for (i = 0; i < cnt; i++, addr += ETH_ALEN)
- if (memcmp(rec.address, addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(rec.address, addr)) {
rec.status = P80211ENUM_status_unspec_failure;
break;
}
@@ -1654,8 +1654,8 @@ static void prism2sta_inf_authreq_defer(wlandevice_t
*wlandev,
if (rec.status == P80211ENUM_status_successful) {
for (i = 0; i < hw->authlist.cnt; i++)
- if (memcmp(rec.address, hw->authlist.addr[i], ETH_ALEN)
- == 0)
+ if (ether_addr_equal(rec.address,
+hw->authlist.addr[i]))
break;
if (i >= hw->authlist.cnt) {
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] leds: add device activity LED triggers
On 10/02 12:08, Josh Cartwright wrote: > > Hmm, maybe we're bikeshedding at this point, but LEDs with those names > seem much more straightfoward to me than a "dev-:" name, for > devices which have done dynamic dev_t allocation. > > > Also, if I'm not mistaken, using this approach the partitions on MMC > > card or SATA drive would end up with the same trigger name, as it is a > > single device. > > This would only be true if you used _just_ the struct device. I was > imagining that you'd specify a (struct device, unsigned index) pair. > Better, you could do a (struct device, const char *) pair. > > Also, from a lifetime management perspective, it starts to feel like > something that might integrate better as a managed resource (devm_*). > > [..] > > Multiple dev nodes will already have different minor numbers, so > > their dev_t is different anyway. > > Okay, backing up I don't really see what this API really buys the > consumer. The dev_t -> struct led_trigger mapping just seems like a > total waste. Why not just make your ledtrig_dev_add() function return > the struct led_trigger * that the consumer keeps track of? > > Maybe seeing an example consumer would provide some clarification. > > > As for devices that do not have a dev_t assigned to them one can still > > pass a custom tag in ledtrig_dev_add(). It's just a number so as long as > > there's no collision in numbering things should be fine. > > Ensuring no collision will be difficult, especially given that it's most > common that the dynamic allocator is used. In order to guarantee no > collisions, a user who doesn't expose any device nodes would need to do > their own dev_t allocation...to use this interface. And that seems > silly to me. Thanks, I really appreciate your feedback. -- Maciek Borzecki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] leds: add device trigger
On 10/02 16:27, Jacek Anaszewski wrote:
> Hi Maciek,
>
> I tested your trigger, and it works fine, but I wonder if
> it really improves the things.
>
> Basically, similarly as Josh, I have doubts related to associating
> triggers with dev_t. It requires from user to figure out how they can
> obtain valid dev_t. For example, in case of v4l2 jpeg codec, I had to
> spend some time looking for the location of struct device containing
> dev_t related to the exposed encoder and decoder nodes, whereas addition
> of debugging instruction should be easy and intuitive.
>
> It is much simpler to register a trigger with human readable names.
> What is more, use of dev_t makes the user thinking that there is
> some mechanism involved, that automatically associates device with
> trigger, and after some time of code investigation one gets
> disillusioned and realizes that dev_t is used only to uniquely identify
> registered triggers.
>
> I tried to add trigger to the JPEG codec interrupt handler using
> ledtrig-oneshot, and below is the result:
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 9690f9d..af826d3 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> #include "jpeg-core.h"
> #include "jpeg-hw-s5p.h"
> @@ -35,6 +36,9 @@
> #include "jpeg-hw-exynos3250.h"
> #include "jpeg-regs.h"
>
> +static unsigned long blink_delay = 30;
> +struct led_trigger *jpeg_led_trig;
> +
> static struct s5p_jpeg_fmt sjpeg_formats[] = {
> {
> .name = "JPEG JFIF",
> @@ -2318,6 +2322,7 @@ static irqreturn_t s5p_jpeg_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +
> static irqreturn_t exynos4_jpeg_irq(int irq, void *priv)
> {
> unsigned int int_status;
> @@ -2375,7 +2380,10 @@ static irqreturn_t exynos4_jpeg_irq(int irq, void
> *priv)
> v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx);
> curr_ctx->subsampling = exynos4_jpeg_get_frame_fmt(jpeg->regs);
>
> + led_trigger_blink_oneshot(jpeg_led_trig, &blink_delay, &blink_delay,
> 0);
> +
> spin_unlock(&jpeg->slock);
> +
> return IRQ_HANDLED;
> }
>
> @@ -2589,6 +2597,8 @@ static int s5p_jpeg_probe(struct platform_device
> *pdev)
>
> v4l2_info(&jpeg->v4l2_dev, "Samsung S5P JPEG codec\n");
>
> + led_trigger_register_simple("jpeg-trig", &jpeg_led_trig);
> +
> return 0;
>
> enc_vdev_register_rollback:
> @@ -2633,6 +2643,8 @@ static int s5p_jpeg_remove(struct platform_device
> *pdev)
> if (!IS_ERR(jpeg->sclk))
> clk_put(jpeg->sclk);
>
> + led_trigger_unregister_simple(jpeg_led_trig);
> +
> return 0;
> }
>
> It needs addition of 6 lines of code versus 2 lines in case
> of ledtrig-device. Not a big deal, taking into account that we
> don't have to spend additional time looking for the suitable
> struct device.
>
> Please note that in case of drivers that expose many dev nodes,
> there are cases like interrupt handlers, where struct device
> can't be automatically retrieved, but it needs additional
> analysis to find out which dev node given call to ISR referes to.
> In this case we would have to check current mode (encoding/decoding)
> and call either
>
> ledtrig_dev_activity(jpeg->vfd_encoder->dev.devt)
> or
> ledtrig_dev_activity(jpeg->vfd_decoder->dev.devt).
>
>
> When comparing the steps required from user space side to activate
> the triggers, it looks as follows:
>
>
> ledtrig-oneshot (we have one trigger for encoding and decoding mode):
> =
> #cd /sys/class/leds/aat1290
> #cat triggers
> #[none] jpeg-trig
> #echo "jpeg-trig" > trigger
>
> ledtrig-dev approach (we have to define trigger per dev_t, we choose
> encoder):
> =
> #grep . /sys/class/video4linux/video*/name
> #/sys/class/video4linux/video7/name:s5p-jpeg-enc
> #/sys/class/video4linux/video8/name:s5p-jpeg-dec
> #ls -l /dev/video7
> #crw-rw---T 1 root video 81, 8 Jan 1 03:32 /dev/video8
> #echo "81:7" > /sys/kernel/debug/ledtrig-dev/register
> #cd /sys/class/leds/aat1290
> #cat triggers
> #[none] dev-81:7
> #echo "dev-81:7" > trigger
>
> It seems that ledtrig-dev is more troublesome in use.
>
> Please let me know if I missed something.
>
Thanks for your c
Re: [PATCH v2 1/3] leds: add device activity LED triggers
On 10/01 09:47, Josh Cartwright wrote:
> Hello Maciek-
>
> Some architectural questions below:
>
> On Thu, Oct 01, 2015 at 04:04:31PM +0200, Maciek Borzecki wrote:
> > The patch adds LED triggers for indicating an activity on a selected
> > device. The drivers that intend to use triggers need to register
> > respective devices using ledtrig_dev_add(). Triggers are generated by
> > explicitly calling ledtrig_dev_activity().
> >
> > Signed-off-by: Maciek Borzecki
> > ---
> [..]
> > +struct ledtrig_dev_data {
> > + char name[MAX_NAME_LEN];
> > + dev_t dev;
> > + struct led_trigger *trig;
> > + struct list_head node;
> > +};
> > +
> > +/**
> > + * ledtrig_dev_activity - signal activity on device
> > + * @dev: device
> > + *
> > + * Fires a trigger assigned to @dev device.
> > + */
> > +void ledtrig_dev_activity(dev_t dev)
>
> It seems a bit strange to me to associate a device LED trigger with
> dev_t. Some devices don't expose a dev node, some devices expose
> multiple dev nodes...
>
> Is there a reason why you are not tying to the device model?
>
Thanks for the comments.
The first proof of concept used `sturct device` as parameter in all API
calls, but then there's a problem of naming of a trigger in a sane
way. The trigger name followed the same approach as __dev_printk, and
the naming was done in this fashion:
sprintf(..., "dev-%s-%s", dev_driver_string(dev), dev_name(dev));
Then for instance on wandboard, /dev/ttymxc0 and /dev/ttymxc2 would
appear as `dev-serial-202` and `dev-serial-21ec000`. In my opinion
this was unnecessarily complicated. Also, if I'm not mistaken, using
this approach the partitions on MMC card or SATA drive would end up with
the same trigger name, as it is a single device. However the the
major:minor numbers assigned to respective partitions are different, and
you'd still be able to say trigger the LEDS on writes to a particular
partition.
Multiple dev nodes will already have different minor numbers, so
their dev_t is different anyway.
As for devices that do not have a dev_t assigned to them one can still
pass a custom tag in ledtrig_dev_add(). It's just a number so as long as
there's no collision in numbering things should be fine.
Hopefull this clears up the things a little.
> > +{
> > + struct ledtrig_dev_data *dev_trig;
> > +
> > + if (!down_read_trylock(&devs_list_lock))
> > + return;
> > +
> > + list_for_each_entry(dev_trig, &devs_list, node) {
> > + if (dev_trig->dev == dev) {
> > + led_trigger_blink_oneshot(dev_trig->trig,
> > + &blink_delay,
> > + &blink_delay,
> > + 0);
> > + break;
> > + }
> > + }
> > + up_read(&devs_list_lock);
> > +}
> > +EXPORT_SYMBOL(ledtrig_dev_activity);
>
> Not _GPL?
I'm ok with EXPORT_SYMBOL_GPL() if that's a policy for new code. Though,
I've looked at other triggers that are called from kernel code, and it
seems that ledtrig-camera is the only one using _GPL.
--
Maciek Borzecki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] Documentation: leds: document ledtrig-device trigger
This patch adds documentation for ledtrig-device trigger. Signed-off-by: Maciek Borzecki --- Documentation/leds/00-INDEX | 3 +++ Documentation/leds/ledtrig-device.txt | 35 +++ 2 files changed, 38 insertions(+) create mode 100644 Documentation/leds/ledtrig-device.txt diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX index b4ef1f34e25faafe544971f619019d748538e4de..7f18adaadc04756a6b52157a71f86bd131dd915c 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX @@ -20,3 +20,6 @@ ledtrig-oneshot.txt - One-shot LED trigger for both sporadic and dense events. ledtrig-transient.txt - LED Transient Trigger, one shot timer activation. +ledtrig-device.txt +- LED Device Activity Trigger for indicating an activity + on a device \ No newline at end of file diff --git a/Documentation/leds/ledtrig-device.txt b/Documentation/leds/ledtrig-device.txt new file mode 100644 index ..c13e1f3f6c1e462c9cf2f083e6f1b1c0838f86b2 --- /dev/null +++ b/Documentation/leds/ledtrig-device.txt @@ -0,0 +1,35 @@ +Device Activity LED Trigger +== + +This is a LED trigger useful for signaling an activity on a given +device identified by it's MKDEV(major, minor). A typical use case +would be debugging of a device or a driver on an embedded board, +patching up trivial electronic hardware design deficiencies in +software or just plain desire to indicate activity on a certain +device. + +Internally, a instance of a trigger is created and registered with LED +triggers for every device added via ledtrig_dev_add() call. The +triggers are named in the following manner: + + `dev-:` + +And can be selected from under /sys/class/leds/*/trigger. A device +activity is explicitly indicated by calling ledtrig_dev_activity() for +a registered device. + +The driver also creates a set of debugfs entries under +/sys/kernel/debug/ledtrig-dev, these are: + + devices - cat'ing will produce a list of currently registered +devices + + register - echo'ing : will create a trigger for this + device (note, you still need to add at least + ledtrig_dev_activity() hook) + + unregister - echo'ing : will delete a trigger for this + device + + trigger - echo'ing : will fire the trigger for this +device -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] leds: add device trigger
A series of patches that add yet another LED trigger, a device activity trigger. The motivation is to have a LED trigger that is associated with a device and can be fired from cetrain points in the code that have been chosen by the developer. With this this device activity trigger it is possible for instance to easily hook up a tty driver for a console to blink one LED, yet another serial port to blink a second LED and writes to a block device to trigger a third LED. The patches have been tested on Wandboard Quad. The first patch adds the actual trigger. Each device wishing to use the trigger has to be explicitly registered by calling ledtrig_dev_add(), and passing it's dev_t. The intention is that the trigger will be used in scenarios that are impossible to foresee at this moment, and are likely to be approach in a case by case manner anyway. The second patch adds couple of debugfs helpers. The third patch adds documentation and notes on debugfs interface. Example hooks into tty driver can be seen here: https://github.com/bboozzoo/linux/commit/d8a875673e37b27d9c9066febe7633382f97d8af Changes since v1: - fixed debugfs user address space access - added unregister debugfs attribute - documentation update Maciek Borzecki (3): leds: add device activity LED triggers leds: add debugfs to device trigger Documentation: leds: document ledtrig-device trigger Documentation/leds/00-INDEX | 3 + Documentation/leds/ledtrig-device.txt | 35 drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-device.c | 326 ++ include/linux/leds.h | 10 ++ 6 files changed, 383 insertions(+) create mode 100644 Documentation/leds/ledtrig-device.txt create mode 100644 drivers/leds/trigger/ledtrig-device.c -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] leds: add debugfs to device trigger
Add debugfs entries for device activity trigger. Three entries are
created under /sys/kernel/debug/ledtrig-dev when the driver gets
loaded. These are:
devices - cat'ing will produce a list of currently registered devices
in : format, a line for each device.
register - echo'ing : will create a trigger for this
device
unregister - echo'ing : will delete a trigger for this
device
trigger - echo'ing : will fire a trigger for this device
Signed-off-by: Maciek Borzecki
---
drivers/leds/trigger/ledtrig-device.c | 145 +-
1 file changed, 143 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-device.c
b/drivers/leds/trigger/ledtrig-device.c
index
dbb8d7d2b4a0258149c581a040c416d412d9ceeb..68f61fb6ebb05ceaee36c58f1a0244a66bf34847
100644
--- a/drivers/leds/trigger/ledtrig-device.c
+++ b/drivers/leds/trigger/ledtrig-device.c
@@ -16,15 +16,19 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#define BLINK_DELAY 30
static unsigned long blink_delay = BLINK_DELAY;
static DECLARE_RWSEM(devs_list_lock);
static LIST_HEAD(devs_list);
+static struct dentry *debug_root;
#define MAX_NAME_LEN 20
-
struct ledtrig_dev_data {
char name[MAX_NAME_LEN];
dev_t dev;
@@ -114,8 +118,11 @@ void ledtrig_dev_add(dev_t dev)
/* register with led triggers */
led_trigger_register_simple(new_dev_trig->name,
&new_dev_trig->trig);
- else
+ else {
+ pr_warn("device %u:%u already registered\n",
+ MAJOR(dev), MINOR(dev));
kfree(new_dev_trig);
+ }
}
EXPORT_SYMBOL(ledtrig_dev_add);
@@ -167,13 +174,147 @@ static void ledtrig_dev_remove_all(void)
up_write(&devs_list_lock);
}
+static int ledtrig_dev_devices_show(struct seq_file *s, void *unused)
+{
+ struct ledtrig_dev_data *dev_trig;
+
+ down_read(&devs_list_lock);
+ list_for_each_entry(dev_trig, &devs_list, node) {
+ seq_printf(s, "%u:%u\n", MAJOR(dev_trig->dev),
+ MINOR(dev_trig->dev));
+ }
+ up_read(&devs_list_lock);
+ return 0;
+}
+
+static int ledtrig_dev_devices_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, ledtrig_dev_devices_show,
+ &inode->i_private);
+}
+
+static const struct file_operations debug_devices_ops = {
+ .owner = THIS_MODULE,
+ .open = ledtrig_dev_devices_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release
+};
+
+static int get_dev_from_user(const char __user *buf, size_t size,
+ dev_t *dev)
+{
+ char temp[MAX_NAME_LEN];
+ unsigned int major;
+ unsigned int minor;
+ int ret;
+
+ WARN_ON(dev == NULL);
+ if (dev == NULL)
+ return -EINVAL;
+
+ if (size > sizeof(temp) || size == 0)
+ return -EINVAL;
+
+ if (copy_from_user(temp, buf, size) != 0)
+ return -EINVAL;
+
+ ret = sscanf(temp, "%u:%u", &major, &minor);
+ if (ret < 2)
+ return -EINVAL;
+
+ *dev = MKDEV(major, minor);
+ return 0;
+}
+
+static ssize_t ledtrig_dev_register_write(struct file *filp,
+ const char __user *buf,
+ size_t size, loff_t *off)
+{
+ dev_t dev;
+ int ret;
+
+ ret = get_dev_from_user(buf, size, &dev);
+ if (ret < 0)
+ return ret;
+
+ pr_debug("register device %u:%u\n", MAJOR(dev), MINOR(dev));
+ ledtrig_dev_add(dev);
+
+ return size;
+}
+
+static const struct file_operations debug_register_ops = {
+ .owner = THIS_MODULE,
+ .write = ledtrig_dev_register_write,
+};
+
+static ssize_t ledtrig_dev_unregister_write(struct file *filp,
+ const char __user *buf,
+ size_t size, loff_t *off)
+{
+ dev_t dev;
+ int ret;
+
+ ret = get_dev_from_user(buf, size, &dev);
+ if (ret < 0)
+ return ret;
+
+ pr_debug("unregister device %u:%u\n", MAJOR(dev), MINOR(dev));
+ ledtrig_dev_del(dev);
+
+ return size;
+}
+
+static const struct file_operations debug_unregister_ops = {
+ .owner = THIS_MODULE,
+ .write = ledtrig_dev_unregister_write,
+};
+
+static ssize_t ledtrig_dev_trigger_write(struct file *filp,
+ const char __user *buf,
+ size_t size, loff_t *off)
+{
+ dev_t dev;
+ int ret;
+
+ ret = get_dev_from_user(buf, size, &dev);
+ if (ret < 0)
+
[PATCH v2 1/3] leds: add device activity LED triggers
The patch adds LED triggers for indicating an activity on a selected
device. The drivers that intend to use triggers need to register
respective devices using ledtrig_dev_add(). Triggers are generated by
explicitly calling ledtrig_dev_activity().
Signed-off-by: Maciek Borzecki
---
drivers/leds/trigger/Kconfig | 8 ++
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-device.c | 185 ++
include/linux/leds.h | 10 ++
4 files changed, 204 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-device.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index
5bda6a9b56bbd90b4a3749f87bc0c6fda8dd5034..c6ecfbd7c0876f21688140aa9afc7eb5b9fec3a2
100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -108,4 +108,12 @@ config LEDS_TRIGGER_CAMERA
This enables direct flash/torch on/off by the driver, kernel space.
If unsure, say Y.
+config LEDS_TRIGGER_DEVICE
+ bool "LED Device Activity Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows LEDs to be triggered by an actvity on a selected
+ device.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index
1abf48dacf7ebfcfb8208f7ae7bdf29d7c11ba32..86beeacd5403afc163873d7c3f817ee082b64e04
100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
+obj-$(CONFIG_LEDS_TRIGGER_DEVICE) += ledtrig-device.o
diff --git a/drivers/leds/trigger/ledtrig-device.c
b/drivers/leds/trigger/ledtrig-device.c
new file mode 100644
index
..dbb8d7d2b4a0258149c581a040c416d412d9ceeb
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-device.c
@@ -0,0 +1,185 @@
+/*
+ * LED Device Activity Trigger
+ *
+ * Copyright 2015 Maciej Borzecki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BLINK_DELAY 30
+static unsigned long blink_delay = BLINK_DELAY;
+
+static DECLARE_RWSEM(devs_list_lock);
+static LIST_HEAD(devs_list);
+
+#define MAX_NAME_LEN 20
+
+struct ledtrig_dev_data {
+ char name[MAX_NAME_LEN];
+ dev_t dev;
+ struct led_trigger *trig;
+ struct list_head node;
+};
+
+/**
+ * ledtrig_dev_activity - signal activity on device
+ * @dev: device
+ *
+ * Fires a trigger assigned to @dev device.
+ */
+void ledtrig_dev_activity(dev_t dev)
+{
+ struct ledtrig_dev_data *dev_trig;
+
+ if (!down_read_trylock(&devs_list_lock))
+ return;
+
+ list_for_each_entry(dev_trig, &devs_list, node) {
+ if (dev_trig->dev == dev) {
+ led_trigger_blink_oneshot(dev_trig->trig,
+ &blink_delay,
+ &blink_delay,
+ 0);
+ break;
+ }
+ }
+ up_read(&devs_list_lock);
+}
+EXPORT_SYMBOL(ledtrig_dev_activity);
+
+static struct ledtrig_dev_data *ledtrig_dev_new(dev_t dev)
+{
+ struct ledtrig_dev_data *dev_trig;
+
+ dev_trig = kzalloc(sizeof(*dev_trig), GFP_KERNEL);
+ if (!dev_trig)
+ return NULL;
+
+ INIT_LIST_HEAD(&dev_trig->node);
+ dev_trig->dev = dev;
+ snprintf(dev_trig->name, sizeof(dev_trig->name),
+"dev-%u:%u", MAJOR(dev), MINOR(dev));
+
+ return dev_trig;
+}
+
+static void ledtrig_dev_release(struct ledtrig_dev_data *dev_trig)
+{
+ led_trigger_unregister_simple(dev_trig->trig);
+
+ kfree(dev_trig);
+}
+
+/**
+ * ledtrig_dev_add - add a trigger for device
+ * @dev: device for which the trigger is to be added
+ *
+ * Create and register a new trigger for device @dev. The trigger will
+ * show up as dev-: in the list of avaialble LED
+ * triggers.
+ */
+void ledtrig_dev_add(dev_t dev)
+{
+ int found = 0;
+ struct ledtrig_dev_data *new_dev_trig;
+ struct ledtrig_dev_data *dev_trig;
+
+ new_dev_trig = ledtrig_dev_new(dev);
+ if (!new_dev_trig)
+ return;
+
+ down_write(&devs_list_lock);
+ list_for_each_entry(dev_trig, &devs_list, node) {
+ if (dev_trig->dev == dev) {
+ found = 1;
+ break;
+ }
+ }
+ if (!found)
Re: [PATCH 2/3] leds: add debugfs to device trigger
On 09/30 16:08, Jacek Anaszewski wrote: > Hi Maciek, > > Please test your solution thoroughly before submitting > the next version. Writing to debugfs register attribute > fails due to lack of proper copying from user memory, > which makes testing impossible. Hi, thanks for the comment. Indeed, I noticed the problem just after sending the patch. Surprisingly this didn't fail on iMX6 for some reason. Aside from the __user access problem, is the approach, in general, ok for you or would you suggest that I changed something? Regards, -- Maciek Borzecki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] leds: add debugfs to device trigger
On 09/29 11:41, kbuild test robot wrote:
> Hi Maciek,
>
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please
> ignore]
>
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
> >> drivers/leds/trigger/ledtrig-device.c:214:22: sparse: incorrect type in
> >> argument 1 (different address spaces)
>drivers/leds/trigger/ledtrig-device.c:214:22:expected char const
> *
>drivers/leds/trigger/ledtrig-device.c:214:22:got char const [noderef]
> *buf
Right, noted right after sending the patch. Will fix in v2.
>
> vim +214 drivers/leds/trigger/ledtrig-device.c
>
>198.read = seq_read,
>199.llseek = seq_lseek,
>200.release = single_release
>201};
>202
>203static int get_dev_from_user(const char __user *buf, size_t
> size,
>204dev_t *dev)
>205{
>206unsigned int major;
>207unsigned int minor;
>208int ret;
>209
>210WARN_ON(dev == NULL);
>211if (dev == NULL)
>212return -EINVAL;
>213
> > 214ret = sscanf(buf, "%u:%u", &major, &minor);
>215if (ret < 2)
>216return -EINVAL;
>217
>218*dev = MKDEV(major, minor);
>219return 0;
>220}
>221
>222static ssize_t ledtrig_dev_register_write(struct file *filp,
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Maciek Borzecki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] leds: add debugfs to device trigger
Add debugfs entries for device activity trigger. Three entries are
created under /sys/kernel/debug/ledtrig-dev when the driver gets
loaded. These are:
devices - cat'ing will produce a list of currently registered devices
in : format, a line for each device.
register - echo'ing : will create a trigger for this
device
trigger - echo'ing : will fire a trigger for this device
Signed-off-by: Maciek Borzecki
---
drivers/leds/trigger/ledtrig-device.c | 113 +-
1 file changed, 111 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-device.c
b/drivers/leds/trigger/ledtrig-device.c
index
dbb8d7d2b4a0258149c581a040c416d412d9ceeb..6814db5e34d76974ae095d2e1c8f1f2e23dea79e
100644
--- a/drivers/leds/trigger/ledtrig-device.c
+++ b/drivers/leds/trigger/ledtrig-device.c
@@ -16,15 +16,18 @@
#include
#include
#include
+#include
+#include
+#include
#define BLINK_DELAY 30
static unsigned long blink_delay = BLINK_DELAY;
static DECLARE_RWSEM(devs_list_lock);
static LIST_HEAD(devs_list);
+static struct dentry *debug_root;
#define MAX_NAME_LEN 20
-
struct ledtrig_dev_data {
char name[MAX_NAME_LEN];
dev_t dev;
@@ -114,8 +117,11 @@ void ledtrig_dev_add(dev_t dev)
/* register with led triggers */
led_trigger_register_simple(new_dev_trig->name,
&new_dev_trig->trig);
- else
+ else {
+ pr_warn("device %u:%u already registered\n",
+ MAJOR(dev), MINOR(dev));
kfree(new_dev_trig);
+ }
}
EXPORT_SYMBOL(ledtrig_dev_add);
@@ -167,13 +173,116 @@ static void ledtrig_dev_remove_all(void)
up_write(&devs_list_lock);
}
+static int ledtrig_dev_devices_show(struct seq_file *s, void *unused)
+{
+ struct ledtrig_dev_data *dev_trig;
+
+ down_read(&devs_list_lock);
+ list_for_each_entry(dev_trig, &devs_list, node) {
+ seq_printf(s, "%u:%u\n", MAJOR(dev_trig->dev),
+ MINOR(dev_trig->dev));
+ }
+ up_read(&devs_list_lock);
+ return 0;
+}
+
+static int ledtrig_dev_devices_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, ledtrig_dev_devices_show,
+ &inode->i_private);
+}
+
+static const struct file_operations debug_devices_ops = {
+ .owner = THIS_MODULE,
+ .open = ledtrig_dev_devices_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release
+};
+
+static int get_dev_from_user(const char __user *buf, size_t size,
+ dev_t *dev)
+{
+ unsigned int major;
+ unsigned int minor;
+ int ret;
+
+ WARN_ON(dev == NULL);
+ if (dev == NULL)
+ return -EINVAL;
+
+ ret = sscanf(buf, "%u:%u", &major, &minor);
+ if (ret < 2)
+ return -EINVAL;
+
+ *dev = MKDEV(major, minor);
+ return 0;
+}
+
+static ssize_t ledtrig_dev_register_write(struct file *filp,
+ const char __user *buf,
+ size_t size, loff_t *off)
+{
+ dev_t dev;
+ int ret;
+
+ ret = get_dev_from_user(buf, size, &dev);
+ if (ret < 0)
+ return ret;
+
+ pr_debug("got device %u:%u\n", MAJOR(dev), MINOR(dev));
+ ledtrig_dev_add(dev);
+
+ return size;
+}
+
+static const struct file_operations debug_register_ops = {
+ .owner = THIS_MODULE,
+ .write = ledtrig_dev_register_write,
+};
+
+static ssize_t ledtrig_dev_trigger_write(struct file *filp,
+ const char __user *buf,
+ size_t size, loff_t *off)
+{
+ dev_t dev;
+ int ret;
+
+ ret = get_dev_from_user(buf, size, &dev);
+ if (ret < 0)
+ return ret;
+
+ pr_debug("trigger device %u:%u\n", MAJOR(dev), MINOR(dev));
+ ledtrig_dev_activity(dev);
+
+ return size;
+}
+
+static const struct file_operations debug_trigger_ops = {
+ .owner = THIS_MODULE,
+ .write = ledtrig_dev_trigger_write,
+};
+
static int __init ledtrig_dev_init(void)
{
+ debug_root = debugfs_create_dir("ledtrig-dev", NULL);
+
+ if (debug_root) {
+ debugfs_create_file("devices", 0444, debug_root, NULL,
+ &debug_devices_ops);
+ debugfs_create_file("register", 0200, debug_root, NULL,
+ &debug_register_ops);
+ debugfs_create_file("trigger", 0200, debug_root, NULL,
+ &debug_trigger_ops);
+ }
+
return 0;
}
static void __exit ledtrig_dev_exit(voi
[PATCH 0/3] leds: add device trigger
A series of patches that add yet another LED trigger, a device activity trigger. The motivation is to have a LED trigger that is associated with a device and can be fired from cetrain points in the code that have been chosen by the developer. With this this device activity trigger it is possible for instance to easily hook up a tty driver for a console to blink one LED, yet another serial port to blink a second LED and writes to a block device to trigger a third LED. The patches have been tested on Wandboard Quad. The first patch adds the actual trigger. Each device wishing to use the trigger has to be explicitly registered by calling ledtrig_dev_add(), and passing it's dev_t. The intention is that the trigger will be used in scenarios that are impossible to foresee at this moment, and are likely to be approach in a case by case manner anyway. The second patch adds couple of debugfs helpers. The third patch adds documentation and notes on debugfs interface. Maciek Borzecki (3): leds: add device activity LED triggers leds: add debugfs to device trigger Documentation: leds: document ledtrig-device trigger Documentation/leds/00-INDEX | 3 + Documentation/leds/ledtrig-device.txt | 32 drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-device.c | 289 ++ include/linux/leds.h | 10 ++ 6 files changed, 343 insertions(+) create mode 100644 Documentation/leds/ledtrig-device.txt create mode 100644 drivers/leds/trigger/ledtrig-device.c -- 2.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Documentation: leds: document ledtrig-device trigger
This patch adds documentation for ledtrig-device trigger. Signed-off-by: Maciek Borzecki --- Documentation/leds/00-INDEX | 3 +++ Documentation/leds/ledtrig-device.txt | 32 2 files changed, 35 insertions(+) create mode 100644 Documentation/leds/ledtrig-device.txt diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX index b4ef1f34e25faafe544971f619019d748538e4de..7f18adaadc04756a6b52157a71f86bd131dd915c 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX @@ -20,3 +20,6 @@ ledtrig-oneshot.txt - One-shot LED trigger for both sporadic and dense events. ledtrig-transient.txt - LED Transient Trigger, one shot timer activation. +ledtrig-device.txt +- LED Device Activity Trigger for indicating an activity + on a device \ No newline at end of file diff --git a/Documentation/leds/ledtrig-device.txt b/Documentation/leds/ledtrig-device.txt new file mode 100644 index ..b319d5da9df513a15b5c8094c6a5923682ff4579 --- /dev/null +++ b/Documentation/leds/ledtrig-device.txt @@ -0,0 +1,32 @@ +Device Activity LED Trigger +== + +This is a LED trigger useful for signaling an activity on a given +device identified by it's MKDEV(major, minor). A typical use case +would be debugging of a device or a driver on an embedded board, +patching up trivial electronic hardware design deficiencies in +software or just plain desire to indicate activity on a certain +device. + +Internally, a instance of a trigger is created and registered with LED +triggers for every device added via ledtrig_dev_add() call. The +triggers are named in the following manner: + + `dev-:` + +And can be selected from under /sys/class/leds/*/trigger. A device +activity is explicitly indicated by calling ledtrig_dev_activity() for +a registered device. + +The driver also creates a set of debugfs entries under +/sys/kernel/debug/ledtrig-dev, these are: + + devices - cat'ing will produce a list of currently registered +devices + + register - echo'ing : will create a trigger for this + device (note, you still need to add at least + ledtrig_dev_activity() hook) + + trigger - echo'ing : will fire the trigger for this +device -- 2.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] leds: add device activity LED triggers
The patch adds LED triggers for indicating an activity on a selected
device. The drivers that intend to use triggers need to register
respective devices using ledtrig_dev_add(). Triggers are generated by
explicitly calling ledtrig_dev_activity().
Signed-off-by: Maciek Borzecki
---
drivers/leds/trigger/Kconfig | 8 ++
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-device.c | 185 ++
include/linux/leds.h | 10 ++
4 files changed, 204 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-device.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index
5bda6a9b56bbd90b4a3749f87bc0c6fda8dd5034..c6ecfbd7c0876f21688140aa9afc7eb5b9fec3a2
100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -108,4 +108,12 @@ config LEDS_TRIGGER_CAMERA
This enables direct flash/torch on/off by the driver, kernel space.
If unsure, say Y.
+config LEDS_TRIGGER_DEVICE
+ bool "LED Device Activity Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows LEDs to be triggered by an actvity on a selected
+ device.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index
1abf48dacf7ebfcfb8208f7ae7bdf29d7c11ba32..86beeacd5403afc163873d7c3f817ee082b64e04
100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
+obj-$(CONFIG_LEDS_TRIGGER_DEVICE) += ledtrig-device.o
diff --git a/drivers/leds/trigger/ledtrig-device.c
b/drivers/leds/trigger/ledtrig-device.c
new file mode 100644
index
..dbb8d7d2b4a0258149c581a040c416d412d9ceeb
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-device.c
@@ -0,0 +1,185 @@
+/*
+ * LED Device Activity Trigger
+ *
+ * Copyright 2015 Maciej Borzecki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BLINK_DELAY 30
+static unsigned long blink_delay = BLINK_DELAY;
+
+static DECLARE_RWSEM(devs_list_lock);
+static LIST_HEAD(devs_list);
+
+#define MAX_NAME_LEN 20
+
+struct ledtrig_dev_data {
+ char name[MAX_NAME_LEN];
+ dev_t dev;
+ struct led_trigger *trig;
+ struct list_head node;
+};
+
+/**
+ * ledtrig_dev_activity - signal activity on device
+ * @dev: device
+ *
+ * Fires a trigger assigned to @dev device.
+ */
+void ledtrig_dev_activity(dev_t dev)
+{
+ struct ledtrig_dev_data *dev_trig;
+
+ if (!down_read_trylock(&devs_list_lock))
+ return;
+
+ list_for_each_entry(dev_trig, &devs_list, node) {
+ if (dev_trig->dev == dev) {
+ led_trigger_blink_oneshot(dev_trig->trig,
+ &blink_delay,
+ &blink_delay,
+ 0);
+ break;
+ }
+ }
+ up_read(&devs_list_lock);
+}
+EXPORT_SYMBOL(ledtrig_dev_activity);
+
+static struct ledtrig_dev_data *ledtrig_dev_new(dev_t dev)
+{
+ struct ledtrig_dev_data *dev_trig;
+
+ dev_trig = kzalloc(sizeof(*dev_trig), GFP_KERNEL);
+ if (!dev_trig)
+ return NULL;
+
+ INIT_LIST_HEAD(&dev_trig->node);
+ dev_trig->dev = dev;
+ snprintf(dev_trig->name, sizeof(dev_trig->name),
+"dev-%u:%u", MAJOR(dev), MINOR(dev));
+
+ return dev_trig;
+}
+
+static void ledtrig_dev_release(struct ledtrig_dev_data *dev_trig)
+{
+ led_trigger_unregister_simple(dev_trig->trig);
+
+ kfree(dev_trig);
+}
+
+/**
+ * ledtrig_dev_add - add a trigger for device
+ * @dev: device for which the trigger is to be added
+ *
+ * Create and register a new trigger for device @dev. The trigger will
+ * show up as dev-: in the list of avaialble LED
+ * triggers.
+ */
+void ledtrig_dev_add(dev_t dev)
+{
+ int found = 0;
+ struct ledtrig_dev_data *new_dev_trig;
+ struct ledtrig_dev_data *dev_trig;
+
+ new_dev_trig = ledtrig_dev_new(dev);
+ if (!new_dev_trig)
+ return;
+
+ down_write(&devs_list_lock);
+ list_for_each_entry(dev_trig, &devs_list, node) {
+ if (dev_trig->dev == dev) {
+ found = 1;
+ break;
+ }
+ }
+ if (!found)
Re: [PATCH] perf: allow user to indicate path to objdump in command line
On Wed, 2012-09-05 at 12:11 +1000, Michael Ellerman wrote: > On Tue, 2012-09-04 at 10:05 -0600, David Ahern wrote: > > On 9/4/12 4:32 AM, Maciek Borzecki wrote: > > > When analyzing perf data from hosts of other architecture than one of the > > > local > > > host it's useful to call objdump that is part of a toolchain for that > > > architecture. Instead of calling regular objdump, call one that user > > > specified > > > in command line. > > > > Why not set the PATH to make the toolchain's version the one used by perf? > > At least one reason is that cross toolchains are usually built such that > the resulting binaries are called -objdump, -gcc etc. Correct, PATH won't work. First I thought, why not hardcode objdump based on CROSS. But then, I'd need to rebuild perf for each toolchain, bad idea. Passing objdump in command line seems like a good compromise to me, especially as I haven't noticed any other binutils tools to be used by perf same way as objdump is. -- Maciek Borzecki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: allow user to indicate path to objdump in command line
When analyzing perf data from hosts of other architecture than one of the local
host it's useful to call objdump that is part of a toolchain for that
architecture. Instead of calling regular objdump, call one that user specified
in command line.
Signed-off-by: Maciek Borzecki
---
tools/perf/Documentation/perf-annotate.txt | 3 +++
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-annotate.c | 2 ++
tools/perf/builtin-report.c| 2 ++
tools/perf/util/annotate.c | 4 +++-
tools/perf/util/annotate.h | 1 +
6 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-annotate.txt
b/tools/perf/Documentation/perf-annotate.txt
index c89f9e1..c8ffd9f 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -85,6 +85,9 @@ OPTIONS
-M::
--disassembler-style=:: Set disassembler style for objdump.
+--objdump=::
+Path to objdump binary.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-report[1]
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 2d89f02..2da267f 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -168,6 +168,9 @@ OPTIONS
branch stacks and it will automatically switch to the branch view mode,
unless --no-branch-stack is used.
+--objdump=::
+Path to objdump binary.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-annotate[1]
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 67522cf..2f3f002 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -282,6 +282,8 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __used)
"Display raw encoding of assembly instructions (default)"),
OPT_STRING('M', "disassembler-style", &disassembler_style,
"disassembler style",
"Specify disassembler style (e.g. -M intel for intel
syntax)"),
+ OPT_STRING(0, "objdump", &objdump_path, "path",
+ "objdump binary to use for disassembly and annotations"),
OPT_END()
};
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 25249f7..dad231b 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -635,6 +635,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __used)
"Show a column with the sum of periods"),
OPT_CALLBACK_NOOPT('b', "branch-stack", &sort__branch_mode, "",
"use branch records for histogram filling",
parse_branch_mode),
+ OPT_STRING(0, "objdump", &objdump_path, "path",
+ "objdump binary to use for disassembly and annotations"),
OPT_END()
};
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 8069dfb..be7290c 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -17,6 +17,7 @@
#include
const char *disassembler_style;
+const char *objdump_path;
static struct ins *ins__find(const char *name);
static int disasm_line__parse(char *line, char **namep, char **rawp);
@@ -809,9 +810,10 @@ fallback:
dso, dso->long_name, sym, sym->name);
snprintf(command, sizeof(command),
-"objdump %s%s --start-address=0x%016" PRIx64
+"%s %s%s --start-address=0x%016" PRIx64
" --stop-address=0x%016" PRIx64
" -d %s %s -C %s|grep -v %s|expand",
+objdump_path ? objdump_path : "objdump",
disassembler_style ? "-M " : "",
disassembler_style ? disassembler_style : "",
map__rip_2objdump(map, sym->start),
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 78a5692..a6d6bc5 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -152,5 +152,6 @@ int symbol__tui_annotate(struct symbol *sym, struct map
*map, int evidx,
#endif
extern const char *disassembler_style;
+extern const char *objdump_path;
#endif /* __PERF_ANNOTATE_H */
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
