Re: [PATCH v3 60/77] ncr5380: Implement new eh_abort_handler
On 12/22/2015 02:18 AM, Finn Thain wrote: Introduce a new eh_abort_handler implementation. This one attempts to follow all of the rules relating to EH handlers. There is still a known bug: during selection, a command becomes invisible to the EH handlers because it only appears in a pointer on the stack of a different thread. This bug is addressed in a subsequent patch. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 155 ++ drivers/scsi/atari_NCR5380.c | 157 ++- 2 files changed, 282 insertions(+), 30 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 59/77] ncr5380: Fix autosense bugs
On 12/22/2015 02:18 AM, Finn Thain wrote: NCR5380_information_transfer() may re-queue a command for autosense, after calling scsi_eh_prep_cmnd(). This creates several possibilities: 1. Reselection may intervene before the re-queued command gets processed. If the reconnected command then undergoes autosense, this causes the scsi_eh_save data from the previous command to be overwritten. 2. After NCR5380_information_transfer() calls scsi_eh_prep_cmnd(), a new REQUEST SENSE command may arrive. This would be queued ahead of any command already undergoing autosense, which means the scsi_eh_save data might be restored to the wrong command. 3. After NCR5380_information_transfer() calls scsi_eh_prep_cmnd(), eh_abort_handler() may abort the command. But the scsi_eh_save data is not discarded, which means the scsi_eh_save data might be incorrectly restored to the next REQUEST SENSE command issued. This patch adds a new autosense list so that commands that are re-queued because of a CHECK CONDITION result can be kept apart from the REQUEST SENSE commands that arrive via queuecommand. This patch also adds a function dedicated to dequeueing and preparing the next command for processing. By refactoring the main loop in this way, scsi_eh_save takes place when an autosense command is dequeued rather than when re-queued. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 194 +++--- drivers/scsi/NCR5380.h |2 drivers/scsi/atari_NCR5380.c | 239 --- 3 files changed, 249 insertions(+), 186 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 58/77] ncr5380: Refactor command completion
On 12/22/2015 02:18 AM, Finn Thain wrote: Implement a 'complete_cmd' function to complete commands. This is needed by the following patch; the new function provides a site for the logic needed to correctly handle REQUEST SENSE commands. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 31 ++-- drivers/scsi/atari_NCR5380.c | 46 --- 2 files changed, 55 insertions(+), 22 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 57/77] ncr5380: Use standard list data structure
On 12/22/2015 02:18 AM, Finn Thain wrote: The NCR5380 drivers have a home-spun linked list implementation for scsi_cmnd structs that uses cmd->host_scribble as a 'next' pointer. Adopt the standard list_head data structure and list operations instead. Remove the eh_abort_handler rather than convert it. Doing the conversion would only be churn because the existing EH handlers don't work and get replaced in a subsequent patch. Signed-off-by: Finn Thain --- Changed since v2: - Fix NULL pointer dereference in NCR5380_reselect() when SUPPORT_TAGS is enabled in the atari_NCR5380.c core driver. Well, using ->host_scribble allows for an easy check on the midlayer if a command has been properly released by the LLDD. But that's just a side-note. Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wlcore: consolidate kmalloc + memset 0 into kzalloc
Hi Nicholas,
On Tue, Dec 22, 2015 at 6:29 PM, Nicholas Mc Guire wrote:
> On Tue, Dec 22, 2015 at 09:56:10AM +1100, Julian Calaby wrote:
>> Hi,
>>
>> On Tue, Dec 22, 2015 at 3:47 AM, Nicholas Mc Guire wrote:
>> > This is an API consolidation only. The use of kmalloc + memset to 0
>> > is equivalent to kzalloc.
>> >
>> > Signed-off-by: Nicholas Mc Guire
>> > ---
>> >
>> > Found by coccinelle script (relaxed version of
>> > scripts/coccinelle/api/alloc/kzalloc-simple.cocci)
>> >
>> > Patch was compile tested with: x86_64_defconfig +
>> > CONFIG_WL12XX=m (implies CONFIG_WLCORE=m)
>> >
>> > Patch is against linux-next (localversion-next is -next-20151221)
>> >
>> > drivers/net/wireless/ti/wlcore/main.c | 3 +--
>> > 1 file changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/ti/wlcore/main.c
>> > b/drivers/net/wireless/ti/wlcore/main.c
>> > index ec7f6af..dfc49bf 100644
>> > --- a/drivers/net/wireless/ti/wlcore/main.c
>> > +++ b/drivers/net/wireless/ti/wlcore/main.c
>> > @@ -838,7 +838,7 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
>> >
>> > wl1271_info("Reading FW panic log");
>> >
>> > - block = kmalloc(wl->fw_mem_block_size, GFP_KERNEL);
>> > + block = kzalloc(wl->fw_mem_block_size, GFP_KERNEL);
>> > if (!block)
>> > return;
>> >
>> > @@ -885,7 +885,6 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
>> > goto out;
>> > }
>> > - memset(block, 0, wl->fw_mem_block_size);
>>
>> I don't think you can't remove this line. It appears that the loop
>> this is part of resets block to be all zero, reads a chunk of data in,
>> then operates on it. I'm guessing that the code after the following
>> line expects that there isn't any data left over from previous runs
>> through the loop.
>>
> the rational for this being ok is thta the copy operation into block is:
> ret = wlcore_read_hwaddr(wl, addr, block,
> wl->fw_mem_block_size, false);
>
> this will end up in the .read methods where block should be completely
> overwritten (length == full block size), so within the loop if successful
> this should be correct - if not successful it would "goto out" witout
> using the content of block.
>
> Am I overlooking something here ?
It's quite possible I am. I didn't look at the implementation of
wlcore_read_hwaddr() so I'm only guessing that it could do partial
reads.
That said, if it does overwrite the entire buffer each time, then
there's no need to use kzalloc() to allocate the buffer in the first
place.
Either way, it needs a review from someone more familiar with the code.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 56/77] ncr5380: Remove redundant volatile qualifiers
On 12/22/2015 02:18 AM, Finn Thain wrote: The hostdata struct is now protected by a spin lock so the volatile qualifiers are redundant. Remove them. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.h | 12 ++-- drivers/scsi/atari_NCR5380.c |2 +- 2 files changed, 7 insertions(+), 7 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] soc: mediatek: PMIC wrap: Clear the vldclr if state machine is stay on FSM_VLDCLR state.
Sometimes PMIC is too busy to send data in time to cause pmic wrap timeout,
because pmic wrap is waiting for FSM_VLDCLR after finishing WACS2_CMD. It
just return error when issue happened, so the state machine will stay on
FSM_VLDCLR state when data send back later by PMIC and timeout again in next
time because pmic wrap waiting for FSM_IDLE state at the begining of the
read/write function.
Clear the vldclr when timeout if state machine is stay on FSM_VLDCLR.
Signed-off-by: Henry Chen
---
drivers/soc/mediatek/mtk-pmic-wrap.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 105597a..ccd5337 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -443,10 +443,16 @@ static int pwrap_wait_for_state(struct pmic_wrapper *wrp,
static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
{
int ret;
+ u32 val;
ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
- if (ret)
+ if (ret) {
+ /* Clear vldclr bit if state is on the WACS_FSM_WFVLDCLR */
+ val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+ if (PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR)
+ pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
return ret;
+ }
pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
PWRAP_WACS2_CMD);
@@ -457,10 +463,16 @@ static int pwrap_write(struct pmic_wrapper *wrp, u32 adr,
u32 wdata)
static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
{
int ret;
+ u32 val;
ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
- if (ret)
+ if (ret) {
+ /* Clear vldclr bit if state is on the WACS_FSM_WFVLDCLR */
+ val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+ if (PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR)
+ pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
return ret;
+ }
pwrap_writel(wrp, (adr >> 1) << 16, PWRAP_WACS2_CMD);
--
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 v3 55/77] ncr5380: Remove LIST and REMOVE macros
On 12/22/2015 02:18 AM, Finn Thain wrote: Printing command pointers can be useful when debugging queues. Other than that, the LIST and REMOVE macros are just clutter. These macros are redundant now that NDEBUG_QUEUES causes pointers to be printed, so remove them. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 19 --- drivers/scsi/atari_NCR5380.c | 32 2 files changed, 51 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 54/77] ncr5380: Use dsprintk() for queue debugging
On 12/22/2015 02:18 AM, Finn Thain wrote: Print the command pointers in the log messages for debugging queue data structures. The LIST and REMOVE macros can then be removed. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 36 drivers/scsi/atari_NCR5380.c | 43 +++ 2 files changed, 47 insertions(+), 32 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration
Hi Javier, On 21/12/15 20:26, Javier Martinez Canillas wrote: > The omapfb is failing to build in -next due missing declarations for > dss_feat_get_supported_displays() and dss_feat_get_supported_outputs(): > > CC [M] drivers/video/fbdev/omap2//omapfb/dss/dss.o > drivers/video/fbdev/omap2//omapfb/dss/dss.c: In function 'dss_save_context': > drivers/video/fbdev/omap2//omapfb/dss/dss.c:144:2: error: implicit > declaration of function 'dss_feat_get_supported_displays' > [-Werror=implicit-function-declaration] > > Add the declaration for these functions in the dss_features.h header > file to fix this compile error. > > Also, remove the functions export since are not used outside the driver. Thanks! Yep, I messed that up. I thought I had tested it, but apparently I only tested the final for-next only for omapdrm, which does compile and work. omapdss.h is the the only file still shared between omapdrm and omapfb after the copy-omapdss-series (I'll work on omapdss.h later), and of course there was a change to omapdss.h which broke the build. So I rebased the copy-omapdss-series on top of the rest of the omapdss patches, and updated the "omapfb: copy omapdss & displays for omapfb" to make a fresh copy of omapdss for omapfb. I think it's better to update the series, rather than applying fixes for already confusing series. I've pushed new version to my for-next branch. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 53/77] ncr5380: Use shost_priv helper
On 12/22/2015 02:18 AM, Finn Thain wrote: Make use of the shost_priv() helper. Remove HOSTDATA and SETUP_HOSTDATA macros because they harm readability. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 23 ++- drivers/scsi/atari_NCR5380.c | 20 +++- 2 files changed, 17 insertions(+), 26 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 52/77] ncr5380: Remove H_NO macro and introduce dsprintk
On 12/22/2015 02:18 AM, Finn Thain wrote: Replace all H_NO and some HOSTNO macros (both peculiar to atari_NCR5380.c) with a new dsprintk macro that's more useful and more consistent. The new macro avoids a lot of boilerplate in new code in subsequent patches. Keep NCR5380.c in sync. Remaining HOSTNO macros are removed as side-effects of subsequent patches. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |9 --- drivers/scsi/NCR5380.h |5 +++ drivers/scsi/atari_NCR5380.c | 54 +-- 3 files changed, 38 insertions(+), 30 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 51/77] ncr5380: Remove command list debug code
On 12/22/2015 02:18 AM, Finn Thain wrote: Some NCR5380 hosts offer a .show_info method to access the contents of the various command list data structures from a procfs file. When NDEBUG is set, the same information is sent to the console during EH. The two core drivers, atari_NCR5380.c and NCR5380.c differ here. Because it is just for debugging, the easiest way to fix the discrepancy is simply remove this code. The only remaining users of NCR5380_show_info() and NCR5380_write_info() are drivers that define PSEUDO_DMA. The others have no use for the .show_info method, so don't initialize it. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 70 ++-- drivers/scsi/arm/oak.c |2 drivers/scsi/atari_NCR5380.c | 94 +-- drivers/scsi/atari_scsi.c|2 drivers/scsi/g_NCR5380.c |1 drivers/scsi/sun3_scsi.c |2 6 files changed, 9 insertions(+), 162 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 50/77] ncr5380: Change instance->host_lock to hostdata->lock
On 12/22/2015 02:18 AM, Finn Thain wrote: NCR5380.c presently uses the instance->host_lock spin lock. Convert this to a new spin lock that protects the NCR5380_hostdata struct. atari_NCR5380.c previously used local_irq_save/restore() rather than a spin lock. Convert this to hostdata->lock in irq mode. For SMP platforms, the interrupt handler now also acquires the spin lock. This brings all locking in the two core drivers into agreement. Adding this locking also means that a bunch of volatile qualifiers can be removed from the members of the NCR5380_hostdata struct. This is done in a subsequent patch. Proper locking will allow the abort handler to locate a command being aborted. This is presently impossible if the abort handler is invoked when the command has been moved from a queue to a pointer on the stack. (If eh_abort_handler can't determine whether a command has been completed or is still being processed then it can't decide whether to return success or failure.) The hostdata spin lock is now held when calling NCR5380_select() and NCR5380_information_transfer(). Where possible, the lock is dropped for polling and PIO transfers. Clean up the now-redundant SELECT_ENABLE_REG writes, that used to provide limited mutual exclusion between information_transfer() and reselect(). Accessing hostdata->connected without data races means taking the lock; cleanup these accesses. The new spin lock falls away for m68k and other UP builds, so this should have little impact there. In the SMP case the new lock should be uncontested even when the SCSI bus is contested. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 49/77] ncr5380: Remove redundant ICR_ARBITRATION_LOST test and eliminate FLAG_DTC3181E
On 12/22/2015 02:18 AM, Finn Thain wrote: Remove FLAG_DTC3181E. It was used to suppress a final Arbitration Lost (SEL asserted) test that isn't actually needed. The test was suppressed because it causes problems for DTC436 and DTC536 chips. It takes place after the host wins arbitration, so SEL has been asserted. These chips can't seem to tell whether it was the host or another bus device that did so. This questionable final test appears in a flow chart in an early NCR5380 datasheet. It was removed from later documents like the DP5380 datasheet. By the time this final test takes place, the driver has already tested the Arbitration Lost bit several times. The first test happens 3 us after BUS FREE (or longer due to register access delays). The protocol requires that a device stop signalling within 1.8 us after BUS FREE unless it won arbitration, in which case it must assert SEL, which is detected 1.2 us later by the first Arbitration Lost test. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 14 +- drivers/scsi/NCR5380.h |1 - drivers/scsi/atari_NCR5380.c |9 - drivers/scsi/dmx3191d.c |2 +- drivers/scsi/g_NCR5380.c |2 +- 5 files changed, 3 insertions(+), 25 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 48/77] atari_NCR5380: Fix queue_size limit
On 12/22/2015 02:18 AM, Finn Thain wrote: When a target reports a QUEUE_FULL condition it causes the driver to update the 'queue_size' limit with the number of currently allocated tags. At least, that's what's supposed to happen, according to the comments. Unfortunately the terms in the assignment are swapped. Fix this and cleanup some obsolete comments. Signed-off-by: Finn Thain --- drivers/scsi/atari_NCR5380.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 47/77] ncr5380: Fix and cleanup scsi_host_template initializers
On 12/22/2015 02:18 AM, Finn Thain wrote: Add missing .module initializer. Use distinct .proc_name values for the g_NCR5380 and g_NCR5380_mmio modules. Remove pointless CAN_QUEUE and CMD_PER_LUN override macros. Cleanup whitespace and code style. Signed-off-by: Finn Thain --- drivers/scsi/atari_scsi.c |2 +- drivers/scsi/dmx3191d.c |1 + drivers/scsi/dtc.c| 32 drivers/scsi/dtc.h|8 drivers/scsi/g_NCR5380.c | 26 +- drivers/scsi/g_NCR5380.h | 10 ++ drivers/scsi/mac_scsi.c | 28 ++-- drivers/scsi/pas16.c | 32 drivers/scsi/pas16.h |8 drivers/scsi/sun3_scsi.c |6 +++--- drivers/scsi/t128.c | 32 drivers/scsi/t128.h |8 12 files changed, 82 insertions(+), 111 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 46/77] ncr5380: Fix NDEBUG_NO_DATAOUT flag
On 12/22/2015 02:18 AM, Finn Thain wrote: NDEBUG_NO_DATAOUT should not disable DATA IN phases too. Fix this. (This bug has long been fixed in atari_NCR5380.c.) Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 45/77] ncr5380: Cleanup #include directives
On 12/22/2015 02:18 AM, Finn Thain wrote: Remove unused includes (stat.h, signal.h, proc_fs.h) and move includes needed by the core drivers into the common header (delay.h etc). Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |2 -- drivers/scsi/NCR5380.h |4 drivers/scsi/arm/cumana_1.c |4 drivers/scsi/arm/oak.c |2 -- drivers/scsi/atari_NCR5380.c |5 - drivers/scsi/atari_scsi.c|1 - drivers/scsi/dmx3191d.c |5 - drivers/scsi/dtc.c |4 +--- drivers/scsi/g_NCR5380.c |6 ++ drivers/scsi/mac_scsi.c |1 - drivers/scsi/pas16.c |4 drivers/scsi/t128.c |3 --- 12 files changed, 7 insertions(+), 34 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 44/77] ncr5380: Fix off-by-one bug in extended_msg[] bounds check
On 12/22/2015 02:18 AM, Finn Thain wrote: Fix the array bounds check when transferring an extended message from the target. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |3 ++- drivers/scsi/atari_NCR5380.c |4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 43/77] ncr5380: Standardize reselection handling
On 12/22/2015 02:18 AM, Finn Thain wrote: Bring the two NCR5380_reselect() implementations into agreement. Replace infinite loops in atari_NCR5380.c with timeouts, as per NCR5380.c. Remove 'abort' flag in NCR5380.c as per atari_NCR5380.c -- if reselection fails, there may be no MESSAGE IN phase so don't attempt data transfer. During selection, don't interfere with the chip registers after a reselection interrupt intervenes. Clean up some trivial issues with code style, comments and printk. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 115 +++ drivers/scsi/atari_NCR5380.c | 50 ++ 2 files changed, 93 insertions(+), 72 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next v3 3/8] watchdog: mei_wdt: implement MEI iAMT watchdog driver
On 12/21/2015 11:19 PM, Winkler, Tomas wrote: On 12/21/2015 03:17 PM, Tomas Winkler wrote: Create a driver with the generic watchdog interface for the MEI iAMT watchdog device. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- V2: The watchdog device is no longer dynamically allocated in separate structure V3: Revert back to dynamically allocated watchdog device wrapper Documentation/misc-devices/mei/mei.txt | 12 +- MAINTAINERS| 1 + drivers/watchdog/Kconfig | 15 + drivers/watchdog/Makefile | 1 + drivers/watchdog/mei_wdt.c | 481 + 5 files changed, 504 insertions(+), 6 deletions(-) create mode 100644 drivers/watchdog/mei_wdt.c diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc- devices/mei/mei.txt index 91c1fa34f48b..2b80a0cd621f 100644 --- a/Documentation/misc-devices/mei/mei.txt +++ b/Documentation/misc-devices/mei/mei.txt @@ -231,15 +231,15 @@ IT knows when a platform crashes even when there is a hard failure on the host. The Intel AMT Watchdog is composed of two parts: 1) Firmware feature - receives the heartbeats and sends an event when the heartbeats stop. - 2) Intel MEI driver - connects to the watchdog feature, configures the - watchdog and sends the heartbeats. + 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, + configures the watchdog and sends the heartbeats. -The Intel MEI driver uses the kernel watchdog API to configure the Intel AMT -Watchdog and to send heartbeats to it. The default timeout of the +The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure +the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the watchdog is 120 seconds. -If the Intel AMT Watchdog feature does not exist (i.e. the connection failed), -the Intel MEI driver will disable the sending of heartbeats. +If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate +on the me client bus and watchdog devices won't be exposed. Supported Chipsets diff --git a/MAINTAINERS b/MAINTAINERS index 9bff63cf326e..e655625c2c16 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5666,6 +5666,7 @@ S:Supported F: include/uapi/linux/mei.h F: include/linux/mei_cl_bus.h F: drivers/misc/mei/* +F: drivers/watchdog/mei_wdt.c F: Documentation/misc-devices/mei/* INTEL MIC DRIVERS (mic) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 1c427beffadd..8ac51d69785c 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1154,6 +1154,21 @@ config SBC_EPX_C3_WATCHDOG To compile this driver as a module, choose M here: the module will be called sbc_epx_c3. +config INTEL_MEI_WDT + tristate "Intel MEI iAMT Watchdog" + depends on INTEL_MEI && X86 + select WATCHDOG_CORE + ---help--- + A device driver for the Intel MEI iAMT watchdog. + + The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. + Whenever the OS hangs or crashes, iAMT will send an event + to any subscriber to this event. The watchdog doesn't reset the + the platform. + + To compile this driver as a module, choose M here: + the module will be called mei_wdt. + # M32R Architecture # M68K Architecture diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 53d4827ddfe1..9069c9dd8aa8 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -123,6 +123,7 @@ obj-$(CONFIG_MACHZ_WDT) += machzwd.o obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o +obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o # M32R Architecture diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c new file mode 100644 index ..5b28a1e95ac1 --- /dev/null +++ b/drivers/watchdog/mei_wdt.c @@ -0,0 +1,481 @@ +/* + * Intel Management Engine Interface (Intel MEI) Linux driver + * Copyright (c) 2015, Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include +#include +#include +#include + +#include +#include + +/* + * iAMT Watchdog Device + */ +#define INTEL_AMT_WATCHDOG_ID "iamt_wdt" + +#define MEI_WDT_DEFAULT_TIMEOUT 120 /* seconds */ +#define MEI_WDT_MIN_TIMEOUT 120 /* seconds */ +#define
Re: [PATCH v3 41/77] ncr5380: Replace redundant flags with FLAG_NO_DMA_FIXUP
On 12/22/2015 02:18 AM, Finn Thain wrote: The flags DMA_WORKS_RIGHT, FLAG_NCR53C400 and FLAG_HAS_LAST_BYTE_SENT all mean the same thing, i.e. the chip is not a 538[01]. (More recent devices such as the 53C80 have a 'Last Byte Sent' bit in the Target Command Register as well as other fixes for End-of-DMA errata.) These flags have no additional meanings since previous cleanup patches eliminated the NCR53C400 macro, moved g_NCR5380-specific code out of the core driver and standardized interrupt handling. Use the FLAG_NO_DMA_FIXUP flag to suppress End-of-DMA errata workarounds, for those cards and drivers that make use of the TCR_LAST_BYTE_SENT bit. Remove the old flags. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 68 +++ drivers/scsi/NCR5380.h |4 -- drivers/scsi/dtc.c |4 -- drivers/scsi/g_NCR5380.c |2 - 4 files changed, 25 insertions(+), 53 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 42/77] ncr5380: Replace READ_OVERRUNS macro with FLAG_NO_DMA_FIXUPS
On 12/22/2015 02:18 AM, Finn Thain wrote: The workarounds for chip errata appear twice, in slightly different forms. One is used when defined(REAL_DMA) || defined(REAL_DMA_POLL), the other when defined(PSEUDO_DMA). In the PDMA case, the workarounds have been made conditional on FLAG_NO_DMA_FIXUPS. Do the same for the DMA case, to eliminate the READ_OVERRUNS macro. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 22
On Tue, Dec 22, 2015 at 04:29:55PM +1100, Stephen Rothwell wrote: > Hi all, > > Changes since 20151221: cris allmodconfig fails with: ../block/partitions/ldm.c: In function 'ldm_partition': ../block/partitions/ldm.c:1567:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027 compiler is based on gcc 5.3.0, and I guess since cris defconfig built properly I have not messed up while building the cross_compiler. cris allmodconfig build log is at: https://travis-ci.org/sudipm-mukherjee/parport/jobs/98258283 regards sudip -- 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 40/77] ncr5380: Introduce NCR5380_poll_politely2
On 12/22/2015 02:18 AM, Finn Thain wrote: SCSI bus protocol sometimes requires monitoring two related conditions simultaneously. Enhance NCR5380_poll_politely() for this purpose, and put it to use in the arbitration algorithm. It will also find use in pseudo DMA. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 66 --- drivers/scsi/atari_NCR5380.c | 62 2 files changed, 75 insertions(+), 53 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 39/77] ncr5380: Standardize interrupt handling
On 12/22/2015 02:18 AM, Finn Thain wrote:
Because interrupt handling is crucial to the core driver(s), all wrapper
drivers need to agree on this code. This patch removes discrepancies.
NCR5380_intr() in NCR5380.c has the following pointless loop that differs
from the code in atari_NCR5380.c.
done = 1;
do {
/* ... */
} while (!done);
The 'done' flag gets cleared when a reconnected command is to be processed
from the work queue. But in NCR5380.c, the flag is also used to cause the
interrupt conditions to be re-examined. Perhaps this was because
NCR5380_reselect() was expected to cause another interrupt, or perhaps
the remaining present interrupt conditions need to be handled after the
NCR5380_reselect() call?
Actually, both possibilities are bogus, as is the loop itself. It seems
have been overlooked in the hit-and-miss removal of scsi host instance
list iteration many years ago; see history/history.git commit 491447e1fcff
("[PATCH] next NCR5380 updates") and commit 69e1a9482e57 ("[PATCH] fix up
NCR5380 private data"). See also my earlier patch, "Always retry
arbitration and selection".
The datasheet says, "IRQ can be reset simply by reading the Reset
Parity/Interrupt Register". So don't treat the chip IRQ like a
level-triggered interrupt. Of the conditions that set the IRQ flag,
some are level-triggered and some are edge-triggered, which means IRQ
itself must be edge-triggered.
Some interrupt conditions are latched and some are not. Before clearing
the chip IRQ flag, clear all state that may cause it to be raised. That
means clearing the DMA Mode and Busy Monitor bits in the Mode Register
and clearing the host ID in the Select Enable register.
Also clean up some printk's and some comments. Keep atari_NCR5380.c and
NCR5380.c in agreement.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 187
+++
drivers/scsi/atari_NCR5380.c | 156 +--
drivers/scsi/dtc.c |8 -
drivers/scsi/g_NCR5380.c |2
4 files changed, 180 insertions(+), 173 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH 2/2] f2fs: speed up shrinking extent tree entries
On Tue, Dec 22, 2015 at 01:20:13PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> We should update _zombie_tree whenever removing unreferenced
> extent tree during shrinking:
> - f2fs_shrink_extent_tree
> if (!atomic_read(>refcount)) {
> ...
> atomic_dec(>total_ext_tree);
> atomic_dec(>total_zombie_tree);
> ...
Sure. :)
Thanks,
> }
>
> Other parts look good to me. :)
>
> Reviewed-by: Chao Yu
>
> Thanks,
>
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Tuesday, December 22, 2015 11:39 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Cc: Jaegeuk Kim
> > Subject: [f2fs-dev] [PATCH 2/2] f2fs: speed up shrinking extent tree entries
> >
> > If there is no candidates for shrinking slab entries, we don't need to
> > traverse
> > any trees at all.
> >
> > Signed-off-by: Jaegeuk Kim
> > ---
> > fs/f2fs/extent_cache.c | 12
> > fs/f2fs/f2fs.h | 1 +
> > fs/f2fs/shrinker.c | 2 +-
> > 3 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> > index 0e97d6af..32693af 100644
> > --- a/fs/f2fs/extent_cache.c
> > +++ b/fs/f2fs/extent_cache.c
> > @@ -71,6 +71,8 @@ static struct extent_tree *__grab_extent_tree(struct
> > inode *inode)
> > atomic_set(>refcount, 0);
> > et->count = 0;
> > atomic_inc(>total_ext_tree);
> > + } else {
> > + atomic_dec(>total_zombie_tree);
> > }
> > atomic_inc(>refcount);
> > up_write(>extent_tree_lock);
> > @@ -547,10 +549,14 @@ unsigned int f2fs_shrink_extent_tree(struct
> > f2fs_sb_info *sbi, int
> > nr_shrink)
> > unsigned int found;
> > unsigned int node_cnt = 0, tree_cnt = 0;
> > int remained;
> > + bool do_free = false;
> >
> > if (!test_opt(sbi, EXTENT_CACHE))
> > return 0;
> >
> > + if (!atomic_read(>total_zombie_tree))
> > + goto free_node;
> > +
> > if (!down_write_trylock(>extent_tree_lock))
> > goto out;
> >
> > @@ -580,6 +586,7 @@ unsigned int f2fs_shrink_extent_tree(struct
> > f2fs_sb_info *sbi, int
> > nr_shrink)
> > }
> > up_write(>extent_tree_lock);
> >
> > +free_node:
> > /* 2. remove LRU extent entries */
> > if (!down_write_trylock(>extent_tree_lock))
> > goto out;
> > @@ -591,9 +598,13 @@ unsigned int f2fs_shrink_extent_tree(struct
> > f2fs_sb_info *sbi, int
> > nr_shrink)
> > if (!remained--)
> > break;
> > list_del_init(>list);
> > + do_free = true;
> > }
> > spin_unlock(>extent_lock);
> >
> > + if (do_free == false)
> > + goto unlock_out;
> > +
> > /*
> > * reset ino for searching victims from beginning of global extent tree.
> > */
> > @@ -651,6 +662,7 @@ void f2fs_destroy_extent_tree(struct inode *inode)
> >
> > if (inode->i_nlink && !is_bad_inode(inode) && et->count) {
> > atomic_dec(>refcount);
> > + atomic_dec(>total_zombie_tree);
> > return;
> > }
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index a7f6191..90fb970 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -763,6 +763,7 @@ struct f2fs_sb_info {
> > struct list_head extent_list; /* lru list for shrinker */
> > spinlock_t extent_lock; /* locking extent lru list */
> > atomic_t total_ext_tree;/* extent tree count */
> > + atomic_t total_zombie_tree; /* extent zombie tree count */
> > atomic_t total_ext_node;/* extent info count */
> >
> > /* basic filesystem units */
> > diff --git a/fs/f2fs/shrinker.c b/fs/f2fs/shrinker.c
> > index a11e099..93606f2 100644
> > --- a/fs/f2fs/shrinker.c
> > +++ b/fs/f2fs/shrinker.c
> > @@ -32,7 +32,7 @@ static unsigned long __count_free_nids(struct
> > f2fs_sb_info *sbi)
> >
> > static unsigned long __count_extent_cache(struct f2fs_sb_info *sbi)
> > {
> > - return atomic_read(>total_ext_tree) +
> > + return atomic_read(>total_zombie_tree) +
> > atomic_read(>total_ext_node);
> > }
> >
> > --
> > 2.5.4 (Apple Git-61)
> >
> >
> > --
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
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 38/77] ncr5380: Remove UNSAFE macro
On 12/22/2015 02:18 AM, Finn Thain wrote: Configuring core drivers using macros like this one prevents re-unifying the core driver forks, and prevents implementing the core driver as a library or a platform driver. The UNSAFE macro in particular is a poor workaround for the problem of interrupt latency. Releasing the locks complicates things because then we would have to handle the possibility of EH handler invocation during a PDMA transfer. The comments say that instead of using this macro, "you're going to be better off twiddling with transfersize". I agree. Remove this stuff. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH 1/2] f2fs: use atomic variable for total_extent_tree
On Tue, Dec 22, 2015 at 01:28:09PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Tuesday, December 22, 2015 11:39 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Cc: Jaegeuk Kim
> > Subject: [f2fs-dev] [PATCH 1/2] f2fs: use atomic variable for
> > total_extent_tree
> >
> > It would be better to use atomic variable for total_extent_tree.
>
> total_extent_tree was protected by extent_tree_lock semaphore, so intention
> here
> is to make related calculation in available_free_memory or
> update_general_status
> more accurate, right?
Moreover, another major thing is to specify it is atomic along with other extent
counts.
Thanks,
>
> Thanks,
>
> >
> > Signed-off-by: Jaegeuk Kim
> > ---
> > fs/f2fs/debug.c| 5 +++--
> > fs/f2fs/extent_cache.c | 8
> > fs/f2fs/f2fs.h | 2 +-
> > fs/f2fs/node.c | 3 ++-
> > fs/f2fs/shrinker.c | 3 ++-
> > 5 files changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> > index bb307e6..ed5dfcc 100644
> > --- a/fs/f2fs/debug.c
> > +++ b/fs/f2fs/debug.c
> > @@ -38,7 +38,7 @@ static void update_general_status(struct f2fs_sb_info
> > *sbi)
> > si->hit_rbtree = atomic64_read(>read_hit_rbtree);
> > si->hit_total = si->hit_largest + si->hit_cached + si->hit_rbtree;
> > si->total_ext = atomic64_read(>total_hit_ext);
> > - si->ext_tree = sbi->total_ext_tree;
> > + si->ext_tree = atomic_read(>total_ext_tree);
> > si->ext_node = atomic_read(>total_ext_node);
> > si->ndirty_node = get_pages(sbi, F2FS_DIRTY_NODES);
> > si->ndirty_dent = get_pages(sbi, F2FS_DIRTY_DENTS);
> > @@ -193,7 +193,8 @@ get_cache:
> > si->cache_mem += si->inmem_pages * sizeof(struct inmem_pages);
> > for (i = 0; i <= UPDATE_INO; i++)
> > si->cache_mem += sbi->im[i].ino_num * sizeof(struct ino_entry);
> > - si->cache_mem += sbi->total_ext_tree * sizeof(struct extent_tree);
> > + si->cache_mem += atomic_read(>total_ext_tree) *
> > + sizeof(struct extent_tree);
> > si->cache_mem += atomic_read(>total_ext_node) *
> > sizeof(struct extent_node);
> >
> > diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> > index e86e9f1e..0e97d6af 100644
> > --- a/fs/f2fs/extent_cache.c
> > +++ b/fs/f2fs/extent_cache.c
> > @@ -70,7 +70,7 @@ static struct extent_tree *__grab_extent_tree(struct
> > inode *inode)
> > rwlock_init(>lock);
> > atomic_set(>refcount, 0);
> > et->count = 0;
> > - sbi->total_ext_tree++;
> > + atomic_inc(>total_ext_tree);
> > }
> > atomic_inc(>refcount);
> > up_write(>extent_tree_lock);
> > @@ -570,7 +570,7 @@ unsigned int f2fs_shrink_extent_tree(struct
> > f2fs_sb_info *sbi, int
> > nr_shrink)
> >
> > radix_tree_delete(root, et->ino);
> > kmem_cache_free(extent_tree_slab, et);
> > - sbi->total_ext_tree--;
> > + atomic_dec(>total_ext_tree);
> > tree_cnt++;
> >
> > if (node_cnt + tree_cnt >= nr_shrink)
> > @@ -663,7 +663,7 @@ void f2fs_destroy_extent_tree(struct inode *inode)
> > f2fs_bug_on(sbi, atomic_read(>refcount) || et->count);
> > radix_tree_delete(>extent_tree_root, inode->i_ino);
> > kmem_cache_free(extent_tree_slab, et);
> > - sbi->total_ext_tree--;
> > + atomic_dec(>total_ext_tree);
> > up_write(>extent_tree_lock);
> >
> > F2FS_I(inode)->extent_tree = NULL;
> > @@ -715,7 +715,7 @@ void init_extent_cache_info(struct f2fs_sb_info *sbi)
> > init_rwsem(>extent_tree_lock);
> > INIT_LIST_HEAD(>extent_list);
> > spin_lock_init(>extent_lock);
> > - sbi->total_ext_tree = 0;
> > + atomic_set(>total_ext_tree, 0);
> > atomic_set(>total_ext_node, 0);
> > }
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 19beabe..a7f6191 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -762,7 +762,7 @@ struct f2fs_sb_info {
> > struct rw_semaphore extent_tree_lock; /* locking extent radix tree */
> > struct list_head extent_list; /* lru list for shrinker */
> > spinlock_t extent_lock; /* locking extent lru list */
> > - int total_ext_tree; /* extent tree count */
> > + atomic_t total_ext_tree;/* extent tree count */
> > atomic_t total_ext_node;/* extent info count */
> >
> > /* basic filesystem units */
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index d842b19..6cc8ac7 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -65,7 +65,8 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int
> > type)
> >
Re: [PATCH v3 37/77] ncr5380: Standardize work queueing algorithm
On 12/22/2015 02:18 AM, Finn Thain wrote: The complex main_running/queue_main mechanism is peculiar to atari_NCR5380.c. It isn't SMP safe and offers little value given that the work queue already offers concurrency management. Remove this complexity to bring atari_NCR5380.c closer to NCR5380.c. It is not a good idea to call the information transfer state machine from queuecommand because, according to Documentation/scsi/scsi_mid_low_api.txt that could happen in soft irq context. Fix this. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.h |1 drivers/scsi/atari_NCR5380.c | 80 +++ 2 files changed, 6 insertions(+), 75 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 36/77] ncr5380: Use work_struct instead of delayed_work
On 12/22/2015 02:18 AM, Finn Thain wrote: Each host instance now has it's own work queue so the main() work item can sleep when necessary. That means we can use a simple work item rather than a delayed work item. This brings NCR5380.c closer to atari_NCR5380.c. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 12 +--- drivers/scsi/NCR5380.h |1 - 2 files changed, 5 insertions(+), 8 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 35/77] ncr5380: Dont wait for BUS FREE after disconnect
On 12/22/2015 02:18 AM, Finn Thain wrote: When there is a queued command and no connected command, NCR5380_select() is called and arbitration begins. The chip waits for BUS FREE once the MR_ARBITRATE bit in the mode register is enabled. That means there is no need to wait for BUS FREE after disconnecting. There is presently no polling for BUS FREE after sending an ABORT or other message that might lead to disconnection. It only happens after COMMAND COMPLETE or DISCONNECT messages, which seems inconsistent. Remove the polling for !BSY in the COMMAND COMPLETE and DISCONNECT cases. BTW, the comments say "avoid nasty timeouts" and perhaps BUS FREE polling was somehow helpful back in Linux v0.99.14u, when it was introduced. The relevant timeout is presently 1 second (for bus arbitration). Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |7 --- drivers/scsi/atari_NCR5380.c | 11 --- 2 files changed, 18 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wlcore: consolidate kmalloc + memset 0 into kzalloc
On Tue, Dec 22, 2015 at 09:56:10AM +1100, Julian Calaby wrote:
> Hi,
>
> On Tue, Dec 22, 2015 at 3:47 AM, Nicholas Mc Guire wrote:
> > This is an API consolidation only. The use of kmalloc + memset to 0
> > is equivalent to kzalloc.
> >
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > Found by coccinelle script (relaxed version of
> > scripts/coccinelle/api/alloc/kzalloc-simple.cocci)
> >
> > Patch was compile tested with: x86_64_defconfig +
> > CONFIG_WL12XX=m (implies CONFIG_WLCORE=m)
> >
> > Patch is against linux-next (localversion-next is -next-20151221)
> >
> > drivers/net/wireless/ti/wlcore/main.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ti/wlcore/main.c
> > b/drivers/net/wireless/ti/wlcore/main.c
> > index ec7f6af..dfc49bf 100644
> > --- a/drivers/net/wireless/ti/wlcore/main.c
> > +++ b/drivers/net/wireless/ti/wlcore/main.c
> > @@ -838,7 +838,7 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
> >
> > wl1271_info("Reading FW panic log");
> >
> > - block = kmalloc(wl->fw_mem_block_size, GFP_KERNEL);
> > + block = kzalloc(wl->fw_mem_block_size, GFP_KERNEL);
> > if (!block)
> > return;
> >
> > @@ -885,7 +885,6 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
> > goto out;
> > }
> > - memset(block, 0, wl->fw_mem_block_size);
>
> I don't think you can't remove this line. It appears that the loop
> this is part of resets block to be all zero, reads a chunk of data in,
> then operates on it. I'm guessing that the code after the following
> line expects that there isn't any data left over from previous runs
> through the loop.
>
the rational for this being ok is thta the copy operation into block is:
ret = wlcore_read_hwaddr(wl, addr, block,
wl->fw_mem_block_size, false);
this will end up in the .read methods where block should be completely
overwritten (length == full block size), so within the loop if successful
this should be correct - if not successful it would "goto out" witout
using the content of block.
Am I overlooking something here ?
thx!
hofrat
--
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 34/77] atari_NCR5380: Use arbitration timeout
On 12/22/2015 02:18 AM, Finn Thain wrote: Allow target selection to fail with a timeout instead of waiting in infinite loops. This gets rid of the unused NCR_TIMEOUT macro, it is more defensive and has proved helpful in debugging. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 44 ++--- drivers/scsi/atari_NCR5380.c | 57 ++- 2 files changed, 49 insertions(+), 52 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] perf tools: Make 'trace' sort key default for tracepoint events
On Mon, Dec 21, 2015 at 11:26:52PM +0900, Namhyung Kim wrote:
> When an evlist contains tracepoint events only, use 'trace' sort key as
> default. This will make users more convenient to see trace result.
>
> Suggested-by: Jiri Olsa
> Cc: Steven Rostedt
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/sort.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index f38a0577967a..43cb9b638718 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -2067,7 +2067,7 @@ static int sort_dimension__add(const char *tok,
> return -ESRCH;
> }
>
> -static const char *get_default_sort_order(void)
> +static const char *get_default_sort_order(struct perf_evlist *evlist)
> {
> const char *default_sort_orders[] = {
> default_sort_order,
> @@ -2076,13 +2076,25 @@ static const char *get_default_sort_order(void)
> default_top_sort_order,
> default_diff_sort_order,
> };
> + bool use_trace = true;
> + struct perf_evsel *evsel;
>
> BUG_ON(sort__mode >= ARRAY_SIZE(default_sort_orders));
>
> + evlist__for_each(evlist, evsel) {
> + if (evsel->attr.type != PERF_TYPE_TRACEPOINT) {
> + use_trace = false;
> + break;
> + }
> + }
> +
> + if (use_trace)
> + return "trace";
I wonder it'd be little 'nicer' to keep the current style
for sort orders for tracepoint even thought it has just single
column.. like adding:
- default_tracepoint_sort_order = "trace"
- SORT_MODE__TRACEPOINT
jirka
> +
> return default_sort_orders[sort__mode];
> }
SNIP
--
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 33/77] atari_NCR5380: Set do_abort() timeouts
On 12/22/2015 02:18 AM, Finn Thain wrote: Use timeouts in do_abort() in atari_NCR5380.c instead of infinite loops. Also fix the kernel-doc comment. Keep the two core driver forks in sync. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 26 +- drivers/scsi/atari_NCR5380.c | 34 +- 2 files changed, 34 insertions(+), 26 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 32/77] ncr5380: Fix bus phase in do_abort()
On 12/22/2015 02:18 AM, Finn Thain wrote: NCR5380_poll_politely() returns either 0 (success) or -ETIMEDOUT. However, in do_abort(), the return value is incorrectly taken to be the status register value. This means that the bus is put into DATA OUT phase instead of MESSAGE OUT. Fix this. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 31/77] ncr5380: Fix !REQ timeout in do_abort()
On 12/22/2015 02:18 AM, Finn Thain wrote: NCR5380_poll_politely() never returns -1. That means do_abort() can fail to handle a timeout after waiting for the target to negate REQ. Fix this and cleanup other NCR5380_poll_politely() call sites. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 30/77] ncr5380: Add missing break after case MESSAGE_REJECT
On 12/22/2015 02:18 AM, Finn Thain wrote:
MESSAGE REJECT does not imply DISCONNECT: the target is about to enter
MESSAGE IN or MESSAGE OUT phase.
This bug fix comes from atari_NCR5380.c. Unfortunately it never made it
into the original NCR5380.c core driver.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c |1 +
1 file changed, 1 insertion(+)
Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c 2015-12-22 12:16:16.0 +1100
+++ linux/drivers/scsi/NCR5380.c2015-12-22 12:16:17.0 +1100
@@ -1990,6 +1990,7 @@ static void NCR5380_information_transfer
default:
break;
}
+ break;
case DISCONNECT:{
/* Accept message by clearing
ACK */
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 29/77] ncr5380: Remove references to linked commands
On 12/22/2015 02:18 AM, Finn Thain wrote: From: Hannes Reinecke Some old drivers partially implemented support for linked commands using a "proposed" next_link pointer in struct scsi_cmnd that never actually existed. Remove this code. Signed-off-by: Finn Thain --- This is a modified version of Hannes' patch so I have dropped his signed-off-by tag. This version has a rewritten commit log and also removes additional references to linked commands from comments. This version also omits the sun3_NCR5380.c changes since that file no longer exists. --- drivers/scsi/NCR5380.c | 42 -- drivers/scsi/atari_NCR5380.c | 60 --- 2 files changed, 102 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 28/77] ncr5380: Drop DEF_SCSI_QCMD macro
On 12/22/2015 02:18 AM, Finn Thain wrote: Remove the DEF_SCSI_QCMD macro (already removed from atari_NCR5380.c). The lock provided by DEF_SCSI_QCMD is only needed for queue data structures. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 30 +++--- drivers/scsi/atari_NCR5380.c |2 +- 2 files changed, 16 insertions(+), 16 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 27/77] ncr5380: Add missing lock in eh_abort_handler
On 12/22/2015 02:18 AM, Finn Thain wrote: The host spin lock needs to be acquired by NCR5380_abort() before it calls NCR5380_select(). This patch doesn't actually fix the EH issues in this driver but it does avoid this: BUG: spinlock already unlocked on CPU#0, kworker/u4:1/14 lock: 0xc0c0f834, .magic: dead4ead, .owner: /-1, .owner_cpu: -1 CPU: 0 PID: 14 Comm: kworker/u4:1 Not tainted 3.15.5 #5 Workqueue: scsi_tmf_4 scmd_eh_abort_handler Call Trace: [ef885d70] [c0008acc] show_stack+0x70/0x1bc (unreliable) [ef885db0] [c0492a00] dump_stack+0x84/0x684 [ef885dc0] [c006f314] spin_dump+0xd0/0xe8 [ef885dd0] [c006f460] do_raw_spin_unlock+0xd4/0xd8 [ef885df0] [c0491c8c] _raw_spin_unlock_irq+0x10/0x3c [ef885e00] [f381fe3c] NCR5380_select+0x3e4/0x6e8 [dmx3191d] [ef885e40] [f382026c] NCR5380_abort+0x12c/0x190 [dmx3191d] [ef885e60] [c02fec9c] scmd_eh_abort_handler+0x100/0x460 [ef885e80] [c0046470] process_one_work+0x16c/0x420 [ef885ea0] [c0046870] worker_thread+0x14c/0x430 [ef885ed0] [c004e4f4] kthread+0xd8/0xec [ef885f40] [c00124d4] ret_from_kernel_thread+0x5c/0x64 Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] perf tools: Add 'trace' sort key
On Mon, Dec 21, 2015 at 11:26:50PM +0900, Namhyung Kim wrote:
SNIP
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index e28d26d0e73c..50a6b35a2fee 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -445,6 +445,65 @@ struct sort_entry sort_socket = {
> .se_width_idx = HISTC_SOCKET,
> };
>
> +/* --sort trace */
> +
> +static char *get_trace_output(struct hist_entry *he)
> +{
> + struct trace_seq seq;
> + struct perf_evsel *evsel;
> + struct pevent_record rec = {
> + .data = he->raw_data,
> + .size = he->raw_size,
> + };
> +
> + evsel = hists_to_evsel(he->hists);
> +
> + trace_seq_init();
> + pevent_event_info(, evsel->tp_format, );
> + return seq.buffer;
> +}
this function could be global and used in previous patch
in update_dynamic_len for trace_output?
hum, one's using evsel->tp_format and the other field->event,
I can't recall if both point to the same stuff..
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 26/77] ncr5380: Fix NCR5380_transfer_pio() result
On 12/22/2015 02:18 AM, Finn Thain wrote: According to the SCSI-2 draft revision 10L, atari_NCR5380.c is correct when it says that the phase lines are valid up until ACK is negated following the transmission of the last byte in MESSAGE IN phase. This is true for all information transfer phases, from target to initiator. Sample the phase bits in STATUS_REG so that NCR5380_transfer_pio() can return the correct result. The return value is presently unused (perhaps because of bugs like this) but this change at least fixes the caller's phase variable, which is passed by reference. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 12 +--- drivers/scsi/atari_NCR5380.c | 11 ++- 2 files changed, 15 insertions(+), 8 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 25/77] ncr5380: Rework disconnect versus poll logic
On 12/22/2015 02:18 AM, Finn Thain wrote:
The atari_NCR5380.c and NCR5380.c core drivers differ in their handling of
target disconnection. This is partly because atari_NCR5380.c had all of
the polling and sleeping removed to become entirely interrupt-driven, and
it is partly because of damage done to NCR5380.c after atari_NCR5380.c was
forked. See commit 37cd23b44929 ("Linux 2.1.105") in history/history.git.
The polling changes that were made in v2.1.105 are questionable at best:
if REQ is not already asserted when NCR5380_transfer_pio() is invoked, and
if the expected phase is DATA IN or DATA OUT, the function will schedule
main() to execute after USLEEP_SLEEP jiffies and then return. The problems
here are the expected REQ timing and the sleep interval*. Avoid this issue
by using NCR5380_poll_politely() instead of scheduling main().
The atari_NCR5380.c core driver requires the use of the chip interrupt and
always permits target disconnection. It sets the cmd->device->disconnect
flag when a device disconnects, but never tests this flag.
The NCR5380.c core driver permits disconnection only when
instance->irq != NO_IRQ. It sets the cmd->device->disconnect flag when
a device disconnects and it tests this flag in a couple of places:
1. During NCR5380_information_transfer(), following COMMAND OUT phase,
if !cmd->device->disconnect, the initiator will take a guess as to
whether or not the target will then choose to go to MESSAGE IN phase
and disconnect. If the driver guesses "yes", it will schedule main()
to execute after USLEEP_SLEEP jiffies and then return there.
Unfortunately the driver may guess "yes" even after it has denied
the target the disconnection privilege. When the target does not
disconnect, the sleep can be beneficial, assuming the sleep interval
is appropriate (mostly it is not*).
And even if the driver guesses "yes" correctly, and the target would
then disconnect, the driver still has to go through the MESSAGE IN
phase in order to get to BUS FREE phase. The main loop can do nothing
useful until BUS FREE, and sleeping just delays the phase transition.
2. If !cmd->device->disconnect and REQ is not already asserted when
NCR5380_information_transfer() is invoked, the function polls for REQ
for USLEEP_POLL jiffies. If REQ is not asserted, it then schedules
main() to execute after USLEEP_SLEEP jiffies and returns.
The idea is apparently to yeild the CPU while waiting for REQ.
This is conditional upon !cmd->device->disconnect, but there seems
to be no rhyme or reason for that. For example, the flag may be
unset because disconnection privilege was denied because the driver
has no IRQ. Or the flag may be unset because the device has never
needed to disconnect before. Or if the flag is set, disconnection
may have no relevance to the present bus phase.
Another deficiency of the existing algorithm is as follows. When the
driver has no IRQ, it prevents disconnection, and generally polls and
sleeps more than it would normally. Now, if the driver is going to poll
anyway, why not allow the target to disconnect? That way the driver can do
something useful with the bus instead of polling unproductively!
Avoid this pointless latency, complexity and guesswork by using
NCR5380_poll_politely() instead of scheduling main().
* For g_NCR5380, the time intervals for USLEEP_SLEEP and USLEEP_POLL are
200 ms and 10 ms, respectively. They are 20 ms and 200 ms respectively
for the other NCR5380 drivers. There doesn't seem to be any reason for
this discrepancy. The timing seems to have no relation to the type of
adapter. Bizarrely, the timing in g_NCR5380 seems to relate only to one
particular type of target device. This patch attempts to solve the
problem for all NCR5380 drivers and all target devices.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 137
++-
drivers/scsi/NCR5380.h | 11 ---
drivers/scsi/atari_NCR5380.c | 24 ++-
drivers/scsi/g_NCR5380.c |4 -
4 files changed, 15 insertions(+), 161 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [char-misc-next v3 3/8] watchdog: mei_wdt: implement MEI iAMT watchdog driver
> > On 12/21/2015 03:17 PM, Tomas Winkler wrote: > > Create a driver with the generic watchdog interface > > for the MEI iAMT watchdog device. > > > > Signed-off-by: Alexander Usyskin > > Signed-off-by: Tomas Winkler > > --- > > V2: The watchdog device is no longer dynamically allocated in separate > structure > > V3: Revert back to dynamically allocated watchdog device wrapper > > > > Documentation/misc-devices/mei/mei.txt | 12 +- > > MAINTAINERS| 1 + > > drivers/watchdog/Kconfig | 15 + > > drivers/watchdog/Makefile | 1 + > > drivers/watchdog/mei_wdt.c | 481 > + > > 5 files changed, 504 insertions(+), 6 deletions(-) > > create mode 100644 drivers/watchdog/mei_wdt.c > > > > diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc- > devices/mei/mei.txt > > index 91c1fa34f48b..2b80a0cd621f 100644 > > --- a/Documentation/misc-devices/mei/mei.txt > > +++ b/Documentation/misc-devices/mei/mei.txt > > @@ -231,15 +231,15 @@ IT knows when a platform crashes even when there > is a hard failure on the host. > > The Intel AMT Watchdog is composed of two parts: > > 1) Firmware feature - receives the heartbeats > >and sends an event when the heartbeats stop. > > - 2) Intel MEI driver - connects to the watchdog feature, configures the > > - watchdog and sends the heartbeats. > > + 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, > > + configures the watchdog and sends the heartbeats. > > > > -The Intel MEI driver uses the kernel watchdog API to configure the Intel > > AMT > > -Watchdog and to send heartbeats to it. The default timeout of the > > +The Intel iAMT watchdog MEI driver uses the kernel watchdog API to > > configure > > +the Intel AMT Watchdog and to send heartbeats to it. The default timeout of > the > > watchdog is 120 seconds. > > > > -If the Intel AMT Watchdog feature does not exist (i.e. the connection > > failed), > > -the Intel MEI driver will disable the sending of heartbeats. > > +If the Intel AMT is not enabled in the firmware then the watchdog client > > won't > enumerate > > +on the me client bus and watchdog devices won't be exposed. > > > > > > Supported Chipsets > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9bff63cf326e..e655625c2c16 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5666,6 +5666,7 @@ S:Supported > > F:include/uapi/linux/mei.h > > F:include/linux/mei_cl_bus.h > > F:drivers/misc/mei/* > > +F: drivers/watchdog/mei_wdt.c > > F:Documentation/misc-devices/mei/* > > > > INTEL MIC DRIVERS (mic) > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > > index 1c427beffadd..8ac51d69785c 100644 > > --- a/drivers/watchdog/Kconfig > > +++ b/drivers/watchdog/Kconfig > > @@ -1154,6 +1154,21 @@ config SBC_EPX_C3_WATCHDOG > > To compile this driver as a module, choose M here: the > > module will be called sbc_epx_c3. > > > > +config INTEL_MEI_WDT > > + tristate "Intel MEI iAMT Watchdog" > > + depends on INTEL_MEI && X86 > > + select WATCHDOG_CORE > > + ---help--- > > + A device driver for the Intel MEI iAMT watchdog. > > + > > + The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. > > + Whenever the OS hangs or crashes, iAMT will send an event > > + to any subscriber to this event. The watchdog doesn't reset the > > + the platform. > > + > > + To compile this driver as a module, choose M here: > > + the module will be called mei_wdt. > > + > > # M32R Architecture > > > > # M68K Architecture > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > > index 53d4827ddfe1..9069c9dd8aa8 100644 > > --- a/drivers/watchdog/Makefile > > +++ b/drivers/watchdog/Makefile > > @@ -123,6 +123,7 @@ obj-$(CONFIG_MACHZ_WDT) += machzwd.o > > obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o > > obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o > > obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o > > +obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o > > > > # M32R Architecture > > > > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c > > new file mode 100644 > > index ..5b28a1e95ac1 > > --- /dev/null > > +++ b/drivers/watchdog/mei_wdt.c > > @@ -0,0 +1,481 @@ > > +/* > > + * Intel Management Engine Interface (Intel MEI) Linux driver > > + * Copyright (c) 2015, Intel Corporation. > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms and conditions of the GNU General Public License, > > + * version 2, as published by the Free Software Foundation. > > + * > > + * This program is distributed in the hope it will be useful, but WITHOUT > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY > or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
RE: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
Hi Radim/Paolo,
> -Original Message-
> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
> Sent: Tuesday, December 22, 2015 3:14 PM
> To: Wu, Feng ; pbonz...@redhat.com;
> rkrc...@redhat.com
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu
> (jiang@linux.intel.com)
> Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
> priority interrupts
>
> On 2015/12/22 14:59, Wu, Feng wrote:
> >
> >
> >> -Original Message-
> >> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
> >> Sent: Tuesday, December 22, 2015 2:49 PM
> >> To: Wu, Feng ; pbonz...@redhat.com;
> >> rkrc...@redhat.com
> >> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu
> >> (jiang@linux.intel.com)
> >> Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
> >> priority interrupts
> >>
> >>
> >> On 2015/12/16 9:37, Feng Wu wrote:
> >>> Use vector-hashing to deliver lowest-priority interrupts, As an
> >>> example, modern Intel CPUs in server platform use this method to
> >>> handle lowest-priority interrupts.
> >>>
> >>> Signed-off-by: Feng Wu
> >>> ---
> >>> arch/x86/kvm/irq_comm.c | 27 ++-
> >>> arch/x86/kvm/lapic.c| 57
> >> -
> >>> arch/x86/kvm/lapic.h| 2 ++
> >>> arch/x86/kvm/x86.c | 9
> >>> arch/x86/kvm/x86.h | 1 +
> >>> 5 files changed, 81 insertions(+), 15 deletions(-)
> >>>
> >>> bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct
> kvm_lapic
> *src,
> >>> struct kvm_lapic_irq *irq, int *r, unsigned long
> >> *dest_map)
> >>> {
> >>> @@ -731,17 +747,38 @@ bool kvm_irq_delivery_to_apic_fast(struct
> kvm
> >> *kvm, struct kvm_lapic *src,
> >>> dst = map->logical_map[cid];
> >>>
> >>> if (kvm_lowest_prio_delivery(irq)) {
> >>> - int l = -1;
> >>> - for_each_set_bit(i, , 16) {
> >>> - if (!dst[i])
> >>> - continue;
> >>> - if (l < 0)
> >>> - l = i;
> >>> - else if (kvm_apic_compare_prio(dst[i]-
> >vcpu,
> >> dst[l]->vcpu) < 0)
> >>> - l = i;
> >>> + if (!kvm_vector_hashing_enabled()) {
> >>> + int l = -1;
> >>> + for_each_set_bit(i, , 16) {
> >>> + if (!dst[i])
> >>> + continue;
> >>> + if (l < 0)
> >>> + l = i;
> >>> + else if
> (kvm_apic_compare_prio(dst[i]-
> >>> vcpu, dst[l]->vcpu) < 0)
> >>> + l = i;
> >>> + }
> >>> + bitmap = (l >= 0) ? 1 << l : 0;
> >>> + } else {
> >>> + int idx = 0;
> >>> + unsigned int dest_vcpus = 0;
> >>> +
> >>> + for_each_set_bit(i, , 16) {
> >>> + if (!dst[i]
> >> && !kvm_lapic_enabled(dst[i]->vcpu)) {
> >>
> >> It should be or(||) not and (&&).
> >
> > Oh, you are right! My negligence! Thanks for pointing this out, Yang!
>
> btw, i think the kvm_lapic_enabled check is wrong here? Why need it here?
> >>>
> >>> If the lapic is not enabled, I think we cannot recognize it as a
> >>> candidate, can
> >> we?
> >>> Maybe Radim can confirm this, Radim, what is your option?
> >>
> >> Lapic can be disable by hw or sw. Here we only need to check the hw is
> >> enough which is already covered while injecting the interrupt into
> >> guest. I remember we(Glab, Macelo and me) have discussed it several ago,
> >> but i cannot find the mail thread.
> >
> > But if the lapic is disabled by software, we cannot still inject interrupts
> > to
> > it, can we?
>
> Yes, We cannot inject the normal interrupt. But this already covered by
> current logic and add a check here seems meaningless. Conversely, it may
> do bad thing..
>
Let's wait for Radim/Paolo's opinions about this.
Thanks,
Feng
--
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 24/77] ncr5380: Implement NCR5380_dma_xfer_len and remove LIMIT_TRANSFERSIZE macro
On 12/22/2015 02:18 AM, Finn Thain wrote: Follow the example of the atari_NCR5380.c core driver and adopt the NCR5380_dma_xfer_len() hook. Implement NCR5380_dma_xfer_len() for dtc.c and g_NCR5380.c to take care of the limitations of these cards. Keep the default for drivers using PSEUDO_DMA. Eliminate the unused macro LIMIT_TRANSFERSIZE. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 32 +--- drivers/scsi/arm/cumana_1.c |3 +++ drivers/scsi/arm/oak.c |2 ++ drivers/scsi/atari_NCR5380.c |8 +--- drivers/scsi/dtc.c | 14 ++ drivers/scsi/dtc.h |3 +++ drivers/scsi/g_NCR5380.c | 15 +++ drivers/scsi/g_NCR5380.h |3 +++ drivers/scsi/mac_scsi.c |1 + drivers/scsi/pas16.h |2 ++ drivers/scsi/t128.h |2 ++ 11 files changed, 55 insertions(+), 30 deletions(-) Hmm. I really, _really_, wish we could move away from the 'magic' definitions and use a proper function template. But maybe next time. So: Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection
>> 6. Apply a recommendation from the script "checkpatch.pl". > > That's 6 different things, shouldn't this be 6 different patches? > > please redo. Dan Carpenter requested to squash the previous update steps 5 and 6 into a single patch for better source code review. Now I see further software development challenges to increase the patch granularity even more as you suggest. Which route would Lustre developers like to follow? Regards, Markus -- 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] s390/vmur: fix build warning
On Tue, Dec 22, 2015 at 06:58:50AM +, Al Viro wrote: > On Tue, Dec 22, 2015 at 12:23:51PM +0530, Sudip Mukherjee wrote: > > The helper no_seek_end_llseek() was added but now newpos is not required > > and as a result we are getting build warning of unused variable. > > Mind if I simply fold that into the commit in question? No problem at all. Please fold them together. regards sudip -- 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 23/77] ncr5380: Always retry arbitration and selection
On 12/22/2015 02:18 AM, Finn Thain wrote:
If NCR5380_select() returns -1, it means arbitration was lost or selection
failed and should be retried. If the main loop simply terminates when there
are still commands on the issue queue, they will remain queued until they
expire.
Fix this by clearing the 'done' flag after selection failure or lost
arbitration.
The "else break" clause in NCR5380_main() that gets removed here appears
to be a vestige of a long-gone loop that iterated over host instances.
See commit 491447e1fcff ("[PATCH] next NCR5380 updates") in
history/history.git.
Signed-off-by: Finn Thain
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 22/77] ncr5380: Eliminate selecting state
On 12/22/2015 02:18 AM, Finn Thain wrote: Linux v2.1.105 changed the algorithm for polling for the BSY signal in NCR5380_select() and NCR5380_main(). Presently, this code has a bug. Back then, NCR5380_set_timer(hostdata, 1) meant reschedule main() after sleeping for 10 ms. Repeated 25 times this provided the recommended 250 ms selection time-out delay. This got broken when HZ became configurable. We could fix this but there's no need to reschedule the main loop. This BSY polling presently happens when the NCR5380_main() work queue item calls NCR5380_select(), which in turn schedules NCR5380_main(), which calls NCR5380_select() again, and so on. This algorithm is a deviation from the simpler one in atari_NCR5380.c. The extra complexity and state is pointless. There's no reason to stop selection half-way and return to to the main loop when the main loop can do nothing useful until selection completes. So just poll for BSY. We can sleep while polling now that we have a suitable workqueue. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
On 2015/12/22 14:59, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Tuesday, December 22, 2015 2:49 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu
(jiang@linux.intel.com)
Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
priority interrupts
On 2015/12/16 9:37, Feng Wu wrote:
Use vector-hashing to deliver lowest-priority interrupts, As an
example, modern Intel CPUs in server platform use this method to
handle lowest-priority interrupts.
Signed-off-by: Feng Wu
---
arch/x86/kvm/irq_comm.c | 27 ++-
arch/x86/kvm/lapic.c| 57
-
arch/x86/kvm/lapic.h| 2 ++
arch/x86/kvm/x86.c | 9
arch/x86/kvm/x86.h | 1 +
5 files changed, 81 insertions(+), 15 deletions(-)
bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic
*src,
struct kvm_lapic_irq *irq, int *r, unsigned long
*dest_map)
{
@@ -731,17 +747,38 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm
*kvm, struct kvm_lapic *src,
dst = map->logical_map[cid];
if (kvm_lowest_prio_delivery(irq)) {
- int l = -1;
- for_each_set_bit(i, , 16) {
- if (!dst[i])
- continue;
- if (l < 0)
- l = i;
- else if (kvm_apic_compare_prio(dst[i]->vcpu,
dst[l]->vcpu) < 0)
- l = i;
+ if (!kvm_vector_hashing_enabled()) {
+ int l = -1;
+ for_each_set_bit(i, , 16) {
+ if (!dst[i])
+ continue;
+ if (l < 0)
+ l = i;
+ else if (kvm_apic_compare_prio(dst[i]-
vcpu, dst[l]->vcpu) < 0)
+ l = i;
+ }
+ bitmap = (l >= 0) ? 1 << l : 0;
+ } else {
+ int idx = 0;
+ unsigned int dest_vcpus = 0;
+
+ for_each_set_bit(i, , 16) {
+ if (!dst[i]
&& !kvm_lapic_enabled(dst[i]->vcpu)) {
It should be or(||) not and (&&).
Oh, you are right! My negligence! Thanks for pointing this out, Yang!
btw, i think the kvm_lapic_enabled check is wrong here? Why need it here?
If the lapic is not enabled, I think we cannot recognize it as a candidate, can
we?
Maybe Radim can confirm this, Radim, what is your option?
Lapic can be disable by hw or sw. Here we only need to check the hw is
enough which is already covered while injecting the interrupt into
guest. I remember we(Glab, Macelo and me) have discussed it several ago,
but i cannot find the mail thread.
But if the lapic is disabled by software, we cannot still inject interrupts to
it, can we?
Yes, We cannot inject the normal interrupt. But this already covered by
current logic and add a check here seems meaningless. Conversely, it may
do bad thing..
--
best regards
yang
--
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 21/77] ncr5380: Sleep when polling, if possible
On 12/22/2015 02:17 AM, Finn Thain wrote: When in process context, sleep during polling if doing so won't add significant latency. In interrupt context or if the lock is held, poll briefly then give up. Keep both core drivers in sync. Calibrate busy-wait iterations to allow for variation in chip register access times between different 5380 hardware implementations. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 20/77] ncr5380: Introduce unbound workqueue
On 12/22/2015 02:17 AM, Finn Thain wrote:
Allocate a work queue that will permit busy waiting and sleeping. This
means NCR5380_init() can potentially fail, so add this error path.
Signed-off-by: Finn Thain
---
In subsequent patches, the work function adopts this work queue so it
can sleep while polling, which allows the removal of some flawed and
complicated code in NCR5380_select() in NCR5380.c.
Changed since v1:
- Dropped WQ_CPU_INTENSIVE flag because Documentation/workqueue.txt says it
"is meaningless for unbound wq".
---
drivers/scsi/NCR5380.c | 15 +++
drivers/scsi/NCR5380.h |1 +
drivers/scsi/arm/cumana_1.c |8 ++--
drivers/scsi/arm/oak.c |8 ++--
drivers/scsi/atari_NCR5380.c |8 +++-
drivers/scsi/atari_scsi.c|5 -
drivers/scsi/dmx3191d.c | 17 +++--
drivers/scsi/dtc.c | 11 +--
drivers/scsi/g_NCR5380.c | 31 +++
drivers/scsi/mac_scsi.c |5 -
drivers/scsi/pas16.c | 10 --
drivers/scsi/sun3_scsi.c |5 -
drivers/scsi/t128.c | 13 ++---
13 files changed, 96 insertions(+), 41 deletions(-)
Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c 2015-12-22 12:15:52.0 +1100
+++ linux/drivers/scsi/NCR5380.c2015-12-22 12:15:56.0 +1100
@@ -514,7 +514,7 @@ static int should_disconnect(unsigned ch
static void NCR5380_set_timer(struct NCR5380_hostdata *hostdata, unsigned
long timeout)
{
hostdata->time_expires = jiffies + timeout;
- schedule_delayed_work(>coroutine, timeout);
+ queue_delayed_work(hostdata->work_q, >coroutine, timeout);
}
@@ -791,7 +791,12 @@ static int NCR5380_init(struct Scsi_Host
hostdata->disconnected_queue = NULL;
INIT_DELAYED_WORK(>coroutine, NCR5380_main);
-
+ hostdata->work_q = alloc_workqueue("ncr5380_%d",
+ WQ_UNBOUND | WQ_MEM_RECLAIM,
+ 1, instance->host_no);
+ if (!hostdata->work_q)
+ return -ENOMEM;
+
/* The CHECK code seems to break the 53C400. Will check it later maybe
*/
if (flags & FLAG_NCR53C400)
hostdata->flags = FLAG_HAS_LAST_BYTE_SENT | flags;
Wouldn't it be better to use a normal (ie bound) workqueue here?
SCSI-2 is pretty much single-threaded, so shifting things onto arbitrary
CPUs don't sound very appealing.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry_rcu
On 12/08/2015 04:46 PM, Paul E. McKenney wrote: On Tue, Dec 08, 2015 at 04:20:03PM +1100, Paul Mackerras wrote: On Sat, Dec 05, 2015 at 06:19:46PM -0800, Paul E. McKenney wrote: As in the following? (And yes, I was confused by the fact that the docbook header was in front of a differently-named macro!) That looks great! Have you committed to one of your branches? Indeed I have, though quite recently. Please see branch rcu/dev of: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git Or, more specifically, this commit: 69b907297f4e If your testing goes well, I will push this into the upcoming merge window. Sorry, it took a little longer than I expected. It works just fine, thanks! -- Alexey -- 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] wlcore: consolidate kmalloc + memset 0 into kzalloc
On Mon, Dec 21, 2015 at 10:17 PM, Nicholas Mc Guire wrote:
> This is an API consolidation only. The use of kmalloc + memset to 0
> is equivalent to kzalloc.
>
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Found by coccinelle script (relaxed version of
> scripts/coccinelle/api/alloc/kzalloc-simple.cocci)
>
> Patch was compile tested with: x86_64_defconfig +
> CONFIG_WL12XX=m (implies CONFIG_WLCORE=m)
>
> Patch is against linux-next (localversion-next is -next-20151221)
>
> drivers/net/wireless/ti/wlcore/main.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c
> b/drivers/net/wireless/ti/wlcore/main.c
> index ec7f6af..dfc49bf 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -838,7 +838,7 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
>
> wl1271_info("Reading FW panic log");
>
> - block = kmalloc(wl->fw_mem_block_size, GFP_KERNEL);
> + block = kzalloc(wl->fw_mem_block_size, GFP_KERNEL);
> if (!block)
> return;
>
> @@ -885,7 +885,6 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
> goto out;
> }
>
> - memset(block, 0, wl->fw_mem_block_size);
Current code is reseting the block value to 0 in each iterations and
perform some operations.
But if you are using kzalloc as mentioned above it will memset 0 to
block pointer only once.
So both are not equivalent operations.
> ret = wlcore_read_hwaddr(wl, addr, block,
> wl->fw_mem_block_size, false);
>
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-Souptick
--
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 19/77] ncr5380: Cleanup bogus {request,release}_region() calls
On 12/22/2015 02:17 AM, Finn Thain wrote:
Commit 8b801ead3d7a ("[ARM] rpc: update Acorn SCSI drivers to modern ecard
interfaces") neglected to remove a request_region() call in cumana_1.c.
Commit eda32612f7b2 ("[PATCH] give all LLDD driver a ->release method") in
history/history.git added some pointless release_region() calls in dtc.c,
pas16.c and t128.c.
Fix these issues.
Signed-off-by: Finn Thain
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 18/77] ncr5380: Eliminate USLEEP_WAITLONG delay
On 12/22/2015 02:17 AM, Finn Thain wrote:
Linux 2.1.105 introduced the USLEEP_WAITLONG delay, apparently "needed for
Mustek scanners". It is intended to stall the issue queue for 5 seconds.
There are a number of problems with this.
1. Only g_NCR5380 enables the delay, which implies that the other five
drivers using the NCR5380.c core driver remain incompatible with
Mustek scanners.
2. The delay is not implemented by atari_NCR5380.c, which is problematic
for re-unifying the two core driver forks.
3. The delay is implemented using NCR5380_set_timer() which makes it
unreliable. A new command queued by the mid-layer cancels the delay.
4. The delay is applied indiscriminately in several situations in which
NCR5380_select() returns -1. These are-- reselection by the target,
failure of the target to assert BSY, and failure of the target to
assert REQ. It's clear from the comments that USLEEP_WAITLONG is not
relevant to the reselection case. And reportedly, these scanners do
not disconnect.
5. atari_NCR5380.c was forked before Linux 2.1.105, so it was spared some
of the damage done to NCR5380.c. In this case, the atari_NCR5380.c core
driver was more standard-compliant and may not have needed any
workaround like the USLEEP_WAITLONG kludge. The compliance issue was
addressed in the previous patch.
If these scanners still don't work, we need a better solution. Retrying
selection until EH aborts a command offers equivalent robustness. Bugs in
the existing driver prevent EH working correctly but this is addressed in
a subsequent patch. Remove USLEEP_WAITLONG.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 19 +--
drivers/scsi/g_NCR5380.c |1 -
2 files changed, 5 insertions(+), 15 deletions(-)
Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c 2015-12-22 12:15:51.0 +1100
+++ linux/drivers/scsi/NCR5380.c2015-12-22 12:15:52.0 +1100
@@ -468,10 +468,6 @@ static void NCR5380_print_phase(struct S
#ifndef USLEEP_POLL
#define USLEEP_POLL msecs_to_jiffies(200)
#endif
-#ifndef USLEEP_WAITLONG
-/* RvC: (reasonable time to wait on select error) */
-#define USLEEP_WAITLONG USLEEP_SLEEP
-#endif
/*
* Function : int should_disconnect (unsigned char cmd)
@@ -619,8 +615,8 @@ static void prepare_info(struct Scsi_Hos
"can_queue %d, cmd_per_lun %d, "
"sg_tablesize %d, this_id %d, "
"flags { %s%s%s%s}, "
-#if defined(USLEEP_POLL) && defined(USLEEP_WAITLONG)
-"USLEEP_POLL %lu, USLEEP_WAITLONG %lu, "
+#if defined(USLEEP_POLL) && defined(USLEEP_SLEEP)
+"USLEEP_POLL %lu, USLEEP_SLEEP %lu, "
#endif
"options { %s} ",
instance->hostt->name, instance->io_port, instance->n_io_port,
@@ -631,8 +627,8 @@ static void prepare_info(struct Scsi_Hos
hostdata->flags & FLAG_DTC3181E ? "DTC3181E " : "",
hostdata->flags & FLAG_NO_PSEUDO_DMA ? "NO_PSEUDO_DMA " : "",
hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY " : "",
-#if defined(USLEEP_POLL) && defined(USLEEP_WAITLONG)
-USLEEP_POLL, USLEEP_WAITLONG,
+#if defined(USLEEP_POLL) && defined(USLEEP_SLEEP)
+USLEEP_POLL, USLEEP_SLEEP,
#endif
#ifdef AUTOPROBE_IRQ
"AUTOPROBE_IRQ "
Wouldn't it make more sense to remove the USLEEP_WAITLONG completely?
From what I can see it is meant to indicate that WAITLONG is enabled,
but we've just removed that functionality...
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 17/77] ncr5380: Keep BSY asserted when entering SELECTION phase
On 12/22/2015 02:17 AM, Finn Thain wrote: NCR5380.c is not compliant with the SCSI-2 standard (at least, not with the draft revision 10L that I have to refer to). The selection algorithm in atari_NCR5380.c is correct, so use that. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "kernel/stop_machine.c: remove CONFIG_SMP dependencies"
On Tue, 22 Dec 2015 11:30:51 +0530 Sudip Mukherjee
wrote:
> > Rationale:
> >
> > stop_machine.o is only built when CONFIG_SMP=y so
> >
> > #if defined(CONFIG_SMP) || defined(CONFIG_HOTPLUG_CPU)
> >
> > always evaluates to true, so remove it.
>
> Hi Andrew,
> The error is still there. I guess you have been busy. :)
>
> next-20151222 fails with the same error. You can see the m32r defconfig
> at https://travis-ci.org/sudipm-mukherjee/parport/jobs/98258267
I forgot to Cc Stephen :(
From: Andrew Morton
Subject: kernel-stop_machinec-remove-config_smp-dependencies-fix
stop_machine.o is only built if CONFIG_SMP=y, so this ifdef always
evaluates to true.
Cc: Chris Wilson
Cc: Ingo Molnar
Cc: Valentin Rothberg
Signed-off-by: Andrew Morton
---
kernel/stop_machine.c |4
1 file changed, 4 deletions(-)
diff -puN
kernel/stop_machine.c~kernel-stop_machinec-remove-config_smp-dependencies-fix
kernel/stop_machine.c
---
a/kernel/stop_machine.c~kernel-stop_machinec-remove-config_smp-dependencies-fix
+++ a/kernel/stop_machine.c
@@ -531,8 +531,6 @@ static int __init cpu_stop_init(void)
}
early_initcall(cpu_stop_init);
-#ifdef CONFIG_HOTPLUG_CPU
-
static int __stop_machine(cpu_stop_fn_t fn, void *data, const struct cpumask
*cpus)
{
struct multi_stop_data msdata = {
@@ -630,5 +628,3 @@ int stop_machine_from_inactive_cpu(cpu_s
mutex_unlock(_cpus_mutex);
return ret ?: done.ret;
}
-
-#endif /* CONFIG_HOTPLUG_CPU */
_
--
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] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
> -Original Message-
> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
> Sent: Tuesday, December 22, 2015 2:49 PM
> To: Wu, Feng ; pbonz...@redhat.com;
> rkrc...@redhat.com
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu
> (jiang@linux.intel.com)
> Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
> priority interrupts
>
>
> On 2015/12/16 9:37, Feng Wu wrote:
> > Use vector-hashing to deliver lowest-priority interrupts, As an
> > example, modern Intel CPUs in server platform use this method to
> > handle lowest-priority interrupts.
> >
> > Signed-off-by: Feng Wu
> > ---
> > arch/x86/kvm/irq_comm.c | 27 ++-
> > arch/x86/kvm/lapic.c| 57
> -
> > arch/x86/kvm/lapic.h| 2 ++
> > arch/x86/kvm/x86.c | 9
> > arch/x86/kvm/x86.h | 1 +
> > 5 files changed, 81 insertions(+), 15 deletions(-)
> >
> > bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic
> >> *src,
> > struct kvm_lapic_irq *irq, int *r, unsigned long
> *dest_map)
> > {
> > @@ -731,17 +747,38 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm
> *kvm, struct kvm_lapic *src,
> > dst = map->logical_map[cid];
> >
> > if (kvm_lowest_prio_delivery(irq)) {
> > - int l = -1;
> > - for_each_set_bit(i, , 16) {
> > - if (!dst[i])
> > - continue;
> > - if (l < 0)
> > - l = i;
> > - else if
> > (kvm_apic_compare_prio(dst[i]->vcpu,
> dst[l]->vcpu) < 0)
> > - l = i;
> > + if (!kvm_vector_hashing_enabled()) {
> > + int l = -1;
> > + for_each_set_bit(i, , 16) {
> > + if (!dst[i])
> > + continue;
> > + if (l < 0)
> > + l = i;
> > + else if
> > (kvm_apic_compare_prio(dst[i]-
> > vcpu, dst[l]->vcpu) < 0)
> > + l = i;
> > + }
> > + bitmap = (l >= 0) ? 1 << l : 0;
> > + } else {
> > + int idx = 0;
> > + unsigned int dest_vcpus = 0;
> > +
> > + for_each_set_bit(i, , 16) {
> > + if (!dst[i]
> && !kvm_lapic_enabled(dst[i]->vcpu)) {
>
> It should be or(||) not and (&&).
> >>>
> >>> Oh, you are right! My negligence! Thanks for pointing this out, Yang!
> >>
> >> btw, i think the kvm_lapic_enabled check is wrong here? Why need it here?
> >
> > If the lapic is not enabled, I think we cannot recognize it as a candidate,
> > can
> we?
> > Maybe Radim can confirm this, Radim, what is your option?
>
> Lapic can be disable by hw or sw. Here we only need to check the hw is
> enough which is already covered while injecting the interrupt into
> guest. I remember we(Glab, Macelo and me) have discussed it several ago,
> but i cannot find the mail thread.
But if the lapic is disabled by software, we cannot still inject interrupts to
it, can we?
Thanks,
Feng
--
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.2 4/6] drm: rockchip: Support Synopsys DW MIPI DSI
Add support for Synopsys DesignWare MIPI DSI controller which is embedded in the rk3288 SoCs. Signed-off-by: Chris Zhong --- Changes in v6.2: - Remove the atomic feature check (Mark Yao) Changes in v6.1: - Add atomic API support (Heiko Stübne) Changes in v6: - Do not use bridge driver (Thierry Reding) - Optimization the phy init sequence Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1196 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + 4 files changed, 1210 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 686cb49..1db1b86 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -34,3 +34,13 @@ config ROCKCHIP_ANALOGIX_DP This selects support for Rockchip SoC specific extensions for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. + +config ROCKCHIP_DW_MIPI_DSI + bool "Rockchip specific extensions for Synopsys DW MIPI DSI" + depends on DRM_ROCKCHIP + select DRM_MIPI_DSI + help +This selects support for Rockchip SoC specific extensions +for the Synopsys DesignWare HDMI driver. If you want to +enable MIPI DSI on RK3288 based SoC, you should selet this +option. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 8ad01fb..c5c2d61 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,5 +7,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \ obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c new file mode 100644 index 000..1fe631e --- /dev/null +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c @@ -0,0 +1,1196 @@ +/* + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define DRIVER_NAME"dw-mipi-dsi" + +#define GRF_SOC_CON60x025c +#define DSI0_SEL_VOP_LIT(1 << 6) +#define DSI1_SEL_VOP_LIT(1 << 9) + +#define DSI_VERSION0x00 +#define DSI_PWR_UP 0x04 +#define RESET 0 +#define POWERUPBIT(0) + +#define DSI_CLKMGR_CFG 0x08 +#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) + +#define DSI_DPI_VCID 0x0c +#define DPI_VID(vid) (((vid) & 0x3) << 0) + +#define DSI_DPI_COLOR_CODING 0x10 +#define EN18_LOOSELY BIT(8) +#define DPI_COLOR_CODING_16BIT_1 0x0 +#define DPI_COLOR_CODING_16BIT_2 0x1 +#define DPI_COLOR_CODING_16BIT_3 0x2 +#define DPI_COLOR_CODING_18BIT_1 0x3 +#define DPI_COLOR_CODING_18BIT_2 0x4 +#define DPI_COLOR_CODING_24BIT 0x5 + +#define DSI_DPI_CFG_POL0x14 +#define COLORM_ACTIVE_LOW BIT(4) +#define SHUTD_ACTIVE_LOW BIT(3) +#define HSYNC_ACTIVE_LOW BIT(2) +#define VSYNC_ACTIVE_LOW BIT(1) +#define DATAEN_ACTIVE_LOW BIT(0) + +#define DSI_DPI_LP_CMD_TIM 0x18 +#define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) +#define INVACT_LPCMD_TIME(p) ((p) & 0xff) + +#define DSI_DBI_CFG0x20 +#define DSI_DBI_CMDSIZE0x28 + +#define DSI_PCKHDL_CFG 0x2c +#define EN_CRC_RX BIT(4) +#define EN_ECC_RX BIT(3) +#define EN_BTA BIT(2) +#define EN_EOTP_RX BIT(1) +#define EN_EOTP_TX BIT(0) + +#define DSI_MODE_CFG 0x34 +#define ENABLE_VIDEO_MODE 0 +#define ENABLE_CMD_MODEBIT(0) + +#define DSI_VID_MODE_CFG 0x38 +#define FRAME_BTA_ACK BIT(14) +#define ENABLE_LOW_POWER
Re: [PATCH] s390/vmur: fix build warning
On Tue, Dec 22, 2015 at 12:23:51PM +0530, Sudip Mukherjee wrote: > The helper no_seek_end_llseek() was added but now newpos is not required > and as a result we are getting build warning of unused variable. Mind if I simply fold that into the commit in question? -- 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/2] zram: try vmalloc() after kmalloc()
Hello,
Cc stable
Do I need to resend the patch or providing the message-id is enough?
lkml.kernel.org/r/1448973390-21170-3-git-send-email-sergey.senozhat...@gmail.com
( http://marc.info/?l=linux-kernel=144897350818887 )
-ss
> From: Kyeongdon Kim
>
> When we're using LZ4 multi compression streams for zram swap, we found out
> page allocation failure message in system running test. That was not only
> once, but a few(2 - 5 times per test). Also, some failure cases were
> continually occurring to try allocation order 3.
>
> In order to make parallel compression private data, we should call
> kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
> 2/3 size memory to allocate in that time, page allocation fails. This
> patch makes to use vmalloc() as fallback of kmalloc(), this prevents page
> alloc failure warning.
>
> After using this, we never found warning message in running test, also It
> could reduce process startup latency about 60-120ms in each case.
>
> For reference a call trace :
>
> Binder_1: page allocation failure: order:3, mode:0x10c0d0
> CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
> Call trace:
> [] dump_backtrace+0x0/0x270
> [] show_stack+0x10/0x1c
> [] dump_stack+0x1c/0x28
> [] warn_alloc_failed+0xfc/0x11c
> [] __alloc_pages_nodemask+0x724/0x7f0
> [] __get_free_pages+0x14/0x5c
> [] kmalloc_order_trace+0x38/0xd8
> [] zcomp_lz4_create+0x2c/0x38
> [] zcomp_strm_alloc+0x34/0x78
> [] zcomp_strm_multi_find+0x124/0x1ec
> [] zcomp_strm_find+0xc/0x18
> [] zram_bvec_rw+0x2fc/0x780
> [] zram_make_request+0x25c/0x2d4
> [] generic_make_request+0x80/0xbc
> [] submit_bio+0xa4/0x15c
> [] __swap_writepage+0x218/0x230
> [] swap_writepage+0x3c/0x4c
> [] shrink_page_list+0x51c/0x8d0
> [] shrink_inactive_list+0x3f8/0x60c
> [] shrink_lruvec+0x33c/0x4cc
> [] shrink_zone+0x3c/0x100
> [] try_to_free_pages+0x2b8/0x54c
> [] __alloc_pages_nodemask+0x514/0x7f0
> [] __get_free_pages+0x14/0x5c
> [] proc_info_read+0x50/0xe4
> [] vfs_read+0xa0/0x12c
> [] SyS_read+0x44/0x74
> DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
> 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB
>
> [minc...@kernel.org: change vmalloc gfp and adding comment about gfp]
> [sergey.senozhat...@gmail.com: tweak comments and styles]
> Signed-off-by: Kyeongdon Kim
> Signed-off-by: Minchan Kim
> Acked-by: Sergey Senozhatsky
> ---
> drivers/block/zram/zcomp_lz4.c | 23 +--
> drivers/block/zram/zcomp_lzo.c | 23 +--
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
> index ee44b51..dd60831 100644
> --- a/drivers/block/zram/zcomp_lz4.c
> +++ b/drivers/block/zram/zcomp_lz4.c
> @@ -10,17 +10,36 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "zcomp_lz4.h"
>
> static void *zcomp_lz4_create(void)
> {
> - return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO);
> + void *ret;
> +
> + /*
> + * This function can be called in swapout/fs write path
> + * so we can't use GFP_FS|IO. And it assumes we already
> + * have at least one stream in zram initialization so we
> + * don't do best effort to allocate more stream in here.
> + * A default stream will work well without further multiple
> + * streams. That's why we use NORETRY | NOWARN.
> + */
> + ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
> + __GFP_NOWARN);
> + if (!ret)
> + ret = __vmalloc(LZ4_MEM_COMPRESS,
> + GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN |
> + __GFP_ZERO | __GFP_HIGHMEM,
> + PAGE_KERNEL);
> + return ret;
> }
>
> static void zcomp_lz4_destroy(void *private)
> {
> - kfree(private);
> + kvfree(private);
> }
>
> static int zcomp_lz4_compress(const unsigned char *src, unsigned char *dst,
> diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
> index 683ce04..edc5499 100644
> --- a/drivers/block/zram/zcomp_lzo.c
> +++ b/drivers/block/zram/zcomp_lzo.c
> @@ -10,17 +10,36 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "zcomp_lzo.h"
>
> static void *lzo_create(void)
> {
> - return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO);
> + void *ret;
> +
> + /*
> + * This function can be called in swapout/fs write path
> + * so we can't use GFP_FS|IO. And it assumes we already
> + * have at least one stream in zram initialization so we
> + * don't do best effort to allocate more stream in here.
> + * A default stream will work well without further multiple
> + * streams. That's why we use NORETRY | NOWARN.
> + */
> + ret = kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
> + __GFP_NOWARN);
> + if (!ret)
>
Re: linux-next: build failure after merge of the gpio tree
Stephen Rothwell writes:
> Hi Linus,
>
> After merging the gpio tree, today's linux-next build (lots without
> CONFIG_OF) failed like this:
>
> drivers/gpio/gpio-pxa.c: In function 'pxa_gpio_probe':
> drivers/gpio/gpio-pxa.c:648:12: error: 'pxa_irq_domain_ops' undeclared (first
> use in this function)
>
> Caused by commit
>
> 384ca3c6a28d ("gpio: pxa: change the interrupt management")
>
> The reference to pxa_irq_domain_ops was moved out of the protection of
> CONFIG_OF ...
>
> Discovered after the release.
Hi Stephen,
The fix has been sent in http://www.spinics.net/lists/kernel/msg2147774.html but
did not reach Linus's next tree yet probably.
Cheers.
--
Robert
--
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 08/10] perf tools: Add --raw-trace option
On Mon, Dec 21, 2015 at 05:44:41PM +0900, Namhyung Kim wrote: SNIP > > > > I think the default is good with the 'trace' sort key as it is now: > > > > $ ./perf report -s trace > > 27.01% offlineimap:17701 [120] S ==> swapper/1:0 [120] > > 27.00% swapper/1:0 [120] R ==> offlineimap:17701 [120] > > > > > > But for '--raw-trace' option rather than displaying fields in the '=' > > notation: > > > > $ ./perf report -s trace --raw-trace > > 27.01% prev_comm=offlineimap prev_pid=17701 prev_prio=120 > > prev_state=1 next_comm=swapper/1 next_pid=0 next_prio=120 > > 27.00% prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=0 > > next_comm=offlineimap next_pid=17701 next_prio=120 > > > > > > it would be more readable to register all available columns as is possible > > to do now with: > > > > $ ./perf report -s > > prev_comm,prev_pid,prev_prio,prev_state,next_comm,next_pid,next_prio > > Overhead prev_commprev_pid prev_prio prev_state > >next_commnext_pid next_prio > > 27.01% offlineimap 17701 120 1 > >swapper/1 0 120 > > 27.00% swapper/1 0 120 0 > > offlineimap 17701 120 > > > > > > it would be default output for 'perf report -s trace --raw-trace' command > > > > how about that? > > > I agree with the latter is much more readable. But the dynamic sort > keys are event specific while 'trace' is generic. So if there are > more than one events, dynamic sort keys should be generated for each > event and they'll show "N/A" for other events. I see.. haven't realized that, maybe we should add columns based in the hists object.. but I guess that's out of scope of this patchset ;-) > > Also I don't like the --raw-trace option affects number of sort keys. > Maybe it'd be better adding 'EVENT.*' dynamic sort key for your case? that's good workaround, 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/
[PATCH] s390/vmur: fix build warning
The helper no_seek_end_llseek() was added but now newpos is not required
and as a result we are getting build warning of unused variable.
Fixes: fb1d259e480c ("new helpers: no_seek_end_llseek{,_size}()")
Cc: Al Viro
Signed-off-by: Sudip Mukherjee
---
drivers/s390/char/vmur.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/s390/char/vmur.c b/drivers/s390/char/vmur.c
index a532e54..6c30e93a 100644
--- a/drivers/s390/char/vmur.c
+++ b/drivers/s390/char/vmur.c
@@ -782,8 +782,6 @@ static int ur_release(struct inode *inode, struct file
*file)
static loff_t ur_llseek(struct file *file, loff_t offset, int whence)
{
- loff_t newpos;
-
if ((file->f_flags & O_ACCMODE) != O_RDONLY)
return -ESPIPE; /* seek allowed only for reader */
if (offset % PAGE_SIZE)
--
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 v4 2/2] zram: try vmalloc() after kmalloc()
On (12/22/15 12:10), Kyeongdon Kim wrote: [..] > > Hello Kyeongdon, > > > > just to make sure, the patch works fine for you and we can move > > forward and Cc -stable. correct? > > > > -ss > > > Hello Sergey, > > I was on vacation so I checked your email a moment ago, sorry about it. > We're using this patch set. and we couldn't find any issue from this one > until now. Hi, no problem, thanks. -ss -- 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] s390: fix build failure
On Mon, Dec 21, 2015 at 10:40 PM, Sudip Mukherjee
wrote:
> s390 defconfig fails with the error:
> ERROR: "phys_to_pfn_t" [drivers/s390/block/dcssblk.ko] undefined!
>
> We need CONFIG_HAS_IOMEM for phys_to_pfn_t() and for that we need to
> have CONFIG_PCI.
>
> Fixes: bfac97e7b361 ("mm, dax, pmem: introduce pfn_t")
> Cc: Dan Williams
> Cc: Andrew Morton
> Signed-off-by: Sudip Mukherjee
> ---
Hi, I fixed this build breakage in v4 of the patch series that
introduces phys_to_pfn_t() [1]. Chnaging the config is not correct
the HAS_IOMEM dependency for the symbol needs to be satisfied.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-December/003610.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
On 2015/12/22 12:37, Wu, Feng wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Yang Zhang
Sent: Monday, December 21, 2015 10:06 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
priority interrupts
On 2015/12/21 9:50, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Monday, December 21, 2015 9:46 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
priority interrupts
On 2015/12/16 9:37, Feng Wu wrote:
Use vector-hashing to deliver lowest-priority interrupts, As an
example, modern Intel CPUs in server platform use this method to
handle lowest-priority interrupts.
Signed-off-by: Feng Wu
---
arch/x86/kvm/irq_comm.c | 27 ++-
arch/x86/kvm/lapic.c| 57
-
arch/x86/kvm/lapic.h| 2 ++
arch/x86/kvm/x86.c | 9
arch/x86/kvm/x86.h | 1 +
5 files changed, 81 insertions(+), 15 deletions(-)
bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic
*src,
struct kvm_lapic_irq *irq, int *r, unsigned long *dest_map)
{
@@ -731,17 +747,38 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm
*kvm, struct kvm_lapic *src,
dst = map->logical_map[cid];
if (kvm_lowest_prio_delivery(irq)) {
- int l = -1;
- for_each_set_bit(i, , 16) {
- if (!dst[i])
- continue;
- if (l < 0)
- l = i;
- else if (kvm_apic_compare_prio(dst[i]->vcpu,
dst[l]->vcpu) < 0)
- l = i;
+ if (!kvm_vector_hashing_enabled()) {
+ int l = -1;
+ for_each_set_bit(i, , 16) {
+ if (!dst[i])
+ continue;
+ if (l < 0)
+ l = i;
+ else if (kvm_apic_compare_prio(dst[i]-
vcpu, dst[l]->vcpu) < 0)
+ l = i;
+ }
+ bitmap = (l >= 0) ? 1 << l : 0;
+ } else {
+ int idx = 0;
+ unsigned int dest_vcpus = 0;
+
+ for_each_set_bit(i, , 16) {
+ if (!dst[i]
&& !kvm_lapic_enabled(dst[i]->vcpu)) {
It should be or(||) not and (&&).
Oh, you are right! My negligence! Thanks for pointing this out, Yang!
btw, i think the kvm_lapic_enabled check is wrong here? Why need it here?
If the lapic is not enabled, I think we cannot recognize it as a candidate, can
we?
Maybe Radim can confirm this, Radim, what is your option?
Lapic can be disable by hw or sw. Here we only need to check the hw is
enough which is already covered while injecting the interrupt into
guest. I remember we(Glab, Macelo and me) have discussed it several ago,
but i cannot find the mail thread.
Thanks,
Feng
--
best regards
yang
--
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] KVM: x86: Add lowest-priority support for vt-d posted-interrupts
On 2015/12/22 12:36, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Monday, December 21, 2015 10:01 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] KVM: x86: Add lowest-priority support for vt-d
posted-interrupts
On 2015/12/21 9:55, Wu, Feng wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Yang Zhang
Sent: Monday, December 21, 2015 9:50 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] KVM: x86: Add lowest-priority support for vt-d
posted-interrupts
On 2015/12/16 9:37, Feng Wu wrote:
Use vector-hashing to deliver lowest-priority interrupts for
VT-d posted-interrupts.
Signed-off-by: Feng Wu
---
arch/x86/kvm/lapic.c | 67
arch/x86/kvm/lapic.h | 2 ++
arch/x86/kvm/vmx.c | 12 --
3 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index e29001f..d4f2c8f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -854,6 +854,73 @@ out:
}
/*
+ * This routine handles lowest-priority interrupts using vector-hashing
+ * mechanism. As an example, modern Intel CPUs use this method to
handle
+ * lowest-priority interrupts.
+ *
+ * Here is the details about the vector-hashing mechanism:
+ * 1. For lowest-priority interrupts, store all the possible destination
+ *vCPUs in an array.
+ * 2. Use "guest vector % max number of destination vCPUs" to find the
right
+ *destination vCPU in the array for the lowest-priority interrupt.
+ */
+struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
+ struct kvm_lapic_irq *irq)
+{
+ struct kvm_apic_map *map;
+ struct kvm_vcpu *vcpu = NULL;
+
+ if (irq->shorthand)
+ return NULL;
+
+ rcu_read_lock();
+ map = rcu_dereference(kvm->arch.apic_map);
+
+ if (!map)
+ goto out;
+
+ if ((irq->dest_mode != APIC_DEST_PHYSICAL) &&
+ kvm_lowest_prio_delivery(irq)) {
+ u16 cid;
+ int i, idx = 0;
+ unsigned long bitmap = 1;
+ unsigned int dest_vcpus = 0;
+ struct kvm_lapic **dst = NULL;
+
+
+ if (!kvm_apic_logical_map_valid(map))
+ goto out;
+
+ apic_logical_id(map, irq->dest_id, , (u16 *));
+
+ if (cid >= ARRAY_SIZE(map->logical_map))
+ goto out;
+
+ dst = map->logical_map[cid];
+
+ for_each_set_bit(i, , 16) {
+ if (!dst[i] && !kvm_lapic_enabled(dst[i]->vcpu)) {
+ clear_bit(i, );
+ continue;
+ }
+ }
+
+ dest_vcpus = hweight16(bitmap);
+
+ if (dest_vcpus != 0) {
+ idx = kvm_vector_2_index(irq->vector, dest_vcpus,
+, 16);
+ vcpu = dst[idx-1]->vcpu;
+ }
+ }
+
+out:
+ rcu_read_unlock();
+ return vcpu;
+}
+EXPORT_SYMBOL_GPL(kvm_intr_vector_hashing_dest);
+
+/*
* Add a pending IRQ into lapic.
* Return 1 if successfully added and 0 if discarded.
*/
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 6890ef0..52bffce 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -172,4 +172,6 @@ bool kvm_intr_is_single_vcpu_fast(struct kvm *kvm,
struct kvm_lapic_irq *irq,
struct kvm_vcpu **dest_vcpu);
int kvm_vector_2_index(u32 vector, u32 dest_vcpus,
const unsigned long *bitmap, u32 bitmap_size);
+struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
+ struct kvm_lapic_irq *irq);
#endif
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5eb56ed..3f89189 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10702,8 +10702,16 @@ static int vmx_update_pi_irte(struct kvm
*kvm,
unsigned int host_irq,
*/
kvm_set_msi_irq(e, );
- if (!kvm_intr_is_single_vcpu(kvm, , ))
- continue;
+
+ if (!kvm_intr_is_single_vcpu(kvm, , )) {
+ if (!kvm_vector_hashing_enabled() ||
+ irq.delivery_mode !=
APIC_DM_LOWEST)
+ continue;
+
+ vcpu = kvm_intr_vector_hashing_dest(kvm, );
+ if (!vcpu)
+ continue;
+ }
I am a little confused with the 'continue'.
[PATCH] s390: fix build failure
s390 defconfig fails with the error:
ERROR: "phys_to_pfn_t" [drivers/s390/block/dcssblk.ko] undefined!
We need CONFIG_HAS_IOMEM for phys_to_pfn_t() and for that we need to
have CONFIG_PCI.
Fixes: bfac97e7b361 ("mm, dax, pmem: introduce pfn_t")
Cc: Dan Williams
Cc: Andrew Morton
Signed-off-by: Sudip Mukherjee
---
s390 defconfig with next-20151222 is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/98258271
arch/s390/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index 9256b48..e56b6df 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -207,3 +207,4 @@ CONFIG_CRC7=m
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
CONFIG_CMM=m
+CONFIG_PCI=y
--
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 1/6] perf, tools, stat: Abstract stat metrics printing
On Tue, Dec 22, 2015 at 02:16:30AM +0100, Andi Kleen wrote:
> > > - fprintf(out, " ");
> > > + print_metric(ctxp, NULL, NULL, "insn per cycle", 0);
> > > }
> > > total =
> > > avg_stats(_stalled_cycles_front_stats[ctx][cpu]);
> > > total = max(total,
> > > avg_stats(_stalled_cycles_back_stats[ctx][cpu]));
> > >
> > > + out->new_line(ctxp);
> > > if (total && avg) {
> > > ratio = total / avg;
> > > - fprintf(out, "\n");
> >
> > you haven't address my first comment in here
> > http://marc.info/?l=linux-kernel=144662610723134=2
>
> The new_line is always needed because stalled cycles is always printed.
>
> The reason it is always printed is that metric-only needs to see all the
> metrics for its column headers. That's why there are else cases
> everywhere.
please notice extra line below - between instructions and cycles lines
[jolsa@krava perf]$ ./perf stat -e instructions,cycles kill
kill: not enough arguments
Performance counter stats for 'kill':
769,784 instructions #0.78 insn per cycle
990,795 cycles
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/
Inconsistent description in memory-barrier.txt
Hi, Paul,
I noticed that in the control dependency section in
memory-barrier.txt, you mistakenly made an inconsistent
description:
On the description part:
641 It is tempting to try to enforce ordering on identical stores on both
642 branches of the "if" statement as follows:
643
644 q = READ_ONCE(a);
645 if (q) {
646 barrier();
647 WRITE_ONCE(b, p);
648 do_something();
649 } else {
650 barrier();
651 WRITE_ONCE(b, p);
652 do_something_else();
653 }
654
655 Unfortunately, current compilers will transform this as follows at high
656 optimization levels:
657
658 q = READ_ONCE(a);
659 barrier();
660 WRITE_ONCE(b, p); /* BUG: No ordering vs. load from a!!! */
661 if (q) {
662 /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
663 do_something();
664 } else {
665 /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
666 do_something_else();
667 }
668
This part is incorporated in commit 2456d2a617de ("memory-barriers: Fix
description of 2-legged-if-based control dependencies") on 2014-08-13.
However, on the summary part:
803 (*) If both legs of the "if" statement begin with identical stores
804 to the same variable, a barrier() statement is required at the
805 beginning of each leg of the "if" statement.
This part is incorporated in commit 9b2b3bf53124
("Documentation/memory-barriers.txt:
Need barriers() for some control dependencies"), on 2014-02-12.
I think you missed fixing the summary part?
Thanks,
Jianyu Zhan
--
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] ASoC: atmel_wm8904: add snd_soc_pm_ops
Sometimes the audio play can not be resumed after it is
suspended. Add snd_soc_pm_ops to execute power management
operations, then this issue is fixed.
Signed-off-by: Songjun Wu
---
sound/soc/atmel/atmel_wm8904.c |1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/atmel/atmel_wm8904.c b/sound/soc/atmel/atmel_wm8904.c
index 1933bcd..fdd28ed 100644
--- a/sound/soc/atmel/atmel_wm8904.c
+++ b/sound/soc/atmel/atmel_wm8904.c
@@ -183,6 +183,7 @@ static struct platform_driver atmel_asoc_wm8904_driver = {
.driver = {
.name = "atmel-wm8904-audio",
.of_match_table = of_match_ptr(atmel_asoc_wm8904_dt_ids),
+ .pm = _soc_pm_ops,
},
.probe = atmel_asoc_wm8904_probe,
.remove = atmel_asoc_wm8904_remove,
--
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:Hello
Hello Christmas day is coming We are holding a big activity this week tv, brand watch, laptop, bicycle, gultat, dj, Samsung products all of our product can be offered 50% discount iphone 6s, 420USD si te: poazzlo .com
Re: IO errors after "block: remove bio_get_nr_vecs()"
On Tue, Dec 22, 2015 at 10:59:09AM +0500, Artem S. Tashkinov wrote: > On 2015-12-22 10:55, Kent Overstreet wrote: > >On Tue, Dec 22, 2015 at 10:52:37AM +0500, Artem S. Tashkinov wrote: > >>On 2015-12-22 10:38, Kent Overstreet wrote: > >>>On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote: > On 12/22/15 12:59, Kent Overstreet wrote: > > reproduced it with 32 bit pae: > > > >> 1. Exclude memory above 4G line with boot param "max_addr=4G". > > > > doesn't work - max_addr=1G doesn't work either > > > >> 2. Disable highmem with "highmem=0". > > > > works! > > > >> 3. Try booting 64bit kernel. > > > > works > > blk_queue_bio() does split then bounce, which makes the segment > counting based on pages before bouncing and could go wrong. > > What do you think of a patch like this? > >>> > >>>Artem, can you give this patch a try? > >> > >> > >>This patch ostensibly fixes the issue - at least I cannot immediately > >>reproduce it. You can count me in as "Tested-by: Artem S. Tashkinov" > > > >Let's all contemplate the fact that blk_segment_map_sg() _overrunning the > >end of > >the provided sglist_ was this much of a clusterfuck to debug. > > From the look of it this fix has nothing to do with PAE, so then why only > PAE users like me were affected by the original > (b54ffb73cadcdcff9cc1ae0e11f502407e3e2e4c) patch? The amusing thing is that I doubt PAE actually requires bouncing - addressing limits come from the device, not the cpu. But evidently in PAE mode, the block layer is in fact bouncing bios. Probably from some default setting in the queue limits that no one ever looks at. The whole queue limits design is an atrocity, it leads to exactly this kind of crap where no one can predict the actual behaviour of any given setup. -- 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] Revert "kernel/stop_machine.c: remove CONFIG_SMP dependencies"
On Fri, Dec 18, 2015 at 03:07:53PM -0800, Andrew Morton wrote:
> On Fri, 18 Dec 2015 15:35:55 +0530 Sudip Mukherjee
> wrote:
>
> > This reverts commit 64dab25b058c12f935794cb239089303bda7dbc1.
> >
> > CONFIG_SMP dependency is needed for some arch like tile, tilegx and
> > m32r. They use stop_machine() but they donot have HOTPLUG_CPU and as a
> > result their builds are failing with "undefined symbol 'stop_machine'".
>
> Thanks. I had my &&'s and ||'s mixed up. I did this:
>
> ---
> a/kernel/stop_machine.c~kernel-stop_machinec-remove-config_smp-dependencies-fix
> +++ a/kernel/stop_machine.c
> @@ -531,8 +531,6 @@ static int __init cpu_stop_init(void)
> }
> early_initcall(cpu_stop_init);
>
> -#ifdef CONFIG_HOTPLUG_CPU
> -
> static int __stop_machine(cpu_stop_fn_t fn, void *data, const struct cpumask
> *cpus)
> {
> struct multi_stop_data msdata = {
> @@ -630,5 +628,3 @@ int stop_machine_from_inactive_cpu(cpu_s
> mutex_unlock(_cpus_mutex);
> return ret ?: done.ret;
> }
> -
> -#endif /* CONFIG_HOTPLUG_CPU */
> _
>
>
> Rationale:
>
> stop_machine.o is only built when CONFIG_SMP=y so
>
> #if defined(CONFIG_SMP) || defined(CONFIG_HOTPLUG_CPU)
>
> always evaluates to true, so remove it.
Hi Andrew,
The error is still there. I guess you have been busy. :)
next-20151222 fails with the same error. You can see the m32r defconfig
at https://travis-ci.org/sudipm-mukherjee/parport/jobs/98258267
do you want me to send the patch to you for it?
regards
sudip
--
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: IO errors after "block: remove bio_get_nr_vecs()"
On 2015-12-22 10:55, Kent Overstreet wrote: On Tue, Dec 22, 2015 at 10:52:37AM +0500, Artem S. Tashkinov wrote: On 2015-12-22 10:38, Kent Overstreet wrote: >On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote: >>On 12/22/15 12:59, Kent Overstreet wrote: >>> reproduced it with 32 bit pae: >>> 1. Exclude memory above 4G line with boot param "max_addr=4G". >>> >>> doesn't work - max_addr=1G doesn't work either >>> 2. Disable highmem with "highmem=0". >>> >>> works! >>> 3. Try booting 64bit kernel. >>> >>> works >> >>blk_queue_bio() does split then bounce, which makes the segment >>counting based on pages before bouncing and could go wrong. >> >>What do you think of a patch like this? > >Artem, can you give this patch a try? This patch ostensibly fixes the issue - at least I cannot immediately reproduce it. You can count me in as "Tested-by: Artem S. Tashkinov" Let's all contemplate the fact that blk_segment_map_sg() _overrunning the end of the provided sglist_ was this much of a clusterfuck to debug. From the look of it this fix has nothing to do with PAE, so then why only PAE users like me were affected by the original (b54ffb73cadcdcff9cc1ae0e11f502407e3e2e4c) patch? -- 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 v7 4/5] iommu/mediatek: Add mt8173 IOMMU driver
On Fri, 2015-12-18 at 17:44 +, Robin Murphy wrote:
> On 18/12/15 08:09, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> >
> > Signed-off-by: Yong Wu
> > ---
> > drivers/iommu/Kconfig | 14 +
> > drivers/iommu/Makefile| 1 +
> > drivers/iommu/mtk_iommu.c | 734
> > ++
> > 3 files changed, 749 insertions(+)
> > create mode 100644 drivers/iommu/mtk_iommu.c
> >
>
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > new file mode 100644
> > index 000..d000d31
> > --- /dev/null
> > +++ b/drivers/iommu/mtk_iommu.c
>
> [...]
>
> > +#define REG_MMU_CTRL_REG 0x110
> > +#define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4)
> > +#define F_MMU_TF_PROTECT_SEL(prot) (((prot) & 0x3) << 5)
> > +#define F_COHERENCE_EN BIT(8)
>
> [...]
>
> > +static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > +{
> > + u32 regval;
> > + int ret;
> > +
> > + ret = clk_prepare_enable(data->bclk);
> > + if (ret) {
> > + dev_err(data->dev, "Failed to enable iommu bclk(%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> > + F_MMU_TF_PROTECT_SEL(2) |
> > + F_COHERENCE_EN;
>
> I meant to ask this last time - does setting F_COHERENCE_EN here imply
> that the M4U is capable of cache-coherent page table walks, or something
> else? If it's the former, and assuming the MT8173 is actually wired up
> to support that, then you should add a dma-coherent property to its DT
> node in patch 5 (which will also save you all the cache flushes on page
> table updates).
No. F_COHERENCE_EN is not for m4u's cache-coherent page table walking.
More about it: There are two iommu cells in the HW. one is
perisys-iommu, the other is mm-iommu. The perisys-iommu currently is not
contained in this upstream version. it will support this F_COHERENCE_EN
bit which will enable coherence access for the master port if the
sharable(S) bit is set in the pagetable descriptor.
And in the mm-iommu, the iommu HW will work regardless of this bit.
So I will delete this bit for readable as this is m4u(mm-iommu) in next
time.
>
> > + writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
> > +
> > + regval = F_L2_MULIT_HIT_EN |
> > + F_TABLE_WALK_FAULT_INT_EN |
> > + F_PREETCH_FIFO_OVERFLOW_INT_EN |
> > + F_MISS_FIFO_OVERFLOW_INT_EN |
> > + F_PREFETCH_FIFO_ERR_INT_EN |
> > + F_MISS_FIFO_ERR_INT_EN;
> > + writel_relaxed(regval, data->base + REG_MMU_INT_CONTROL0);
> > +
> > + regval = F_INT_TRANSLATION_FAULT |
> > + F_INT_MAIN_MULTI_HIT_FAULT |
> > + F_INT_INVALID_PA_FAULT |
> > + F_INT_ENTRY_REPLACEMENT_FAULT |
> > + F_INT_TLB_MISS_FAULT |
> > + F_INT_MISS_TRANSATION_FIFO_FAULT |
> > + F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
> > + writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
> > +
> > + regval = F_MMU_IVRP_PA_SET(data->protect_base);
> > + writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
> > +
> > + writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> > + writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
> > +
> > + if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> > +dev_name(data->dev), (void *)data)) {
> > + writel_relaxed(0, data->base + REG_MMU_PT_BASE_ADDR);
> > + clk_disable_unprepare(data->bclk);
> > + dev_err(data->dev, "Failed @ IRQ-%d Request\n", data->irq);
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
>
> Otherwise, I've not had the chance to go through this thoroughly but at
> a glance it seems in pretty good shape now - nothing immediately jumps
> out as looking wrong or worth making a fuss over.
>
> Thanks,
> Robin.
--
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: IO errors after "block: remove bio_get_nr_vecs()"
On Tue, Dec 22, 2015 at 10:52:37AM +0500, Artem S. Tashkinov wrote: > On 2015-12-22 10:38, Kent Overstreet wrote: > >On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote: > >>On 12/22/15 12:59, Kent Overstreet wrote: > >>> reproduced it with 32 bit pae: > >>> > 1. Exclude memory above 4G line with boot param "max_addr=4G". > >>> > >>> doesn't work - max_addr=1G doesn't work either > >>> > 2. Disable highmem with "highmem=0". > >>> > >>> works! > >>> > 3. Try booting 64bit kernel. > >>> > >>> works > >> > >>blk_queue_bio() does split then bounce, which makes the segment > >>counting based on pages before bouncing and could go wrong. > >> > >>What do you think of a patch like this? > > > >Artem, can you give this patch a try? > > > This patch ostensibly fixes the issue - at least I cannot immediately > reproduce it. You can count me in as "Tested-by: Artem S. Tashkinov" Let's all contemplate the fact that blk_segment_map_sg() _overrunning the end of the provided sglist_ was this much of a clusterfuck to debug. -- 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: IO errors after "block: remove bio_get_nr_vecs()"
On 2015-12-22 10:38, Kent Overstreet wrote:
On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote:
On 12/22/15 12:59, Kent Overstreet wrote:
> reproduced it with 32 bit pae:
>
>> 1. Exclude memory above 4G line with boot param "max_addr=4G".
>
> doesn't work - max_addr=1G doesn't work either
>
>> 2. Disable highmem with "highmem=0".
>
> works!
>
>> 3. Try booting 64bit kernel.
>
> works
blk_queue_bio() does split then bounce, which makes the segment
counting based on pages before bouncing and could go wrong.
What do you think of a patch like this?
Artem, can you give this patch a try?
This patch ostensibly fixes the issue - at least I cannot immediately
reproduce it. You can count me in as "Tested-by: Artem S. Tashkinov"
--
Jun'ichi Nomura, NEC Corporation
diff --git a/block/blk-core.c b/block/blk-core.c
index 5131993b..1d1c3c7 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1689,8 +1689,6 @@ static blk_qc_t blk_queue_bio(struct
request_queue *q, struct bio *bio)
struct request *req;
unsigned int request_count = 0;
- blk_queue_split(q, , q->bio_split);
-
/*
* low level driver can indicate that it wants pages above a
* certain limit bounced to low memory (ie for highmem, or even
@@ -1698,6 +1696,8 @@ static blk_qc_t blk_queue_bio(struct
request_queue *q, struct bio *bio)
*/
blk_queue_bounce(q, );
+ blk_queue_split(q, , q->bio_split);
+
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio->bi_error = -EIO;
bio_endio(bio);
--
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] ASoC: rt5616: add an of_match table
Add a device tree match table. This serves to make the driver's support
of device tree more explicit.
Signed-off-by: Caesar Wang
---
Changes in v2: None
Changes in v1: None
sound/soc/codecs/rt5616.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/codecs/rt5616.c b/sound/soc/codecs/rt5616.c
index f4005cb..e01a32d 100644
--- a/sound/soc/codecs/rt5616.c
+++ b/sound/soc/codecs/rt5616.c
@@ -1287,6 +1287,14 @@ static const struct i2c_device_id rt5616_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, rt5616_i2c_id);
+#if defined(CONFIG_OF)
+static const struct of_device_id rt5616_of_match[] = {
+ { .compatible = "realtek,rt5616", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rt5616_of_match);
+#endif
+
static int rt5616_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -1359,6 +1367,7 @@ static void rt5616_i2c_shutdown(struct i2c_client *client)
static struct i2c_driver rt5616_i2c_driver = {
.driver = {
.name = "rt5616",
+ .of_match_table = of_match_ptr(rt5616_of_match),
},
.probe = rt5616_i2c_probe,
.remove = rt5616_i2c_remove,
--
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 v2 2/2] dt-bindings: sound: add devicetree document for rt5616
Add the description for rt5616 codec.
Signed-off-by: Caesar Wang
---
Changes in v2:
- As Frank comments, rt5616@1b to instead of rt5616.
- Update the Pins device from Bard.
Changes in v1:
- As Heiko comments, remove the not exist option properties.
Documentation/devicetree/bindings/sound/rt5616.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt
diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt
b/Documentation/devicetree/bindings/sound/rt5616.txt
new file mode 100644
index 000..efc48c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5616.txt
@@ -0,0 +1,26 @@
+RT5616 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "realtek,rt5616".
+
+- reg : The I2C address of the device.
+
+Pins on the device (for linking into audio routes) for RT5616:
+
+ * IN1P
+ * IN2P
+ * IN2N
+ * LOUTL
+ * LOUTR
+ * HPOL
+ * HPOR
+
+Example:
+
+codec: rt5616@1b {
+ compatible = "realtek,rt5616";
+ reg = <0x1b>;
+};
--
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/
linux-next: build failure after merge of the gpio tree
Hi Linus,
After merging the gpio tree, today's linux-next build (lots without
CONFIG_OF) failed like this:
drivers/gpio/gpio-pxa.c: In function 'pxa_gpio_probe':
drivers/gpio/gpio-pxa.c:648:12: error: 'pxa_irq_domain_ops' undeclared (first
use in this function)
Caused by commit
384ca3c6a28d ("gpio: pxa: change the interrupt management")
The reference to pxa_irq_domain_ops was moved out of the protection of
CONFIG_OF ...
Discovered after the release.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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: comedi: fix block comments coding style issue in comedi.h
Fix up block comments to make a trailing */ on a separate line
Signed-off-by: maomao xu
---
drivers/staging/comedi/comedi.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index 66edda1..ec5e59c 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -895,7 +895,8 @@ enum amplc_dio_ts_clock_src {
};
/* Values for setting a gate source with INSN_CONFIG_SET_GATE_SRC for
- * 8254 counter subdevices on Amplicon DIO boards (amplc_dio200 driver). */
+ * 8254 counter subdevices on Amplicon DIO boards (amplc_dio200 driver).
+ */
enum amplc_dio_gate_source {
AMPLC_DIO_GAT_VCC, /* internal high logic level */
AMPLC_DIO_GAT_GND, /* internal low logic level */
--
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] dmaengine: dw: clear LLP_[SD]_EN bits in last descriptor of a chain
On 21-12-15, 19:10, Mans Rullgard wrote: > The datasheet requires that the LLP_[SD]_EN bits be cleared whenever > LLP.LOC is zero, i.e. in the last descriptor of a multi-block chain. > Make the driver do this. > > Signed-off-by: Mans Rullgard > --- > drivers/dma/dw/core.c | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Viresh Kumar -- viresh -- 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: IO errors after "block: remove bio_get_nr_vecs()"
On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote:
> On 12/22/15 12:59, Kent Overstreet wrote:
> > reproduced it with 32 bit pae:
> >
> >> 1. Exclude memory above 4G line with boot param "max_addr=4G".
> >
> > doesn't work - max_addr=1G doesn't work either
> >
> >> 2. Disable highmem with "highmem=0".
> >
> > works!
> >
> >> 3. Try booting 64bit kernel.
> >
> > works
>
> blk_queue_bio() does split then bounce, which makes the segment
> counting based on pages before bouncing and could go wrong.
>
> What do you think of a patch like this?
Artem, can you give this patch a try?
>
> --
> Jun'ichi Nomura, NEC Corporation
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 5131993b..1d1c3c7 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1689,8 +1689,6 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
> struct bio *bio)
> struct request *req;
> unsigned int request_count = 0;
>
> - blk_queue_split(q, , q->bio_split);
> -
> /*
>* low level driver can indicate that it wants pages above a
>* certain limit bounced to low memory (ie for highmem, or even
> @@ -1698,6 +1696,8 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
> struct bio *bio)
>*/
> blk_queue_bounce(q, );
>
> + blk_queue_split(q, , q->bio_split);
> +
> if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
> bio->bi_error = -EIO;
> bio_endio(bio);
--
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: IO errors after "block: remove bio_get_nr_vecs()"
On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote:
> On 12/22/15 12:59, Kent Overstreet wrote:
> > reproduced it with 32 bit pae:
> >
> >> 1. Exclude memory above 4G line with boot param "max_addr=4G".
> >
> > doesn't work - max_addr=1G doesn't work either
> >
> >> 2. Disable highmem with "highmem=0".
> >
> > works!
> >
> >> 3. Try booting 64bit kernel.
> >
> > works
>
> blk_queue_bio() does split then bounce, which makes the segment
> counting based on pages before bouncing and could go wrong.
>
> What do you think of a patch like this?
Shit, you nailed it. Can't believe I didn't think to check that.
>
> --
> Jun'ichi Nomura, NEC Corporation
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 5131993b..1d1c3c7 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1689,8 +1689,6 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
> struct bio *bio)
> struct request *req;
> unsigned int request_count = 0;
>
> - blk_queue_split(q, , q->bio_split);
> -
> /*
>* low level driver can indicate that it wants pages above a
>* certain limit bounced to low memory (ie for highmem, or even
> @@ -1698,6 +1696,8 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
> struct bio *bio)
>*/
> blk_queue_bounce(q, );
>
> + blk_queue_split(q, , q->bio_split);
> +
> if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
> bio->bi_error = -EIO;
> bio_endio(bio);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] blackfin-cpufreq: Mark cpu_set_cclk() as static
On 21-12-15, 22:32, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 21 Dec 2015 22:12:26 +0100 > > The cpu_set_cclk() function was only used in a single source file so far. > Indicate this setting also by the corresponding linkage specifier. > > Signed-off-by: Markus Elfring > Acked-by: Viresh Kumar Well, I never Acked this patch as such and you shouldn't have mentioned it by yourself. But it looks fine otherwise and so Acked-by: Viresh Kumar -- viresh -- 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] mm: change find_vma() function
> On Dec 15, 2015, at 19:53, Kirill A. Shutemov > wrote: > > On Tue, Dec 15, 2015 at 02:41:21PM +0800, yalin wang wrote: >>> On Dec 15, 2015, at 05:11, Kirill A. Shutemov wrote: >>> Anyway, I don't think it's possible to gain anything measurable from this >>> optimization. >>> >> the advantage is that if addr don’t belong to any vma, we don’t need loop >> all vma, >> we can break earlier if we found the most closest vma which vma->end_add > >> addr, > > Do you have any workload which can demonstrate the advantage? > > — i add the log in find_vma() to see the call stack , it is very efficient in mmap() / munmap / do_execve() / get_unmaped_area() / mem_cgroup_move_task()->walk_page_range()->find_vma() call , in most time the loop will break after search about 7 vm, i don’t consider the cache pollution problem in this patch, yeah, this patch will check the vm_prev->vm_end for every loop, but this only happened when tmp->vm_end > addr , if you don’t not check this , you will continue to loop to check next rb , this will also pollute the cache , so the question is which one is better ? i don’t have a better method to test this . Any good ideas about this ? how to test it ? 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: [char-misc-next v3 4/8] watchdog: mei_wdt: add status debugfs entry
On 12/21/2015 03:17 PM, Tomas Winkler wrote:
Add entry for dumping current watchdog internal state
Signed-off-by: Tomas Winkler
---
V2: new in the series
V3: rebase
drivers/watchdog/mei_wdt.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index 5b28a1e95ac1..ab9aec218d69 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -54,6 +55,24 @@ enum mei_wdt_state {
MEI_WDT_STOPPING,
};
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static const char *mei_wdt_state_str(enum mei_wdt_state state)
+{
+ switch (state) {
+ case MEI_WDT_IDLE:
+ return "IDLE";
+ case MEI_WDT_START:
+ return "START";
+ case MEI_WDT_RUNNING:
+ return "RUNNING";
+ case MEI_WDT_STOPPING:
+ return "STOPPING";
+ default:
+ return "unknown";
+ }
+}
+#endif /* CONFIG_DEBUG_FS */
+
I still don't understand why this code has to be here instead of
further below (at <> mark).
struct mei_wdt;
/**
@@ -76,6 +95,8 @@ struct mei_wdt_dev {
* @cldev: mei watchdog client device
* @state: watchdog internal state
* @timeout: watchdog current timeout
+ *
+ * @dbgfs_dir: debugfs dir entry
*/
struct mei_wdt {
struct mei_wdt_dev *mwd;
@@ -83,6 +104,10 @@ struct mei_wdt {
struct mei_cl_device *cldev;
enum mei_wdt_state state;
u16 timeout;
+
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+ struct dentry *dbgfs_dir;
+#endif /* CONFIG_DEBUG_FS */
};
/*
@@ -387,6 +412,65 @@ static int mei_wdt_register(struct mei_wdt *wdt)
return 0;
}
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+
<>
+static ssize_t mei_dbgfs_read_state(struct file *file, char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ struct mei_wdt *wdt = file->private_data;
+ const size_t bufsz = 32;
+ char buf[32];
+ ssize_t pos = 0;
+
+ pos += scnprintf(buf + pos, bufsz - pos, "state: %s\n",
+mei_wdt_state_str(wdt->state));
+
Seems to me that "pos = ..." would accomplish exactly the same
without having to pre-initialize pos. I also don't understand the use of
"+ pos" and "- pos" in the parameter field. pos is 0, isn't it ?
When would it ever be non-0 ?
pos = scnprintf(buf, sizeof(buf), "state: %s\n",
mei_wdt_state_str(wdt->state));
What am I missing here ?
+ return simple_read_from_buffer(ubuf, cnt, ppos, buf, pos);
+}
+
+static const struct file_operations dbgfs_fops_state = {
+ .open = simple_open,
+ .read = mei_dbgfs_read_state,
+ .llseek = generic_file_llseek,
+};
+
+static void dbgfs_unregister(struct mei_wdt *wdt)
+{
+ if (!wdt->dbgfs_dir)
+ return;
+ debugfs_remove_recursive(wdt->dbgfs_dir);
debugfs_remove_recursive() checks if the parameter is NULL,
so it is not necessary to check if it is NULL before the call.
+ wdt->dbgfs_dir = NULL;
+}
+
+static int dbgfs_register(struct mei_wdt *wdt)
+{
+ struct dentry *dir, *f;
+
+ dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ if (!dir)
+ return -ENOMEM;
+
+ wdt->dbgfs_dir = dir;
+ f = debugfs_create_file("state", S_IRUSR, dir, wdt, _fops_state);
+ if (!f)
+ goto err;
+
+ return 0;
+err:
+ dbgfs_unregister(wdt);
+ return -ENODEV;
The error value is ignored by the caller - why bother returning an error in the
first place ?
+}
+
+#else
+
+static inline void dbgfs_unregister(struct mei_wdt *wdt) {}
+
+static inline int dbgfs_register(struct mei_wdt *wdt)
+{
+ return 0;
+}
+#endif /* CONFIG_DEBUG_FS */
+
static int mei_wdt_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
@@ -414,6 +498,8 @@ static int mei_wdt_probe(struct mei_cl_device *cldev,
if (ret)
goto err_disable;
+ dbgfs_register(wdt);
+
return 0;
err_disable:
@@ -433,6 +519,8 @@ static int mei_wdt_remove(struct mei_cl_device *cldev)
mei_cldev_disable(cldev);
+ dbgfs_unregister(wdt);
+
kfree(wdt);
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/
linux-next: Tree for Dec 22
Hi all, Changes since 20151221: I added a patch to the orangefs tree for a post release discovered build failure. The i2c tree still had its build failure for which I applied a patch. The drm tree gained a conflict against the imx-mxs tree. The drm-intel tree gained a conflict against Linus' tree. The pinctrl tree lost its build failure. The gpio tree lost its build failure. Non-merge commits (relative to Linus' tree): 7020 7310 files changed, 290228 insertions(+), 117897 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4ef7675344d6 Linux 4.4-rc6) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (07fd7d4bbcb9 ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE) Merging arm-current/fixes (34bfbae33ae8 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (036592fbbe75 powerpc/opal-irqchip: Fix deadlock introduced by "Fix double endian conversion") Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73796d8bf273 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (987aaad93a4c Merge branch 'cdc_ncm-new-Dell-devices') Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (01d85b9b2b6b Merge tag 'iwlwifi-for-kalle-2015-12-16' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (cf1e05c63642 mac80211: handle width changes from opmode notification IE in beacon) Merging sound-current/for-linus (3e6db33aaf1d ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()) Merging pci-current/for-linus (1dbe162d53e1 PCI: hisi: Fix hisi_pcie_cfg_read() 32-bit reads) Merging driver-core.current/driver-core-linus (4ef7675344d6 Linux 4.4-rc6) Merging tty.current/tty-linus (4ef7675344d6 Linux 4.4-rc6) Merging usb.current/usb-linus (4ef7675344d6 Linux 4.4-rc6) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (9f9499ae8e64 Linux 4.4-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9f9499ae8e64 Linux 4.4-rc5) Merging char-misc.current/char-misc-linus (9f9499ae8e64 Linux 4.4-rc5) Merging input-current/for-linus (478e5ed1c3f6 Input: elants_i2c - fix wake-on-touch) Merging crypto-current/master (70d906bc1750 crypto: skcipher - Copy iv from desc even for 0-len walks) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_
RE: [f2fs-dev] [PATCH 1/2] f2fs: use atomic variable for total_extent_tree
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, December 22, 2015 11:39 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 1/2] f2fs: use atomic variable for
> total_extent_tree
>
> It would be better to use atomic variable for total_extent_tree.
total_extent_tree was protected by extent_tree_lock semaphore, so intention here
is to make related calculation in available_free_memory or update_general_status
more accurate, right?
Thanks,
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/debug.c| 5 +++--
> fs/f2fs/extent_cache.c | 8
> fs/f2fs/f2fs.h | 2 +-
> fs/f2fs/node.c | 3 ++-
> fs/f2fs/shrinker.c | 3 ++-
> 5 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index bb307e6..ed5dfcc 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -38,7 +38,7 @@ static void update_general_status(struct f2fs_sb_info *sbi)
> si->hit_rbtree = atomic64_read(>read_hit_rbtree);
> si->hit_total = si->hit_largest + si->hit_cached + si->hit_rbtree;
> si->total_ext = atomic64_read(>total_hit_ext);
> - si->ext_tree = sbi->total_ext_tree;
> + si->ext_tree = atomic_read(>total_ext_tree);
> si->ext_node = atomic_read(>total_ext_node);
> si->ndirty_node = get_pages(sbi, F2FS_DIRTY_NODES);
> si->ndirty_dent = get_pages(sbi, F2FS_DIRTY_DENTS);
> @@ -193,7 +193,8 @@ get_cache:
> si->cache_mem += si->inmem_pages * sizeof(struct inmem_pages);
> for (i = 0; i <= UPDATE_INO; i++)
> si->cache_mem += sbi->im[i].ino_num * sizeof(struct ino_entry);
> - si->cache_mem += sbi->total_ext_tree * sizeof(struct extent_tree);
> + si->cache_mem += atomic_read(>total_ext_tree) *
> + sizeof(struct extent_tree);
> si->cache_mem += atomic_read(>total_ext_node) *
> sizeof(struct extent_node);
>
> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> index e86e9f1e..0e97d6af 100644
> --- a/fs/f2fs/extent_cache.c
> +++ b/fs/f2fs/extent_cache.c
> @@ -70,7 +70,7 @@ static struct extent_tree *__grab_extent_tree(struct inode
> *inode)
> rwlock_init(>lock);
> atomic_set(>refcount, 0);
> et->count = 0;
> - sbi->total_ext_tree++;
> + atomic_inc(>total_ext_tree);
> }
> atomic_inc(>refcount);
> up_write(>extent_tree_lock);
> @@ -570,7 +570,7 @@ unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info
> *sbi, int
> nr_shrink)
>
> radix_tree_delete(root, et->ino);
> kmem_cache_free(extent_tree_slab, et);
> - sbi->total_ext_tree--;
> + atomic_dec(>total_ext_tree);
> tree_cnt++;
>
> if (node_cnt + tree_cnt >= nr_shrink)
> @@ -663,7 +663,7 @@ void f2fs_destroy_extent_tree(struct inode *inode)
> f2fs_bug_on(sbi, atomic_read(>refcount) || et->count);
> radix_tree_delete(>extent_tree_root, inode->i_ino);
> kmem_cache_free(extent_tree_slab, et);
> - sbi->total_ext_tree--;
> + atomic_dec(>total_ext_tree);
> up_write(>extent_tree_lock);
>
> F2FS_I(inode)->extent_tree = NULL;
> @@ -715,7 +715,7 @@ void init_extent_cache_info(struct f2fs_sb_info *sbi)
> init_rwsem(>extent_tree_lock);
> INIT_LIST_HEAD(>extent_list);
> spin_lock_init(>extent_lock);
> - sbi->total_ext_tree = 0;
> + atomic_set(>total_ext_tree, 0);
> atomic_set(>total_ext_node, 0);
> }
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 19beabe..a7f6191 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -762,7 +762,7 @@ struct f2fs_sb_info {
> struct rw_semaphore extent_tree_lock; /* locking extent radix tree */
> struct list_head extent_list; /* lru list for shrinker */
> spinlock_t extent_lock; /* locking extent lru list */
> - int total_ext_tree; /* extent tree count */
> + atomic_t total_ext_tree;/* extent tree count */
> atomic_t total_ext_node;/* extent info count */
>
> /* basic filesystem units */
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index d842b19..6cc8ac7 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -65,7 +65,8 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int
> type)
> sizeof(struct ino_entry)) >> PAGE_CACHE_SHIFT;
> res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 1);
> } else if (type == EXTENT_CACHE) {
> - mem_size = (sbi->total_ext_tree * sizeof(struct extent_tree) +
> + mem_size =
Re: IO errors after "block: remove bio_get_nr_vecs()"
On 12/22/15 12:59, Kent Overstreet wrote:
> reproduced it with 32 bit pae:
>
>> 1. Exclude memory above 4G line with boot param "max_addr=4G".
>
> doesn't work - max_addr=1G doesn't work either
>
>> 2. Disable highmem with "highmem=0".
>
> works!
>
>> 3. Try booting 64bit kernel.
>
> works
blk_queue_bio() does split then bounce, which makes the segment
counting based on pages before bouncing and could go wrong.
What do you think of a patch like this?
--
Jun'ichi Nomura, NEC Corporation
diff --git a/block/blk-core.c b/block/blk-core.c
index 5131993b..1d1c3c7 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1689,8 +1689,6 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
struct bio *bio)
struct request *req;
unsigned int request_count = 0;
- blk_queue_split(q, , q->bio_split);
-
/*
* low level driver can indicate that it wants pages above a
* certain limit bounced to low memory (ie for highmem, or even
@@ -1698,6 +1696,8 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
struct bio *bio)
*/
blk_queue_bounce(q, );
+ blk_queue_split(q, , q->bio_split);
+
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio->bi_error = -EIO;
bio_endio(bio);--
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: [f2fs-dev] [PATCH 2/2] f2fs: speed up shrinking extent tree entries
Hi Jaegeuk,
We should update _zombie_tree whenever removing unreferenced
extent tree during shrinking:
- f2fs_shrink_extent_tree
if (!atomic_read(>refcount)) {
...
atomic_dec(>total_ext_tree);
atomic_dec(>total_zombie_tree);
...
}
Other parts look good to me. :)
Reviewed-by: Chao Yu
Thanks,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, December 22, 2015 11:39 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 2/2] f2fs: speed up shrinking extent tree entries
>
> If there is no candidates for shrinking slab entries, we don't need to
> traverse
> any trees at all.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/extent_cache.c | 12
> fs/f2fs/f2fs.h | 1 +
> fs/f2fs/shrinker.c | 2 +-
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> index 0e97d6af..32693af 100644
> --- a/fs/f2fs/extent_cache.c
> +++ b/fs/f2fs/extent_cache.c
> @@ -71,6 +71,8 @@ static struct extent_tree *__grab_extent_tree(struct inode
> *inode)
> atomic_set(>refcount, 0);
> et->count = 0;
> atomic_inc(>total_ext_tree);
> + } else {
> + atomic_dec(>total_zombie_tree);
> }
> atomic_inc(>refcount);
> up_write(>extent_tree_lock);
> @@ -547,10 +549,14 @@ unsigned int f2fs_shrink_extent_tree(struct
> f2fs_sb_info *sbi, int
> nr_shrink)
> unsigned int found;
> unsigned int node_cnt = 0, tree_cnt = 0;
> int remained;
> + bool do_free = false;
>
> if (!test_opt(sbi, EXTENT_CACHE))
> return 0;
>
> + if (!atomic_read(>total_zombie_tree))
> + goto free_node;
> +
> if (!down_write_trylock(>extent_tree_lock))
> goto out;
>
> @@ -580,6 +586,7 @@ unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info
> *sbi, int
> nr_shrink)
> }
> up_write(>extent_tree_lock);
>
> +free_node:
> /* 2. remove LRU extent entries */
> if (!down_write_trylock(>extent_tree_lock))
> goto out;
> @@ -591,9 +598,13 @@ unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info
> *sbi, int
> nr_shrink)
> if (!remained--)
> break;
> list_del_init(>list);
> + do_free = true;
> }
> spin_unlock(>extent_lock);
>
> + if (do_free == false)
> + goto unlock_out;
> +
> /*
>* reset ino for searching victims from beginning of global extent tree.
>*/
> @@ -651,6 +662,7 @@ void f2fs_destroy_extent_tree(struct inode *inode)
>
> if (inode->i_nlink && !is_bad_inode(inode) && et->count) {
> atomic_dec(>refcount);
> + atomic_dec(>total_zombie_tree);
> return;
> }
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index a7f6191..90fb970 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -763,6 +763,7 @@ struct f2fs_sb_info {
> struct list_head extent_list; /* lru list for shrinker */
> spinlock_t extent_lock; /* locking extent lru list */
> atomic_t total_ext_tree;/* extent tree count */
> + atomic_t total_zombie_tree; /* extent zombie tree count */
> atomic_t total_ext_node;/* extent info count */
>
> /* basic filesystem units */
> diff --git a/fs/f2fs/shrinker.c b/fs/f2fs/shrinker.c
> index a11e099..93606f2 100644
> --- a/fs/f2fs/shrinker.c
> +++ b/fs/f2fs/shrinker.c
> @@ -32,7 +32,7 @@ static unsigned long __count_free_nids(struct f2fs_sb_info
> *sbi)
>
> static unsigned long __count_extent_cache(struct f2fs_sb_info *sbi)
> {
> - return atomic_read(>total_ext_tree) +
> + return atomic_read(>total_zombie_tree) +
> atomic_read(>total_ext_node);
> }
>
> --
> 2.5.4 (Apple Git-61)
>
>
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
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: IO errors after "block: remove bio_get_nr_vecs()"
On 2015-12-22 01:07, Tejun Heo wrote:
Hello, Artem.
Can you please apply the following patch on top and see whether
anything changes? If it does make the issue go away, can you please
revert the ".can_queue" part and test again?
Thanks.
---
drivers/ata/ahci.h|2 +-
drivers/ata/libahci.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -365,7 +365,7 @@ extern struct device_attribute *ahci_sde
*/
#define AHCI_SHT(drv_name) \
ATA_NCQ_SHT(drv_name), \
- .can_queue = AHCI_MAX_CMDS - 1,\
+ .can_queue = 1/*AHCI_MAX_CMDS - 1*/, \
.sg_tablesize = AHCI_MAX_SG, \
.dma_boundary = AHCI_DMA_BOUNDARY,\
.shost_attrs= ahci_shost_attrs, \
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -420,7 +420,7 @@ void ahci_save_initial_config(struct dev
hpriv->saved_cap2 = cap2 = 0;
/* some chips have errata preventing 64bit use */
- if ((cap & HOST_CAP_64) && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)) {
+ if ((cap & HOST_CAP_64)/* && (hpriv->flags &
AHCI_HFLAG_32BIT_ONLY)*/) {
dev_info(dev, "controller can't do 64bit DMA, forcing 32bit\n");
cap &= ~HOST_CAP_64;
}
With the ".can_queue" part left intact the bug resurfaced. Full dmesg
output is attached.
dmesg.xz
Description: application/xz
Re: [char-misc-next v3 6/8] watchdog: mei_wdt: register wd device only if required
On 12/21/2015 03:17 PM, Tomas Winkler wrote:
From: Alexander Usyskin
For Intel Broadwell and newer platforms, the ME device can inform
the host whether the watchdog functionality is activated or not.
If the watchdog functionality is not activated then the watchdog interface
can be not registered and eliminate unnecessary pings and hence lower the
power consumption by avoiding waking up the device.
The feature can be deactivated also without reboot
in that case the watchdog device should be unregistered at runtime.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
V2: rework unregistration
V3: rebase; implement unregistraion also at runtime
drivers/watchdog/mei_wdt.c | 183 +
1 file changed, 169 insertions(+), 14 deletions(-)
diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index ab9aec218d69..3cd80aa75db1 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,24 +39,30 @@
/* Sub Commands */
#define MEI_MC_START_WD_TIMER_REQ 0x13
+#define MEI_MC_START_WD_TIMER_RES 0x83
+#define MEI_WDT_STATUS_SUCCESS 0
+#define MEI_WDT_WDSTATE_NOT_REQUIRED 0x1
#define MEI_MC_STOP_WD_TIMER_REQ 0x14
/**
* enum mei_wdt_state - internal watchdog state
*
+ * @MEI_WDT_PROBE: wd in probing stage
* @MEI_WDT_IDLE: wd is idle and not opened
* @MEI_WDT_START: wd was opened, start was called
* @MEI_WDT_RUNNING: wd is expecting keep alive pings
* @MEI_WDT_STOPPING: wd is stopping and will move to IDLE
+ * @MEI_WDT_NOT_REQUIRED: wd device is not required
*/
enum mei_wdt_state {
+ MEI_WDT_PROBE,
MEI_WDT_IDLE,
MEI_WDT_START,
MEI_WDT_RUNNING,
MEI_WDT_STOPPING,
+ MEI_WDT_NOT_REQUIRED,
};
-#if IS_ENABLED(CONFIG_DEBUG_FS)
static const char *mei_wdt_state_str(enum mei_wdt_state state)
{
switch (state) {
@@ -71,7 +78,6 @@ static const char *mei_wdt_state_str(enum mei_wdt_state state)
return "unknown";
}
}
-#endif /* CONFIG_DEBUG_FS */
struct mei_wdt;
@@ -94,6 +100,10 @@ struct mei_wdt_dev {
*
* @cldev: mei watchdog client device
* @state: watchdog internal state
+ * @resp_required: ping required response
+ * @response: ping response completion
+ * @unregister: unregister worker
+ * @reg_lock: watchdog device registration lock
* @timeout: watchdog current timeout
*
* @dbgfs_dir: debugfs dir entry
@@ -103,6 +113,10 @@ struct mei_wdt {
struct mei_cl_device *cldev;
enum mei_wdt_state state;
+ bool resp_required;
+ struct completion response;
+ struct work_struct unregister;
+ struct mutex reg_lock;
u16 timeout;
#if IS_ENABLED(CONFIG_DEBUG_FS)
@@ -139,6 +153,19 @@ struct mei_wdt_start_request {
} __packed;
/**
+ * struct mei_wdt_start_response watchdog start/ping response
+ *
+ * @hdr: Management Control Command Header
+ * @status: operation status
+ * @wdstate: watchdog status bit mask
+ */
+struct mei_wdt_start_response {
+ struct mei_mc_hdr hdr;
+ u8 status;
+ u8 wdstate;
+} __packed;
+
+/**
* struct mei_wdt_stop_request - watchdog stop
*
* @hdr: Management Control Command Header
@@ -277,13 +304,18 @@ static int mei_wdt_ops_ping(struct watchdog_device *wdd)
if (wdt->state != MEI_WDT_START && wdt->state != MEI_WDT_RUNNING)
return 0;
+ if (wdt->resp_required)
+ init_completion(>response);
+
+ wdt->state = MEI_WDT_RUNNING;
ret = mei_wdt_ping(wdt);
if (ret)
return ret;
- wdt->state = MEI_WDT_RUNNING;
The state is now set to RUNNING even if the ping failed.
Is that on purpose ?
+ if (wdt->resp_required)
+ ret = wait_for_completion_killable(>response);
- return 0;
+ return ret;
}
/**
@@ -358,15 +390,22 @@ static struct watchdog_info wd_info = {
*/
static void mei_wdt_unregister(struct mei_wdt *wdt)
{
- struct mei_wdt_dev *mwd = wdt->mwd;
+ struct mei_wdt_dev *mwd;
- if (!mwd)
- return;
+ mutex_lock(>reg_lock);
+
+ if (!wdt->mwd)
+ goto out;
+
Is this because the error on registration was ignored ?
Trying to understand the rationale for this check.
+ mwd = wdt->mwd;
watchdog_unregister_device(>wdd);
+
It would be better to make such changes in an earlier patch and avoid the
whitespace change here.
wdt->mwd = NULL;
- wdt->state = MEI_WDT_IDLE;
kref_put(>refcnt, mei_wdt_release);
+
+out:
+ mutex_unlock(>reg_lock);
}
/**
@@ -387,9 +426,13 @@ static int mei_wdt_register(struct mei_wdt *wdt)
dev = >cldev->dev;
+ mutex_lock(>reg_lock);
+
mwd = kzalloc(sizeof(struct mei_wdt_dev), GFP_KERNEL);
- if (!mwd)
- return -ENOMEM;
+ if
