Re: [PATCH] atheros/atlx: Simplify bit manipulations
From: Rasmus Villemoes Date: Fri, 23 Jan 2015 12:06:52 +0100 > The code 'if (foo & X) foo &= ~X;' is semantically equivalent to > simply 'foo &= ~X;', but gcc generates about four instructions for the > former, one for the latter. Similarly, if X consists of a single bit, > 'if (!(foo & X)) X |= X;' can be replaced by 'foo |= X;'. > > In the atl2 case, gcc does know how to merge the new adjacent > operations, so altogether this gives a nice little code size > reduction of about 80 bytes. > > Signed-off-by: Rasmus Villemoes I agree with the feedback given that these open-coded sequences should be replaced with the appropriate PCI helpers instead of edited further. -- 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] drm/nouveau/subdev: fix simple_return.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci CC: Martin Peres Signed-off-by: Fengguang Wu --- gm107.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c +++ b/drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c @@ -47,10 +47,7 @@ gm107_fuse_ctor(struct nouveau_object *p ret = nouveau_fuse_create(parent, engine, oclass, ); *pobject = nv_object(priv); - if (ret) - return ret; - - return 0; + return ret; } struct nouveau_oclass -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/7] r8152: adjust rx_bottom
From: Hayes Wang Date: Tue, 20 Jan 2015 03:24:52 + > David Miller [mailto:da...@davemloft.net] >> Sent: Tuesday, January 20, 2015 10:52 AM > [...] >> agg->list is not local, you have to use a spinlock to protect >> modifications to it, some other sites which modify agg->list do take >> the lock properly. >> >> You cannot modify a list like agg->list without proper locking. > > Excuse me. I don't understand. > > Before step1 >tp_rx_done->listA->listB->listC->listD->... >rx_queue-> > Because the other function would chage tp->rx_done, > I need move the lists with spin lock. > > After step1 >tp_rx_done-> >rx_queue->listA->listB->listC->listD->... > > Now I dequeue one of the lists from the list_head and > deal with it. >tp_rx_done-> >rx_queue->listA->listC->listD->... > listB > > Then, if I want to put it back to rx_queue, I have to > use spin lock. Why? No other function would chage > rx_queue and the items in it. What keeps rtl_start_rx() from running in parallel with r8152_submit_rx(), or any other accessor of the RX agg->list? You also keep using different terminology from me when discussing what lists do or do not need protection, and that is going to make it difficult for anyone to follow our conversation at all. We're talking specifically about RX agg->list objects and whether access to them need synchronization or not. -- 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] drm/nouveau/bar: fix simple_return.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/bar/base.c:132:5-8: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci Signed-off-by: Fengguang Wu --- base.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c @@ -129,10 +129,7 @@ nouveau_bar_create_(struct nouveau_objec ret = nouveau_subdev_create_(parent, engine, oclass, 0, "BARCTL", "bar", length, pobject); bar = *pobject; - if (ret) - return ret; - - return 0; + return ret; } void -- 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: pull-request: wireless-drivers 2015-01-20
From: Kalle Valo Date: Tue, 20 Jan 2015 11:03:33 +0200 > more fixes for 3.19, I hope these are still appropriate. Please let me > know if there are any issues. Pulled, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
support for EasyCap Somagic driver (smi2021)
Are there any plans to include the smi2021 driver in the vanilla kernel any time soon? This driver is for the EasyCap Somagic usb framegrabbers: https://code.google.com/p/easycap-somagic-linux/wiki/BuildingKernelModule#Compile The latest version of the driver is due to Jon Arne and can be found in his kernel branch on github: https://github.com/jonjonarnearne/smi2021 Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/13] kdbus: add documentation
On Fri, Jan 23, 2015 at 09:19:46PM +0800, Greg Kroah-Hartman wrote: > On Fri, Jan 23, 2015 at 08:28:20AM +0200, Ahmed S. Darwish wrote: > > On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote: > > > From: Daniel Mack > > > > > > kdbus is a system for low-latency, low-overhead, easy to use > > > interprocess communication (IPC). > > > > > > The interface to all functions in this driver is implemented via ioctls > > > on files exposed through a filesystem called 'kdbusfs'. The default > > > mount point of kdbusfs is /sys/fs/kdbus. > > > > Pardon my ignorance, but we've always been told that adding > > new ioctl()s to the kernel is a very big no-no. But given > > the seniority of the folks stewarding this kdbus effort, > > there must be a good rationale ;-) > > > > So, can the rationale behind introducing new ioctl()s be > > further explained? It would be even better if it's included > > in the documentation patch itself. > > The main reason to use an ioctl is that you want to atomically set > and/or get something "complex" through the user/kernel boundary. For > simple device attributes, sysfs works great, for configuring devices, > configfs works great, but for data streams / structures / etc. an ioctl > is the correct thing to use. > > Examples of new ioctls being added to the kernel are all over the > place, look at all of the special-purpose ioctls the filesystems keep > creating (they aren't adding new syscalls), look at the monstrosity that > is the DRM layer, look at other complex things like openvswitch, or > "simpler" device-specific interfaces like the MEI one, or even more > complex ones like the MMC interface. These are all valid uses of ioctls > as they are device/filesystem specific ways to interact with the kernel. > > The thing is, almost no one pays attention to these new ioctls as they > are domain-specific interfaces, with open userspace programs talking to > them, and they work well. ioctl is a powerful and useful interface, and > if we were to suddenly require no new ioctls, and require everything to > be a syscall, we would do nothing except make apis more complex (hint, > you now have to do extra validation on your file descriptor passed to > you to determine if it really is what you can properly operate your > ioctl on), and cause no real benefit at all. > > Yes, people abuse ioctls at times, but really, they are needed. > > And remember, I was one of the people who long ago thought we should not > be adding more ioctls, but I have seen the folly of my ways, and chalk > it up to youthful ignorance :) > Exactly, and that's why I wondered about the sudden change of heart ;-) Thanks for taking the time to write this. Regards, Darwish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
Hi!
On Wed, Jan 21, 2015 at 04:20:25PM +, Andri Yngvason wrote:
> Quoting Ahmed S. Darwish (2015-01-20 21:45:37)
> > From: Ahmed S. Darwish
> >
> > Replace most of the can interface's state and error counters
> > handling with the new can-dev can_change_state() mechanism.
> >
> > Suggested-by: Andri Yngvason
> > Signed-off-by: Ahmed S. Darwish
> > ---
> > drivers/net/can/usb/kvaser_usb.c | 114
> > +++
> > 1 file changed, 55 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/net/can/usb/kvaser_usb.c
> > b/drivers/net/can/usb/kvaser_usb.c
> > index 971c5f9..0386d3f 100644
> > --- a/drivers/net/can/usb/kvaser_usb.c
> > +++ b/drivers/net/can/usb/kvaser_usb.c
> > @@ -620,40 +620,43 @@ static void kvaser_usb_unlink_tx_urbs(struct
> > kvaser_usb_net_priv *priv)
> > }
> >
> > static void kvaser_usb_rx_error_update_can_state(struct
> > kvaser_usb_net_priv *priv,
> > -const struct
> > kvaser_usb_error_summary *es)
> > +const struct
> > kvaser_usb_error_summary *es,
> > +struct can_frame *cf)
> > {
> > struct net_device_stats *stats;
> > - enum can_state new_state;
> > -
> > - stats = >netdev->stats;
> > - new_state = priv->can.state;
> > + enum can_state cur_state, new_state, tx_state, rx_state;
> >
> > netdev_dbg(priv->netdev, "Error status: 0x%02x\n", es->status);
> >
> > - if (es->status & M16C_STATE_BUS_OFF) {
> > - priv->can.can_stats.bus_off++;
> > + stats = >netdev->stats;
> > + new_state = cur_state = priv->can.state;
> > +
> > + if (es->status & M16C_STATE_BUS_OFF)
> > new_state = CAN_STATE_BUS_OFF;
> > - } else if (es->status & M16C_STATE_BUS_PASSIVE) {
> > - if (priv->can.state != CAN_STATE_ERROR_PASSIVE)
> > - priv->can.can_stats.error_passive++;
> > + else if (es->status & M16C_STATE_BUS_PASSIVE)
> > new_state = CAN_STATE_ERROR_PASSIVE;
> > - }
> >
> > if (es->status == M16C_STATE_BUS_ERROR) {
> > - if ((priv->can.state < CAN_STATE_ERROR_WARNING) &&
> > - ((es->txerr >= 96) || (es->rxerr >= 96))) {
> > - priv->can.can_stats.error_warning++;
> > + if ((cur_state < CAN_STATE_ERROR_WARNING) &&
> > + ((es->txerr >= 96) || (es->rxerr >= 96)))
> > new_state = CAN_STATE_ERROR_WARNING;
> > - } else if (priv->can.state > CAN_STATE_ERROR_ACTIVE) {
> > + else if (cur_state > CAN_STATE_ERROR_ACTIVE)
> > new_state = CAN_STATE_ERROR_ACTIVE;
> > - }
> > }
> >
> > if (!es->status)
> > new_state = CAN_STATE_ERROR_ACTIVE;
> >
> > + if (new_state != cur_state) {
> > + tx_state = (es->txerr >= es->rxerr) ? new_state : 0;
> > + rx_state = (es->txerr <= es->rxerr) ? new_state : 0;
> > +
> > + can_change_state(priv->netdev, cf, tx_state, rx_state);
>
> This (below) is redundant. It doesn't harm but at this point can_change_state
> has set priv->can.state to new_state.
>
> > + new_state = priv->can.state;
> > + }
> > +
Correct; I will remove it.
> > if (priv->can.restart_ms &&
> > - (priv->can.state >= CAN_STATE_BUS_OFF) &&
> > + (cur_state >= CAN_STATE_BUS_OFF) &&
> > (new_state < CAN_STATE_BUS_OFF)) {
> > priv->can.can_stats.restarts++;
> > }
> > @@ -665,18 +668,17 @@ static void
> > kvaser_usb_rx_error_update_can_state(struct kvaser_usb_net_priv *pri
> >
> > priv->bec.txerr = es->txerr;
> > priv->bec.rxerr = es->rxerr;
> > - priv->can.state = new_state;
> > }
> >
> > static void kvaser_usb_rx_error(const struct kvaser_usb *dev,
> > const struct kvaser_msg *msg)
> > {
> > - struct can_frame *cf;
> > + struct can_frame *cf, tmp_cf = { .can_id = CAN_ERR_FLAG, .can_dlc =
> > CAN_ERR_DLC };
> > struct sk_buff *skb;
> > struct net_device_stats *stats;
> > struct kvaser_usb_net_priv *priv;
> > struct kvaser_usb_error_summary es = { };
> > - enum can_state old_state;
> > + enum can_state old_state, new_state;
> >
> > switch (msg->id) {
> > case CMD_CAN_ERROR_EVENT:
> > @@ -721,60 +723,54 @@ static void kvaser_usb_rx_error(const struct
> > kvaser_usb *dev,
> > }
> >
> > /* Update all of the can interface's state and error counters before
> > -* trying any skb allocation that can actually fail with -ENOMEM.
> > +* trying any memory allocation that can actually fail with -ENOMEM.
> > +*
> > +* We send a temporary
Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
On Thu, Jan 22, 2015 at 10:14:47AM +, Andri Yngvason wrote: > Quoting Marc Kleine-Budde (2015-01-21 22:59:23) > > On 01/21/2015 05:20 PM, Andri Yngvason wrote: > > > Marc, could you merge the "move bus_off++" patch before you merge this so > > > that I > > > won't have to incorporate this patch-set into it? > > > > ...included in the lastest pull-request to David. Use > > tags/linux-can-next-for-3.20-20150121 of the can-next repo as you new base. > > > > Thanks! > I guess I'll re-base my next submission over this tag too. Nothing in the new 5 patches is substantial enough to be included in the current kernel release. Thanks! Darwish -- 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] modsign: use shred to overwrite the private key before deleting it
Am 25.01.2015 um 03:13 schrieb Pádraig Brady: On 24/01/15 12:29, Alexander Holler wrote: Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am 24.01.2015 um 11:45 schrieb Alexander Holler: It uses shred, in the hope it will somedays learn how to shred stuff on FLASH based devices securely too, once that has become possible. BTW: This is a good example where technology failed to keep the needs of users in mind. Failed completely. Since ever it's a problem for people to securely delete files on storage. Also it should be very simple to securely erase files on block based devices, people have to try cruel ways in the hope to get securely rid of files nobody else should be able to see ever again. It's almost unbelievable how completely the IT industry (including the field I'm working myself: SW) failed in regard to that since 30 years or even more. And it isn't such that this is a new requirement. Humans are doing such since thousands of years. They use fire to get rid of paper documents and even the old egypts were able to destroyed stuff on stones by using simple steps. Just the IT failed completely. Really unbelievable. So, sorry if anyone got bored by this mail, but I think that really has to be said and repeated. Well not failed completely, just used a different method (encryption). As for "shredding", that improves in effectiveness the lower you go. I.E. it's effective for the whole file system (SSD range), or whole device. That's the usual broken way to go by adding another layer. And if you encrypt your whole device, it won't help if you want to delete one file. As long as the encrypted device is mounted and the blocks aren't overwritten, the stuff is still there. So your solution would end up with: - mount encrypted device - build kernel and secret key - install kernel and secret key - unmount encrypted device That's almost the same as shredding a whole device just to securely delete one file, with the added complication that the encryption requires an authentication, which usually is very uncomfortable to do, at least if the authentication is somewhat secure. Or what do you have in mind? Sorry, but deleting a file such that it isn't readable anymore by anyone shouldn't be a complicated sequence of geek-stuff and all filesystem and storage designers should be ashamed that they haven't managed it in around 30 years to accomplish that simple goal. (imho) ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
On Fri, Jan 23, 2015 at 10:32:13AM +, Andri Yngvason wrote:
> Quoting Ahmed S. Darwish (2015-01-23 06:07:34)
> > On Wed, Jan 21, 2015 at 05:13:45PM +0100, Wolfgang Grandegger wrote:
> > > On Wed, 21 Jan 2015 10:36:47 -0500, "Ahmed S. Darwish"
> > > wrote:
> > > > On Wed, Jan 21, 2015 at 03:00:15PM +, Andri Yngvason wrote:
> > > >> Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
> > > >> > Hi!
> > > >
> > > > ...
> > > >
> > > >> > <-- Unplug the cable -->
> > > >> >
> > > >> > (000.009106) can0 2080 [8] 00 00 00 00 00 00 08 00
> > > >> > ERRORFRAME
> > > >> > bus-error
> > > >> > error-counter-tx-rx{{8}{0}}
> > > >> > (000.001872) can0 2080 [8] 00 00 00 00 00 00 10 00
> > >
> > > For a bus-errors I would also expcect some more information in the
> > > data[2..3] fields. But these are always zero.
> > >
> >
> > M16C error factors made it possible to report things like
> > CAN_ERR_PROT_FORM/STUFF/BIT0/BIT1/TX in data[2], and
> > CAN_ERR_PROT_LOC_ACK/CRC_DEL in data[3].
> >
> > Unfortunately such error factors are only reported in Leaf, but
> > not in USBCan-II due to the wire format change in the error event:
> >
> > struct leaf_msg_error_event {
> > u8 tid;
> > u8 flags;
> > __le16 time[3];
> > u8 channel;
> > u8 padding;
> > u8 tx_errors_count;
> > u8 rx_errors_count;
> > u8 status;
> > u8 error_factor;
> > } __packed;
> >
> > struct usbcan_msg_error_event {
> > u8 tid;
> > u8 padding;
> > u8 tx_errors_count_ch0;
> > u8 rx_errors_count_ch0;
> > u8 tx_errors_count_ch1;
> > u8 rx_errors_count_ch1;
> > u8 status_ch0;
> > u8 status_ch1;
> > __le16 time;
> > } __packed;
> >
> > I speculate that the wire format was changed due to controller
> > bugs in the USBCan-II, which was slightly mentioned in their
> > data sheets here:
> >
> >
> > http://www.kvaser.com/canlib-webhelp/page_hardware_specific_can_controllers.html
> >
> > So it seems there's really no way for filling such bus error
> > info given the very limited amount of data exported :-(
> >
> We experienced similar problems with FlexCAN.
Hmm, I'll have a look there then...
Although my initial instincts imply that the FlexCAN driver has
access to the raw CAN registers, something I'm unable to do here.
But maybe there's some black magic I'm missing :-)
[...]
> >
> > I've dumped _every_ message I receive from the firmware while
> > disconnecting the CAN bus, waiting a while, and connecting it again.
> > I really received _nothing_ from the firmware when the CAN bus was
> > reconnected and the data packets were flowing again. Not even a
> > single CHIP_STATE_EVENT, even after waiting for a long time.
> >
> > So it's basically:
> > ...
> > ERR EVENT, txerr=128, rxerr=0
> > ERR EVENT, txerr=128, rxerr=0
> > ERR EVENT, txerr=128, rxerr=0
> > ...
> >
> > then complete silence, except the data frames. I've even tried with
> > different versions of the firmware, but the same behaviour persisted.
> >
> > > > So, What can the driver do given the above?
> > >
> > > Little if the notification does not come.
> > >
> >
> > We can poll the state by sending CMD_GET_CHIP_STATE to the firmware,
> > and it will hopefully reply with a CHIP_STATE_EVENT response
> > containing the new txerr and rxerr values that we can use for
> > reverse state transitions.
> >
> > But do we _really_ want to go through the path? I feel that it will
> > open some cans of worms w.r.t. concurrent access to both the netdev
> > and USB stacks from a single driver.
> >
> Honestly, I don't know.
> >
> > A possible solution can be setting up a kernel thread that queries
> > for a CHIP_STATE_EVENT every second?
> >
> Have you considered polling in kvaser_usb_tx_acknowledge? You could do
> something
> like:
> if(unlikely(dev->can.state != CAN_STATE_ERROR_ACTIVE))
> {
> request_state();
> }
>
OK, I have four important updates on this issue:
a) My initial testing was done on high-speed channel, at a bitrate
of 50K. After setting the bus to a more reasonable bitrate 500K
or 1M, I was _consistently_ able to receive CHIP_STATE_EVENTs
when plugging the CAN connector again after an unplug.
b) The error counters on this device do not get reset on plugging
after an unplug. I've setup a kernel thread [2] that queries
the chip state event every second, and the error counters stays
the same all the time. [1]
c) There's a single case when the erro counters do indeed get
reversed, and it happens only when introducing some noise in
the bus after the re-plug. In that case, the new error events
get raised with new error counters starting from 0/1 again.
d) I've discovered a bug that
[git pull] vfs.git fixes
A couple of fixes - deadlock in CIFS and build breakage in cris serial driver (resurfaced f_dentry in there). Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (1): fix deadlock in cifs_ioctl_clone() David Howells (1): VFS: Convert file->f_dentry->d_inode to file_inode() Diffstat: arch/cris/arch-v32/drivers/sync_serial.c | 2 +- fs/cifs/ioctl.c | 21 + 2 files changed, 6 insertions(+), 17 deletions(-) -- 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] modsign: use shred to overwrite the private key before deleting it
On 24/01/15 12:29, Alexander Holler wrote: > Am 24.01.2015 um 13:09 schrieb Alexander Holler: >> Am 24.01.2015 um 12:37 schrieb Alexander Holler: >>> Am 24.01.2015 um 11:45 schrieb Alexander Holler: >>> It uses shred, in the hope it will somedays learn how to shred stuff on FLASH based devices securely too, once that has become possible. >>> >>> BTW: This is a good example where technology failed to keep the needs of >>> users in mind. >> >> Failed completely. >> >> Since ever it's a problem for people to securely delete files on storage. >> >> Also it should be very simple to securely erase files on block based >> devices, people have to try cruel ways in the hope to get securely rid >> of files nobody else should be able to see ever again. >> >> It's almost unbelievable how completely the IT industry (including the >> field I'm working myself: SW) failed in regard to that since 30 years or >> even more. > > And it isn't such that this is a new requirement. Humans are doing such > since thousands of years. They use fire to get rid of paper documents > and even the old egypts were able to destroyed stuff on stones by using > simple steps. Just the IT failed completely. > > Really unbelievable. > > So, sorry if anyone got bored by this mail, but I think that really has > to be said and repeated. Well not failed completely, just used a different method (encryption). As for "shredding", that improves in effectiveness the lower you go. I.E. it's effective for the whole file system (SSD range), or whole device. Pádraig. -- 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 v6] thermal: rockchip: make temperature reporting much more accurate
In general, the kernel should report temperature readings exactly as
reported by the hardware. The cpu / gpu thermal driver works in 5 degree
increments,but we ought to do more accurate. The temperature will do
linear interpolation between the entries in the table.
Test= $md5sum /dev/zero &
$while true; do grep "" /sys/class/thermal/thermal_zone[1-2]/temp;
sleep .5; done
e.g. We can get the result as follows:
/sys/class/thermal/thermal_zone1/temp:39994
/sys/class/thermal/thermal_zone2/temp:39086
/sys/class/thermal/thermal_zone1/temp:39994
/sys/class/thermal/thermal_zone2/temp:39540
/sys/class/thermal/thermal_zone1/temp:39540
/sys/class/thermal/thermal_zone2/temp:39540
/sys/class/thermal/thermal_zone1/temp:39540
/sys/class/thermal/thermal_zone2/temp:39994
Signed-off-by: Caesar Wang
Reviewed-by: Dmitry Torokhov
Reviewed-by: Daniel Kurtz
---
Changes in v6:
It's not really need,so delete the follows:
else if (code == TSADCV2_DATA_MASK)
Changes in v5:
Fixed some style.
Changes in v4:
"return -EAGAIN" instead of "return rk_tsadcv2_code_to_temp(code)"
Changes in v3:
Suggested-by Daniel Kurtz,
the check doesn't reject "code == 0xfff"
Fixed in rk_tsadcv2_code_to_temp(u32 code)
Changes in v2:
Reviewed-by: Dmitry Torokhov
drivers/thermal/rockchip_thermal.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 1bcddfc..19553e9 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -193,19 +193,20 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
static long rk_tsadcv2_code_to_temp(u32 code)
{
- int high, low, mid;
-
- low = 0;
- high = ARRAY_SIZE(v2_code_table) - 1;
- mid = (high + low) / 2;
-
- if (code > v2_code_table[low].code || code < v2_code_table[high].code)
- return 125000; /* No code available, return max temperature */
+ unsigned int low = 0;
+ unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
+ unsigned int mid = (low + high) / 2;
+ unsigned int num;
+ unsigned long denom;
+
+ /* Invalid code, return -EAGAIN */
+ if (code > TSADCV2_DATA_MASK)
+ return -EAGAIN;
- while (low <= high) {
- if (code >= v2_code_table[mid].code && code <
- v2_code_table[mid - 1].code)
- return v2_code_table[mid].temp;
+ while (low <= high && mid) {
+ if (code >= v2_code_table[mid].code &&
+ code < v2_code_table[mid - 1].code)
+ break;
else if (code < v2_code_table[mid].code)
low = mid + 1;
else
@@ -213,7 +214,16 @@ static long rk_tsadcv2_code_to_temp(u32 code)
mid = (low + high) / 2;
}
- return 125000;
+ /*
+* The 5C granularity provided by the table is too much. Let's
+* assume that the relationship between sensor readings and
+* temperature between 2 table entries is linear and interpolate
+* to produce less granular result.
+*/
+ num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
+ num *= v2_code_table[mid - 1].code - code;
+ denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
+ return v2_code_table[mid - 1].temp + (num / denom);
}
/**
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/1] thermal: rockchip: make temperature reporting much more accurate
This patch is merged on chromiumos/third_party/kernel. https://chromium-review.googlesource.com/#/c/239190/ Tested on veyron boards. Changes in v6: It's not really need,so delete the follows: else if (code == TSADCV2_DATA_MASK) Changes in v5: Fixed some style. Changes in v4: "return -EAGAIN" instead of "return rk_tsadcv2_code_to_temp(code)" Changes in v3: Suggested-by Daniel Kurtz, the check doesn't reject "code == 0xfff" Fixed in rk_tsadcv2_code_to_temp(u32 code) Changes in v2: Reviewed-by: Dmitry Torokhov Caesar Wang (1): thermal: rockchip: make temperature reporting much more accurate drivers/thermal/rockchip_thermal.c | 36 +++- 1 file changed, 23 insertions(+), 13 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] thermal: rockchip: make temperature reporting much more accurate
On Fri, Jan 23, 2015 at 11:49 PM, Caesar Wang wrote:
> In general, the kernel should report temperature readings exactly as
> reported by the hardware. The cpu / gpu thermal driver works in 5 degree
> increments,but we ought to do more accurate. The temperature will do
> linear interpolation between the entries in the table.
>
> Test= $md5sum /dev/zero &
> $while true; do grep "" /sys/class/thermal/thermal_zone[1-2]/temp;
> sleep .5; done
>
> e.g. We can get the result as follows:
> /sys/class/thermal/thermal_zone1/temp:39994
> /sys/class/thermal/thermal_zone2/temp:39086
> /sys/class/thermal/thermal_zone1/temp:39994
> /sys/class/thermal/thermal_zone2/temp:39540
> /sys/class/thermal/thermal_zone1/temp:39540
> /sys/class/thermal/thermal_zone2/temp:39540
> /sys/class/thermal/thermal_zone1/temp:39540
> /sys/class/thermal/thermal_zone2/temp:39994
>
> Signed-off-by: Caesar Wang
> Reviewed-by: Dmitry Torokhov
>
> ---
>
> Changes in v5:
> Fixed some style.
>
> Changes in v4:
> "return -EAGAIN" instead of "return rk_tsadcv2_code_to_temp(code)"
>
> Changes in v3:
> Suggested-by Daniel Kurtz,
> the check doesn't reject "code == 0xfff"
> Fixed in rk_tsadcv2_code_to_temp(u32 code)
>
> Changes in v2:
> Reviewed-by: Dmitry Torokhov
>
> drivers/thermal/rockchip_thermal.c | 38
> +-
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> index 1bcddfc..83bdf82 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -193,19 +193,22 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
>
> static long rk_tsadcv2_code_to_temp(u32 code)
> {
> - int high, low, mid;
> -
> - low = 0;
> - high = ARRAY_SIZE(v2_code_table) - 1;
> - mid = (high + low) / 2;
> -
> - if (code > v2_code_table[low].code || code < v2_code_table[high].code)
> - return 125000; /* No code available, return max temperature */
> + unsigned int low = 0;
> + unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
> + unsigned int mid = (low + high) / 2;
> + unsigned int num;
> + unsigned long denom;
> +
> + /* Invalid code, return -EAGAIN */
> + if (code > TSADCV2_DATA_MASK)
> + return -EAGAIN;
>
> - while (low <= high) {
> - if (code >= v2_code_table[mid].code && code <
> - v2_code_table[mid - 1].code)
> - return v2_code_table[mid].temp;
> + while (low <= high && mid) {
> + if (code >= v2_code_table[mid].code &&
> + code < v2_code_table[mid - 1].code)
> + break;
> + else if (code == TSADCV2_DATA_MASK)
> + break;
I don't think you need this check since this is v2_code_table[0].
But, it doesn't hurt, so either way, this is:
Reviewed-by: Daniel Kurtz
> else if (code < v2_code_table[mid].code)
> low = mid + 1;
> else
> @@ -213,7 +216,16 @@ static long rk_tsadcv2_code_to_temp(u32 code)
> mid = (low + high) / 2;
> }
>
> - return 125000;
> + /*
> +* The 5C granularity provided by the table is too much. Let's
> +* assume that the relationship between sensor readings and
> +* temperature between 2 table entries is linear and interpolate
> +* to produce less granular result.
> +*/
> + num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
> + num *= v2_code_table[mid - 1].code - code;
> + denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
> + return v2_code_table[mid - 1].temp + (num / denom);
> }
>
> /**
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/nouveau/i2c: fix semicolon.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/i2c/padnv94.c:74:26-27: Unneeded semicolon Removes unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Fengguang Wu --- padnv94.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/padnv94.c +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/padnv94.c @@ -71,7 +71,7 @@ nv94_i2c_pad_ctor(struct nouveau_object if (ret) return ret; - pad->addr = index * 0x50;; + pad->addr = index * 0x50; return 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 0/4] net: stmmac: dwmac-rk: Fix phy regulator issues
From: Romain Perier Date: Tue, 20 Jan 2015 07:09:36 + > This series fixes few issues in dwmac-rk: > > 1. Voltage settings was hardcoded into the driver for the phy regulator. >The driver now uses the default voltage settings found in the devicetree, >which are applied throught the regulator framework. > 2. The regulator name used to power on or power off the phy was put in the > devicetree >variable "phy_regulator", which is not standard and added a lot of code > for nothing. >The driver now uses the devicetree property "phy-supply" and the > corresponding functions >to manipulate this regulator. > > The corresponding devicetree files are also updated. As this new binding for > rk3288 has not been released with any official kernel yet (not until 3.20), > I don't need to care about keeping compatibility with the old non standard > property. Series applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clk: Introduce clk_has_parent()
Quoting Thierry Reding (2015-01-23 01:34:10) > On Thu, Jan 22, 2015 at 12:25:46PM -0800, Stephen Boyd wrote: > > On 01/22, Thierry Reding wrote: > > > On Wed, Jan 21, 2015 at 04:16:05PM -0800, Stephen Boyd wrote: > > > > On 01/21/2015 08:13 AM, Thierry Reding wrote: > > > > > From: Thierry Reding > > > > > > > > > > This new function is similar to clk_set_parent(), except that it > > > > > doesn't > > > > > actually change the parent. It merely checks that the given parent > > > > > clock > > > > > can be a parent for the given clock. > > > > > > > > > > A situation where this is useful is to check that a particular setup > > > > > is > > > > > valid before switching to it. One specific use-case for this is atomic > > > > > modesetting in the DRM framework where setting a mode is divided into > > > > > a > > > > > check phase where a given configuration is validated before applying > > > > > changes to the hardware. > > > > > > > > > > Cc: Russell King > > > > > Cc: Mike Turquette > > > > > Cc: Stephen Boyd > > > > > Signed-off-by: Thierry Reding > > > > > --- > > > > > > > > Reviewed-by: Stephen Boyd > > > > > > > > This will slightly conflict with Tomeu's patches for per-user clock > > > > constraints. It would be best if we can take this through the clk tree > > > > to fix up any conflicts > > > > > > I had hoped to take this through the drm tree to resolve the build-time. > > > Another possibility would be for me to include the clk tree (or a subset > > > thereof) in my pull-request. That way you can still fix things up in the > > > clock tree if there are any conflicts with other work. We could make > > > that work two ways: this patch gets applied to the clk tree and I pull > > > it, or I provide a stable branch that I base my pull request on and that > > > branch can be pulled into the clk tree. > > > > > > Yet another alternative would be to split out the clk_has_parent() > > > change from the series and not use it for now. That way we're going to > > > miss this check, but we do that anyway currently and it will only be > > > temporary until v3.21. > > > > > > Perhaps given where we are in the release cycle the latter would make > > > the most sense for now. > > > > Ok well let's see what Mike wants to do given that he's doing all > > the patch applying right now. I'd think that we could put this > > one patch on a different branch that we can merge into clk-next > > and you can merge into the drm tree. At least that's the typical > > workflow that usually works for everyone. > > I will be sending out a pull request today, so I'm not going to include > this patch or the dependent patch. I'll pick it up again after the merge > window and see if I need to rebase it on top of Tomeu's work. I've created an immutable branch based on 3.19-rc1 with only this patch on it and I've merged that branch into the clk tree. Immutable branch: git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-has-parent You can see it merged into the clk tree here: https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/commit/?h=clk-next=57386798f7db7f09d69f3b44fc66570e6db91bba Regards, Mike > > Thierry -- 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/
NAPOMENA: Odgovor pošaljite na ovaj e-mail: standardloanofficial2...@gmail.com SAMO
Trebate li financiranje? Trebate li poslovne i osobne kredite? Želite li vaša tvrtka za refinanciranje? Naše sjedište nalazi se u Sjedinjenim Americkim Državama i Europi. dajemo kredit svaki Pojedinca i društva kamatnoj stopi od 3% godišnje. Za više informacija kontaktirajte e-mail: standardloanofficial2...@gmail.com Napomena: Pošaljite svoj odgovor na ovaj e-mail: standardloanofficial2...@gmail.com Do you need financing? Do you need business or personal loans? Would you like your company to refinance? Our headquarters are located in United States and Europe. we give credit each Individual and society to the interest rate of 3% per year. For more Information contact E-Mail: standardloanofficial2...@gmail.com Note: Submit your answer to this E-Mail: standardloanofficial2...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Two block IO fixes for 3.19
Hi Linus, Two small patches that should make it into 3.19: - A fixup from me for NVMe, making the cq_vector a signed variable. Otherwise our -1 comparison fails, and commit 2b25d981790b doesn't do what it was supposed to. - A fixup for the hotplug handling for blk-mq from Ming Lei, using the proper kobject referencing to ensure we release resources at the right time. Please pull! git://git.kernel.dk/linux-block.git for-linus Jens Axboe (1): NVMe: cq_vector should be signed Ming Lei (1): blk-mq: fix hctx/ctx kobject use-after-free block/blk-mq-sysfs.c | 25 +++-- block/blk-mq.c| 6 +- drivers/block/nvme-core.c | 2 +- 3 files changed, 25 insertions(+), 8 deletions(-) -- Jens Axboe -- 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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi Heikki,
On Fri, Jan 23, 2015 at 05:12:58PM +0200, Heikki Krogerus wrote:
> TUSB1210 ULPI PHY has vendor specific register for eye
> diagram tuning. On some platforms the system firmware has
> set optimized value to it. In order to not loose the
> optimized value, the driver stores it during probe and
> restores it every time the PHY is powered back on.
>
> Signed-off-by: Heikki Krogerus
> Cc: Kishon Vijay Abraham I
> ---
> drivers/phy/Kconfig| 6 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-tusb1210.c | 133
> +
> 3 files changed, 140 insertions(+)
> create mode 100644 drivers/phy/phy-tusb1210.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26a7623..52ee720 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -284,4 +284,10 @@ config PHY_QCOM_UFS
> help
> Support for UFS PHY on QCOM chipsets.
>
> +config PHY_TUSB1210
> + tristate "TI TUSB1210 ULPI PHY module"
> + depends on USB_ULPI_BUS
> + help
> + Support for TI TUSB1210 USB ULPI PHY.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index cfbb720..03f3d85 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -37,3 +37,4 @@ obj-$(CONFIG_PHY_STIH41X_USB) +=
> phy-stih41x-usb.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
> +obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
> diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
> new file mode 100644
> index 000..1551ae8
> --- /dev/null
> +++ b/drivers/phy/phy-tusb1210.c
> @@ -0,0 +1,133 @@
> +/**
> + * tusb1210.c - TUSB1210 USB ULPI PHY driver
> + *
> + * Copyright (C) 2015 Intel Corporation
> + *
> + * Author: Heikki Krogerus
> + *
> + * 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 "ulpi_phy.h"
> +
> +#define TUSB1210_VENDOR_SPECIFIC2 0x80
> +
> +struct tusb1210 {
> + struct ulpi *ulpi;
> + struct phy *phy;
> + struct gpio_desc *gpio_reset;
> + struct gpio_desc *gpio_cs;
> + u8 eye_diagram_tuning;
> +};
> +
> +static int tusb1210_power_on(struct phy *phy)
> +{
> + struct tusb1210 *tusb = phy_get_drvdata(phy);
> +
> + gpiod_set_value_cansleep(tusb->gpio_reset, 1);
> + gpiod_set_value_cansleep(tusb->gpio_cs, 1);
> +
> + /* Restore eye diagram optimisation value */
> + ulpi_write(tusb->ulpi, TUSB1210_VENDOR_SPECIFIC2,
> +tusb->eye_diagram_tuning);
After you power on phy, ulpi bus may not be available right away. In
intel case, phy power on happens during dwc3 power on. ULPI bus is not
available until OTG controller and phy are in sync.
In resume, you can't restore eye diagram from here.
> +
> + return 0;
> +}
> +
> +static int tusb1210_power_off(struct phy *phy)
> +{
> + struct tusb1210 *tusb = phy_get_drvdata(phy);
> +
> + gpiod_set_value_cansleep(tusb->gpio_reset, 0);
> + gpiod_set_value_cansleep(tusb->gpio_cs, 0);
> +
> + return 0;
> +}
> +
> +static struct phy_ops phy_ops = {
> + .power_on = tusb1210_power_on,
> + .power_off = tusb1210_power_off,
> + .init = tusb1210_power_on,
> + .exit = tusb1210_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int tusb1210_probe(struct ulpi *ulpi)
> +{
> + struct gpio_desc *gpio;
> + struct tusb1210 *tusb;
> + int ret;
> +
> + tusb = devm_kzalloc(>dev, sizeof(*tusb), GFP_KERNEL);
> + if (!tusb)
> + return -ENOMEM;
> +
> + gpio = devm_gpiod_get(>dev, "reset");
> + if (!IS_ERR(gpio)) {
> + ret = gpiod_direction_output(gpio, 0);
> + if (ret)
> + return ret;
> + tusb->gpio_reset = gpio;
> + }
You cannot proceed with probe if gpio reset is not available. Different
from CS, it's a mandatory pin to toggle in order to power on/off phy and
get it in sync with OTG controller.
> +
> + gpio = devm_gpiod_get(>dev, "cs");
> + if (!IS_ERR(gpio)) {
> + ret = gpiod_direction_output(gpio, 0);
> + if (ret)
> + return ret;
> + tusb->gpio_cs = gpio;
> + }
> +
> + /* Store initial eye diagram optimisation value */
> + ret = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
It's unclear if ulpi is accessible at this point. You can't read it at
this point.
Br, David
> + if (ret < 0)
> + return ret;
> +
> + tusb->eye_diagram_tuning = ret;
> +
> + tusb->phy = ulpi_phy_create(ulpi, _ops);
> + if (IS_ERR(tusb->phy))
> + return PTR_ERR(tusb->phy);
> +
> + tusb->ulpi = ulpi;
> +
> + phy_set_drvdata(tusb->phy, tusb);
> +
Re: [RFC PATCH v2 2/5] irq: Allow interrupts to routed to NMI (or similar)
On Wed, 21 Jan 2015, Daniel Thompson wrote:
> @@ -307,6 +307,7 @@ static inline irq_hw_number_t irqd_to_hwirq(struct
> irq_data *d)
> * @irq_eoi: end of interrupt
> * @irq_set_affinity:set the CPU affinity on SMP machines
> * @irq_retrigger: resend an IRQ to the CPU
> + * @irq_set_nmi_routing:set whether interrupt can act like NMI
-ENOPARSE
> +int handle_nmi_irq_desc(unsigned int irq, struct irq_desc *desc);
And that's global for what?
> +int handle_nmi_irq(unsigned int irq);
> +
> #endif
> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
> index 99793b9b6d23..876d01a6ad74 100644
> --- a/kernel/irq/irqdesc.c
> +++ b/kernel/irq/irqdesc.c
> @@ -646,3 +646,51 @@ unsigned int kstat_irqs_usr(unsigned int irq)
> irq_unlock_sparse();
> return sum;
> }
> +
> +/**
> + * handle_nmi_irq_desc - Call an NMI handler
> + * @irq: the interrupt number
> + * @desc:the interrupt description structure for this irq
> + *
> + * To the caller this function is similar in scope to
> generic_handle_irq_desc()
> + * but without any attempt to manage the handler flow. We assume that if the
We assume nothing. We set clear rules and if possible we enforce them.
> + * flow is complex then NMI routing is a bad idea; the caller is expected to
> + * handle the ack, clear, mask and unmask issues if necessary.
And the caller is supposed to do that in which way?
> + * Note that this function does not take any of the usual locks. Instead
> + * is relies on NMIs being prohibited from sharing interrupts (i.e.
> + * there will be exactly one irqaction) and that no call to free_irq()
> + * will be made whilst the handler is running.
And how do you guarantee that? Not at all AFAICT.
> + */
> +int handle_nmi_irq_desc(unsigned int irq, struct irq_desc *desc)
> +{
> + struct irqaction *action = desc->action;
> +
> + BUG_ON(action->next);
> +
> + return action->handler(irq, action->dev_id);
> +}
> +EXPORT_SYMBOL_GPL(handle_nmi_irq_desc);
You seem to have a strong determination to add EXPORT_SYMBOL_GPL to
everything and some more. How is a module supposed to call this?
> +/**
> + * handle_nmi - Call an NMI handler
> + * @irq: the interrupt number
> + * @desc:the interrupt description structure for this irq
> + *
> + * To the caller this function is similar in scope to generic_handle_irq(),
> + * see handle_nmi_irq_desc for more detail.
I don't see a detail here which connects that in any way to
generic_handle_irq().
> + */
> +int handle_nmi_irq(unsigned int irq)
> +{
> + /*
> + * irq_to_desc is either simple arithmetic (no locking) or a radix
> + * tree lookup (RCU). Both are safe from NMI.
> + */
> + struct irq_desc *desc = irq_to_desc(irq);
> +
> + if (!desc)
> + return -EINVAL;
> + handle_nmi_irq_desc(irq, desc);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(handle_nmi_irq);
Sigh. Why would any low level entry handler live in a module?
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 80692373abd6..96212a0493c0 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -571,6 +571,17 @@ int can_request_irq(unsigned int irq, unsigned long
> irqflags)
> return canrequest;
> }
Of course, because the function you copied has no documentation, you are
supposed to omit it as well, right?
> +int __irq_set_nmi_routing(struct irq_desc *desc, unsigned int irq,
And irq is used for what? Just because the function you copied does
not use it either?
And why is it global? Just because the function you copied is global
as well?
> +unsigned int nmi)
> +{
> + struct irq_chip *chip = desc->irq_data.chip;
> +
> + if (!chip || !chip->irq_set_nmi_routing)
> + return -EINVAL;
> +
> + return chip->irq_set_nmi_routing(>irq_data, nmi);
> +}
> +
> int __irq_set_trigger(struct irq_desc *desc, unsigned int irq,
> unsigned long flags)
> {
> @@ -966,6 +977,16 @@ __setup_irq(unsigned int irq, struct irq_desc *desc,
> struct irqaction *new)
>
> if (desc->irq_data.chip == _irq_chip)
> return -ENOSYS;
> +
> + if (new->flags & __IRQF_NMI) {
> + if (new->flags & IRQF_SHARED)
> + return -EINVAL;
> +
> + ret = arch_filter_nmi_handler(new->handler);
See rant below.
> + if (ret < 0)
> + return ret;
> + }
> +
> if (!try_module_get(desc->owner))
> return -ENODEV;
>
> @@ -1153,6 +1174,19 @@ __setup_irq(unsigned int irq, struct irq_desc *desc,
> struct irqaction *new)
>
> init_waitqueue_head(>wait_for_threads);
>
> + if (new->flags & __IRQF_NMI) {
> + ret = __irq_set_nmi_routing(desc, irq, true);
> + if (ret != 1)
> + goto out_mask;
Another set of magic return values which are completely undocumented
and follow the windows
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 966903a98fd80ae5f5c4a7ca121d36ea0ba23143: Merge tag 'samsung-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes (2015-01-16 19:11:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-for-linus for you to fetch changes up to 4b3415c9363f828e7f1e45edecb57930849d5d5b: Merge tag 'imx-fixes-3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes (2015-01-23 14:23:40 -0800) ARM: SoC fixes A week's worth of fixes for various ARM platforms. Diff wise, the largest fix is for OMAP to deal with how GIC now registers interrupts (irq_domain_add_legacy() -> irq_domain_add_linear() changes). Besides this, a few more renesas platforms needed the GIC instatiation done for legacy boards. There's also a fix that disables coherency of mvebu due to issues, and a few other smaller fixes. Andrew Lunn (1): bus: mvebu-mbus: fix support of MBus window 13 Fabio Estevam (1): ARM: dts: imx25: Fix PWM "per" clocks Felipe Balbi (1): arm: boot: dts: dra7: enable dwc3 suspend PHY quirk Magnus Damm (2): ARM: shmobile: r8a7778: Instantiate GIC from C board code in legacy builds ARM: shmobile: r8a7779: Instantiate GIC from C board code in legacy builds Marc Zyngier (1): ARM: OMAP: Work around hardcoded interrupts Olof Johansson (5): Merge tag 'mvebu-fixes-3.19-3' of git://git.infradead.org/linux-mvebu into fixes Merge tag 'omap-for-v3.19/gic-regression-v2' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'renesas-soc-fixes2-for-v3.19' of git://git.kernel.org/.../horms/renesas into fixes Merge tag 'mvebu-fixes-3.19-4' of git://git.infradead.org/linux-mvebu into fixes Merge tag 'imx-fixes-3.19-2' of git://git.kernel.org/.../shawnguo/linux into fixes Robin Murphy (1): arm64: dts: add baud rate to Juno stdout-path Thomas Petazzoni (1): ARM: mvebu: completely disable hardware I/O coherency arch/arm/boot/dts/dra7.dtsi| 6 ++ arch/arm/boot/dts/imx25.dtsi | 8 arch/arm/mach-mvebu/coherency.c| 7 ++- arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/omap4-common.c | 32 ++ arch/arm/mach-omap2/omap_hwmod.c | 10 -- arch/arm/mach-omap2/omap_hwmod.h | 1 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 1 + arch/arm/mach-omap2/prcm-common.h | 1 + arch/arm/mach-omap2/prm44xx.c | 5 - arch/arm/mach-omap2/prm_common.c | 14 +++-- arch/arm/mach-omap2/twl-common.c | 7 ++- arch/arm/mach-shmobile/setup-r8a7778.c | 9 - arch/arm/mach-shmobile/setup-r8a7779.c | 9 - arch/arm64/boot/dts/arm/juno.dts | 2 +- drivers/bus/mvebu-mbus.c | 13 17 files changed, 117 insertions(+), 14 deletions(-) -- 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/5] Overhaul the audit filename handling
Hi Sedat, On Sat, 24 Jan 2015 10:03:06 +0100 Sedat Dilek wrote: > > AFAICS, a new linux-next will be available on Monday (2015-01-26). > I try to retest with this. Actually, Tuesday - Monday is a holiday here. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpRUAUirAkkE.pgp Description: OpenPGP digital signature
Re: [PATCH 3.19-rc2 v15 4/8] sched_clock: Avoid deadlock during read from NMI
On Fri, 23 Jan 2015, Daniel Thompson wrote:
> This patch fixes that problem by providing banked clock data in a
> similar manner to Thomas Gleixner's 4396e058c52e("timekeeping: Provide
> fast and NMI safe access to CLOCK_MONOTONIC").
By some definition of similar.
> -struct clock_data {
> - ktime_t wrap_kt;
> +struct clock_data_banked {
> u64 epoch_ns;
> u64 epoch_cyc;
> - seqcount_t seq;
> - unsigned long rate;
> + u64 (*read_sched_clock)(void);
> + u64 sched_clock_mask;
> u32 mult;
> u32 shift;
> bool suspended;
> };
>
> +struct clock_data {
> + ktime_t wrap_kt;
> + seqcount_t seq;
> + unsigned long rate;
> + struct clock_data_banked bank[2];
> +};
> -static u64 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
> +static struct clock_data cd = {
> + .bank = {
> + [0] = {
> + .mult = NSEC_PER_SEC / HZ,
> + .read_sched_clock = jiffy_sched_clock_read,
> + },
> + },
> +};
If you had carefully studied the changes which made it possible to do
the nmi safe clock monotonic accessor then you'd had noticed that I
went a great way to optimize the cache foot print first and then add
this new fangled thing.
So in the first place 'cd' lacks cacheline_aligned. It should have
been there before, but that's a different issue. You should have
noticed.
Secondly, I don't see any hint that you actually thought about the
cache foot print of the result struct clock_data.
struct clock_data {
ktime_t wrap_kt;
seqcount_t seq;
unsigned long rate;
struct clock_data_banked bank[2];
};
wrap_kt and rate are completely irrelevant for the hotpath. The whole
thing up to the last member of bank[0] still fits into 64 byte on both
32 and 64bit, but that's not by design and not documented so anyone
who is aware of cache foot print issues will go WTF when the first
member of a hot path data structure is completely irrelevant.
> static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
> {
> @@ -58,50 +65,82 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult,
> u32 shift)
>
> unsigned long long notrace sched_clock(void)
> {
> - u64 epoch_ns;
> - u64 epoch_cyc;
> u64 cyc;
> unsigned long seq;
> -
> - if (cd.suspended)
> - return cd.epoch_ns;
> + struct clock_data_banked *b;
> + u64 res;
So we now have
u64 cyc;
unsigned long seq;
struct clock_data_banked *b;
u64 res;
Let me try a different version of that:
struct clock_data_banked *b;
unsigned long seq;
u64 res, cyc;
Can you spot the difference in the reading experience?
> do {
> - seq = raw_read_seqcount_begin();
> - epoch_cyc = cd.epoch_cyc;
> - epoch_ns = cd.epoch_ns;
> + seq = raw_read_seqcount();
> + b = cd.bank + (seq & 1);
> + if (b->suspended) {
> + res = b->epoch_ns;
So now we have read_sched_clock as a pointer in the bank. Why do you
still need b->suspended?
What's wrong with setting b->read_sched_clock to NULL at suspend and
restore the proper pointer on resume and use that as a conditional?
It would allow the compiler to generate better code, but that's
obviously not the goal here. Darn, this is hot path code and not some
random driver.
> + } else {
> + cyc = b->read_sched_clock();
> + cyc = (cyc - b->epoch_cyc) & b->sched_clock_mask;
> + res = b->epoch_ns + cyc_to_ns(cyc, b->mult, b->shift);
It would allow the following optimization as well:
res = b->epoch_ns;
if (b->read_sched_clock) {
...
}
If you think that compilers are smart enough to figure all that out
for you, you might get surprised. The more clear your code is the
better is the chance that the compiler gets it right. We have seen the
opposite of that as well, but that's clearly a compiler bug.
> +/*
> + * Start updating the banked clock data.
> + *
> + * sched_clock will never observe mis-matched data even if called from
> + * an NMI. We do this by maintaining an odd/even copy of the data and
> + * steering sched_clock to one or the other using a sequence counter.
> + * In order to preserve the data cache profile of sched_clock as much
> + * as possible the system reverts back to the even copy when the update
> + * completes; the odd copy is used *only* during an update.
> + *
> + * The caller is responsible for avoiding simultaneous updates.
> + */
> +static struct clock_data_banked *update_bank_begin(void)
> +{
> + /* update the backup (odd) bank and steer readers towards it */
> + memcpy(cd.bank + 1, cd.bank, sizeof(struct clock_data_banked));
> + raw_write_seqcount_latch();
> +
> + return cd.bank;
> +}
> +
> +/*
> + * Finalize update of banked clock
Re: perf not capturing stack traces
Hi, On Sat, Jan 24, 2015 at 12:12:04PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 23, 2015 at 04:37:45PM -0600, Felipe Balbi escreveu: > > On Fri, Jan 23, 2015 at 05:59:59PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Fri, Jan 23, 2015 at 01:51:28PM -0600, Felipe Balbi escreveu: > > > > I'm using v3.19-rc5 on an ARM Cortex A9 board. Unfortunately, perf is > > > > not able to capture any stack traces even though I CONFIG_STACKTRACE, > > > > CONFIG_FRAME_POINTER and CONFIG_ARM_UNWIND all enabled. > > > > > > > > I wonder if anybody else is facing similar issues. > > > > > > Did it work with a previous kernel? > > > > haven't checked with this board. First time I tried to use perf for > > anything. > > And it is the first time I've heard about such a problem, not dealing > with ARM myself, so I guess this is a case for looking if there was some > previous kernel where this worked, then trying to bisect where the > problem was introduced :-\ yeah, I'll try a few older kernels, also see if I can reproduce on other boards. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/1] x86: Add Isolated Memory Regions for Quark X1000
On 24/01/15 21:56, Bryan O'Donoghue wrote:
+
+ if ((imr_to_phys(imr.addr_lo) == base) &&
+ (imr_to_phys(imr.addr_hi) == max)) {
I think we need to take care of the size that has been fix-up here ...
+ found = 1;
+ reg = i;
According to your comment this line becomes redundant.
Ah but I still think though.
"Ah but I still think *I'll keep* that though
:)
We eventually do an imr_write(reg, ); which I think reads better
than imr_write(i, );
--
BOD
--
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/1] x86: Add Isolated Memory Regions for Quark X1000
On 24/01/15 11:02, Andy Shevchenko wrote:
On Sat, Jan 24, 2015 at 3:48 AM, Ong, Boon Leong
wrote:
+static int imr_enabled(struct imr_regs *imr)
Do we want to make it inline perhaps since it is 1 liner?
Since it is declared static I would even suggest the new name is_imr_enabled().
I think imr_is_enabled() is a better name. Every other function is imr_
prefixed.
+
+ if ((imr_to_phys(imr.addr_lo) == base) &&
+ (imr_to_phys(imr.addr_hi) == max)) {
I think we need to take care of the size that has been fix-up here ...
+ found = 1;
+ reg = i;
According to your comment this line becomes redundant.
Ah but I still think though.
We eventually do an imr_write(reg, ); which I think reads better
than imr_write(i, );
--
BOD
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] fs: fix code-formatting issues in inotify
Fix code-formatting warnings from script/checkpatch.pl; multiple instances of
WARNING: line over 80 characters
CHECK: No space is necessary after a cast
CHECK: Alignment should match open parenthesis
WARNING: quoted string split across lines
CHECK: Blank lines aren't necessary before a close brace '}'
CHECK: Please don't use multiple blank lines
Signed-off-by: Stefan Haun
---
fs/notify/inotify/inotify_fsnotify.c | 11 +++---
fs/notify/inotify/inotify_user.c | 68 ++
2 files changed, 43 insertions(+), 36 deletions(-)
diff --git a/fs/notify/inotify/inotify_fsnotify.c
b/fs/notify/inotify/inotify_fsnotify.c
index 2cd900c..0238615 100644
--- a/fs/notify/inotify/inotify_fsnotify.c
+++ b/fs/notify/inotify/inotify_fsnotify.c
@@ -54,7 +54,7 @@ static bool event_compare(struct fsnotify_event *old_fsn,
}
static int inotify_merge(struct list_head *list,
- struct fsnotify_event *event)
+struct fsnotify_event *event)
{
struct fsnotify_event *last_event;
@@ -120,7 +120,8 @@ int inotify_handle_event(struct fsnotify_group *group,
return 0;
}
-static void inotify_freeing_mark(struct fsnotify_mark *fsn_mark, struct
fsnotify_group *group)
+static void inotify_freeing_mark(struct fsnotify_mark *fsn_mark,
+struct fsnotify_group *group)
{
inotify_ignored_and_remove_idr(fsn_mark, group);
}
@@ -145,8 +146,8 @@ static int idr_callback(int id, void *p, void *data)
fsn_mark = p;
i_mark = container_of(fsn_mark, struct inotify_inode_mark, fsn_mark);
- WARN(1, "inotify closing but id=%d for fsn_mark=%p in group=%p still in
"
- "idr. Probably leaking memory\n", id, p, data);
+ WARN(1, "inotify closing but id=%d for fsn_mark=%p in group=%p still in
idr. Probably leaking memory\n",
+id, p, data);
/*
* I'm taking the liberty of assuming that the mark in question is a
@@ -156,7 +157,7 @@ static int idr_callback(int id, void *p, void *data)
*/
if (fsn_mark)
printk(KERN_WARNING "fsn_mark->group=%p inode=%p wd=%d\n",
- fsn_mark->group, fsn_mark->inode, i_mark->wd);
+ fsn_mark->group, fsn_mark->inode, i_mark->wd);
return 0;
}
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 45064869..3214e2b 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -201,9 +201,9 @@ static ssize_t copy_event_to_user(struct fsnotify_group
*group,
buf += event_size;
/*
-* fsnotify only stores the pathname, so here we have to send the
pathname
-* and then pad that pathname out to a multiple of sizeof(inotify_event)
-* with zeros.
+* fsnotify only stores the pathname, so here we have to send the
+* pathname and then pad that pathname out to a multiple of
+* sizeof(inotify_event) with zeros.
*/
if (pad_name_len) {
/* copy the path name */
@@ -278,7 +278,10 @@ static int inotify_release(struct inode *ignored, struct
file *file)
pr_debug("%s: group=%p\n", __func__, group);
- /* free this group, matching get was
inotify_init->fsnotify_obtain_group */
+ /*
+* free this group, matching get was
+* inotify_init->fsnotify_obtain_group
+*/
fsnotify_destroy_group(group);
return 0;
@@ -294,7 +297,7 @@ static long inotify_ioctl(struct file *file, unsigned int
cmd,
size_t send_len = 0;
group = file->private_data;
- p = (void __user *) arg;
+ p = (void __user *)arg;
pr_debug("%s: group=%p cmd=%u\n", __func__, group, cmd);
@@ -307,7 +310,7 @@ static long inotify_ioctl(struct file *file, unsigned int
cmd,
send_len += round_event_name_len(fsn_event);
}
mutex_unlock(>notification_mutex);
- ret = put_user(send_len, (int __user *) p);
+ ret = put_user(send_len, (int __user *)p);
break;
}
@@ -325,11 +328,11 @@ static const struct file_operations inotify_fops = {
.llseek = noop_llseek,
};
-
/*
* find_inode - resolve a user-given path to a specific inode
*/
-static int inotify_find_inode(const char __user *dirname, struct path *path,
unsigned flags)
+static int inotify_find_inode(const char __user *dirname, struct path *path,
+ unsigned flags)
{
int error;
@@ -363,8 +366,9 @@ static int inotify_add_to_idr(struct idr *idr, spinlock_t
*idr_lock,
return ret < 0 ? ret : 0;
}
-static struct inotify_inode_mark *inotify_idr_find_locked(struct
fsnotify_group *group,
- int wd)
+static struct inotify_inode_mark *inotify_idr_find_locked(
+
[PATCH 2/2] fs: fix checkpatch code warnings for inotify
./fs/notify/inotify/inotify.h:23:
CHECK: extern prototypes should be avoided in .h files
./fs/notify/inotify/inotify.h:25:
CHECK: extern prototypes should be avoided in .h files
Removed extrn keywords; the matter, however, seems to be an open
debate.
./fs/notify/inotify/inotify_fsnotify.c:140:
ERROR: do not initialise statics to 0 or NULL
Replace the initialization by a comment:
Compiler takes care of the proper initialization.
./fs/notify/inotify/inotify_fsnotify.c:159:
WARNING: Prefer [subsystem eg: netdev]_warn([subsystem]dev, ... then
dev_warn(dev, ... then pr_warn(... to printk(KERN_WARNING ...
./fs/notify/inotify/inotify_user.c:473:
WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
./fs/notify/inotify/inotify_user.c:474:
WARNING: quoted string split across lines
Use pr_warn instead of printk and fix line break.
./fs/notify/inotify/inotify_user.c:645:
CHECK: Prefer kmalloc(sizeof(*oevent)...) over
kmalloc(sizeof(struct inotify_event_info)...)
Done that (complies to coding stlye).
Signed-off-by: Stefan Haun
---
fs/notify/inotify/inotify.h | 16
fs/notify/inotify/inotify_fsnotify.c |6 +++---
fs/notify/inotify/inotify_user.c |8
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/fs/notify/inotify/inotify.h b/fs/notify/inotify/inotify.h
index ed855ef..9d6d4e2 100644
--- a/fs/notify/inotify/inotify.h
+++ b/fs/notify/inotify/inotify.h
@@ -20,13 +20,13 @@ static inline struct inotify_event_info *INOTIFY_E(struct
fsnotify_event *fse)
return container_of(fse, struct inotify_event_info, fse);
}
-extern void inotify_ignored_and_remove_idr(struct fsnotify_mark *fsn_mark,
- struct fsnotify_group *group);
-extern int inotify_handle_event(struct fsnotify_group *group,
- struct inode *inode,
- struct fsnotify_mark *inode_mark,
- struct fsnotify_mark *vfsmount_mark,
- u32 mask, void *data, int data_type,
- const unsigned char *file_name, u32 cookie);
+void inotify_ignored_and_remove_idr(struct fsnotify_mark *fsn_mark,
+ struct fsnotify_group *group);
+
+int inotify_handle_event(struct fsnotify_group *group, struct inode *inode,
+struct fsnotify_mark *inode_mark,
+struct fsnotify_mark *vfsmount_mark,
+u32 mask, void *data, int data_type,
+const unsigned char *file_name, u32 cookie);
extern const struct fsnotify_ops inotify_fsnotify_ops;
diff --git a/fs/notify/inotify/inotify_fsnotify.c
b/fs/notify/inotify/inotify_fsnotify.c
index 0238615..16efe98 100644
--- a/fs/notify/inotify/inotify_fsnotify.c
+++ b/fs/notify/inotify/inotify_fsnotify.c
@@ -137,7 +137,7 @@ static int idr_callback(int id, void *p, void *data)
{
struct fsnotify_mark *fsn_mark;
struct inotify_inode_mark *i_mark;
- static bool warned = false;
+ static bool warned; /* = false; default by GCC */
if (warned)
return 0;
@@ -156,8 +156,8 @@ static int idr_callback(int id, void *p, void *data)
* BUG() that was here.
*/
if (fsn_mark)
- printk(KERN_WARNING "fsn_mark->group=%p inode=%p wd=%d\n",
- fsn_mark->group, fsn_mark->inode, i_mark->wd);
+ pr_warn("fsn_mark->group=%p inode=%p wd=%d\n",
+ fsn_mark->group, fsn_mark->inode, i_mark->wd);
return 0;
}
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 3214e2b..d7e3e58 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -470,9 +470,9 @@ static void inotify_remove_from_idr(struct fsnotify_group
*group,
* one ref grabbed by inotify_idr_find
*/
if (unlikely(atomic_read(_mark->fsn_mark.refcnt) < 3)) {
- printk(KERN_ERR "%s: i_mark=%p i_mark->wd=%d i_mark->group=%p"
- " i_mark->inode=%p\n", __func__, i_mark, i_mark->wd,
- i_mark->fsn_mark.group, i_mark->fsn_mark.inode);
+ pr_err("%s: i_mark=%p i_mark->wd=%d i_mark->group=%p
i_mark->inode=%p\n",
+ __func__, i_mark, i_mark->wd, i_mark->fsn_mark.group,
+ i_mark->fsn_mark.inode);
/* we can't really recover with bad ref cnting.. */
BUG();
}
@@ -642,7 +642,7 @@ static struct fsnotify_group *inotify_new_group(unsigned
int max_events)
if (IS_ERR(group))
return group;
- oevent = kmalloc(sizeof(struct inotify_event_info), GFP_KERNEL);
+ oevent = kmalloc(sizeof(*oevent), GFP_KERNEL);
if
Re: [PATCH 2/2] fs: fix checkpatch code warnings for inotify
I just noticed that I failed in setting the right From: header. Sorry for
this, I will re-post the patches with correct meta-data set.
Am Freitag, 16. Januar 2015, 16:15:11 schrieb y...@mail.netz39.de:
> From: Stefan Haun
>
> ./fs/notify/inotify/inotify.h:23:
> CHECK: extern prototypes should be avoided in .h files
> ./fs/notify/inotify/inotify.h:25:
> CHECK: extern prototypes should be avoided in .h files
>
> Removed extrn keywords; the matter, however, seems to be an open
> debate.
>
> ./fs/notify/inotify/inotify_fsnotify.c:140:
> ERROR: do not initialise statics to 0 or NULL
>
> Replace the initialization by a comment:
> Compiler takes care of the proper initialization.
>
> ./fs/notify/inotify/inotify_fsnotify.c:159:
> WARNING: Prefer [subsystem eg: netdev]_warn([subsystem]dev, ... then
> dev_warn(dev, ... then pr_warn(... to printk(KERN_WARNING ...
> ./fs/notify/inotify/inotify_user.c:473:
> WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
> dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
> ./fs/notify/inotify/inotify_user.c:474:
> WARNING: quoted string split across lines
>
> Use pr_warn instead of printk and fix line break.
>
> ./fs/notify/inotify/inotify_user.c:645:
> CHECK: Prefer kmalloc(sizeof(*oevent)...) over
> kmalloc(sizeof(struct inotify_event_info)...)
>
> Done that (complies to coding stlye).
>
> Signed-off-by: Stefan Haun
> ---
> fs/notify/inotify/inotify.h | 16
> fs/notify/inotify/inotify_fsnotify.c |6 +++---
> fs/notify/inotify/inotify_user.c |8
> 3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/fs/notify/inotify/inotify.h b/fs/notify/inotify/inotify.h
> index ed855ef..9d6d4e2 100644
> --- a/fs/notify/inotify/inotify.h
> +++ b/fs/notify/inotify/inotify.h
> @@ -20,13 +20,13 @@ static inline struct inotify_event_info
> *INOTIFY_E(struct fsnotify_event *fse) return container_of(fse, struct
> inotify_event_info, fse);
> }
>
> -extern void inotify_ignored_and_remove_idr(struct fsnotify_mark *fsn_mark,
> -struct fsnotify_group *group);
> -extern int inotify_handle_event(struct fsnotify_group *group,
> - struct inode *inode,
> - struct fsnotify_mark *inode_mark,
> - struct fsnotify_mark *vfsmount_mark,
> - u32 mask, void *data, int data_type,
> - const unsigned char *file_name, u32 cookie);
> +void inotify_ignored_and_remove_idr(struct fsnotify_mark *fsn_mark,
> + struct fsnotify_group *group);
> +
> +int inotify_handle_event(struct fsnotify_group *group, struct inode
> *inode, + struct fsnotify_mark *inode_mark,
> + struct fsnotify_mark *vfsmount_mark,
> + u32 mask, void *data, int data_type,
> + const unsigned char *file_name, u32 cookie);
>
> extern const struct fsnotify_ops inotify_fsnotify_ops;
> diff --git a/fs/notify/inotify/inotify_fsnotify.c
> b/fs/notify/inotify/inotify_fsnotify.c index 0238615..16efe98 100644
> --- a/fs/notify/inotify/inotify_fsnotify.c
> +++ b/fs/notify/inotify/inotify_fsnotify.c
> @@ -137,7 +137,7 @@ static int idr_callback(int id, void *p, void *data)
> {
> struct fsnotify_mark *fsn_mark;
> struct inotify_inode_mark *i_mark;
> - static bool warned = false;
> + static bool warned; /* = false; default by GCC */
>
> if (warned)
> return 0;
> @@ -156,8 +156,8 @@ static int idr_callback(int id, void *p, void *data)
>* BUG() that was here.
>*/
> if (fsn_mark)
> - printk(KERN_WARNING "fsn_mark->group=%p inode=%p wd=%d\n",
> -fsn_mark->group, fsn_mark->inode, i_mark->wd);
> + pr_warn("fsn_mark->group=%p inode=%p wd=%d\n",
> + fsn_mark->group, fsn_mark->inode, i_mark->wd);
> return 0;
> }
>
> diff --git a/fs/notify/inotify/inotify_user.c
> b/fs/notify/inotify/inotify_user.c index 3214e2b..d7e3e58 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -470,9 +470,9 @@ static void inotify_remove_from_idr(struct
> fsnotify_group *group, * one ref grabbed by inotify_idr_find
>*/
> if (unlikely(atomic_read(_mark->fsn_mark.refcnt) < 3)) {
> - printk(KERN_ERR "%s: i_mark=%p i_mark->wd=%d i_mark->group=%p"
> - " i_mark->inode=%p\n", __func__, i_mark, i_mark->wd,
> - i_mark->fsn_mark.group, i_mark->fsn_mark.inode);
> + pr_err("%s: i_mark=%p i_mark->wd=%d i_mark->group=%p
> i_mark->inode=%p\n", + __func__, i_mark, i_mark->wd,
> i_mark->fsn_mark.group,
> +i_mark->fsn_mark.inode);
> /* we can't really recover with bad ref cnting.. */
>
Re: [PATCH 3.19-rc2 v15 5/8] printk: Simple implementation for NMI backtracing
On Fri, 23 Jan 2015, Daniel Thompson wrote:
> +#ifdef CONFIG_ARCH_WANT_NMI_PRINTK
> +extern __printf(1, 0) int nmi_vprintk(const char *fmt, va_list args);
> +
> +struct cpumask;
> +extern int prepare_nmi_printk(struct cpumask *cpus);
> +extern void complete_nmi_printk(struct cpumask *cpus);
> +
> +/*
> + * Replace printk to write into the NMI seq.
> + *
> + * To avoid include hell this is a macro rather than an inline function
> + * (printk_func is not declared in this header file).
> + */
> +#define this_cpu_begin_nmi_printk() ({ \
> + printk_func_t __orig = this_cpu_read(printk_func); \
> + this_cpu_write(printk_func, nmi_vprintk); \
> + __orig; \
> +})
> +#define this_cpu_end_nmi_printk(fn) this_cpu_write(printk_func, fn)
Why can't we just make it a proper function in printk.c and make
DEFINE_PER_CPU(printk_func_t, printk_func) static once x86 is
converted over, thereby getting rid of the misplaced declaration in
percpu.h?
It's really not performance critical at all. If you do system wide
backtraces a function call is the least of your worries.
> +#ifdef CONFIG_ARCH_WANT_NMI_PRINTK
Why can't this simply be CONFIG_PRINTK_NMI and live at the same place
as the other printk related options?
> +int nmi_vprintk(const char *fmt, va_list args)
> +{
> + struct nmi_seq_buf *s = this_cpu_ptr(_print_seq);
> + unsigned int len = seq_buf_used(>seq);
> +
> + seq_buf_vprintf(>seq, fmt, args);
> + return seq_buf_used(>seq) - len;
> +}
> +EXPORT_SYMBOL_GPL(nmi_vprintk);
What's the point of these exports? This stuff is really not supposed
to be used inside random modules.
> +/*
> + * Check for concurrent usage and set up per_cpu seq_buf buffers that the
> NMIs
> + * running on the other CPUs will write to. Provides the mask of CPUs it is
> + * safe to write from (i.e. a copy of the online mask).
> + */
> +int prepare_nmi_printk(struct cpumask *cpus)
Can we please make all this proper prefixed? , i.e. printk_nmi_*
> +{
> + struct nmi_seq_buf *s;
> + int cpu;
> +
> + if (test_and_set_bit(0, _print_flag)) {
> + /*
> + * If something is already using the NMI print facility we
> + * can't allow a second one...
> + */
> + return -EBUSY;
So what's the point of saving and restoring the printk_func pointer at
the call site?
void printk_nmi_begin()
{
if (__this_cpu_inc_return(nmi_printk_nest_level) == 1)
this_cpu_write(printk_func, nmi_vprintk);
}
void printk_nmi_end()
{
if (__this_cpu_dec_return(nmi_printk_nest_level) > 0)
return;
this_cpu_write(printk_func, default_vprintk);
if (in_nmi())
irq_work_schedule();
else
printk_nmi_complete();
}
> + }
> +
> + cpumask_copy(cpus, cpu_online_mask);
Why do you need external storage for this if nesting is not allowed?
What's wrong with having a printk_nmi_mask? It's protected by the
nmi_print_flag, so the call sites do not have to take care about
protecting it until printk_nmi_complete() has been invoked.
> + for_each_cpu(cpu, cpus) {
> + s = _cpu(nmi_print_seq, cpu);
> + seq_buf_init(>seq, s->buffer, NMI_BUF_SIZE);
Why do you want to do this here? The buffers should be initialized
before the first NMI can hit and the complete code should reinit them
before the next printk_nmi_prepare() sees the nmi_print_flag cleared.
> +static void print_seq_line(struct nmi_seq_buf *s, int start, int end)
> +{
> + const char *buf = s->buffer + start;
> +
> + printk("%.*s", (end - start) + 1, buf);
> +}
> +
> +void complete_nmi_printk(struct cpumask *cpus)
> +{
> + struct nmi_seq_buf *s;
> + int len;
> + int cpu;
> + int i;
Please condense all ints to a single line, but what's worse is the
completely inconsistency versus scopes.
len and i are only used in the for_each loop. Either we put all of
them at the top of the function or we do it right.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: ux500: Move struct
On Saturday 24 January 2015 18:33:00 Rickard Strandqvist wrote: > 2015-01-22 8:44 GMT+01:00 Lee Jones : > > > > Are you sure a struct is required at all now? It only contains a > > single bool after all. > > > Hi Lee > > Okay, I will gladly remove ab8500_ext_regulator_cfg completely. > And I will try to update the comments, but since I'm not so familiar > with what this code was meant to do it is a little more difficult. > Try to take small steps then: See if there is something in this code that is either never called, or data structures that are only written but never read, or pointers that are verifiably always NULL, then eliminate one piece of the code at a time, with a patch that explains what you found. Try to make sure everything still builds after each patch, and note that this was not the case with your first patch, though it would have worked in the reverse order. I suspect the best way forward is to actually move all of ab8500_regulator_plat_data and whatever it references into drivers/regulator/ab8500-ext.c because there now is only one remaining instance of that. After this move, you can delete a lot of code in arch/arm/mach-ux500 and possibly move all of include/linux/regulator/ab8500.h into drivers/regulator/ab8500-ext.c as well. Arnd -- 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: rcu, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()
On Sat, Jan 24, 2015 at 10:18:05AM +0800, Lai Jiangshan wrote:
> On 01/23/2015 05:36 PM, Paul E. McKenney wrote:
> > On Thu, Jan 22, 2015 at 10:55:42PM -0800, Paul E. McKenney wrote:
> >> On Thu, Jan 22, 2015 at 11:05:45PM -0500, Sasha Levin wrote:
> >>> On 01/22/2015 11:02 PM, Sasha Levin wrote:
> On 01/22/2015 10:51 PM, Paul E. McKenney wrote:
> > On Thu, Jan 22, 2015 at 10:29:01PM -0500, Sasha Levin wrote:
> >>> On 01/21/2015 07:43 PM, Paul E. McKenney wrote:
> > On Wed, Jan 21, 2015 at 10:44:57AM -0500, Sasha Levin wrote:
> >>> On 01/20/2015 09:57 PM, Paul E. McKenney wrote:
> > So RCU believes that an RCU read-side critical section that
> > ended within
> > an interrupt handler (in this case, an hrtimer) somehow
> > got preempted.
> > Which is not supposed to happen.
> >
> > Do you have CONFIG_PROVE_RCU enabled? If not, could
> > you please enable it
> > and retry?
> >
> > I did have CONFIG_PROVE_RCU, and didn't see anything else
> > besides what I pasted here.
> > OK, fair enough. I do have a stack of RCU CPU stall-warning
> > changes on
> > their way in, please see v3.19-rc1..630181c4a915 in -rcu, which
> > is at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >
> > These handle the problems that Dave Jones, yourself, and a few
> > others
> > located this past December. Could you please give them a spin?
> >>>
> >>> They seem to be a part of -next already, so this testing already
> >>> includes them.
> >>>
> >>> I seem to be getting them about once a day, anything I can add to
> >>> debug it?
> >
> > Could you please try reproducing with the following patch?
> >>>
> >>> Yes, and I've got mixed results. It reproduced, and all I got was:
> >>>
> >>> [ 717.645572] ===
> >>> [ 717.645572] [ INFO: suspicious RCU usage. ]
> >>> [ 717.645572] 3.19.0-rc5-next-20150121-sasha-00064-g3c37e35-dirty
> >>> #1809 Tainted: GW
> >>> [ 717.645572] ---
> >>> [ 717.645572] kernel/rcu/tree_plugin.h:337 rcu_read_unlock() from
> >>> irq or softirq with blocking in critical section!!!
> >>> [ 717.645572] !
> >>> [ 717.645572]
> >>> [ 717.645572] other info that might help us debug this:
> >>> [ 717.645572]
> >>> [ 717.645572]
> >>> [ 717.645572] rcu_scheduler_active = 1, debug_locks = 1
> >>> [ 717.645572] 3 locks held by trinity-c29/16497:
> >>> [ 717.645572] #0: (>s_type->i_mutex_key){+.+.+.}, at:
> >>> [] lookup_slow+0xd3/0x420
> >>> [ 717.645572] #1:
> >>> [hang]
> >>>
> >>> So the rest of the locks/stack trace didn't get printed, nor the
> >>> pr_alert() which
> >>> should follow that.
> >>>
> >>> I've removed the lockdep call and will re-run it.
> > Thank you! You are keeping the pr_alert(), correct?
>
> Yup, just the lockdep call goes away.
> >>>
> >>> Okay, this reproduced faster than I anticipated:
> >>>
> >>> [ 786.160131] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.239513] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.240503] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.242575] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> >>>
> >>> It seems like the WARN_ON_ONCE was hiding the fact it actually got hit
> >>> couple
> >>> of times in a very short interval. Maybe that would also explain lockdep
> >>> crapping
> >>> itself.
> >>
> >> OK, that was what I thought was the situation. I have not yet fully
> >> worked out how RCU gets into that state, but in the meantime, here
> >> is a patch that should prevent the splats. (It requires a subtle
> >> interaction of quiescent-state detection and the scheduling-clock
> >> interrupt.)
> >
> > And I did finally figure out how this can happen. Please see below
> > for an updated patch with this information recorded in the commit log.
> > Sasha, I am impressed -- your testing not only located a true RCU bug,
> > but an RCU bug that can happen on a uniprocessor! ;-)
> >
> > As far as I know, the bug is harmless apart from the splat, but still...
> >
> > Thanx, Paul
Re: [PATCH 14/32] rcu: use %*pb[l] to print bitmaps including cpumasks and nodemasks
On Sat, Jan 24, 2015 at 09:03:20AM -0500, Tejun Heo wrote:
> printk and friends can now formap bitmaps using '%*pb[l]'. cpumask
> and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
> respectively which can be used to generate the two printf arguments
> necessary to format the specified cpu/nodemask.
>
> This patch is dependent on the following two patches.
>
> lib/vsprintf: implement bitmap printing through '%*pb[l]'
> cpumask, nodemask: implement cpumask/nodemask_pr_args()
>
> Please wait till the forementioned patches are merged to mainline
> before applying to subsystem trees.
>
> Signed-off-by: Tejun Heo
> Cc: Andrew Morton
> Cc: "Paul E. McKenney"
Nice!!! I would be happy to take these, if you would like. If so, please
let me know when the two patches above hit mainline.
Thanx, Paul
> ---
> kernel/rcu/tree_plugin.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 3ec85cb..26e04cf 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -53,7 +53,6 @@ DEFINE_PER_CPU(char, rcu_cpu_has_work);
> static cpumask_var_t rcu_nocb_mask; /* CPUs to have callbacks offloaded. */
> static bool have_rcu_nocb_mask; /* Was rcu_nocb_mask allocated? */
> static bool __read_mostly rcu_nocb_poll;/* Offload kthread are to poll.
> */
> -static char __initdata nocb_buf[NR_CPUS * 5];
> #endif /* #ifdef CONFIG_RCU_NOCB_CPU */
>
> /*
> @@ -2513,8 +2512,8 @@ void __init rcu_init_nohz(void)
> cpumask_and(rcu_nocb_mask, cpu_possible_mask,
> rcu_nocb_mask);
> }
> - cpulist_scnprintf(nocb_buf, sizeof(nocb_buf), rcu_nocb_mask);
> - pr_info("\tOffload RCU callbacks from CPUs: %s.\n", nocb_buf);
> + pr_info("\tOffload RCU callbacks from CPUs: %*pbl.\n",
> + cpumask_pr_args(rcu_nocb_mask));
> if (rcu_nocb_poll)
> pr_info("\tPoll for callbacks from no-CBs CPUs.\n");
>
> --
> 2.1.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 0/4] defconfigs: cleanup obsolete MTD configs
> That's news for me. I thought they are silently ignored. Do you have an > example of such a warning? Not really. It was just assumption. It seems you are right, they are just ignored silently. But item 2 is still relevant and it was actually confused me when I tried to figure out MTD configuration for my platform. Anyway, garbage should be taken out from time to time. > Seems like the kind of change that can only be reviewed by a script. Good point. Because these patches were done by script to start with. Anyway, I reviewed result patches manually to be completely sure. You can write verifying script though, if you need to, it wouldn't take more than 2 minutes (it takes one-liner, actually). > I seem to remember Greg stating that defconfig files are on their way > out. Did I remember that correctly? Maybe they are. But they still in place, and why it's so, we should maintain them up-to-date. Ideally, this kind of work should be done by someone who introduces changes into Kconfig files. So I just fixed that oversight. -- 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] ARM: OMAP2+: gpmc: Do not modify LIMITEDADDRESS on new architectures
New OMAP-based architectures (like OMAP5, DRA7XX, AM572X) don't have
LIMITEDADDRESS bit in GPMC_CONFIG register (this bit marked as
RESERVED). Seems like these SoCs have new revision of GPMC IP-core
(despite of same GPMC_REVISION value as for earlier SoCs).
According to OMAP5 TRM: "Nonmultiplexed NOR flash devices are
supported by the GPMC, but their use is highly limited. Because only
10 address pins are available on the GPMC interface, the maximum device
size supported is 2KiB."
>From [1]:
- OMAP4 GPMC_CONFIG has LIMITEDADDRESS bit, hence supports both
limited and full address mode.
- OMAP5 GPMC_CONFIG doesn't have LIMITEDDADDRESS bit.
OMAP5 supports only limited address mode for nonmultiplexed flashes
In this mode only A1-A10 lines are being modified by GPMC, which
leaves us (on flash devices with 1 word = 2 bytes) only
2^10 * 2 = 2KiB memory that we can access.
- DRA7XX GPMC_CONFIG doesn't have LIMITEDADDRESS bit.
DRA7XX supports only full address mode for nonmultiplexed flashes
(current TRM says contrary, but according to [1] it's typo and
gonna be fixed in new DRA7XX TRMs). In full address mode all
A1-A26 lines are modified by GPMC, so one can address up to 128 MiB.
This patch ensures that GPMC driver doesn't try to modify LIMITEDADDRESS
bit on new OMAP-based devices, because such an action could possibly
lead to undefined behavior in GPMC state-machine (this bit is marked as
RESERVED now).
[1] http://e2e.ti.com/support/omap/f/885/t/396939
Signed-off-by: Semen Protsenko
---
drivers/memory/omap-gpmc.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index db77adb..477d0ba 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -108,6 +108,7 @@
#defineGPMC_HAS_WR_ACCESS 0x1
#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
#defineGPMC_HAS_MUX_AAD0x4
+#defineGPMC_HAS_LIMITEDADDRESS 0x8
#define GPMC_NR_WAITPINS 4
@@ -1709,6 +1710,18 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static void gpmc_disable_limited(void)
+{
+ if (gpmc_capability & GPMC_HAS_LIMITEDADDRESS) {
+ u32 val;
+
+ /* Clear limited address i.e. enable A26-A11 */
+ val = gpmc_read_reg(GPMC_CONFIG);
+ val &= ~GPMC_CONFIG_LIMITEDADDRESS;
+ gpmc_write_reg(GPMC_CONFIG, val);
+ }
+}
+
/**
* gpmc_probe_generic_child - configures the gpmc for a child device
* @pdev: pointer to gpmc platform device
@@ -1726,7 +1739,6 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
unsigned long base;
const char *name;
int ret, cs;
- u32 val;
if (of_property_read_u32(child, "reg", ) < 0) {
dev_err(>dev, "%s has no 'reg' property\n",
@@ -1805,10 +1817,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
goto err;
}
- /* Clear limited address i.e. enable A26-A11 */
- val = gpmc_read_reg(GPMC_CONFIG);
- val &= ~GPMC_CONFIG_LIMITEDADDRESS;
- gpmc_write_reg(GPMC_CONFIG, val);
+ gpmc_disable_limited();
/* Enable CS region */
gpmc_cs_enable_mem(cs);
@@ -1935,14 +1944,21 @@ static int gpmc_probe(struct platform_device *pdev)
* devices support the addr-addr-data multiplex protocol.
*
* GPMC IP revisions:
-* - OMAP24xx = 2.0
-* - OMAP3xxx = 5.0
-* - OMAP44xx/54xx/AM335x = 6.0
+* - OMAP24xx = 2.0
+* - OMAP3xxx = 5.0
+* - OMAP44xx/54xx/AM335x/DRA7XX= 6.0
*/
if (GPMC_REVISION_MAJOR(l) > 0x4)
gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
if (GPMC_REVISION_MAJOR(l) > 0x5)
gpmc_capability |= GPMC_HAS_MUX_AAD;
+ if (GPMC_REVISION_MAJOR(l) < 0x6)
+ gpmc_capability |= GPMC_HAS_LIMITEDADDRESS;
+#if !defined(CONFIG_SOC_OMAP5) && !defined(CONFIG_SOC_DRA7XX)
+ if (GPMC_REVISION_MAJOR(l) == 0x6)
+ gpmc_capability |= GPMC_HAS_LIMITEDADDRESS;
+#endif
+
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: OMAP2+: gpmc: make gpmc_cs_get_name() static
Fix sparse warning:
warning: symbol 'gpmc_cs_get_name' was not declared. Should it be static?
Signed-off-by: Semen Protsenko
---
drivers/memory/omap-gpmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 10eb4ac..db77adb 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -668,7 +668,7 @@ static void gpmc_cs_set_name(int cs, const char *name)
gpmc->name = name;
}
-const char *gpmc_cs_get_name(int cs)
+static const char *gpmc_cs_get_name(int cs)
{
struct gpmc_cs_data *gpmc = _cs[cs];
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: OMAP2+: gpmc: Fix writing in gpmc_cs_set_memconf
Some GPMC_CONFIG7 register bits marked as "RESERVED", means they shouldn't be overwritten. A typical approach to handle such bits called "Read-Modify-Write". Writing procedure used in gpmc_cs_set_memconf() utilizes RMW technique, but implemented incorrectly. Due to obvious typo in code read register value is being rewritten by another value, which leads to loss of read RESERVED bits. This patch fixes this. While at it, replace magic numbers with named constants to improve code readability. Signed-off-by: Semen Protsenko --- drivers/memory/omap-gpmc.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 24696f5..10eb4ac 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -153,6 +153,15 @@ #define GPMC_CONFIG1_FCLK_DIV4 (GPMC_CONFIG1_FCLK_DIV(3)) #define GPMC_CONFIG7_CSVALID (1 << 6) +#define GPMC_CONFIG7_BASEADDRESS_MASK 0x3f +#define GPMC_CONFIG7_CSVALID_MASK BIT(6) +#define GPMC_CONFIG7_MASKADDRESS_OFFSET8 +#define GPMC_CONFIG7_MASKADDRESS_MASK (0xf << GPMC_CONFIG7_MASKADDRESS_OFFSET) +/* All CONFIG7 bits except reserved bits */ +#define GPMC_CONFIG7_MASK (GPMC_CONFIG7_BASEADDRESS_MASK | \ +GPMC_CONFIG7_CSVALID_MASK | \ +GPMC_CONFIG7_MASKADDRESS_MASK) + #define GPMC_DEVICETYPE_NOR0 #define GPMC_DEVICETYPE_NAND 2 #define GPMC_CONFIG_WRITEPROTECT 0x0010 @@ -586,12 +595,15 @@ static int gpmc_cs_set_memconf(int cs, u32 base, u32 size) if (base & (size - 1)) return -EINVAL; + base >>= GPMC_CHUNK_SHIFT; mask = (1 << GPMC_SECTION_SHIFT) - size; + mask >>= GPMC_CHUNK_SHIFT; + mask <<= GPMC_CONFIG7_MASKADDRESS_OFFSET; + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7); - l &= ~0x3f; - l = (base >> GPMC_CHUNK_SHIFT) & 0x3f; - l &= ~(0x0f << 8); - l |= ((mask >> GPMC_CHUNK_SHIFT) & 0x0f) << 8; + l &= ~GPMC_CONFIG7_MASK; + l |= base & GPMC_CONFIG7_BASEADDRESS_MASK; + l |= mask & GPMC_CONFIG7_MASKADDRESS_MASK; l |= GPMC_CONFIG7_CSVALID; gpmc_cs_write_reg(cs, GPMC_CS_CONFIG7, l); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots
Daniel, Matt, On Sat, Jan 24, 2015 at 12:24:55PM +0100, Daniel Vetter wrote: > On Fri, Jan 23, 2015 at 10:57:32PM -0800, Jeremiah Mahler wrote: > > all, > > > > On Tue, Jan 20, 2015 at 06:48:42AM +0100, Daniel Vetter wrote: > > > On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote: > > > > On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote: > > > > > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote: [...] > drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb > > that should rectify the sluggish i915 cursor. But it's in a separate topic > branch which isn't in linux-next. Should show up in drm-next next week > though. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch I found the patch and tried it out. It does fix the mouse pointer problem. Thanks for the fix. -- - Jeremiah Mahler -- 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: question about save_xstate_sig() - WHY DOES THIS WORK?
Let me abuse this thread to ask more questions.
Peter, could you help?
On 01/23, Rik van Riel wrote:
>
> Not only is this broken with my new code, but it looks like it may
> be broken with the current code, too...
As I already mentioned, at least math_error()->save_init_fpu() looks
buggy. And unlazy_fpu() doesn't look right too.
Note that save_init_fpu() is calles after conditional_sti(), so unless
I missed something the task can be preempted and we can actually hit
WARN_ON_ONCE(!__thread_has_fpu()) if !use_eager_fpu() && .fpu_counter == 0.
Worse, the unconditional __save_init_fpu() is obviously wrong in this case.
I already have a patch which (like the patch from Rik) turns it into
static inline void save_init_fpu(struct task_struct *tsk)
{
preempt_disable();
if (__thread_has_fpu(tsk)) {
if (use_eager_fpu()) {
__save_fpu(tsk);
} else {
__save_init_fpu(tsk);
__thread_fpu_end(tsk);
}
}
preempt_enable();
}
and I think this fix needs the separate patch/changelog.
Now the questions:
- This doesn't hurt, but does it really need __thread_fpu_end?
Perhaps this is because we do not check the error code returned
by __save_init_fpu? although I am not sure I understand the comment
above fpu_save_init correctly...
- What about do_bounds() ? Should not it use save_init_fpu() rather
than fpu_save_init() ?
- Why unlazy_fpu() always does __save_init_fpu() even if use_eager_fpu?
and note that in this case __thread_fpu_end() is wrong if use_eager_fpu,
but fortunately the only possible caller of unlazy_fpu() is coredump.
fpu_copy() checks use_eager_fpu().
- Is unlazy_fpu()->__save_init_fpu() safe wrt __kernel_fpu_begin() from
irq?
I mean, is it safe if __save_init_fpu() path is interrupted by another
__save_init_fpu() + restore_fpu_checking() from __kernel_fpu_begin/end?
Thanks,
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8712: fix Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
This patch fixes the following checkpatch.pl warning: fix Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ... netdev_info was used since it is a network subsystem Signed-off-by: Heba Aamer --- drivers/staging/rtl8712/usb_intf.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c index 7d0d171..7748a75 100644 --- a/drivers/staging/rtl8712/usb_intf.c +++ b/drivers/staging/rtl8712/usb_intf.c @@ -366,7 +366,7 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf, struct net_device *pnetdev; struct usb_device *udev; - printk(KERN_INFO "r8712u: Staging version\n"); + netdev_info(pnetdev, "r8712u: Staging version\n"); /* In this probe function, O.S. will provide the usb interface pointer * to driver. We have to increase the reference count of the usb device * structure by using the usb_get_dev function. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] x86: Add Isolated Memory Regions for Quark X1000
On 24/01/15 01:48, Ong, Boon Leong wrote:
Skipping stuff I agree with.
From V1 comment:
Suggest to add a statement on 3 different types of IMR: General IMR, Host Memory
I/O Boundary IMR & System Management Mode IMR. Then, call out that this patch
is meant to support general IMR type only.
Hmm - There's no mention of grouping like that in the documentation, nor
in released silicon - to my knowledge.
Also why do you want a statement added saying that it supports CPU only
mode ?
This patch will support adding IMRs for SMM mode - if calling code wants
do do that - it's just imr_add_range(base, size, SMM, SMM);
Same thing with virtual-channels, RMU, etc.
+ ret = imr_check_range(base, size);
+ if (ret)
+ return ret;
+
+ if (size < IMR_ALIGN)
+ return -EINVAL;
I believe this is redundant because imr_check_range() has test for (size &
IMR_MASK)
which means if the size is indeed smaller than 0x400, the test will caught it
anyway.
Nope.
(0 & 0x3FF) == 0
We need to bounds check for a zero size.
I'll change it to
if (size == 0)
return -EINVAL;
to avoid confusion.
+
+ /* Tweak the size value */
+ size = imr_fixup_size(size);
+ pr_debug("IMR %d phys 0x%08lx-0x%08lx rmask 0x%08x wmask
0x%08x\n",
+ reg, base, end, rmask, wmask);
Do we want to account for the 'size fixup' above on 'end'
+
+ /* Allocate IMR */
+ imr.addr_lo = phys_to_imr(base);
+ imr.addr_hi = phys_to_imr(end);
The fix-up size above is never factored here ...
'end-size' should be the correct one
hmmm.
The correct fix is
size = imr_fixup_size(size);
end = base + size;
+ } else {
+ /* Search for match based on address range */
+ for (i = 0; i < imr_dev.max_imr; i++) {
+ ret = imr_read(reg, );
A serious bug here 'reg' should be 'i' . We enter this branch if reg=-1
Is there a miss in your test case?
Hmm you're right.
Turns out there's only the one test case for imr_del_range();
Good catch.
--
BOD
--
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/2] posix-timers: Prevents overrun counter overflow
On 01/24/2015 12:48 PM, Daniel Church wrote: > +#define DELAYTIMER_MAX_DEFAULT 100 Why did you chose 1 million? Have you reviewed what constant userspace, particularly glibc, is using? Cheers, Carlos. -- 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 2/2] posix-timers: Exposes DELAYTIMER_MAX constant used to govern overruns
On 01/24/2015 02:20 PM, Thomas Gleixner wrote: > On Sat, 24 Jan 2015, Daniel Church wrote: > >> POSIX.1-2001 specification of timer_getoverrun() supports constant >> DELAYTIMER_MAX which prevents overflow and caps overrun count. Exposes >> delaytimer_max value to userland via /proc/sys/kernel/delaytimer_max such > > I know that you try to match the posix name, but when looking at the > prctl w/o knowing about DELAYTIMER_MAX, it's non intuitive. > > Something like posixtimer_max_overruns or if you insist on the > delaytimer_max part, then let us prepend it with posixtimer_ at least. > > New prctls require an update of Documentation/sysctl/kernel.txt. Agreed, the name should be self-explanatory and point at POSIX. The documentation should be detailed and explain exactly what this is for, what are valid values, and why you would ever want to change them. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/kstrtox.c clean kstrtoll function
On Fri, Jan 23, 2015 at 06:55:36PM +0530, Anshul Garg wrote: > if (((long long)tmp < LLONG_MIN) || ((long long)tmp > LLONG_MAX) ) > + return -ERANGE; This proposed code is still wrong (-ERANGE can never be returned by this statement). It may be best to leave the code alone, rather than propose more untested alternatives. Jeff -- 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: [Resend Patch v4 00/16] Kill SMP single function call interrupt
On Fri, 23 Jan 2015, Jiang Liu wrote: > 38 files changed, 65 insertions(+), 268 deletions(-) Nice cleanup. If nobody yells, I'm going to route it through tip. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] ARM: sa1100: use ioremapped memory to access SC registers
On Sat, 24 Jan 2015, Dmitry Eremin-Solenikov wrote:
> 2015-01-24 20:48 GMT+03:00 Thomas Gleixner :
> > On Thu, 15 Jan 2015, Dmitry Eremin-Solenikov wrote:
> >> static void sa1100_mask_irq(struct irq_data *d)
> >> {
> >> - ICMR &= ~BIT(d->hwirq);
> >> + u32 reg;
> >> + unsigned long flags;
> >> +
> >> + raw_spin_lock_irqsave(, flags);
> >
> > What's the exact point of that lock? And how is it related to the
> > $subject of the patch?
>
> It is needed to protect ICMR register during RMW cycle, isn't it?
The original code has no protection for the RMW either.
And there is a simple reason for this. These functions are guaranteed
to be called with interrupts disabled and this is a uniprocessor
machine and it will never grow SMP support. So interrupts disabled is
serialization enough.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] ARM: sa1100: use ioremapped memory to access SC registers
2015-01-24 22:24 GMT+03:00 Thomas Gleixner :
> On Sat, 24 Jan 2015, Dmitry Eremin-Solenikov wrote:
>
>> 2015-01-24 20:48 GMT+03:00 Thomas Gleixner :
>> > On Thu, 15 Jan 2015, Dmitry Eremin-Solenikov wrote:
>> >> static void sa1100_mask_irq(struct irq_data *d)
>> >> {
>> >> - ICMR &= ~BIT(d->hwirq);
>> >> + u32 reg;
>> >> + unsigned long flags;
>> >> +
>> >> + raw_spin_lock_irqsave(, flags);
>> >
>> > What's the exact point of that lock? And how is it related to the
>> > $subject of the patch?
>>
>> It is needed to protect ICMR register during RMW cycle, isn't it?
>
> The original code has no protection for the RMW either.
>
> And there is a simple reason for this. These functions are guaranteed
> to be called with interrupts disabled and this is a uniprocessor
> machine and it will never grow SMP support. So interrupts disabled is
> serialization enough.
OK, thanks for pointing. I'll update the patchset in a few days.
--
With best wishes
Dmitry
--
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 2/2] posix-timers: Exposes DELAYTIMER_MAX constant used to govern overruns
On Sat, 24 Jan 2015, Daniel Church wrote: > POSIX.1-2001 specification of timer_getoverrun() supports constant > DELAYTIMER_MAX which prevents overflow and caps overrun count. Exposes > delaytimer_max value to userland via /proc/sys/kernel/delaytimer_max such I know that you try to match the posix name, but when looking at the prctl w/o knowing about DELAYTIMER_MAX, it's non intuitive. Something like posixtimer_max_overruns or if you insist on the delaytimer_max part, then let us prepend it with posixtimer_ at least. New prctls require an update of Documentation/sysctl/kernel.txt. Thanks, tglx -- 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/2] posix-timers: Prevents overrun counter overflow
On Sat, 24 Jan 2015, Daniel Church wrote:
> +/*
> + * Updates a timer's overrun count while capping it to delaytimer_max
> + */
> +static void posix_timer_update_overrun_count(struct k_itimer *timer,
> + unsigned int overruns)
> +{
> + const bool newOverrunsAboveMax = overruns >= delaytimer_max;
> + const bool totalOverrunsAboveMax =
> + timer->it_overrun >= 0 &&
> + timer->it_overrun >= delaytimer_max - overruns;
No CaMelCaSe please. And the const here is pointless.
Aside of that in a function like this we really want short local
variables so we can avoid the horrible to read multi line code.
> + if (newOverrunsAboveMax || totalOverrunsAboveMax) {
> + timer->it_overrun = delaytimer_max;
> + } else {
> + timer->it_overrun += overruns;
> + }
> +}
> +
> /* Get clock_realtime */
> static int posix_clock_realtime_get(clockid_t which_clock, struct timespec
> *tp)
> {
> @@ -350,14 +370,17 @@ __initcall(init_posix_timers);
>
> static void schedule_next_timer(struct k_itimer *timr)
> {
> + unsigned int overruns;
> struct hrtimer *timer = >it.real.timer;
>
> if (timr->it.real.interval.tv64 == 0)
> return;
>
> - timr->it_overrun += (unsigned int) hrtimer_forward(timer,
> - timer->base->get_time(),
> - timr->it.real.interval);
> + overruns = (unsigned int) hrtimer_forward(timer,
> + timer->base->get_time(),
> + timr->it.real.interval);
Why not:
posix_timer_forward(struct hrtimer *hrt, struct k_itimer *tmr)
and doing the forward there as well? The now optimization in
common_timer_get is not that important and if we really want to keep
it, we can hand in a pointer and read the time in the function if the
pointer is NULL.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8192u: r8192U_core: Fix compile issue when CONFIG_WIRELESS_EXT is not defined
This patch gets rid of the following error when compiling r8192U_core.c and CONFIG_WIRELESS_EXT is not defined: drivers/staging/rtl8192u/r8192U_core.c: In function ‘rtl8192_usb_probe’: drivers/staging/rtl8192u/r8192U_core.c:4697:5: error: ‘struct net_device’ has no member named ‘wireless_handlers’ dev->wireless_handlers = (struct iw_handler_def *) _wx_handlers_def; ^ Signed-off-by: Murilo Opsfelder Araujo --- drivers/staging/rtl8192u/r8192U_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index e031a25..396a11f 100644 --- a/drivers/staging/rtl8192u/r8192U_core.c +++ b/drivers/staging/rtl8192u/r8192U_core.c @@ -4694,7 +4694,9 @@ static int rtl8192_usb_probe(struct usb_interface *intf, dev->netdev_ops = _netdev_ops; +#ifdef CONFIG_WIRELESS_EXT dev->wireless_handlers = (struct iw_handler_def *) _wx_handlers_def; +#endif dev->type = ARPHRD_ETHER; -- 2.1.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/
[GIT PULL] SCSI fixes for 3.19-rc5
This patch consists of four real fixes and three MAINTAINER updates.
Three of the fixes are obvious (the DIX and atomic allocation are bug on
and warn on fixes and the other is just trivial) and the ipr one is a
bit more involved but is required because without it, the card double
completes aborted commands and causes a kernel oops.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Brian King (1):
ipr: wait for aborted command responses
Colin Ian King (1):
scsi_debug: test always evaluates to false, || should be used instead
Dave Jiang (1):
MAINTAINERS: Remove self as isci maintainer
Ewan D. Milne (1):
scsi: Avoid crashing if device uses DIX but adapter does not support it
Sasha Levin (1):
scsi_debug: use atomic allocation in resp_rsup_opcodes
Tyrel Datwyler (2):
MAINTAINERS: ibmvscsi driver maintainer change
MAINTAINERS: ibmvfc driver maintainer change
and the diffstat:
MAINTAINERS | 5 ++-
drivers/scsi/ipr.c| 92 +++
drivers/scsi/ipr.h| 1 +
drivers/scsi/scsi_debug.c | 4 +--
drivers/scsi/scsi_lib.c | 12 ++-
5 files changed, 108 insertions(+), 6 deletions(-)
With full diff below.
James
---
diff --git a/MAINTAINERS b/MAINTAINERS
index f6dee56..2a97e05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4754,14 +4754,14 @@ S: Supported
F: drivers/net/ethernet/ibm/ibmveth.*
IBM Power Virtual SCSI Device Drivers
-M: Nathan Fontenot
+M: Tyrel Datwyler
L: linux-s...@vger.kernel.org
S: Supported
F: drivers/scsi/ibmvscsi/ibmvscsi*
F: drivers/scsi/ibmvscsi/viosrp.h
IBM Power Virtual FC Device Drivers
-M: Brian King
+M: Tyrel Datwyler
L: linux-s...@vger.kernel.org
S: Supported
F: drivers/scsi/ibmvscsi/ibmvfc*
@@ -4951,7 +4951,6 @@ K:\b(ABS|SYN)_MT_
INTEL C600 SERIES SAS CONTROLLER DRIVER
M: Intel SCU Linux support
M: Artur Paszkiewicz
-M: Dave Jiang
L: linux-s...@vger.kernel.org
T: git git://git.code.sf.net/p/intel-sas/isci
S: Supported
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index df4e27c..9219953 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -683,6 +683,7 @@ static void ipr_init_ipr_cmnd(struct ipr_cmnd *ipr_cmd,
ipr_reinit_ipr_cmnd(ipr_cmd);
ipr_cmd->u.scratch = 0;
ipr_cmd->sibling = NULL;
+ ipr_cmd->eh_comp = NULL;
ipr_cmd->fast_done = fast_done;
init_timer(_cmd->timer);
}
@@ -848,6 +849,8 @@ static void ipr_scsi_eh_done(struct ipr_cmnd *ipr_cmd)
scsi_dma_unmap(ipr_cmd->scsi_cmd);
scsi_cmd->scsi_done(scsi_cmd);
+ if (ipr_cmd->eh_comp)
+ complete(ipr_cmd->eh_comp);
list_add_tail(_cmd->queue, _cmd->hrrq->hrrq_free_q);
}
@@ -4811,6 +4814,84 @@ static int ipr_slave_alloc(struct scsi_device *sdev)
return rc;
}
+/**
+ * ipr_match_lun - Match function for specified LUN
+ * @ipr_cmd: ipr command struct
+ * @device:device to match (sdev)
+ *
+ * Returns:
+ * 1 if command matches sdev / 0 if command does not match sdev
+ **/
+static int ipr_match_lun(struct ipr_cmnd *ipr_cmd, void *device)
+{
+ if (ipr_cmd->scsi_cmd && ipr_cmd->scsi_cmd->device == device)
+ return 1;
+ return 0;
+}
+
+/**
+ * ipr_wait_for_ops - Wait for matching commands to complete
+ * @ipr_cmd: ipr command struct
+ * @device:device to match (sdev)
+ * @match: match function to use
+ *
+ * Returns:
+ * SUCCESS / FAILED
+ **/
+static int ipr_wait_for_ops(struct ipr_ioa_cfg *ioa_cfg, void *device,
+ int (*match)(struct ipr_cmnd *, void *))
+{
+ struct ipr_cmnd *ipr_cmd;
+ int wait;
+ unsigned long flags;
+ struct ipr_hrr_queue *hrrq;
+ signed long timeout = IPR_ABORT_TASK_TIMEOUT;
+ DECLARE_COMPLETION_ONSTACK(comp);
+
+ ENTER;
+ do {
+ wait = 0;
+
+ for_each_hrrq(hrrq, ioa_cfg) {
+ spin_lock_irqsave(hrrq->lock, flags);
+ list_for_each_entry(ipr_cmd, >hrrq_pending_q,
queue) {
+ if (match(ipr_cmd, device)) {
+ ipr_cmd->eh_comp =
+ wait++;
+ }
+ }
+ spin_unlock_irqrestore(hrrq->lock, flags);
+ }
+
+ if (wait) {
+ timeout = wait_for_completion_timeout(, timeout);
+
+ if (!timeout) {
+ wait = 0;
+
+ for_each_hrrq(hrrq, ioa_cfg) {
+ spin_lock_irqsave(hrrq->lock, flags);
+ list_for_each_entry(ipr_cmd,
Re: [PATCH v2 1/2] posix-timers: Prevents overrun counter overflow
On Sat, Jan 24, 2015 at 12:48:56PM -0500, Daniel Church wrote:
> +/*
> + * Updates a timer's overrun count while capping it to delaytimer_max
> + */
> +static void posix_timer_update_overrun_count(struct k_itimer *timer,
> + unsigned int overruns)
> +{
> + const bool newOverrunsAboveMax = overruns >= delaytimer_max;
> + const bool totalOverrunsAboveMax =
> + timer->it_overrun >= 0 &&
> + timer->it_overrun >= delaytimer_max - overruns;
Lower camel case is not a part of the kernel coding style.
Also, the 'const' keyword is useless in this context.
> +
> + if (newOverrunsAboveMax || totalOverrunsAboveMax) {
> + timer->it_overrun = delaytimer_max;
> + } else {
> + timer->it_overrun += overruns;
> + }
> +}
> +
> /* Get clock_realtime */
> static int posix_clock_realtime_get(clockid_t which_clock, struct timespec
> *tp)
> {
> @@ -1122,3 +1150,4 @@ long clock_nanosleep_restart(struct restart_block
> *restart_block)
>
> return kc->nsleep_restart(restart_block);
> }
> +
This stray newline and the camel case are the kinds of things that
checkpatch.pl will catch.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] perf: Make perf aware of tracefs
From: "Steven Rostedt (Red Hat)"
As tracefs may be mounted instead of debugfs to get to the event directories,
have perf know about tracefs, and use that file system over debugfs if it
is present.
Signed-off-by: Steven Rostedt
---
tools/perf/tests/open-syscall-all-cpus.c | 7 +++-
tools/perf/tests/open-syscall.c | 7 +++-
tools/perf/tests/parse-events.c | 13 +--
tools/perf/util/cache.h | 1 +
tools/perf/util/evlist.c | 7 ++--
tools/perf/util/parse-events.c | 15 +---
tools/perf/util/parse-events.h | 2 +-
tools/perf/util/probe-event.c| 24 -
tools/perf/util/util.c | 60 ++--
tools/perf/util/util.h | 1 +
10 files changed, 106 insertions(+), 31 deletions(-)
diff --git a/tools/perf/tests/open-syscall-all-cpus.c
b/tools/perf/tests/open-syscall-all-cpus.c
index 8fa82d1700c7..21969e99ea46 100644
--- a/tools/perf/tests/open-syscall-all-cpus.c
+++ b/tools/perf/tests/open-syscall-all-cpus.c
@@ -29,7 +29,12 @@ int test__open_syscall_event_on_all_cpus(void)
evsel = perf_evsel__newtp("syscalls", "sys_enter_open");
if (evsel == NULL) {
- pr_debug("is debugfs mounted on /sys/kernel/debug?\n");
+ if (tracefs_configured())
+ pr_debug("is tracefs mounted on /sys/kernel/debug?\n");
+ else if (debugfs_configured())
+ pr_debug("is debugfs mounted on /sys/kernel/debug?\n");
+ else
+ pr_debug("Neither tracefs or debugfs is enabled in this
kernel\n");
goto out_thread_map_delete;
}
diff --git a/tools/perf/tests/open-syscall.c b/tools/perf/tests/open-syscall.c
index a33b2daae40f..4250e40234d2 100644
--- a/tools/perf/tests/open-syscall.c
+++ b/tools/perf/tests/open-syscall.c
@@ -18,7 +18,12 @@ int test__open_syscall_event(void)
evsel = perf_evsel__newtp("syscalls", "sys_enter_open");
if (evsel == NULL) {
- pr_debug("is debugfs mounted on /sys/kernel/debug?\n");
+ if (tracefs_configured())
+ pr_debug("is tracefs mounted on /sys/kernel/debug?\n");
+ else if (debugfs_configured())
+ pr_debug("is debugfs mounted on /sys/kernel/debug?\n");
+ else
+ pr_debug("Neither tracefs or debugfs is enabled in this
kernel\n");
goto out_thread_map_delete;
}
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 7f2f51f93619..ce474fba5a92 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -3,6 +3,7 @@
#include "evsel.h"
#include "evlist.h"
#include
+#include
#include
#include "tests.h"
#include "debug.h"
@@ -1149,11 +1150,19 @@ static int count_tracepoints(void)
{
char events_path[PATH_MAX];
struct dirent *events_ent;
+ const char *mountpoint;
DIR *events_dir;
int cnt = 0;
- scnprintf(events_path, PATH_MAX, "%s/tracing/events",
- debugfs_find_mountpoint());
+ mountpoint = tracefs_find_mountpoint();
+ if (mountpoint) {
+ scnprintf(events_path, PATH_MAX, "%s/events",
+ mountpoint);
+ } else {
+ mountpoint = debugfs_find_mountpoint();
+ scnprintf(events_path, PATH_MAX, "%s/tracing/events",
+ mountpoint);
+ }
events_dir = opendir(events_path);
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 5cf9e1b5989d..99f7f8bd5fcd 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -17,6 +17,7 @@
#define EXEC_PATH_ENVIRONMENT "PERF_EXEC_PATH"
#define DEFAULT_PERF_DIR_ENVIRONMENT ".perf"
#define PERF_DEBUGFS_ENVIRONMENT "PERF_DEBUGFS_DIR"
+#define PERF_TRACEFS_ENVIRONMENT "PERF_TRACEFS_DIR"
typedef int (*config_fn_t)(const char *, const char *, void *);
extern int perf_default_config(const char *, const char *, void *);
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index cbab1fb77b1d..cbe7ac93bedb 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1444,10 +1444,11 @@ int perf_evlist__strerror_tp(struct perf_evlist *evlist
__maybe_unused,
switch (err) {
case ENOENT:
scnprintf(buf, size, "%s",
- "Error:\tUnable to find debugfs\n"
+ "Error:\tUnable to find tracefs or debugfs\n"
"Hint:\tWas your kernel was compiled with debugfs
support?\n"
- "Hint:\tIs the debugfs filesystem mounted?\n"
- "Hint:\tTry 'sudo mount -t debugfs nodev
/sys/kernel/debug'");
+ "Hint:\tIs the debugfs or tracefs filesystem
mounted?\n"
+
[PATCH 2/5] tools lib api fs: Add tracefs mount helper functions
From: "Steven Rostedt (Red Hat)"
Since tracefs will now hold the event directory for perf, and
even though by default, debugfs still mounts tracefs on the
debugfs/tracing directory, the system admin may now choose to not
mount debugfs and instead just mount tracefs instead.
Having tracefs helper functions will facilitate having perf look
for tracefs first, and then try debugfs as a fallback.
Signed-off-by: Steven Rostedt
---
tools/lib/api/Makefile | 2 ++
tools/lib/api/fs/tracefs.c | 71 ++
tools/lib/api/fs/tracefs.h | 29 +++
3 files changed, 102 insertions(+)
create mode 100644 tools/lib/api/fs/tracefs.c
create mode 100644 tools/lib/api/fs/tracefs.h
diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
index 22b2f15d7255..212aa4fd65a0 100644
--- a/tools/lib/api/Makefile
+++ b/tools/lib/api/Makefile
@@ -9,12 +9,14 @@ LIB_H=
LIB_OBJS=
LIB_H += fs/debugfs.h
+LIB_H += fs/tracefs.h
LIB_H += fs/findfs.h
LIB_H += fs/fs.h
# See comment below about piggybacking...
LIB_H += fd/array.h
LIB_OBJS += $(OUTPUT)fs/debugfs.o
+LIB_OBJS += $(OUTPUT)fs/tracefs.o
LIB_OBJS += $(OUTPUT)fs/findfs.o
LIB_OBJS += $(OUTPUT)fs/fs.o
# XXX piggybacking here, need to introduce libapikfd, or rename this
diff --git a/tools/lib/api/fs/tracefs.c b/tools/lib/api/fs/tracefs.c
new file mode 100644
index ..bdaf54142c5d
--- /dev/null
+++ b/tools/lib/api/fs/tracefs.c
@@ -0,0 +1,71 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tracefs.h"
+#include "findfs.h"
+
+#ifndef TRACEFS_DEFAULT_PATH
+#define TRACEFS_DEFAULT_PATH "/sys/kernel/tracing"
+#endif
+
+char tracefs_mountpoint[PATH_MAX + 1] = TRACEFS_DEFAULT_PATH;
+
+static const char * const tracefs_known_mountpoints[] = {
+ TRACEFS_DEFAULT_PATH,
+ "/sys/kernel/debug/tracing",
+ "/tracing",
+ "/trace",
+ 0,
+};
+
+static bool tracefs_found;
+
+/* find the path to the mounted tracefs */
+const char *tracefs_find_mountpoint(void)
+{
+ if (tracefs_found)
+ return (const char *)tracefs_mountpoint;
+
+ return find_mountpoint("tracefs", (long) TRACEFS_MAGIC,
+ tracefs_mountpoint, PATH_MAX + 1,
+ tracefs_known_mountpoints);
+}
+
+/* verify that a mountpoint is actually a tracefs instance */
+
+int tracefs_valid_mountpoint(const char *tracefs)
+{
+ return valid_mountpoint(tracefs, (long) TRACEFS_MAGIC);
+}
+
+/* mount the tracefs somewhere if it's not mounted */
+char *tracefs_mount(const char *mountpoint)
+{
+ /* see if it's already mounted */
+ if (tracefs_find_mountpoint())
+ goto out;
+
+ /* if not mounted and no argument */
+ if (mountpoint == NULL) {
+ /* see if environment variable set */
+ mountpoint = getenv(PERF_TRACEFS_ENVIRONMENT);
+ /* if no environment variable, use default */
+ if (mountpoint == NULL)
+ mountpoint = TRACEFS_DEFAULT_PATH;
+ }
+
+ if (mount(NULL, mountpoint, "tracefs", 0, NULL) < 0)
+ return NULL;
+
+ /* save the mountpoint */
+ tracefs_found = true;
+ strncpy(tracefs_mountpoint, mountpoint, sizeof(tracefs_mountpoint));
+out:
+ return tracefs_mountpoint;
+}
diff --git a/tools/lib/api/fs/tracefs.h b/tools/lib/api/fs/tracefs.h
new file mode 100644
index ..576206500e15
--- /dev/null
+++ b/tools/lib/api/fs/tracefs.h
@@ -0,0 +1,29 @@
+#ifndef __API_TRACEFS_H__
+#define __API_TRACEFS_H__
+
+#define _STR(x) #x
+#define STR(x) _STR(x)
+
+/*
+ * On most systems would have given us this, but not on some
systems
+ * (e.g. GNU/Hurd).
+ */
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
+#ifndef TRACEFS_MAGIC
+#define TRACEFS_MAGIC 0x74726163
+#endif
+
+#ifndef PERF_TRACEFS_ENVIRONMENT
+#define PERF_TRACEFS_ENVIRONMENT "PERF_TRACEFS_DIR"
+#endif
+
+const char *tracefs_find_mountpoint(void);
+int tracefs_valid_mountpoint(const char *debugfs);
+char *tracefs_mount(const char *mountpoint);
+
+extern char tracefs_mountpoint[];
+
+#endif /* __API_DEBUGFS_H__ */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] perf: Have perf become tracefs aware
As I'm trying to move the tracing directory from debugfs, perf needs to
be aware of this as system admins will now be able to mount the tracing
directory without needing to mount debugfs. This patch series addresses
this and makes perf aware of tracefs.
I based this series on a recent tip branch: perf/core.
You can also get this series from my repo as stated below.
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/core
Head SHA1: 1a334ac9034ceefc1c87e4cd95c6e103ba29df44
Steven Rostedt (Red Hat) (5):
tools lib fs: Add helper to find mounted file systems
tools lib api fs: Add tracefs mount helper functions
tools lib api fs: Add DEBUGFS_DEFAULT_PATH macro
tools lib api fs: Add {tracefs,debugfs}_configured() functions
perf: Make perf aware of tracefs
tools/lib/api/Makefile | 4 ++
tools/lib/api/fs/debugfs.c | 68 ++
tools/lib/api/fs/debugfs.h | 1 +
tools/lib/api/fs/findfs.c| 63
tools/lib/api/fs/findfs.h| 10
tools/lib/api/fs/tracefs.c | 84
tools/lib/api/fs/tracefs.h | 30
tools/perf/tests/open-syscall-all-cpus.c | 7 ++-
tools/perf/tests/open-syscall.c | 7 ++-
tools/perf/tests/parse-events.c | 13 -
tools/perf/util/cache.h | 1 +
tools/perf/util/evlist.c | 7 +--
tools/perf/util/parse-events.c | 15 --
tools/perf/util/parse-events.h | 2 +-
tools/perf/util/probe-event.c| 24 ++---
tools/perf/util/util.c | 60 ++-
tools/perf/util/util.h | 1 +
17 files changed, 323 insertions(+), 74 deletions(-)
--
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/5] tools lib fs: Add helper to find mounted file systems
From: "Steven Rostedt (Red Hat)"
In preparation for adding tracefs for perf to use, create a findfs
helper utility that find_debugfs uses instead of hard coding the search
in the code. This will allow for a find_tracefs to be used as well.
Signed-off-by: Steven Rostedt
---
tools/lib/api/Makefile | 2 ++
tools/lib/api/fs/debugfs.c | 45 -
tools/lib/api/fs/findfs.c | 63 ++
tools/lib/api/fs/findfs.h | 10
4 files changed, 80 insertions(+), 40 deletions(-)
create mode 100644 tools/lib/api/fs/findfs.c
create mode 100644 tools/lib/api/fs/findfs.h
diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
index 36c08b1f4afb..22b2f15d7255 100644
--- a/tools/lib/api/Makefile
+++ b/tools/lib/api/Makefile
@@ -9,11 +9,13 @@ LIB_H=
LIB_OBJS=
LIB_H += fs/debugfs.h
+LIB_H += fs/findfs.h
LIB_H += fs/fs.h
# See comment below about piggybacking...
LIB_H += fd/array.h
LIB_OBJS += $(OUTPUT)fs/debugfs.o
+LIB_OBJS += $(OUTPUT)fs/findfs.o
LIB_OBJS += $(OUTPUT)fs/fs.o
# XXX piggybacking here, need to introduce libapikfd, or rename this
# to plain libapik.a and make it have it all api goodies
diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
index a74fba6d7743..76eb92c0623f 100644
--- a/tools/lib/api/fs/debugfs.c
+++ b/tools/lib/api/fs/debugfs.c
@@ -8,6 +8,7 @@
#include
#include "debugfs.h"
+#include "findfs.h"
char debugfs_mountpoint[PATH_MAX + 1] = "/sys/kernel/debug";
@@ -22,55 +23,19 @@ static bool debugfs_found;
/* find the path to the mounted debugfs */
const char *debugfs_find_mountpoint(void)
{
- const char * const *ptr;
- char type[100];
- FILE *fp;
-
if (debugfs_found)
return (const char *)debugfs_mountpoint;
- ptr = debugfs_known_mountpoints;
- while (*ptr) {
- if (debugfs_valid_mountpoint(*ptr) == 0) {
- debugfs_found = true;
- strcpy(debugfs_mountpoint, *ptr);
- return debugfs_mountpoint;
- }
- ptr++;
- }
-
- /* give up and parse /proc/mounts */
- fp = fopen("/proc/mounts", "r");
- if (fp == NULL)
- return NULL;
-
- while (fscanf(fp, "%*s %" STR(PATH_MAX) "s %99s %*s %*d %*d\n",
- debugfs_mountpoint, type) == 2) {
- if (strcmp(type, "debugfs") == 0)
- break;
- }
- fclose(fp);
-
- if (strcmp(type, "debugfs") != 0)
- return NULL;
-
- debugfs_found = true;
-
- return debugfs_mountpoint;
+ return find_mountpoint("debugfs", (long) DEBUGFS_MAGIC,
+ debugfs_mountpoint, PATH_MAX + 1,
+ debugfs_known_mountpoints);
}
/* verify that a mountpoint is actually a debugfs instance */
int debugfs_valid_mountpoint(const char *debugfs)
{
- struct statfs st_fs;
-
- if (statfs(debugfs, _fs) < 0)
- return -ENOENT;
- else if (st_fs.f_type != (long) DEBUGFS_MAGIC)
- return -ENOENT;
-
- return 0;
+ return valid_mountpoint(debugfs, (long) DEBUGFS_MAGIC);
}
/* mount the debugfs somewhere if it's not mounted */
diff --git a/tools/lib/api/fs/findfs.c b/tools/lib/api/fs/findfs.c
new file mode 100644
index ..fc62c84cc2e9
--- /dev/null
+++ b/tools/lib/api/fs/findfs.c
@@ -0,0 +1,63 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "findfs.h"
+
+/* verify that a mountpoint is actually the type we want */
+
+int valid_mountpoint(const char *mount, long magic)
+{
+ struct statfs st_fs;
+
+ if (statfs(mount, _fs) < 0)
+ return -ENOENT;
+ else if (st_fs.f_type != magic)
+ return -ENOENT;
+
+ return 0;
+}
+
+/* find the path to a mounted file system */
+const char *find_mountpoint(const char *fstype, long magic,
+ char *mountpoint, int len,
+ const char * const *known_mountpoints)
+{
+ const char * const *ptr;
+ char format[128];
+ char type[100];
+ FILE *fp;
+
+ if (known_mountpoints) {
+ ptr = known_mountpoints;
+ while (*ptr) {
+ if (valid_mountpoint(*ptr, magic) == 0) {
+ strncpy(mountpoint, *ptr, len - 1);
+ mountpoint[len-1] = 0;
+ return mountpoint;
+ }
+ ptr++;
+ }
+ }
+
+ /* give up and parse /proc/mounts */
+ fp = fopen("/proc/mounts", "r");
+ if (fp == NULL)
+ return NULL;
+
+ snprintf(format, 128, "%%*s %%%ds %%99s %%*s %%*d %%*d\n", len);
+
+ while (fscanf(fp, format, mountpoint, type) == 2) {
+ if (strcmp(type, fstype) == 0)
+
[PATCH 4/5] tools lib api fs: Add {tracefs,debugfs}_configured() functions
From: "Steven Rostedt (Red Hat)"
Add tracefs_configured() to return true if tracefs is configured in the
kernel (/sys/kernel/tracing exists), and debugfs_configured() if debugfs
is configured in the kernel (/sys/kernel/debug exists).
Signed-off-by: Steven Rostedt
---
tools/lib/api/fs/debugfs.c | 13 +
tools/lib/api/fs/debugfs.h | 1 +
tools/lib/api/fs/tracefs.c | 13 +
tools/lib/api/fs/tracefs.h | 1 +
4 files changed, 28 insertions(+)
diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
index 1637e5b6a5d5..a2d8e59f042b 100644
--- a/tools/lib/api/fs/debugfs.c
+++ b/tools/lib/api/fs/debugfs.c
@@ -2,8 +2,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include
#include
@@ -24,6 +27,16 @@ static const char * const debugfs_known_mountpoints[] = {
static bool debugfs_found;
+bool debugfs_configured(void)
+{
+ struct stat st;
+
+ if (stat(DEBUGFS_DEFAULT_PATH, ) < 0)
+ return false;
+
+ return true;
+}
+
/* find the path to the mounted debugfs */
const char *debugfs_find_mountpoint(void)
{
diff --git a/tools/lib/api/fs/debugfs.h b/tools/lib/api/fs/debugfs.h
index f19d3df9609d..a8a385008db3 100644
--- a/tools/lib/api/fs/debugfs.h
+++ b/tools/lib/api/fs/debugfs.h
@@ -20,6 +20,7 @@
#define PERF_DEBUGFS_ENVIRONMENT "PERF_DEBUGFS_DIR"
#endif
+bool debugfs_configured(void);
const char *debugfs_find_mountpoint(void);
int debugfs_valid_mountpoint(const char *debugfs);
char *debugfs_mount(const char *mountpoint);
diff --git a/tools/lib/api/fs/tracefs.c b/tools/lib/api/fs/tracefs.c
index bdaf54142c5d..43cb0b24a999 100644
--- a/tools/lib/api/fs/tracefs.c
+++ b/tools/lib/api/fs/tracefs.c
@@ -2,8 +2,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include
#include
@@ -26,6 +29,16 @@ static const char * const tracefs_known_mountpoints[] = {
static bool tracefs_found;
+bool tracefs_configured(void)
+{
+ struct stat st;
+
+ if (stat(TRACEFS_DEFAULT_PATH, ) < 0)
+ return false;
+
+ return true;
+}
+
/* find the path to the mounted tracefs */
const char *tracefs_find_mountpoint(void)
{
diff --git a/tools/lib/api/fs/tracefs.h b/tools/lib/api/fs/tracefs.h
index 576206500e15..a25a003a9ee6 100644
--- a/tools/lib/api/fs/tracefs.h
+++ b/tools/lib/api/fs/tracefs.h
@@ -20,6 +20,7 @@
#define PERF_TRACEFS_ENVIRONMENT "PERF_TRACEFS_DIR"
#endif
+bool tracefs_configured(void);
const char *tracefs_find_mountpoint(void);
int tracefs_valid_mountpoint(const char *debugfs);
char *tracefs_mount(const char *mountpoint);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] tools lib api fs: Add DEBUGFS_DEFAULT_PATH macro
From: "Steven Rostedt (Red Hat)"
Instead of hard coding "/sys/kernel/debug" everywhere, create
a macro to hold where the default path exists.
Signed-off-by: Steven Rostedt
---
tools/lib/api/fs/debugfs.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
index 76eb92c0623f..1637e5b6a5d5 100644
--- a/tools/lib/api/fs/debugfs.c
+++ b/tools/lib/api/fs/debugfs.c
@@ -10,10 +10,14 @@
#include "debugfs.h"
#include "findfs.h"
-char debugfs_mountpoint[PATH_MAX + 1] = "/sys/kernel/debug";
+#ifndef DEBUGFS_DEFAULT_PATH
+#define DEBUGFS_DEFAULT_PATH "/sys/kernel/debug"
+#endif
+
+char debugfs_mountpoint[PATH_MAX + 1] = DEBUGFS_DEFAULT_PATH;
static const char * const debugfs_known_mountpoints[] = {
- "/sys/kernel/debug",
+ DEBUGFS_DEFAULT_PATH,
"/debug",
0,
};
@@ -51,7 +55,7 @@ char *debugfs_mount(const char *mountpoint)
mountpoint = getenv(PERF_DEBUGFS_ENVIRONMENT);
/* if no environment variable, use default */
if (mountpoint == NULL)
- mountpoint = "/sys/kernel/debug";
+ mountpoint = DEBUGFS_DEFAULT_PATH;
}
if (mount(NULL, mountpoint, "debugfs", 0, NULL) < 0)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/boot/video: move video_segment variable to video.c
It's only user of the video_segment variable, so move it to video.c
Signed-off-by: Alexander Kuleshov
---
arch/x86/boot/video-mode.c | 4 +---
arch/x86/boot/video.c | 2 ++
arch/x86/boot/video.h | 1 -
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/boot/video-mode.c b/arch/x86/boot/video-mode.c
index 748e8d0..aa8a96b 100644
--- a/arch/x86/boot/video-mode.c
+++ b/arch/x86/boot/video-mode.c
@@ -22,10 +22,8 @@
/*
* Common variables
*/
-int adapter; /* 0=CGA/MDA/HGC, 1=EGA, 2=VGA+ */
-u16 video_segment;
+int adapter; /* 0=CGA/MDA/HGC, 1=EGA, 2=VGA+ */
int force_x, force_y; /* Don't query the BIOS for cols/rows */
-
int do_restore;/* Screen contents changed during mode flip */
int graphic_mode; /* Graphic mode with linear frame buffer */
diff --git a/arch/x86/boot/video.c b/arch/x86/boot/video.c
index 43eda28..05111bb 100644
--- a/arch/x86/boot/video.c
+++ b/arch/x86/boot/video.c
@@ -17,6 +17,8 @@
#include "video.h"
#include "vesa.h"
+static u16 video_segment;
+
static void store_cursor_position(void)
{
struct biosregs ireg, oreg;
diff --git a/arch/x86/boot/video.h b/arch/x86/boot/video.h
index 0bb2549..b54e032 100644
--- a/arch/x86/boot/video.h
+++ b/arch/x86/boot/video.h
@@ -91,7 +91,6 @@ int mode_defined(u16 mode); /* video.c */
#define ADAPTER_VGA2
extern int adapter;
-extern u16 video_segment;
extern int force_x, force_y; /* Don't query the BIOS for cols/rows */
extern int do_restore; /* Restore screen contents */
extern int graphic_mode; /* Graphics mode with linear frame buffer */
--
2.3.0.rc1.275.g028c360
--
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 V4 01/14] sh: Eliminate unused irq_reg_{readl,writel} accessors
On Mon, 19 Jan 2015, Geert Uytterhoeven wrote: > Will you still do so, or shall I forward the patch to Andrew Morton? akpm please. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] ARM: sa1100: use ioremapped memory to access SC registers
2015-01-24 20:48 GMT+03:00 Thomas Gleixner :
> On Thu, 15 Jan 2015, Dmitry Eremin-Solenikov wrote:
>> static void sa1100_mask_irq(struct irq_data *d)
>> {
>> - ICMR &= ~BIT(d->hwirq);
>> + u32 reg;
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(, flags);
>
> What's the exact point of that lock? And how is it related to the
> $subject of the patch?
It is needed to protect ICMR register during RMW cycle, isn't it?
I might have missed locks around ack/mask/unmask calls from irq
core. If so, I can happily drop this spinlock.
--
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] posix-timers: Prevents overrun counter overflow
If a timer overruns too many times before a call to timer_getoverrun the
overrun count can overflow and go negative. Adds delaytimer_max value
to cap overrun count and prevent overflow.
Signed-off-by: Daniel Church
---
include/linux/posix-timers.h | 3 +++
kernel/time/posix-timers.c | 45
2 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index 907f3fd..dc8a1e7 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -138,4 +138,7 @@ long clock_nanosleep_restart(struct restart_block
*restart_block);
void update_rlimit_cpu(struct task_struct *task, unsigned long rlim_new);
+#define DELAYTIMER_MAX_DEFAULT 100
+extern int delaytimer_max;
+
#endif
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 31ea01f..010344e 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -68,6 +68,8 @@ static struct kmem_cache *posix_timers_cache;
static DEFINE_HASHTABLE(posix_timers_hashtable, 9);
static DEFINE_SPINLOCK(hash_lock);
+int delaytimer_max = DELAYTIMER_MAX_DEFAULT;
+
/*
* we assume that the new SIGEV_THREAD_ID shares no bits with the other
* SIGEV values. Here we put out an error if this assumption fails.
@@ -202,6 +204,24 @@ static inline void unlock_timer(struct k_itimer *timr,
unsigned long flags)
spin_unlock_irqrestore(>it_lock, flags);
}
+/*
+ * Updates a timer's overrun count while capping it to delaytimer_max
+ */
+static void posix_timer_update_overrun_count(struct k_itimer *timer,
+unsigned int overruns)
+{
+ const bool newOverrunsAboveMax = overruns >= delaytimer_max;
+ const bool totalOverrunsAboveMax =
+ timer->it_overrun >= 0 &&
+ timer->it_overrun >= delaytimer_max - overruns;
+
+ if (newOverrunsAboveMax || totalOverrunsAboveMax) {
+ timer->it_overrun = delaytimer_max;
+ } else {
+ timer->it_overrun += overruns;
+ }
+}
+
/* Get clock_realtime */
static int posix_clock_realtime_get(clockid_t which_clock, struct timespec *tp)
{
@@ -350,14 +370,17 @@ __initcall(init_posix_timers);
static void schedule_next_timer(struct k_itimer *timr)
{
+ unsigned int overruns;
struct hrtimer *timer = >it.real.timer;
if (timr->it.real.interval.tv64 == 0)
return;
- timr->it_overrun += (unsigned int) hrtimer_forward(timer,
- timer->base->get_time(),
- timr->it.real.interval);
+ overruns = (unsigned int) hrtimer_forward(timer,
+ timer->base->get_time(),
+ timr->it.real.interval);
+
+ posix_timer_update_overrun_count(timr, overruns);
timr->it_overrun_last = timr->it_overrun;
timr->it_overrun = -1;
@@ -436,6 +459,7 @@ static enum hrtimer_restart posix_timer_fn(struct hrtimer
*timer)
{
struct k_itimer *timr;
unsigned long flags;
+ unsigned int overruns;
int si_private = 0;
enum hrtimer_restart ret = HRTIMER_NORESTART;
@@ -484,9 +508,10 @@ static enum hrtimer_restart posix_timer_fn(struct hrtimer
*timer)
now = ktime_add(now, kj);
}
#endif
- timr->it_overrun += (unsigned int)
- hrtimer_forward(timer, now,
- timr->it.real.interval);
+ overruns = (unsigned int) hrtimer_forward(timer, now,
+
timr->it.real.interval);
+ posix_timer_update_overrun_count(timr, overruns);
+
ret = HRTIMER_RESTART;
++timr->it_requeue_pending;
}
@@ -729,6 +754,7 @@ static void
common_timer_get(struct k_itimer *timr, struct itimerspec *cur_setting)
{
ktime_t now, remaining, iv;
+ unsigned int overruns;
struct hrtimer *timer = >it.real.timer;
memset(cur_setting, 0, sizeof(struct itimerspec));
@@ -750,8 +776,10 @@ common_timer_get(struct k_itimer *timr, struct itimerspec
*cur_setting)
* expiry is > now.
*/
if (iv.tv64 && (timr->it_requeue_pending & REQUEUE_PENDING ||
- (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE))
- timr->it_overrun += (unsigned int) hrtimer_forward(timer, now,
iv);
+ (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE)) {
+ overruns = (unsigned int) hrtimer_forward(timer, now, iv);
+ posix_timer_update_overrun_count(timr, overruns);
+ }
remaining = ktime_sub(hrtimer_get_expires(timer), now);
/* Return 0 only,
[PATCH v2 0/2] posix-timers: Prevents overrun counter overflow, adds DELAYTIMER_MAX
If a timer overruns too many times before a call to timer_getoverrun the overrun count can overflow and go negative. POSIX.1-2001 specification of timer_getoverrun() supports constant DELAYTIMER_MAX which prevents overflow and caps overrun count. Adds delaytimer_max value, caps overrun count, and exposes value to userland via /proc/sys/kernel/delaytimer_max. Resolves https://bugzilla.kernel.org/show_bug.cgi?id=12665 - POSIX timers API does not support DELAYTIMER_MAX v2: Consolidates overflow logic into helper function as suggested by Thomas Gleixner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] posix-timers: Exposes DELAYTIMER_MAX constant used to govern overruns
POSIX.1-2001 specification of timer_getoverrun() supports constant
DELAYTIMER_MAX which prevents overflow and caps overrun count. Exposes
delaytimer_max value to userland via /proc/sys/kernel/delaytimer_max such
that GLIBC can support DELAYTIMER_MAX constant.
Signed-off-by: Daniel Church
---
kernel/sysctl.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 137c7f6..b283808 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -63,6 +63,7 @@
#include
#include
#include
+#include
#include
#include
@@ -761,6 +762,13 @@ static struct ctl_table kern_table[] = {
},
#endif
{
+ .procname = "delaytimer_max",
+ .data = _max,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
.procname = "pid_max",
.data = _max,
.maxlen = sizeof (int),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 26/32] slub: use %*pb[l] to print bitmaps including cpumasks and nodemasks
Acked-by: Christoph Lameter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] ARM: sa1100: use ioremapped memory to access SC registers
On Thu, 15 Jan 2015, Dmitry Eremin-Solenikov wrote:
> static void sa1100_mask_irq(struct irq_data *d)
> {
> - ICMR &= ~BIT(d->hwirq);
> + u32 reg;
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(, flags);
What's the exact point of that lock? And how is it related to the
$subject of the patch?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] fbcon: expose cursor blink interval via sysfs
The fbcon cursor, when set to blink, is hardcoded to toggle display state
five times per second. Expose this setting via
/sys/class/graphics/fbcon/cursor_blink_ms
Values written to the interface set the approximate time interval in
milliseconds between cursor toggles, from 1 to 32767. Since the interval
is stored internally as a number of jiffies, the millisecond value read
from the interface may not exactly match the entered value.
An outstanding blink timer is reset after a new value is entered.
If the cursor blink is disabled, either via the 'cursor_blink' boolean
setting or some other mechanism, the 'cursor_blink_ms' setting may still
be modified. The new value will be used if the blink is reactivated.
Tested with intelfb.
Signed-off-by: Scot Doyle
---
v2: Use kstrtos16() instead of kstrtoul() and min_t(). Thanks Geert!
drivers/video/console/fbcon.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 7a2030b..7b6815d 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3495,11 +3495,84 @@ err:
return count;
}
+static ssize_t show_cursor_blink_ms(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info;
+ struct fbcon_ops *ops;
+ int idx, ms = -1;
+
+ if (fbcon_has_exited)
+ return 0;
+
+ console_lock();
+ idx = con2fb_map[fg_console];
+
+ if (idx == -1 || registered_fb[idx] == NULL)
+ goto err;
+
+ info = registered_fb[idx];
+ ops = info->fbcon_par;
+
+ if (!ops)
+ goto err;
+
+ ms = jiffies_to_msecs(ops->blink_jiffies);
+
+err:
+ console_unlock();
+ return snprintf(buf, PAGE_SIZE, "%d\n", ms);
+}
+
+static ssize_t store_cursor_blink_ms(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct fb_info *info;
+ struct fbcon_ops *ops;
+ int idx;
+ short ms;
+
+ if (fbcon_has_exited)
+ return count;
+
+ console_lock();
+ idx = con2fb_map[fg_console];
+
+ if (idx == -1 || registered_fb[idx] == NULL)
+ goto err;
+
+ info = registered_fb[idx];
+
+ if (!info->fbcon_par)
+ goto err;
+
+ ops = info->fbcon_par;
+
+ if (!ops)
+ goto err;
+
+ if (!kstrtos16(buf, 0, )) {
+ ops->blink_jiffies = max_t(int, msecs_to_jiffies(ms), 1);
+ if (info->queue.func == fb_flashcursor &&
+ ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
+ fbcon_del_cursor_timer(info);
+ fbcon_add_cursor_timer(info);
+ }
+ }
+
+err:
+ console_unlock();
+ return count;
+}
+
static struct device_attribute device_attrs[] = {
__ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
__ATTR(rotate_all, S_IWUSR, NULL, store_rotate_all),
__ATTR(cursor_blink, S_IRUGO|S_IWUSR, show_cursor_blink,
store_cursor_blink),
+ __ATTR(cursor_blink_ms, S_IRUGO|S_IWUSR, show_cursor_blink_ms,
+ store_cursor_blink_ms),
};
static int fbcon_init_device(void)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] fbcon: store cursor blink interval in fbcon_ops
The fbcon cursor, when set to blink, is hardcoded to toggle display state
five times per second. Move this setting to a the driver's fbdev_ops
structure, retaining the default blink interval.
Signed-off-by: Scot Doyle
---
drivers/video/console/fbcon.c | 5 +++--
drivers/video/console/fbcon.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index ea43724..7a2030b 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -405,7 +405,7 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fbcon_ops *ops = info->fbcon_par;
queue_work(system_power_efficient_wq, >queue);
- mod_timer(>cursor_timer, jiffies + HZ/5);
+ mod_timer(>cursor_timer, jiffies + ops->blink_jiffies);
}
static void fbcon_add_cursor_timer(struct fb_info *info)
@@ -420,7 +420,7 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
init_timer(>cursor_timer);
ops->cursor_timer.function = cursor_timer_handler;
- ops->cursor_timer.expires = jiffies + HZ / 5;
+ ops->cursor_timer.expires = jiffies + ops->blink_jiffies;
ops->cursor_timer.data = (unsigned long ) info;
add_timer(>cursor_timer);
ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
@@ -959,6 +959,7 @@ static const char *fbcon_startup(void)
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
+ ops->blink_jiffies = msecs_to_jiffies(200);
info->fbcon_par = ops;
p->con_rotate = initial_rotation;
set_blitting_type(vc, info);
diff --git a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h
index 6bd2e0c..642c4e7 100644
--- a/drivers/video/console/fbcon.h
+++ b/drivers/video/console/fbcon.h
@@ -70,6 +70,7 @@ struct fbcon_ops {
struct fb_cursor cursor_state;
struct display *p;
intcurrcon;/* Current VC. */
+ intblink_jiffies;
intcursor_flash;
intcursor_reset;
intblank_state;
--
2.1.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/
[GIT PULL REQUEST] watchdog - v3.19-rc5 Fixes
Hi Linus,
Please pull from 'master' branch of
git://www.linux-watchdog.org/linux-watchdog.git
It will fix reboot issues with the imx2_wdt driver and it also
drops some forgotten owner assignments from platform_drivers.
This will update the following files:
cadence_wdt.c |1 -
imx2_wdt.c| 40 +++-
meson_wdt.c |1 -
3 files changed, 31 insertions(+), 11 deletions(-)
with these Changes:
commit 7a32757eda68a53626f003018733d09f94138334
Author: Wolfram Sang
Date: Sun Dec 21 22:14:43 2014 +0100
watchdog: drop owner assignment from platform_drivers
This platform_driver does not need to set an owner, it will be populated by
the
driver core.
Signed-off-by: Wolfram Sang
Signed-off-by: Wim Van Sebroeck
commit 5fe65ce7ccbb47b16e17a88bcdac73cffadb80fa
Author: Markus Pargmann
Date: Mon Sep 8 09:14:07 2014 +0200
watchdog: imx2_wdt: Disable power down counter on boot
Disable power down counter of the watchdog to avoid system resets. The
watchdog power down counter is set automatically by the chip. If it is
not set to 0 in the driver, the system resets.
Signed-off-by: Markus Pargmann
Acked-by: Shawn Guo
Signed-off-by: Wim Van Sebroeck
commit bbd5900935be8755b6344386373174b20cd474a2
Author: Xiubo Li
Date: Thu Oct 16 11:44:15 2014 +0800
watchdog: imx2_wdt: Improve power management support.
Improve power management operations(suspend and resume) as part of
dev_pm_ops for IMX2 watchdog driver.
If PM will be supported, please make sure that the wdev->clk
could disable the watchdog's counter input clock source or can
mask watchdog's reset request to the core.
If watchdog is still used by consumers and resumes from deep
sleep state, we need to restart the watchdog again without
enabling the timer.
If watchdog been has started --> stopped by the consumers and
resumes from non-deep sleep state, then start the timer again.
If watchdog has been started --> stopped by the consumers and
resumes from deep sleep state, will do nothing. The watchdog
will be restarted by consumers next time to be used.
Signed-off-by: Xiubo Li
Reviewed-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
For completeness, I added the overal diff below.
Greetings,
Wim.
diff --git a/drivers/watchdog/cadence_wdt.c b/drivers/watchdog/cadence_wdt.c
index 5927c0a..bcfd2a2 100644
--- a/drivers/watchdog/cadence_wdt.c
+++ b/drivers/watchdog/cadence_wdt.c
@@ -503,7 +503,6 @@ static struct platform_driver cdns_wdt_driver = {
.shutdown = cdns_wdt_shutdown,
.driver = {
.name = "cdns-wdt",
- .owner = THIS_MODULE,
.of_match_table = cdns_wdt_of_match,
.pm = _wdt_pm_ops,
},
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index d6add51..5142bba 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -52,6 +52,8 @@
#define IMX2_WDT_WRSR 0x04/* Reset Status Register */
#define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
+#define IMX2_WDT_WMCR 0x08/* Misc Register */
+
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
@@ -274,6 +276,13 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
imx2_wdt_ping_if_active(wdog);
+ /*
+* Disable the watchdog power down counter at boot. Otherwise the power
+* down counter will pull down the #WDOG interrupt line for one clock
+* cycle.
+*/
+ regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
+
ret = watchdog_register_device(wdog);
if (ret) {
dev_err(>dev, "cannot register watchdog device\n");
@@ -327,18 +336,21 @@ static void imx2_wdt_shutdown(struct platform_device
*pdev)
}
#ifdef CONFIG_PM_SLEEP
-/* Disable watchdog if it is active during suspend */
+/* Disable watchdog if it is active or non-active but still running */
static int imx2_wdt_suspend(struct device *dev)
{
struct watchdog_device *wdog = dev_get_drvdata(dev);
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
- imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
- imx2_wdt_ping(wdog);
+ /* The watchdog IP block is running */
+ if (imx2_wdt_is_running(wdev)) {
+ imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
+ imx2_wdt_ping(wdog);
- /* Watchdog has been stopped but IP block is still running */
- if (!watchdog_active(wdog) && imx2_wdt_is_running(wdev))
- del_timer_sync(>timer);
+ /* The watchdog is not active */
+ if (!watchdog_active(wdog))
+
Re: [PATCH 06/12] time: Add infrastructure to cap clocksource reads to the max_cycles value
On Thu, Jan 22, 2015 at 04:09:21PM -0800, John Stultz wrote:
> +static inline cycle_t timekeeping_get_delta(struct tk_read_base *tkr)
> +{
> + cycle_t cycle_now, delta;
> +
> + /* read clocksource */
> + cycle_now = tkr->read(tkr->clock);
> +
> + /* calculate the delta since the last update_wall_time */
> + delta = clocksource_delta(cycle_now, tkr->cycle_last, tkr->mask);
> +
> + /* Cap delta value to the max_cycles values to avoid mult overflows */
> + if (unlikely(delta > tkr->clock->max_cycles))
> + delta = tkr->clock->max_cycles;
> +
> + return delta;
> +}
> #else
> #define timekeeping_check_update(x, y)
> +static inline cycle_t timekeeping_get_delta(struct tk_read_base *tkr)
> +{
> + /* calculate the delta since the last update_wall_time */
> + return clocksource_delta(tkr->read(tkr->clock), tkr->cycle_last,
> + tkr->mask);
Coding style is strange here. It would look nicer it were like the
debug version, above.
> +}
> #endif
Series looks fine to me.
Acked-by: Richard Cochran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: ux500: Move struct
2015-01-22 8:44 GMT+01:00 Lee Jones : > > Are you sure a struct is required at all now? It only contains a > single bool after all. Hi Lee Okay, I will gladly remove ab8500_ext_regulator_cfg completely. And I will try to update the comments, but since I'm not so familiar with what this code was meant to do it is a little more difficult. Kind regards Rickard Strandqvist -- 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 v4 2/4] irqchip: mtk-sysirq: Get irq number from register resource size
On Thu, 22 Jan 2015, Matthias Brugger wrote: > 2015-01-13 14:12 GMT+01:00 Matthias Brugger : > > 2015-01-12 10:14 GMT+01:00 Eddie Huang : > >> From: Yingjoe Chen > >> > >> Originally mtk-sysirq hardcoded supported irq number to 224. This > >> was fine since all SoCs before support the same number of irqs for > >> intpol. > >> > >> However MT8173 intpol support 32 more irq pins, changes to get > >> irq number from register resource size to suppor MT8173 properly. > >> > >> Signed-off-by: Yingjoe Chen > >> Signed-off-by: Eddie Huang > >> --- > >> drivers/irqchip/irq-mtk-sysirq.c | 18 +++--- > >> 1 file changed, 11 insertions(+), 7 deletions(-) > >> > > > > Jason, Thomas, will you take this patch through your branch? > > I will take the rest of the series. > > > > Best regards, > > Matthias > > > > -- > > motzblog.wordpress.com > > Hi Thomas, hi Jason, > > do you have any comments on this patch? Jason is swamped. I'm currently collecting stuff. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] ARM: at91: fix irq_pm_install_action WARNING
Hi Thomas, On Sat, 24 Jan 2015 17:37:48 +0100 (CET) Thomas Gleixner wrote: > On Fri, 23 Jan 2015, Boris Brezillon wrote: > > - change the compatible string to clearly show that this chip is purely > >virtual > > So we probably want to do : s/dumb/virt/ for both DT and code to make > it clear from the names as well. I thought the dumb word was denoting the simplicity (stupidity ?) of the irq demultiplexer, but indeed, I don't see how a virtual irq demuxer could have enough information to do a better job (if there's an interrupt cause register, then it's not a virtual/software demuxer anymore). So replacing dumb by virt or virtual makes sense here. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] irqchip: gic: Allow interrupt level to be set for PPIs.
On Thu, 22 Jan 2015, Marc Zyngier wrote: > On Tue, Jan 20 2015 at 4:52:59 pm GMT, Liviu Dudau > wrote: > > During a recent cleanup of the arm64 DTs it has become clear that > > the handling of PPIs in _set_type() is incorrect. The ARM TRMs > > for GICv2 and later allow for "implementation defined" support for > > setting the edge or level type of the PPI interrupts and don't restrict > > the activation level of the signal. Current ARM implementations > > do restrict the PPI level type to IRQ_TYPE_LEVEL_LOW, but licensees > > of the IP can decide to shoot themselves in the foot at any time. > > > > Signed-off-by: Liviu Dudau > > For the GIC and GICv3 parts: > > Acked-by: Marc Zyngier So I queue that if there are no further objections from Russell or the DT folks. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] time: clocksource: Add a comment to CLOCK_SOURCE_SUSPEND_NONSTOP
On Sat, 24 Jan 2015, Xunlei Pang wrote: > Before this, I tried to add some code to catch such problem at the > time of registering the clocksource, like using the > CLOCKSOURCE_MASK(), for example 64bit counter will never wrap for > us. But there may be other values like CLOCKSOURCE_MASK(56), I just > can't figure out exactly how to do this judge. I don't think there is a good way to do so. Registration time is the wrong place anyway because the problem depends on: - The width of the counter - The frequency of the counter The frequency of the counter might even change after registration. Now add the unknown duration of the suspend to the picture and you're completely lost. All we can do is provide information about the actual wraparound time, if the CLOCK_SOURCE_SUSPEND_NONSTOP flag is set and the wraparound time is less than some reasonable margin. Thanks, tglx -- 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 0/4] defconfigs: cleanup obsolete MTD configs
On Sat, 2015-01-24 at 18:33 +0200, Semen Protsenko wrote: > This patch series removes next obsolete MTD configs from all defconfig files: > - CONFIG_MTD_CHAR > - CONFIG_MTD_CONCAT > - CONFIG_MTD_DEBUG > - CONFIG_MTD_DEBUG_VERBOSE > - CONFIG_MTD_PARTITIONS > > All those configs were removed from drivers/mtd/Kconfig earlier, but their > usage > in defconfig files was remain unnoticed. There are at least two obvious > reasons > to get rid of those configs: > 1. Their usage may cause to build warnings That's news for me. I thought they are silently ignored. Do you have an example of such a warning? > 2. Their usage may confuse someone who is grepping defconfig files to get > the clue what MTD configuration may look like. > > This series is harmless for all those defconfigs and will not break anything. > > > Semen Protsenko (4): > defconfigs: remove CONFIG_MTD_CONCAT > defconfigs: remove CONFIG_MTD_PARTITIONS > defconfigs: remove CONFIG_MTD_CHAR > defconfigs: remove CONFIG_MTD_DEBUG* > > arch/arm/configs/acs5k_defconfig |3 --- > [...] > arch/unicore32/configs/unicore32_defconfig |2 -- > 226 files changed, 364 deletions(-) Seems like the kind of change that can only be reviewed by a script. Is there any policy on keeping defconfig files up to date? Because, only slightly exaggerated, all the defconfig files are outdated, in minor or major ways, at any given moment. I seem to remember Greg stating that defconfig files are on their way out. Did I remember that correctly? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/2] perf: convert: fix duplicate field names and avoid reserved keywords.
On Fri, Jan 23, 2015 at 05:40:02PM -0500, Jérémie Galarneau wrote: SNIP > > bt_ctf_clock_create() with the checked name and then free it. However, it > > is hacky > > and I think you won't like it. > > The prospect of seeing that code has convinced me to introduce > int bt_ctf_validate_identifier(const char *identifier); > > commit 654c1444b546fd79b209288b93ed4e87d9bb8a2b > Author: Jérémie Galarneau > Date: Fri Jan 23 16:24:52 2015 -0500 > > Add utility function to validate CTF identifiers > > Introduces bt_ctf_validate_identifier() which validates a given > identifier against the list of CTF reserved keywords. > > This function may evolve to perform additional validity checks in > the future as the CTF specification moves forward. > > Acked-by: Mathieu Desnoyers > Signed-off-by: Jérémie Galarneau > > > Does that take care of the problem? seems good to me, thanks jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] ARM: at91: fix irq_pm_install_action WARNING
On Fri, 23 Jan 2015, Boris Brezillon wrote: > - change the compatible string to clearly show that this chip is purely >virtual So we probably want to do : s/dumb/virt/ for both DT and code to make it clear from the names as well. Thanks, tglx -- 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/4] defconfigs: remove CONFIG_MTD_CHAR
CONFIG_MTD_CHAR was removed from drivers/mtd/Kconfig by commit: 660685d9d1b4 "mtd: merge mtdchar module with mtdcore". This patch finishes job by getting rid of CONFIG_MTD_CHAR in all defconfig files. Since CONFIG_MTD_CHAR was merged with CONFIG_MTD (see commit above), it is harmless to remove all CONFIG_MTD_CHAR references as long as those defconfig files have CONFIG_MTD declared. Signed-off-by: Semen Protsenko --- arch/arm/configs/acs5k_defconfig |1 - arch/arm/configs/acs5k_tiny_defconfig |1 - arch/arm/configs/am200epdkit_defconfig |1 - arch/arm/configs/assabet_defconfig |1 - arch/arm/configs/badge4_defconfig |1 - arch/arm/configs/bockw_defconfig |1 - arch/arm/configs/cerfcube_defconfig|1 - arch/arm/configs/cm_x2xx_defconfig |1 - arch/arm/configs/cm_x300_defconfig |1 - arch/arm/configs/cns3420vb_defconfig |1 - arch/arm/configs/colibri_pxa270_defconfig |1 - arch/arm/configs/collie_defconfig |1 - arch/arm/configs/corgi_defconfig |1 - arch/arm/configs/davinci_all_defconfig |1 - arch/arm/configs/em_x270_defconfig |1 - arch/arm/configs/ezx_defconfig |1 - arch/arm/configs/hackkit_defconfig |1 - arch/arm/configs/imote2_defconfig |1 - arch/arm/configs/iop32x_defconfig |1 - arch/arm/configs/iop33x_defconfig |1 - arch/arm/configs/ixp4xx_defconfig |1 - arch/arm/configs/ks8695_defconfig |1 - arch/arm/configs/lart_defconfig|1 - arch/arm/configs/lpc32xx_defconfig |1 - arch/arm/configs/lpd270_defconfig |1 - arch/arm/configs/lubbock_defconfig |1 - arch/arm/configs/mackerel_defconfig|1 - arch/arm/configs/magician_defconfig|1 - arch/arm/configs/mainstone_defconfig |1 - arch/arm/configs/mini2440_defconfig|1 - arch/arm/configs/mv78xx0_defconfig |1 - arch/arm/configs/netx_defconfig|1 - arch/arm/configs/nuc910_defconfig |1 - arch/arm/configs/nuc950_defconfig |1 - arch/arm/configs/nuc960_defconfig |1 - arch/arm/configs/omap1_defconfig |1 - arch/arm/configs/orion5x_defconfig |1 - arch/arm/configs/pcm027_defconfig |1 - arch/arm/configs/pleb_defconfig|1 - arch/arm/configs/pxa255-idp_defconfig |1 - arch/arm/configs/pxa3xx_defconfig |1 - arch/arm/configs/raumfeld_defconfig|1 - arch/arm/configs/realview-smp_defconfig|1 - arch/arm/configs/realview_defconfig|1 - arch/arm/configs/s3c2410_defconfig |1 - arch/arm/configs/shannon_defconfig |1 - arch/arm/configs/simpad_defconfig |1 - arch/arm/configs/spear13xx_defconfig |1 - arch/arm/configs/spear3xx_defconfig|1 - arch/arm/configs/spear6xx_defconfig|1 - arch/arm/configs/spitz_defconfig |1 - arch/arm/configs/tct_hammer_defconfig |1 - arch/arm/configs/trizeps4_defconfig|1 - arch/arm/configs/viper_defconfig |1 - arch/arm/configs/zeus_defconfig|1 - arch/avr32/configs/atngw100_defconfig |1 - arch/avr32/configs/atngw100_evklcd100_defconfig|1 - arch/avr32/configs/atngw100_evklcd101_defconfig|1 - arch/avr32/configs/atngw100_mrmt_defconfig |1 - arch/avr32/configs/atngw100mkii_defconfig |1 - .../avr32/configs/atngw100mkii_evklcd100_defconfig |1 - .../avr32/configs/atngw100mkii_evklcd101_defconfig |1 - arch/avr32/configs/atstk1002_defconfig |1 - arch/avr32/configs/atstk1003_defconfig |1 - arch/avr32/configs/atstk1004_defconfig |1 - arch/avr32/configs/atstk1006_defconfig |1 - arch/avr32/configs/favr-32_defconfig |1 - arch/avr32/configs/hammerhead_defconfig|1 - arch/avr32/configs/merisc_defconfig|1 - arch/avr32/configs/mimc200_defconfig |1 - arch/blackfin/configs/BF518F-EZBRD_defconfig |1 - arch/blackfin/configs/BF527-TLL6527M_defconfig |1 - arch/blackfin/configs/BF533-EZKIT_defconfig|1 - arch/blackfin/configs/BF533-STAMP_defconfig|1 - arch/blackfin/configs/BF537-STAMP_defconfig|1 -
[PATCH 4/4] defconfigs: remove CONFIG_MTD_DEBUG*
CONFIG_MTD_DEBUG and CONFIG_MTD_DEBUG_VERBOSE were removed from drivers/mtd/Kconfig by commit: 87ed114bb22b "mtd: remove CONFIG_MTD_DEBUG" This patch finishes job by getting rid of CONFIG_MTD_DEBUG* in all defconfig files. This patch is harmless for all modified defconfig files. Signed-off-by: Semen Protsenko --- arch/arm/configs/badge4_defconfig |1 - arch/arm/configs/hackkit_defconfig |2 -- arch/arm/configs/lart_defconfig |2 -- arch/arm/configs/omap1_defconfig|2 -- arch/blackfin/configs/DNP5370_defconfig |2 -- arch/mn10300/configs/asb2303_defconfig |1 - arch/mn10300/configs/asb2364_defconfig |1 - arch/sh/configs/edosk7760_defconfig |1 - arch/sh/configs/titan_defconfig |1 - 9 files changed, 13 deletions(-) diff --git a/arch/arm/configs/badge4_defconfig b/arch/arm/configs/badge4_defconfig index e8913b0..9d11ff7 100644 --- a/arch/arm/configs/badge4_defconfig +++ b/arch/arm/configs/badge4_defconfig @@ -29,7 +29,6 @@ CONFIG_BT_HCIUART=m CONFIG_BT_HCIVHCI=m # CONFIG_FW_LOADER is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_ADV_OPTIONS=y diff --git a/arch/arm/configs/hackkit_defconfig b/arch/arm/configs/hackkit_defconfig index ab2acf1..f469536 100644 --- a/arch/arm/configs/hackkit_defconfig +++ b/arch/arm/configs/hackkit_defconfig @@ -20,8 +20,6 @@ CONFIG_INET=y CONFIG_SYN_COOKIES=y # CONFIG_IPV6 is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=3 CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y diff --git a/arch/arm/configs/lart_defconfig b/arch/arm/configs/lart_defconfig index 191c0b3..ff61d33 100644 --- a/arch/arm/configs/lart_defconfig +++ b/arch/arm/configs/lart_defconfig @@ -29,8 +29,6 @@ CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_DEBUG=y CONFIG_SA1100_FIR=m CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=1 CONFIG_MTD_BLOCK=y CONFIG_MTD_LART=y CONFIG_BLK_DEV_RAM=y diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig index a234203..f10b269 100644 --- a/arch/arm/configs/omap1_defconfig +++ b/arch/arm/configs/omap1_defconfig @@ -92,8 +92,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_CONNECTOR=y # CONFIG_PROC_EVENTS is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=3 CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y diff --git a/arch/blackfin/configs/DNP5370_defconfig b/arch/blackfin/configs/DNP5370_defconfig index 8860059..18e97c1 100644 --- a/arch/blackfin/configs/DNP5370_defconfig +++ b/arch/blackfin/configs/DNP5370_defconfig @@ -34,8 +34,6 @@ CONFIG_SYN_COOKIES=y CONFIG_LLC2=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=1 CONFIG_MTD_BLOCK=y CONFIG_NFTL=y CONFIG_NFTL_RW=y diff --git a/arch/mn10300/configs/asb2303_defconfig b/arch/mn10300/configs/asb2303_defconfig index 4f0f31f..b6364ea 100644 --- a/arch/mn10300/configs/asb2303_defconfig +++ b/arch/mn10300/configs/asb2303_defconfig @@ -33,7 +33,6 @@ CONFIG_IP_PNP_BOOTP=y # CONFIG_IPV6 is not set # CONFIG_WIRELESS is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y CONFIG_MTD_REDBOOT_PARTS=y CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED=y CONFIG_MTD_CFI=y diff --git a/arch/mn10300/configs/asb2364_defconfig b/arch/mn10300/configs/asb2364_defconfig index f5ccb76..b43179f 100644 --- a/arch/mn10300/configs/asb2364_defconfig +++ b/arch/mn10300/configs/asb2364_defconfig @@ -50,7 +50,6 @@ CONFIG_IPV6=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_CONNECTOR=y CONFIG_MTD=y -CONFIG_MTD_DEBUG=y CONFIG_MTD_REDBOOT_PARTS=y CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED=y CONFIG_MTD_CFI=y diff --git a/arch/sh/configs/edosk7760_defconfig b/arch/sh/configs/edosk7760_defconfig index e98e847..758b489 100644 --- a/arch/sh/configs/edosk7760_defconfig +++ b/arch/sh/configs/edosk7760_defconfig @@ -38,7 +38,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEBUG_DRIVER=y CONFIG_DEBUG_DEVRES=y CONFIG_MTD=y -CONFIG_MTD_DEBUG=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y diff --git a/arch/sh/configs/titan_defconfig b/arch/sh/configs/titan_defconfig index cbb3166..2417a09 100644 --- a/arch/sh/configs/titan_defconfig +++ b/arch/sh/configs/titan_defconfig @@ -153,7 +153,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_FW_LOADER=m CONFIG_CONNECTOR=m CONFIG_MTD=m -CONFIG_MTD_DEBUG=y CONFIG_MTD_BLOCK=m CONFIG_FTL=m CONFIG_NFTL=m -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] defconfigs: remove CONFIG_MTD_CONCAT
CONFIG_MTD_CONCAT was removed from drivers/mtd/Kconfig by commit: f53fdebcc3e1 "mtd: drop MTD_CONCAT from Kconfig entirely". This patch finishes job by getting rid of CONFIG_MTD_CONCAT in all defconfig files. This patch is harmless for all modified defconfig files, because MTD_CONCAT code is now compiled without checking for CONFIG_MTD_CONCAT. For details see next commit: a8adc3f01b9a "mtd: drop CONFIG_MTD_CONCAT ifdefs" Signed-off-by: Semen Protsenko --- arch/arm/configs/acs5k_defconfig |1 - arch/arm/configs/acs5k_tiny_defconfig |1 - arch/arm/configs/colibri_pxa270_defconfig |1 - arch/arm/configs/mackerel_defconfig|1 - arch/arm/configs/mini2440_defconfig|1 - arch/arm/configs/neponset_defconfig|1 - arch/arm/configs/nuc910_defconfig |1 - arch/arm/configs/nuc950_defconfig |1 - arch/arm/configs/nuc960_defconfig |1 - arch/arm/configs/pxa3xx_defconfig |1 - arch/arm/configs/raumfeld_defconfig|1 - arch/arm/configs/realview-smp_defconfig|1 - arch/arm/configs/realview_defconfig|1 - arch/arm/configs/simpad_defconfig |1 - arch/arm/configs/trizeps4_defconfig|1 - arch/arm/configs/xcep_defconfig|1 - arch/avr32/configs/merisc_defconfig|1 - arch/m32r/configs/usrv_defconfig |1 - arch/powerpc/configs/44x/eiger_defconfig |1 - arch/powerpc/configs/44x/redwood_defconfig |1 - arch/powerpc/configs/52xx/motionpro_defconfig |1 - arch/powerpc/configs/52xx/tqm5200_defconfig|1 - arch/powerpc/configs/83xx/sbc834x_defconfig|1 - arch/powerpc/configs/85xx/ksi8560_defconfig|1 - arch/powerpc/configs/85xx/ppa8548_defconfig|1 - arch/powerpc/configs/85xx/socrates_defconfig |1 - arch/powerpc/configs/85xx/tqm8540_defconfig|1 - arch/powerpc/configs/85xx/tqm8541_defconfig|1 - arch/powerpc/configs/85xx/tqm8555_defconfig|1 - arch/powerpc/configs/85xx/tqm8560_defconfig|1 - arch/powerpc/configs/86xx/gef_ppc9a_defconfig |1 - arch/powerpc/configs/86xx/gef_sbc310_defconfig |1 - arch/powerpc/configs/86xx/gef_sbc610_defconfig |1 - arch/powerpc/configs/86xx/sbc8641d_defconfig |1 - arch/powerpc/configs/c2k_defconfig |1 - arch/powerpc/configs/linkstation_defconfig |1 - arch/powerpc/configs/tqm8xx_defconfig |1 - arch/sh/configs/ap325rxa_defconfig |1 - arch/sh/configs/apsh4a3a_defconfig |1 - arch/sh/configs/ecovec24_defconfig |1 - arch/sh/configs/edosk7760_defconfig|1 - arch/sh/configs/kfr2r09_defconfig |1 - arch/sh/configs/migor_defconfig|1 - arch/sh/configs/rsk7201_defconfig |1 - arch/sh/configs/rsk7203_defconfig |1 - arch/sh/configs/rts7751r2dplus_defconfig |1 - arch/sh/configs/se7206_defconfig |1 - arch/sh/configs/se7343_defconfig |1 - arch/sh/configs/se7619_defconfig |1 - arch/sh/configs/se7712_defconfig |1 - arch/sh/configs/se7721_defconfig |1 - arch/sh/configs/se7724_defconfig |1 - arch/sh/configs/sh7785lcr_32bit_defconfig |1 - arch/sh/configs/sh7785lcr_defconfig|1 - arch/sh/configs/ul2_defconfig |1 - arch/sh/configs/urquell_defconfig |1 - 56 files changed, 56 deletions(-) diff --git a/arch/arm/configs/acs5k_defconfig b/arch/arm/configs/acs5k_defconfig index 92b0f90..b8be0bc 100644 --- a/arch/arm/configs/acs5k_defconfig +++ b/arch/arm/configs/acs5k_defconfig @@ -34,7 +34,6 @@ CONFIG_IP_PNP_DHCP=y # CONFIG_IPV6 is not set CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_MTD=y -CONFIG_MTD_CONCAT=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y diff --git a/arch/arm/configs/acs5k_tiny_defconfig b/arch/arm/configs/acs5k_tiny_defconfig index 2a27a14..886448a 100644 --- a/arch/arm/configs/acs5k_tiny_defconfig +++ b/arch/arm/configs/acs5k_tiny_defconfig @@ -29,7 +29,6 @@ CONFIG_INET=y # CONFIG_IPV6 is not set CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_MTD=y -CONFIG_MTD_CONCAT=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y diff --git a/arch/arm/configs/colibri_pxa270_defconfig b/arch/arm/configs/colibri_pxa270_defconfig index 18c311a..8a1d763 100644 --- a/arch/arm/configs/colibri_pxa270_defconfig +++ b/arch/arm/configs/colibri_pxa270_defconfig @@ -57,7 +57,6 @@ CONFIG_CFG80211=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_CONNECTOR=y CONFIG_MTD=y -CONFIG_MTD_CONCAT=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y diff --git a/arch/arm/configs/mackerel_defconfig
[PATCH 2/4] defconfigs: remove CONFIG_MTD_PARTITIONS
CONFIG_MTD_PARTITIONS was removed from drivers/mtd/Kconfig by commit: 6a8a98b22b10 "mtd: kill CONFIG_MTD_PARTITIONS". This patch finishes job by getting rid of CONFIG_MTD_PARTITIONS in all defconfig files. This patch is harmless for all modified defconfig files, because MTD_PARTITIONS code is now compiled without checking for CONFIG_MTD_PARTITIONS. For details see next commit: 5fcb033159bc "mtd: always build partitioning support". Signed-off-by: Semen Protsenko --- arch/arm/configs/acs5k_defconfig |1 - arch/arm/configs/acs5k_tiny_defconfig |1 - arch/arm/configs/assabet_defconfig |1 - arch/arm/configs/badge4_defconfig |1 - arch/arm/configs/cerfcube_defconfig|1 - arch/arm/configs/cm_x300_defconfig |1 - arch/arm/configs/cns3420vb_defconfig |1 - arch/arm/configs/collie_defconfig |1 - arch/arm/configs/corgi_defconfig |1 - arch/arm/configs/davinci_all_defconfig |1 - arch/arm/configs/h5000_defconfig |1 - arch/arm/configs/iop13xx_defconfig |1 - arch/arm/configs/iop32x_defconfig |1 - arch/arm/configs/iop33x_defconfig |1 - arch/arm/configs/ixp4xx_defconfig |1 - arch/arm/configs/ks8695_defconfig |1 - arch/arm/configs/lart_defconfig|1 - arch/arm/configs/lpd270_defconfig |1 - arch/arm/configs/lubbock_defconfig |1 - arch/arm/configs/mackerel_defconfig|1 - arch/arm/configs/magician_defconfig|1 - arch/arm/configs/mainstone_defconfig |1 - arch/arm/configs/mini2440_defconfig|1 - arch/arm/configs/mv78xx0_defconfig |1 - arch/arm/configs/neponset_defconfig|1 - arch/arm/configs/netx_defconfig|1 - arch/arm/configs/nuc910_defconfig |1 - arch/arm/configs/nuc950_defconfig |1 - arch/arm/configs/nuc960_defconfig |1 - arch/arm/configs/omap1_defconfig |1 - arch/arm/configs/pcm027_defconfig |1 - arch/arm/configs/pleb_defconfig|1 - arch/arm/configs/pxa255-idp_defconfig |1 - arch/arm/configs/raumfeld_defconfig|1 - arch/arm/configs/realview-smp_defconfig|1 - arch/arm/configs/realview_defconfig|1 - arch/arm/configs/shannon_defconfig |1 - arch/arm/configs/simpad_defconfig |1 - arch/arm/configs/spitz_defconfig |1 - arch/arm/configs/tct_hammer_defconfig |1 - arch/m32r/configs/m32700ut.smp_defconfig |1 - arch/m32r/configs/m32700ut.up_defconfig|1 - arch/m32r/configs/mappi.smp_defconfig |1 - arch/m32r/configs/mappi.up_defconfig |1 - arch/m32r/configs/mappi3.smp_defconfig |1 - arch/m32r/configs/usrv_defconfig |1 - arch/mn10300/configs/asb2303_defconfig |1 - arch/mn10300/configs/asb2364_defconfig |1 - arch/sh/configs/ap325rxa_defconfig |1 - arch/sh/configs/apsh4a3a_defconfig |1 - arch/sh/configs/ecovec24_defconfig |1 - arch/sh/configs/edosk7760_defconfig|1 - arch/sh/configs/espt_defconfig |1 - arch/sh/configs/magicpanelr2_defconfig |1 - arch/sh/configs/migor_defconfig|1 - arch/sh/configs/polaris_defconfig |1 - arch/sh/configs/r7780mp_defconfig |1 - arch/sh/configs/rsk7201_defconfig |1 - arch/sh/configs/rsk7203_defconfig |1 - arch/sh/configs/rts7751r2dplus_defconfig |1 - arch/sh/configs/sdk7786_defconfig |1 - arch/sh/configs/se7206_defconfig |1 - arch/sh/configs/se7343_defconfig |1 - arch/sh/configs/se7619_defconfig |1 - arch/sh/configs/se7705_defconfig |1 - arch/sh/configs/se7712_defconfig |1 - arch/sh/configs/se7721_defconfig |1 - arch/sh/configs/se7724_defconfig |1 - arch/sh/configs/se7750_defconfig |1 - arch/sh/configs/se7751_defconfig |1 - arch/sh/configs/se7780_defconfig |1 - arch/sh/configs/secureedge5410_defconfig |1 - arch/sh/configs/sh7710voipgw_defconfig |1 - arch/sh/configs/sh7763rdp_defconfig|1 - arch/sh/configs/sh7785lcr_32bit_defconfig |1 - arch/sh/configs/sh7785lcr_defconfig|1 - arch/sh/configs/shmin_defconfig|1 - arch/sh/configs/ul2_defconfig |1 - arch/sh/configs/urquell_defconfig |1 - arch/unicore32/configs/unicore32_defconfig |1 - 80 files changed, 80 deletions(-) diff --git a/arch/arm/configs/acs5k_defconfig b/arch/arm/configs/acs5k_defconfig index b8be0bc..4faff9a 100644 --- a/arch/arm/configs/acs5k_defconfig +++ b/arch/arm/configs/acs5k_defconfig @@ -34,7 +34,6 @@ CONFIG_IP_PNP_DHCP=y # CONFIG_IPV6 is
[PATCH 0/4] defconfigs: cleanup obsolete MTD configs
This patch series removes next obsolete MTD configs from all defconfig files: - CONFIG_MTD_CHAR - CONFIG_MTD_CONCAT - CONFIG_MTD_DEBUG - CONFIG_MTD_DEBUG_VERBOSE - CONFIG_MTD_PARTITIONS All those configs were removed from drivers/mtd/Kconfig earlier, but their usage in defconfig files was remain unnoticed. There are at least two obvious reasons to get rid of those configs: 1. Their usage may cause to build warnings 2. Their usage may confuse someone who is grepping defconfig files to get the clue what MTD configuration may look like. This series is harmless for all those defconfigs and will not break anything. Semen Protsenko (4): defconfigs: remove CONFIG_MTD_CONCAT defconfigs: remove CONFIG_MTD_PARTITIONS defconfigs: remove CONFIG_MTD_CHAR defconfigs: remove CONFIG_MTD_DEBUG* arch/arm/configs/acs5k_defconfig |3 --- arch/arm/configs/acs5k_tiny_defconfig |3 --- arch/arm/configs/am200epdkit_defconfig |1 - arch/arm/configs/assabet_defconfig |2 -- arch/arm/configs/badge4_defconfig |3 --- arch/arm/configs/bockw_defconfig |1 - arch/arm/configs/cerfcube_defconfig|2 -- arch/arm/configs/cm_x2xx_defconfig |1 - arch/arm/configs/cm_x300_defconfig |2 -- arch/arm/configs/cns3420vb_defconfig |2 -- arch/arm/configs/colibri_pxa270_defconfig |2 -- arch/arm/configs/collie_defconfig |2 -- arch/arm/configs/corgi_defconfig |2 -- arch/arm/configs/davinci_all_defconfig |2 -- arch/arm/configs/em_x270_defconfig |1 - arch/arm/configs/ezx_defconfig |1 - arch/arm/configs/h5000_defconfig |1 - arch/arm/configs/hackkit_defconfig |3 --- arch/arm/configs/imote2_defconfig |1 - arch/arm/configs/iop13xx_defconfig |1 - arch/arm/configs/iop32x_defconfig |2 -- arch/arm/configs/iop33x_defconfig |2 -- arch/arm/configs/ixp4xx_defconfig |2 -- arch/arm/configs/ks8695_defconfig |2 -- arch/arm/configs/lart_defconfig|4 arch/arm/configs/lpc32xx_defconfig |1 - arch/arm/configs/lpd270_defconfig |2 -- arch/arm/configs/lubbock_defconfig |2 -- arch/arm/configs/mackerel_defconfig|3 --- arch/arm/configs/magician_defconfig|2 -- arch/arm/configs/mainstone_defconfig |2 -- arch/arm/configs/mini2440_defconfig|3 --- arch/arm/configs/mv78xx0_defconfig |2 -- arch/arm/configs/neponset_defconfig|2 -- arch/arm/configs/netx_defconfig|2 -- arch/arm/configs/nuc910_defconfig |3 --- arch/arm/configs/nuc950_defconfig |3 --- arch/arm/configs/nuc960_defconfig |3 --- arch/arm/configs/omap1_defconfig |4 arch/arm/configs/orion5x_defconfig |1 - arch/arm/configs/pcm027_defconfig |2 -- arch/arm/configs/pleb_defconfig|2 -- arch/arm/configs/pxa255-idp_defconfig |2 -- arch/arm/configs/pxa3xx_defconfig |2 -- arch/arm/configs/raumfeld_defconfig|3 --- arch/arm/configs/realview-smp_defconfig|3 --- arch/arm/configs/realview_defconfig|3 --- arch/arm/configs/s3c2410_defconfig |1 - arch/arm/configs/shannon_defconfig |2 -- arch/arm/configs/simpad_defconfig |3 --- arch/arm/configs/spear13xx_defconfig |1 - arch/arm/configs/spear3xx_defconfig|1 - arch/arm/configs/spear6xx_defconfig|1 - arch/arm/configs/spitz_defconfig |2 -- arch/arm/configs/tct_hammer_defconfig |2 -- arch/arm/configs/trizeps4_defconfig|2 -- arch/arm/configs/viper_defconfig |1 - arch/arm/configs/xcep_defconfig|1 - arch/arm/configs/zeus_defconfig|1 - arch/avr32/configs/atngw100_defconfig |1 - arch/avr32/configs/atngw100_evklcd100_defconfig|1 - arch/avr32/configs/atngw100_evklcd101_defconfig|1 - arch/avr32/configs/atngw100_mrmt_defconfig |1 - arch/avr32/configs/atngw100mkii_defconfig |1 - .../avr32/configs/atngw100mkii_evklcd100_defconfig |1 - .../avr32/configs/atngw100mkii_evklcd101_defconfig |1 - arch/avr32/configs/atstk1002_defconfig |1 -
Re: [PATCH 1/2] posix-timers: Prevents overrun counter overflow
On Fri, 23 Jan 2015, Daniel Church wrote:
> + overruns = (unsigned int) hrtimer_forward(timer,
> + timer->base->get_time(),
> + timr->it.real.interval);
> + if (overruns >= delaytimer_max ||
> + (timr->it_overrun >= 0 &&
> + timr->it_overrun >= delaytimer_max - overruns)) {
> + timr->it_overrun = delaytimer_max;
> + } else {
> + timr->it_overrun += overruns;
> + }
We certainly do not add the same logic 3 times via copy and
paste. Please make that a proper helper function.
Thanks,
tglx
--
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: futex(2) man page update help request
On Sat, 24 Jan 2015, Torvald Riegel wrote: > On Sat, 2015-01-24 at 11:05 +0100, Thomas Gleixner wrote: > > On Fri, 23 Jan 2015, Torvald Riegel wrote: > > > > > On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote: > > > > On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)" > > > > wrote: > > > > > > > > >Color me stupid, but I can't see this in futex_requeue(). Where is that > > > > >check that is "independent of the requeue type (normal/pi)"? > > > > > > > > > >When I look through futex_requeue(), all the likely looking sources > > > > >of EINVAL are governed by a check on the 'requeue_pi' argument. > > > > > > > > > > > > Right, in the non-PI case, I believe there are valid use cases: move to > > > > the back of the FIFO, for example (OK, maybe the only example?). > > > > > > But we never guarantee a futex is a FIFO, or do we? If we don't, then > > > such a requeue could be implemented as a no-op by the kernel, which > > > would sort of invalidate the use case. > > > > > > (And I guess we don't want to guarantee FIFO behavior for futexes.) > > > > The (current) behaviour is: > > > > real-time threads: FIFO per priority level > > sched-other threads: FIFO independent of nice level > > > > The wakeup is priority ordered. Highest priority level first. > > OK. > > But, just to be clear, do I correctly understand that you do not want to > guarantee FIFO behavior in the specified futex semantics? I think there > are cases where being able to *rely* on FIFO (now and on all future > kernels) would be helpful for users (e.g., on POSIX/C++11 condvars and I > assume in other ordered-wakeup cases too) -- but at the same time, this > would constrain future futex implementations. It would be a constraint, but I don't think it would be a horrible one. Though I have my doubts, that we can actually guarantee it under all circumstances. One thing comes to my mind right away: spurious wakeups. There is no way that we can guarantee FIFO ordering in the context of those. And we cannot prevent them either. Thanks, tglx -- 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 RESEND] PM / sleep: Fix racing timers
On Fri, 23 Jan 2015, Sören Brinkmann wrote: > On Mon, 2015-01-12 at 04:14PM +, Lorenzo Pieralisi wrote: > > I thought that a shutdown clock event device explicitly disables IRQ > > assertion, that's why I am inquiring, I do not understand how this > > can happen - how can you have a pending timer IRQ at step 3 above. > > It does I guess, but the shutdown of the IRQ happens after disabling > IRQs. During that window the IRQ can become pening without anybody > handling it. Shutting the timer down usually just ensures that no new > interrupts are signaled but it apparently doesn't check whether any are > still pending (which isn't necessary in almost all cases since the ISR > would take care of it). Well, the issue is that lots of platforms are just not affected by this because they either power off or simply do not propagate interrupts which are not explicitely marked as wakeup sources. After thinking more about it, we really should try to handle it at the core code, especially because the freezer folks who try to shutdown the tick completely run into similar issues. But, I don't think that just moving the suspend() call before disabling interrupts is sufficient. I rather think it's outright dangerous. suspend_ce() local_irq_disable(); ---> Interrupt becomes pending shutdown(ce); local_irq_enable(); ---> Interrupt fires There are implementations which actually switch of clocks and such at shutdown. So depending on the code in the actual interrupt handler (not the clockevent->handler, though that might have issues as well) we might touch a disfunctional device with possibly fatal consequences. Right now this cannot happen as the invocation of the interrupt handler is guaranteed to happen _after_ the device has been resumed. Just because it does not explode in your implementation does not mean its safe to inflict on everyone. So if we try to handle this issue at the core level, then we really must deal with the interrupt itself. Timer interrupts are always marked IRQF_NO_SUSPEND, because we still need them until syscore_suspend(). So in case we really shut down the clockevent device via tick_suspend() then we must disable the interrupt there as well and reenable it in tick_resume(). But that's not really possible at the core level today. Timer interrupts are delivered by various mechanisms: - plain interrupts - percpu interrupts - per cpu direct vectors - more complex stuff and we have no idea which type we are dealing with. So the only option would be to have a callback and let the suspend code do: if (cedev->disable_irq) cedev->disable_irq(cddev); and the reverse operation for resume. So we can provide default implementations for the callbacks: void ce_[dis|en]able_irq(...) void ce_[dis|en]able_percpu_irq(...) which would rely on cedev->irq. Those two would cover most of the implementations. The ones with special requirements can implement their own. Now at the irq level, we'd need a new function for the device irqs: disable_and_mask_irq_nosync(irq) which makes sure that the line is masked at the hardware level. That's necessary because the lazy interrupt disable is not sufficient. The percpu irqs are already masking at the hardware level. One might argue that we could handle this in set_mode() as well, but we are thinking about going away from that multiplex call. Aside of that, ensuring the symmetry of disable/enable invocations would be problematic with the existing set_mode() implementations and usage. Thanks, tglx
Re: [PATCH v3 01/12] clk: samsung: exynos5433: Add clocks using common clock framework
2015-01-23 1:47 GMT+09:00 Sylwester Nawrocki :
> Hi Chanwoo,
>
> On 21/01/15 07:26, Chanwoo Choi wrote:
>> This patch adds the support for CMU (Clock Management Units) of Exynos5433
>> which is 64bit SoC and has Octa-cores. This patch supports necessary clocks
>> (PLL/MMC/UART/MCT/I2C/SPI) for kernel boot and includes binding documentation
>> for Exynos5433 clock controller.
>
>> diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
>> b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
>> new file mode 100644
>> index 000..72cd0ba
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
>> @@ -0,0 +1,106 @@
>> +* Samsung Exynos5433 CMU (Clock Management Units)
>> +
>> +The Exynos5433 clock controller generates and supplies clock to various
>> +controllers within the Exynos5433 SoC.
>> +
>> +Required Properties:
>> +
>> +- compatible: should be one of the following.
>> + - "samsung,exynos5433-cmu-top" - clock controller compatible for CMU_TOP
>> +which generates clocks for
>> IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
>> +domains and bus clocks.
>> + - "samsung,exynos5433-cmu-cpif" - clock controller compatible for
>> CMU_CPIF
>> +which generates clocks for LLI (Low Latency Interface) IP.
>> + - "samsung,exynos5433-cmu-mif" - clock controller compatible for CMU_MIF
>> +which generates clocks for DRAM Memory Controller domain.
>> + - "samsung,exynos5433-cmu-peric" - clock controller compatible for
>> CMU_PERIC
>> +which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs.
>> + - "samsung,exynos5433-cmu-peris" - clock controller compatible for
>> CMU_PERIS
>> +which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
>> + - "samsung,exynos5433-cmu-fsys" - clock controller compatible for
>> CMU_FSYS
>> +which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
>> +
>> +- reg: physical base address of the controller and length of memory mapped
>> + region.
>> +
>> +- #clock-cells: should be 1.
>> +
>> +Each clock is assigned an identifier and client nodes can use this
>> identifier
>> +to specify the clock which they consume.
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/exynos5433.h header and can be used in device
>> +tree sources.
>> +
>> +Example 1: Examples of clock controller nodes are listed below.
>> +
>> + cmu_top: clock-controller@0x1003 {
>> + compatible = "samsung,exynos5433-cmu-top";
>> + reg = <0x1003 0x0c04>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + cmu_cpif: clock-controller@0x10fc {
>> + compatible = "samsung,exynos5433-cmu-cpif";
>> + reg = <0x10fc 0x0c04>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + cmu_mif: clock-controller@0x105b {
>> + compatible = "samsung,exynos5433-cmu-mif";
>> + reg = <0x105b 0x100c>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + cmu_peric: clock-controller@0x14c8 {
>> + compatible = "samsung,exynos5433-cmu-peric";
>> + reg = <0x14c8 0x0b08>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + cmu_peris: clock-controller@0x1004 {
>> + compatible = "samsung,exynos5433-cmu-peris";
>> + reg = <0x1004 0x0b20>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + cmu_fsys: clock-controller@0x156e {
>> + compatible = "samsung,exynos5433-cmu-fsys";
>> + reg = <0x156e 0x0b04>;
>> + #clock-cells = <1>;
>> + };
>
> What are the reasons to split the whole clock controller into separate
> device nodes with different compatible strings like this? I doubt drivers
> associated with each of those compatible strings could be ever reused on
> different Exynos SoCs.
Well, they are separate IP blocks, so this is how they should be
represented in DT and IMHO using different compatible strings is a bit
cleaner than relying on aliases to get instance index.
Plus we probably want to learn from mistakes done when designing
Exynos4x12 clock bindings, which prevent us from fixing the issue of
ISP power domain, in which the ISP CMU is located. AFAICS, Exynos5433
clock tree is split between several such "ISP CMUs".
>
> There are hardware dependencies between these clock domains, which are
> not currently modelled in DT with your binding. IOW, there is currently
> no way to ensure proper registration order of the CMUs (clock domains).
> This may be important in some cases.
>
> To address this we could either add clocks/clock-names properties in
> respective CMU device nodes, pointing to any clocks in other CMU(s)
which I believe is the proper way of doing things, which lets us
preserve the correct representation of separate CMUs in DT.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
[PATCH] rtc: (x1205) use sign_extend32() for sign extension
Signed-off-by: Martin Kepplinger --- Despite it's name, sign_extend32() is safe to use for 8 bit types too. (see https://lkml.org/lkml/2015/1/18/289 if interested) drivers/rtc/rtc-x1205.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-x1205.c b/drivers/rtc/rtc-x1205.c index b1de58e..5638b7b 100644 --- a/drivers/rtc/rtc-x1205.c +++ b/drivers/rtc/rtc-x1205.c @@ -22,6 +22,7 @@ #include #include #include +#include #define DRV_VERSION "1.0.8" @@ -366,8 +367,7 @@ static int x1205_get_atrim(struct i2c_client *client, int *trim) * perform sign extension. The formula is * Catr = (atr * 0.25pF) + 11.00pF. */ - if (atr & 0x20) - atr |= 0xC0; + atr = sign_extend32(atr, 5); dev_dbg(>dev, "%s: raw atr=%x (%d)\n", __func__, atr, atr); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: sun4i: Add initial dts for Gemei G9 tablet
On Sat, 2015-01-24 at 15:39 +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jan 23, 2015 at 11:59:35PM +0200, Priit Laes wrote:
> >
> > On Fri, 2015-01-23 at 22:22 +0100, Maxime Ripard wrote:
> > > On Fri, Jan 23, 2015 at 10:36:49PM +0200, Priit Laes wrote:
> > > > Gemei G9 is an A10 based tablet, with 1G RAM, 16G NAND,
> > > > 1024x768 IPS LCD display, stereo speakers, 1.3MP front camera
> > > > and 5 MP
> > > > rear camera, 8000mAh battery, GT901 2+1 touchscreen, Bosch
> > > > BMA250 accelerometer and RTL8188CUS USB wifi. It also has
> > > > MicroSD slot, miniHDMI, 1 x MicroUSB OTG port and 1 x MicroUSB
> > > > host port and 3.5mm headphone jack.
> > > > More details are available at: http://linux-sunxi.org/Gemei_G9
> > > >
> > [..]
> > > >
> > > > +/ {
> > > > +model = "Gemei G9 Tablet";
> > > > +compatible = "gemei,g9", "allwinner,sun4i-a10";
> > > > +};
> > > > +
> > > > +/*
> > > > + * http://linux-sunxi.org/Gemei_G9
> > >
> > > Please don't put URL in the DT. This is very likely to change in
> > > the future, and won't be valid anymore.
> >
> > OK! The URL in commit message is ok to stay?
>
> Yeah, I'm not that fond of it, but it's not that important either.
>
> > > > + {
> > > > +pinctrl-names = "default";
> > > > +pinctrl-0 = <_pins_a>;
> > > > +status = "okay";
> > > > +
> > > > +/* Accelerometer */
> > > > +bma250@18 {
> > > > +compatible = "bosch,bma250";
> > > > +reg = <0x18>;
> > >
> > > Is there a driver for this? It looks weird that it doesn't need
> > > more properties than that.
> >
> > Yes, it's supported by drivers/iio/accel/bma180.c though I have to
> > admit that this name is a bit misleading. (bosch-bma.c would
> > better, I guess).
> >
> > And I was a bit surprised that it worked out of the box too, but
> > the device was present under /sys and I was able to read x, y, z
> > and temperature values.
>
> Cool :)
>
> There's no interrupt wired to it then?
Well, FEX file contained this:
[gsensor_para]
gsensor_used = 1
gsensor_name = "bma250"
gsensor_twi_addr = 0x18
gsensor_twi_id = 1
gsensor_int1 = port:PH00<6><1>
gsensor_int2 = port:PI10<6><1>
And according to the datasheet, this chip (bma250) has two interrupt
pins.
Now, the bma180/250 driver works without IRQ-s, but it currently only
supports single interrupt pin. Therefore I should at least add a
comment about these pins and revisit this issue later.
/* TODO: check whether following interrupt pins are connected:
* - int1 - PH00
* - int2 - PI10
*/
Päikest,
Priit Laes :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: oxu210hp-hcd: Fix deadlock in oxu_qh_alloc()
On Sat, 24 Jan 2015, Alexey Khoroshilov wrote:
> oxu_qh_alloc() acquires oxu->mem_lock spinlock, finds free qh slot
> and calls ehci_qtd_alloc() to initialize qh->dummy, but
> ehci_qtd_alloc() acquires oxu->mem_lock as well.
> That means an unavoidable deadlock in oxu_qh_alloc().
>
> The patch fixes the issue by introduction of unlocked version
> of ehci_qtd_alloc().
This deadlock would affect anybody the moment they plugged a USB device
into one of these controllers, right?
Which means nobody can possibly be using them under Linux. So wouldn't
it be better to remove the driver entirely?
Alan Stern
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> ---
> drivers/usb/host/oxu210hp-hcd.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
> index 036924e640f5..15d4cf2c35cd 100644
> --- a/drivers/usb/host/oxu210hp-hcd.c
> +++ b/drivers/usb/host/oxu210hp-hcd.c
> @@ -573,13 +573,11 @@ static inline void oxu_qtd_free(struct oxu_hcd *oxu,
> struct ehci_qtd *qtd)
> spin_unlock(>mem_lock);
> }
>
> -static struct ehci_qtd *ehci_qtd_alloc(struct oxu_hcd *oxu)
> +static struct ehci_qtd *ehci_qtd_alloc_unlocked(struct oxu_hcd *oxu)
> {
> int i;
> struct ehci_qtd *qtd = NULL;
>
> - spin_lock(>mem_lock);
> -
> for (i = 0; i < QTD_NUM; i++)
> if (!oxu->qtd_used[i])
> break;
> @@ -598,6 +596,17 @@ static struct ehci_qtd *ehci_qtd_alloc(struct oxu_hcd
> *oxu)
> oxu->qtd_used[i] = 1;
> }
>
> + return qtd;
> +}
> +
> +static struct ehci_qtd *ehci_qtd_alloc(struct oxu_hcd *oxu)
> +{
> + struct ehci_qtd *qtd;
> +
> + spin_lock(>mem_lock);
> +
> + qtd = ehci_qtd_alloc_unlocked(oxu);
> +
> spin_unlock(>mem_lock);
>
> return qtd;
> @@ -651,7 +660,7 @@ static struct ehci_qh *oxu_qh_alloc(struct oxu_hcd *oxu)
> INIT_LIST_HEAD(>qtd_list);
>
> /* dummy td enables safe urb queuing */
> - qh->dummy = ehci_qtd_alloc(oxu);
> + qh->dummy = ehci_qtd_alloc_unlocked(oxu);
> if (qh->dummy == NULL) {
> oxu_dbg(oxu, "no dummy td\n");
> oxu->qh_used[i] = 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: [RFC PATCH 2/2] fbcon: expose cursor blink interval via sysfs
On Sat, Jan 24, 2015 at 2:19 AM, Scot Doyle wrote:
> +static ssize_t store_cursor_blink_ms(struct device *device,
> +struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
...
> + unsigned long ms;
...
> + if (!kstrtoul(buf, 0, )) {
kstrtos16()?
> + ms = min_t(unsigned long, ms, SHRT_MAX);
> + ops->blink_jiffies = max_t(int, msecs_to_jiffies(ms), 1);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: Retry port status check on resume to work around RH bugs
On Fri, 23 Jan 2015, Julius Werner wrote:
> The EHCI controller on the RK3288 SoC is violating basic parts of the
> USB spec and thereby unable to properly resume a suspended port. It does
> not start SOF generation within 3ms of finishing resume signaling, so
> the attached device will drop off the bus again. This is a particular
> problem with runtime PM, where accessing the device will trigger a
> resume that immediately makes it unavailabe (and reenumerate with a new
> handle).
>
> Thankfully, the persist feature is generally able to work around stuff
> like that. Unfortunately, it doesn't quite work in this particular case
> because the controller will turn off the CurrentConnectStatus bit for an
> instant while the device is reconnecting, which causes the kernel to
> conclude that it permanently disappeared. This patch adds a tiny retry
> mechanism to the core port resume code which will catch this case and
> shouldn't have any notable impact on other controllers.
>
> Signed-off-by: Julius Werner
> ---
> drivers/usb/core/hub.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index aeb50bb..d1d0a66 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2896,10 +2896,12 @@ static int port_is_suspended(struct usb_hub *hub,
> unsigned portstatus)
> */
> static int check_port_resume_type(struct usb_device *udev,
> struct usb_hub *hub, int port1,
> - int status, unsigned portchange, unsigned portstatus)
> + int status, u16 portchange, u16 portstatus)
> {
> struct usb_port *port_dev = hub->ports[port1 - 1];
> + int retries = 3;
>
> +retry:
> /* Is a warm reset needed to recover the connection? */
> if (status == 0 && udev->reset_resume
> && hub_port_warm_reset_required(hub, port1, portstatus)) {
> @@ -2909,8 +2911,15 @@ static int check_port_resume_type(struct usb_device
> *udev,
> else if (status || port_is_suspended(hub, portstatus) ||
> !port_is_power_on(hub, portstatus) ||
> !(portstatus & USB_PORT_STAT_CONNECTION)) {
> - if (status >= 0)
> + if (status >= 0) {
> + if (retries--) {
> + udelay(200);
You should use a sleeping function call, not a delay.
> + status = hub_port_status(hub, port1,
> + , );
> + goto retry;
> + }
> status = -ENODEV;
> + }
> }
>
> /* Can't do a normal resume if the port isn't enabled,
Otherwise this is okay.
Alan Stern
--
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] mm: incorporate read-only pages into transparent huge pages
This patch aims to improve THP collapse rates, by allowing
THP collapse in the presence of read-only ptes, like those
left in place by do_swap_page after a read fault.
Currently THP can collapse 4kB pages into a THP when
there are up to khugepaged_max_ptes_none pte_none ptes
in a 2MB range. This patch applies the same limit for
read-only ptes.
The patch was tested with a test program that allocates
800MB of memory, writes to it, and then sleeps. I force
the system to swap out all but 190MB of the program by
touching other memory. Afterwards, the test program does
a mix of reads and writes to its memory, and the memory
gets swapped back in.
Without the patch, only the memory that did not get
swapped out remained in THPs, which corresponds to 24% of
the memory of the program. The percentage did not increase
over time.
With this patch, after 5 minutes of waiting khugepaged had
collapsed 48% of the program's memory back into THPs.
Signed-off-by: Ebru Akagunduz
Reviewed-by: Rik van Riel
Acked-by: Vlastimil Babka
---
Changes in v2:
- Remove extra code indent
- Add fast path optimistic check to
__collapse_huge_page_isolate()
- Add comment line for check condition of page_count()
- Move check condition of page_count() below to trylock_page()
I've written down test results:
With the patch:
After swapped out:
cat /proc/pid/smaps:
Anonymous: 42804 kB
AnonHugePages: 38912 kB
Swap: 757200 kB
Fraction: 90,90
cat /proc/meminfo:
AnonPages: 1843956 kB
AnonHugePages: 1712128 kB
Fraction: 92,85
After swapped in:
In a few seconds:
cat /proc/pid/smaps:
Anonymous: 84 kB
AnonHugePages: 104448 kB
Swap: 0 kB
Fraction: 13,05
cat /proc/meminfo:
AnonPages: 2605728 kB
AnonHugePages: 1777664 kB
Fraction: 68,22
In 5 minutes:
cat /proc/pid/smaps
Anonymous: 84 kB
AnonHugePages: 389120 kB
Swap: 0 kB
Fraction: 48,63
cat /proc/meminfo:
AnonPages: 2607824 kB
AnonHugePages: 2041856 kB
Fraction: 78,29
Without the patch:
After swapped out:
cat /proc/pid/smaps:
Anonymous: 190660 kB
AnonHugePages: 190464 kB
Swap: 609344 kB
Fraction: 99,89
cat /proc/meminfo:
AnonPages: 1740456 kB
AnonHugePages: 1667072 kB
Fraction: 95,78
After swapped in:
cat /proc/pid/smaps:
Anonymous: 84 kB
AnonHugePages: 190464 kB
Swap: 0 kB
Fraction: 23,80
cat /proc/meminfo:
AnonPages: 2350032 kB
AnonHugePages: 1667072 kB
Fraction: 70,93
I waited 10 minutes the fractions
did not change without the patch.
mm/huge_memory.c | 48 +++-
1 file changed, 39 insertions(+), 9 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 817a875..5e3e9b9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2148,7 +2148,7 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
{
struct page *page;
pte_t *_pte;
- int referenced = 0, none = 0;
+ int referenced = 0, none = 0, ro = 0;
for (_pte = pte; _pte < pte+HPAGE_PMD_NR;
_pte++, address += PAGE_SIZE) {
pte_t pteval = *_pte;
@@ -2158,7 +2158,7 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
else
goto out;
}
- if (!pte_present(pteval) || !pte_write(pteval))
+ if (!pte_present(pteval))
goto out;
page = vm_normal_page(vma, address, pteval);
if (unlikely(!page))
@@ -2168,9 +2168,6 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
VM_BUG_ON_PAGE(!PageAnon(page), page);
VM_BUG_ON_PAGE(!PageSwapBacked(page), page);
- /* cannot use mapcount: can't collapse if there's a gup pin */
- if (page_count(page) != 1)
- goto out;
/*
* We can do it before isolate_lru_page because the
* page can't be freed from under us. NOTE: PG_lock
@@ -2179,6 +2176,31 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
*/
if (!trylock_page(page))
goto out;
+
+ /*
+* cannot use mapcount: can't collapse if there's a gup pin.
+* The page must only be referenced by the scanned process
+* and page swap cache.
+*/
+ if (page_count(page) != 1 + !!PageSwapCache(page)) {
+ unlock_page(page);
+ goto out;
+ }
+ if (!pte_write(pteval)) {
+ if (++ro > khugepaged_max_ptes_none) {
+ unlock_page(page);
+ goto out;
+ }
+ if (PageSwapCache(page) &&
Re: [PATCH v2 0/2] drm/rockchip: Optimization vop dpms control
Am Donnerstag, 22. Januar 2015, 18:29:55 schrieb Mark Yao: > drm dpms have many power modes, ON,OFF,SUSPEND,STANDBY, etc. > but vop only have enable/disable mode, maybe case such bug: > --> DRM_DPMS_ON: power on vop > --> DRM_DPMS_SUSPEND: power off vop > --> DRM_DPMS_OFF: already power off at SUSPEND, crash > so use a bool val is more suitable. > > another problem at vop_crtc_dpms: > vop_enable()->drm_vblank_on, drm_vblank_on may call vop > enable vblank. if it happen, vblank enable would failed, > then cause irq status error. because is_enabled value is set > after drm_vblank_on. This series, on a rk3288-firefly board with a sda7123 vga connector Tested-by: Heiko Stuebner Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/rockchip: vop: fix vop vsync/hsync polarity
Am Donnerstag, 22. Januar 2015, 11:15:02 schrieb Mark Yao: > Vop set wrong vsync/hsync polarity, it may cause some > display problem. known problem is that caused HDMI hdcp > authenticate failed, caused pixel offset with hdmi display. > the polarity description at RK3288 TRM doc: > dsp_vsync_pol > VSYNC polarity > 1'b0 : negative > 1'b1 : positive > dsp_hsync_pol > HSYNC polarity > 1'b0 : negative > 1'b1 : positive > > Signed-off-by: Mark Yao > --- on a rk3288-firefly board with a sda7123 vga connector Tested-by: Heiko Stuebner Heiko -- 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: perf not capturing stack traces
Em Fri, Jan 23, 2015 at 04:37:45PM -0600, Felipe Balbi escreveu: > On Fri, Jan 23, 2015 at 05:59:59PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jan 23, 2015 at 01:51:28PM -0600, Felipe Balbi escreveu: > > > I'm using v3.19-rc5 on an ARM Cortex A9 board. Unfortunately, perf is > > > not able to capture any stack traces even though I CONFIG_STACKTRACE, > > > CONFIG_FRAME_POINTER and CONFIG_ARM_UNWIND all enabled. > > > > > > I wonder if anybody else is facing similar issues. > > > > Did it work with a previous kernel? > > haven't checked with this board. First time I tried to use perf for > anything. And it is the first time I've heard about such a problem, not dealing with ARM myself, so I guess this is a case for looking if there was some previous kernel where this worked, then trying to bisect where the problem was introduced :-\ - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/4] MAINTAINERS: add entry for lubbock-cplds
Add entry Lubbock cplds driver into the pxa platform scope. Signed-off-by: Robert Jarzmik --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddb9ac8..8c6a49d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7681,6 +7681,7 @@ T:git git://github.com/hzhuang1/linux.git T: git git://github.com/rjarzmik/linux.git S: Maintained F: arch/arm/mach-pxa/ +F: drivers/mfd/lubbock.c F: drivers/pcmcia/pxa2xx* F: drivers/spi/spi-pxa2xx* F: drivers/usb/gadget/udc/pxa2* -- 2.1.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/
