Re: [PATCH v5 2/5] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.
Hi Linus, 2015-02-10 9:01 GMT+01:00 Linus Walleij : > On Wed, Jan 21, 2015 at 1:28 PM, Hongzhou Yang > wrote: > >> From: Hongzhou Yang >> >> Add devicetree bindings for Mediatek SoC pinctrl driver. >> >> Signed-off-by: Hongzhou Yang > > OK applied this patch for v3.21 now, relying on Sascha's ACK. I can see the the pinctrl driver parts in your tree repository [0], but not in linux-next. Do think of merging them in the next merge window? Thanks, Matthias [0] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=mtk-staging > > Yours, > Linus Walleij -- motzblog.wordpress.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V2 03/12] i2c: at91: make use of the new infrastructure for quirks
On Wed, Feb 25, 2015 at 05:01:54PM +0100, Wolfram Sang wrote:
> From: Wolfram Sang
>
> Signed-off-by: Wolfram Sang
Hi Ludovic,
if you have a few minutes, could you please test this series? I'd like to
include it in 4.1. and because at91 is using the quirk infrastructure in
a more complex way, it is a really good test candidate.
Thanks,
Wolfram
> ---
> drivers/i2c/busses/i2c-at91.c | 32 +++-
> 1 file changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 636fd2efad8850..b3a70e8fc653c5 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -487,30 +487,10 @@ static int at91_twi_xfer(struct i2c_adapter *adap,
> struct i2c_msg *msg, int num)
> if (ret < 0)
> goto out;
>
> - /*
> - * The hardware can handle at most two messages concatenated by a
> - * repeated start via it's internal address feature.
> - */
> - if (num > 2) {
> - dev_err(dev->dev,
> - "cannot handle more than two concatenated messages.\n");
> - ret = 0;
> - goto out;
> - } else if (num == 2) {
> + if (num == 2) {
> int internal_address = 0;
> int i;
>
> - if (msg->flags & I2C_M_RD) {
> - dev_err(dev->dev, "first transfer must be write.\n");
> - ret = -EINVAL;
> - goto out;
> - }
> - if (msg->len > 3) {
> - dev_err(dev->dev, "first message size must be <= 3.\n");
> - ret = -EINVAL;
> - goto out;
> - }
> -
> /* 1st msg is put into the internal address, start with 2nd */
> m_start = &msg[1];
> for (i = 0; i < msg->len; ++i) {
> @@ -540,6 +520,15 @@ out:
> return ret;
> }
>
> +/*
> + * The hardware can handle at most two messages concatenated by a
> + * repeated start via it's internal address feature.
> + */
> +static struct i2c_adapter_quirks at91_twi_quirks = {
> + .flags = I2C_AQ_COMB | I2C_AQ_COMB_WRITE_FIRST | I2C_AQ_COMB_SAME_ADDR,
> + .max_comb_1st_msg_len = 3,
> +};
> +
> static u32 at91_twi_func(struct i2c_adapter *adapter)
> {
> return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL
> @@ -777,6 +766,7 @@ static int at91_twi_probe(struct platform_device *pdev)
> dev->adapter.owner = THIS_MODULE;
> dev->adapter.class = I2C_CLASS_DEPRECATED;
> dev->adapter.algo = &at91_twi_algorithm;
> + dev->adapter.quirks = &at91_twi_quirks;
> dev->adapter.dev.parent = dev->dev;
> dev->adapter.nr = pdev->id;
> dev->adapter.timeout = AT91_I2C_TIMEOUT;
> --
> 2.1.4
>
signature.asc
Description: Digital signature
[PATCH 3/3] Input: elan_i2c - Remove duplicate repeat code
Remove duplicate "repeat--" from function elan_initialize. Signed-off-by: Duson Lin --- drivers/input/mouse/elan_i2c_core.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c index f24078b..4b970e2 100644 --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -198,7 +198,6 @@ static int elan_initialize(struct elan_tp_data *data) if (!error) return 0; - repeat--; msleep(30); } while (--repeat > 0); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] misc: bh1780: Add module aliases
The bh1780gli driver does not create an i2c module alias for the
device it supports, preventing the driver from being loaded
automatically when needed on non-OF/DT systems. Add it.
Signed-off-by: Jean Delvare
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/bh1780gli.c |2 ++
1 file changed, 2 insertions(+)
--- linux-4.0-rc2.orig/drivers/misc/bh1780gli.c 2015-02-23 03:21:14.0
+0100
+++ linux-4.0-rc2/drivers/misc/bh1780gli.c 2015-03-08 09:38:28.742091860
+0100
@@ -230,6 +230,8 @@ static const struct i2c_device_id bh1780
{ },
};
+MODULE_DEVICE_TABLE(i2c, bh1780_id);
+
#ifdef CONFIG_OF
static const struct of_device_id of_bh1780_match[] = {
{ .compatible = "rohm,bh1780gli", },
--
Jean Delvare
SUSE L3 Support
--
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/1] x86/fpu: math_state_restore() should not blindly disable irqs
* Linus Torvalds wrote: > On Sat, Mar 7, 2015 at 2:36 AM, Ingo Molnar wrote: > > > > We could save the same 10 cycles from page fault overhead as well, > > AFAICS. > > Are trap gates actually noticeably faster? Or is it just he > "conditional_sti()" you're worried about? ( I'll talk about the CR2 complication later, please ignore that problem for a moment. ) So I base my thinking on the following hierarchy of fast paths. In a typical x86 system there are 4 main types of 'context switches', in order of decreasing frequency: - syscall'context switch': entry/exit from syscall - trap/fault 'context switch': entry/exit from trap/fault - irq'context switch': entry/exit from irqs - task 'context switch': scheduler context-switch Where each successive level is about an order of magnitude less frequently executed on a typical system than the previous one, so to optimize a level we are willing to push overhead to the next one(s). So the primary payoff in executing much of the entry code with irqs enabled would be to allow 64-bit *syscalls* to be made without irqs disabled: the first, most important level of context entries. Doing that would give us four (theoretical) performance advantages: - No implicit irq disabling overhead when the syscall instruction is executed: we could change MSR_SYSCALL_MASK from 0xc084 to 0xc284, which removes the implicit CLI on syscall entry. - No explicit irq enabling overhead via ENABLE_INTERRUPTS() [STI] in system_call. - No explicit irq disabling overhead in the ret_from_sys_call fast path, i.e. no DISABLE_INTERRUPTS() [CLI]. - No implicit irq enabling overhead in ret_from_sys_call's USERGS_SYSRET64: the SYSRETQ instruction would not have to re-enable irqs as the user-space IF in R11 would match that of the current IF. whether that's an actual performance win in practice as well needs to be measured, but I'd be (very!) shocked if it wasn't in the 20+ cycles range: which is absolutely huge in terms of system_call optimizations. Now do I think this could be done realistically? I think yes (by re-using the NMI code's paranoid entry codepaths for the irq code as well, essentially fixing up the effects of any partial entries in an irq entry slow path), but I could be wrong about that. My main worry isn't even feasibility but maintainability and general robustness: all these asm cleanups we are doing now could enable such a trick to be pulled off robustly. But I think it could be done technically, because the NMI code already has to be careful about 'preempting' partial entries, so we have the logic. Complications: - We now enable double partial entries: partial syscall interrupted by an irq interrupted by an NMI context. I think it should all work out fine but it's a new scenario. - We'd enable interruptible return from system call, which caused trouble in the past. Solvable IMHO, by being careful in the irq entry code. - We'd now have to be extra careful about the possibility of exceptions triggered in the entry/exit code itself, triggered by any sort of unusual register content or MMU fault. Simplifications: - I'd ruthlessly disable IRQs for any sort of non fast path: for example 32-bit compat entries, ptrace or any other slowpath - at least initially until we map out the long term effects of this optimization. Does this scare me? Yes, I think it should scare any sane person, but I don't think it's all that bad: all the NMI paranoidentry work has already the trail blazed, and most of the races will be readily triggerable via regular irq loads, so it's not like we'll leave subtle bugs in there. Being able to do the same with certain traps, because irq entry is careful about partial entry state, would just be a secondary bonus. Regarding the CR2 value on page faults: > Anyway, for page faulting, we traditionally actually wanted an > interrupt gate, because of how we wanted to avoid interrupts coming > in and possibly messing up %cr2 due to vmalloc faults, but more > importantly for preemption. [...] Here too I think we could take a page from the NMI code: save cr2 in the page fault asm code, recognize from the irq code when we are interrupting that and dropping into a slowpath that saves cr2 right there. Potentially task-context-switching will be safe after that. Saving cr2 in the early page fault code should be much less of an overhead than what the IRQ disabling/enabling costs, so this should be a win. The potential win could be similar to that of system calls: - Removal of an implicit 'CLI' in irq gates - Removal of the explicit 'STI' in conditional_sti in your proposed code - Removal of an explicit 'CLI' (DISABLE_INTERRUPTS) in error_exit/retint_swapgs. - Removal of an implicit 'STI' when SYSRET enables interrupts from R11 and the same savings would apply to FPU traps as well. I'd leave a
Re: [PATCH 1/1] usb: xhci: handle Config Error Change (CEC) in xhci driver
Hi Alan,
Do you have any comments for this patch?
Thanks,
Baolu
On 03/06/2015 04:12 PM, Lu Baolu wrote:
Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends when the root port
fails to configure its link partner, e.g. the port fails to exchange
port capabilities information using Port Capability LMPs.
Then the Port Status Change Events will be blocked until all status
change bits(CEC is one of the change bits) are cleared('0') (refer to
xHCI spec 4.19.2). Otherwise, the port status change event for this
root port will not be generated anymore, then root port would look
like dead for user and can't be recovered until a Host Controller
Reset(HCRST).
This patch is to check CEC bit in PORTSC in xhci_get_port_status()
and set a Config Error in the return status if CEC is set. This will
cause a ClearPortFeature request, where CEC bit is cleared in
xhci_clear_port_change_bit().
[Mathias Nyman contributed the idea. The commit log is based on patch
posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2]
Signed-off-by: Lu Baolu
Cc: stable # v3.2+
---
drivers/usb/host/xhci-hub.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..0827d7c 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -387,6 +387,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
status = PORT_PLC;
port_change_bit = "link state";
break;
+ case USB_PORT_FEAT_C_PORT_CONFIG_ERROR:
+ status = PORT_CEC;
+ port_change_bit = "config error";
+ break;
default:
/* Should never happen */
return;
@@ -588,6 +592,8 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd,
status |= USB_PORT_STAT_C_LINK_STATE << 16;
if ((raw_port_status & PORT_WRC))
status |= USB_PORT_STAT_C_BH_RESET << 16;
+ if ((raw_port_status & PORT_CEC))
+ status |= USB_PORT_STAT_C_CONFIG_ERROR << 16;
}
if (hcd->speed != HCD_USB3) {
@@ -1005,6 +1011,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
case USB_PORT_FEAT_C_OVER_CURRENT:
case USB_PORT_FEAT_C_ENABLE:
case USB_PORT_FEAT_C_PORT_LINK_STATE:
+ case USB_PORT_FEAT_C_PORT_CONFIG_ERROR:
xhci_clear_port_change_bit(xhci, wValue, wIndex,
port_array[wIndex], temp);
break;
@@ -1069,7 +1076,7 @@ int xhci_hub_status_data(struct usb_hcd *hcd, char *buf)
*/
status = bus_state->resuming_ports;
- mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC;
+ mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC;
spin_lock_irqsave(&xhci->lock, flags);
/* For each port, did anything change? If so, set that bit in buf. */
--
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 4/4] mm: numa: Slow PTE scan rate if migration failures occur
* Mel Gorman wrote: > xfsrepair > 4.0.0-rc1 4.0.0-rc1 > 3.19.0 > vanilla slowscan-v2 > vanilla > Min real-fsmark1157.41 ( 0.00%) 1150.38 ( 0.61%) > 1164.44 ( -0.61%) > Min syst-fsmark3998.06 ( 0.00%) 3988.42 ( 0.24%) > 4016.12 ( -0.45%) > Min real-xfsrepair 497.64 ( 0.00%) 456.87 ( 8.19%) > 442.64 ( 11.05%) > Min syst-xfsrepair 500.61 ( 0.00%) 263.41 ( 47.38%) > 194.97 ( 61.05%) > Ameanreal-fsmark1166.63 ( 0.00%) 1155.97 ( 0.91%) > 1166.28 ( 0.03%) > Ameansyst-fsmark4020.94 ( 0.00%) 4004.19 ( 0.42%) > 4025.87 ( -0.12%) > Ameanreal-xfsrepair 507.85 ( 0.00%) 459.58 ( 9.50%) > 447.66 ( 11.85%) > Ameansyst-xfsrepair 519.88 ( 0.00%) 281.63 ( 45.83%) > 202.93 ( 60.97%) > Stddev real-fsmark 6.55 ( 0.00%)3.97 ( 39.30%) > 1.44 ( 77.98%) > Stddev syst-fsmark 16.22 ( 0.00%) 15.09 ( 6.96%) > 9.76 ( 39.86%) > Stddev real-xfsrepair 11.17 ( 0.00%)3.41 ( 69.43%) > 5.57 ( 50.17%) > Stddev syst-xfsrepair 13.98 ( 0.00%) 19.94 (-42.60%) > 5.69 ( 59.31%) > CoeffVar real-fsmark 0.56 ( 0.00%)0.34 ( 38.74%) > 0.12 ( 77.97%) > CoeffVar syst-fsmark 0.40 ( 0.00%)0.38 ( 6.57%) > 0.24 ( 39.93%) > CoeffVar real-xfsrepair2.20 ( 0.00%)0.74 ( 66.22%) > 1.24 ( 43.47%) > CoeffVar syst-xfsrepair2.69 ( 0.00%)7.08 (-163.23%) > 2.80 ( -4.23%) > Max real-fsmark1171.98 ( 0.00%) 1159.25 ( 1.09%) > 1167.96 ( 0.34%) > Max syst-fsmark4033.84 ( 0.00%) 4024.53 ( 0.23%) > 4039.20 ( -0.13%) > Max real-xfsrepair 523.40 ( 0.00%) 464.40 ( 11.27%) > 455.42 ( 12.99%) > Max syst-xfsrepair 533.37 ( 0.00%) 309.38 ( 42.00%) > 207.94 ( 61.01%) Btw., I think it would be nice if these numbers listed v3.19 performance in the first column, to make it clear at a glance how much regression we still have? Thanks, Ingo -- 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 4/4] mm: numa: Slow PTE scan rate if migration failures occur
* Mel Gorman wrote:
> Elapsed time is primarily worse on one benchmark -- numa01 which is
> an adverse workload. The user time differences are also dominated by
> that benchmark
>
>4.0.0-rc1 4.0.0-rc1
> 3.19.0
> vanilla slowscan-v2r7
>vanilla
> Time User-NUMA01 32883.59 ( 0.00%)35288.00 ( -7.31%)
> 25695.96 ( 21.86%)
> Time User-NUMA01_THEADLOCAL 17453.20 ( 0.00%)17765.79 ( -1.79%)
> 17404.36 ( 0.28%)
> Time User-NUMA02 2063.70 ( 0.00%) 2063.22 ( 0.02%)
> 2037.65 ( 1.26%)
> Time User-NUMA02_SMT983.70 ( 0.00%) 976.01 ( 0.78%)
> 981.02 ( 0.27%)
But even for 'numa02', the simplest of the workloads, there appears to
be some of a regression relative to v3.19, which ought to be beyond
the noise of the measurement (which would be below 1% I suspect), and
as such relevant, right?
And the XFS numbers still show significant regression compared to
v3.19 - and that cannot be ignored as artificial, 'adversarial'
workload, right?
For example, from your numbers:
xfsrepair
4.0.0-rc1 4.0.0-rc1
3.19.0
vanilla slowscan-v2
vanilla
...
Ameanreal-xfsrepair 507.85 ( 0.00%) 459.58 ( 9.50%) 447.66
( 11.85%)
Ameansyst-xfsrepair 519.88 ( 0.00%) 281.63 ( 45.83%) 202.93
( 60.97%)
if I interpret the numbers correctly, it shows that compared to v3.19,
system time increased by 38% - which is rather significant!
> > So what worries me is that Dave bisected the regression to:
> >
> > 4d9424669946 ("mm: convert p[te|md]_mknonnuma and remaining page table
> > manipulations")
> >
> > And clearly your patch #4 just tunes balancing/migration intensity
> > - is that a workaround for the real problem/bug?
>
> The patch makes NUMA hinting faults use standard page table handling
> routines and protections to trap the faults. Fundamentally it's
> safer even though it appears to cause more traps to be handled. I've
> been assuming this is related to the different permissions PTEs get
> and when they are visible on all CPUs. This path is addressing the
> symptom that more faults are being handled and that it needs to be
> less aggressive.
But the whole cleanup ought to have been close to an identity
transformation from the CPU's point of view - and your measurements
seem to confirm Dave's findings.
And your measurement was on bare metal, while Dave's is on a VM, and
both show a significant slowdown on the xfs tests even with your
slow-tuning patch applied, so it's unlikely to be a measurement fluke
or some weird platform property.
> I've gone through that patch and didn't spot anything else that is
> doing wrong that is not already handled in this series. Did you spot
> anything obviously wrong in that patch that isn't addressed in this
> series?
I didn't spot anything wrong, but is that a basis to go forward and
work around the regression, in a way that doesn't even recover lost
performance?
> > And the patch Dave bisected to is a relatively simple patch. Why
> > not simply revert it to see whether that cures much of the
> > problem?
>
> Because it also means reverting all the PROT_NONE handling and going
> back to _PAGE_NUMA tricks which I expect would be naked by Linus.
Yeah, I realize that (and obviously I support the PROT_NONE direction
that Peter Zijlstra prototyped with the original sched/numa series),
but can we leave this much of a regression on the table?
I hate to be such a pain in the neck, but especially the 'down tuning'
of the scanning intensity will make an apples to apples comparison
harder!
I'd rather not do the slow-tuning part and leave sucky performance in
place for now and have an easy method plus the motivation to find and
fix the real cause of the regression, than to partially hide it this
way ...
Thanks,
Ingo
--
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] crypto: omap-sham: Check for return value from pm_runtime_get_sync
Function pm_runtime_get_sync could fail and we need to check return
value to prevent kernel crash.
Signed-off-by: Pali Rohár
---
v2: Check return value for all pm_runtime_get_sync() calls
---
drivers/crypto/omap-sham.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b20e374..c5df53d 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -362,7 +362,13 @@ static void omap_sham_copy_ready_hash(struct ahash_request
*req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- pm_runtime_get_sync(dd->dev);
+ int err;
+
+ err = pm_runtime_get_sync(dd->dev);
+ if (err < 0) {
+ dev_err(dd->dev, "failed to get sync: %d\n", err);
+ return err;
+ }
if (!test_bit(FLAGS_INIT, &dd->flags)) {
set_bit(FLAGS_INIT, &dd->flags);
@@ -1949,7 +1955,13 @@ static int omap_sham_probe(struct platform_device *pdev)
dd->flags |= dd->pdata->flags;
pm_runtime_enable(dev);
- pm_runtime_get_sync(dev);
+
+ err = pm_runtime_get_sync(dev);
+ if (err < 0) {
+ dev_err(dev, "failed to get sync: %d\n", err);
+ goto err_pm;
+ }
+
rev = omap_sham_read(dd, SHA_REG_REV(dd));
pm_runtime_put_sync(&pdev->dev);
@@ -1979,6 +1991,7 @@ err_algs:
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_ahash(
&dd->pdata->algs_info[i].algs_list[j]);
+err_pm:
pm_runtime_disable(dev);
if (dd->dma_lch)
dma_release_channel(dd->dma_lch);
@@ -2021,7 +2034,11 @@ static int omap_sham_suspend(struct device *dev)
static int omap_sham_resume(struct device *dev)
{
- pm_runtime_get_sync(dev);
+ int err = pm_runtime_get_sync(dev);
+ if (err < 0) {
+ dev_err(dev, "failed to get sync: %d\n", err);
+ return err;
+ }
return 0;
}
#endif
--
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 00/10] omap3 crypto fixes
On Friday 06 March 2015 23:23:06 Aaro Koskinen wrote: > Hi, > > On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: > > Are there any fixes in this series that should go into > > v4.0-rc series, or can it all wait for v4.1? > > I think these all should wait for v4.1. > > A. I would suggest to include at least patches 01, 04, 06. Probably those could go to -stable tree... but this decision is up to you. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur
* Linus Torvalds wrote: > On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote: > > > > And the patch Dave bisected to is a relatively simple patch. Why > > not simply revert it to see whether that cures much of the > > problem? > > So the problem with that is that "pmd_set_numa()" and friends simply > no longer exist. So we can't just revert that one patch, it's the > whole series, and the whole point of the series. Yeah. > What confuses me is that the only real change that I can see in that > patch is the change to "change_huge_pmd()". Everything else is > pretty much a 100% equivalent transformation, afaik. Of course, I > may be wrong about that, and missing something silly. Well, there's a difference in what we write to the pte: #define _PAGE_BIT_NUMA (_PAGE_BIT_GLOBAL+1) #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL and our expectation was that the two should be equivalent methods from the POV of the NUMA balancing code, right? > And the changes to "change_huge_pmd()" were basically re-done > differently by subsequent patches anyway. > > The *only* change I see remaining is that change_huge_pmd() now does > >entry = pmdp_get_and_clear_notify(mm, addr, pmd); >entry = pmd_modify(entry, newprot); >set_pmd_at(mm, addr, pmd, entry); > > for all changes. It used to do that "pmdp_set_numa()" for the > prot_numa case, which did just > >pmd_t pmd = *pmdp; >pmd = pmd_mknuma(pmd); >set_pmd_at(mm, addr, pmdp, pmd); > > instead. > > I don't like the old pmdp_set_numa() because it can drop dirty bits, > so I think the old code was actively buggy. Could we, as a silly testing hack not to be applied, write a hack-patch that re-introduces the racy way of setting the NUMA bit, to confirm that it is indeed this difference that changes pte visibility across CPUs enough to create so many more faults? Because if the answer is 'yes', then we can safely say: 'we regressed performance because correctness [not dropping dirty bits] comes before performance'. If the answer is 'no', then we still have a mystery (and a regression) to track down. As a second hack (not to be applied), could we change: #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL to: #define _PAGE_BIT_PROTNONE (_PAGE_BIT_GLOBAL+1) to double check that the position of the bit does not matter? I don't think we've exhaused all avenues of analysis here. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ASoC: wm8996: match wait_for_completion_timeout return type
return type of wait_for_completion_timeout is unsigned long not int. An
appropriately named unsigned long is added and the assignment fixed up
in case of completion occurring the remaining time is >=1 so ret is set to
1 if no timeout occurred.
Signed-off-by: Nicholas Mc Guire
---
This was only compile tested for exynos_defconfig + CONFIG_COMPILE_TEST=y,
SND_SOC_ALL_CODECS=m (implies CONFIG_SND_SOC_WM8996=m)
Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)
sound/soc/codecs/wm8996.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index dc92d5e..24d9705 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2009,7 +2009,7 @@ static int wm8996_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
struct wm8996_priv *wm8996 = snd_soc_codec_get_drvdata(codec);
struct i2c_client *i2c = to_i2c_client(codec->dev);
struct _fll_div fll_div;
- unsigned long timeout;
+ unsigned long timeout, time_left;
int ret, reg, retry;
/* Any change? */
@@ -2113,10 +2113,11 @@ static int wm8996_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
timeout /= 2;
for (retry = 0; retry < 10; retry++) {
- ret = wait_for_completion_timeout(&wm8996->fll_lock,
- timeout);
- if (ret != 0) {
+ time_left = wait_for_completion_timeout(&wm8996->fll_lock,
+ timeout);
+ if (time_left != 0) {
WARN_ON(!i2c->irq);
+ ret = 1;
break;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ASoC: wm8996: ensure lower bounds of 1 for timeout
wait_for_completion_timeout can be called with timeout == 0 due to
msecs_to_jiffies(2) == 1 for HZ < 1000 and usecs_to_jiffies(300) == 1
for all reasonable values of HZ, thus the following timeout /= 2; sets
timeout to 0. This patch simply adds a lower-bounds of 1.
Signed-off-by: Nicholas Mc Guire
---
line numbers from wm9666.c linux-next -next-20150306
2101 /* Wait for the FLL to lock, using the interrupt if possible */
2102 if (Fref > 100)
2103 timeout = usecs_to_jiffies(300);
2104 else
2105 timeout = msecs_to_jiffies(2);
2106
2107 /* Allow substantially longer if we've actually got the IRQ, poll
2108 * at a slightly higher rate if we don't.
2109 */
2110 if (i2c->irq)
2111 timeout *= 10;
2112 else
2113 timeout /= 2;
2114
2115 ret = wait_for_completion_timeout(&wm8996->fll_lock,
2116timeout);
The call-path here would then be:
wait_for_completion_timeout(...,timeout)
-> wait_for_common action==schedule_timeout
-> schedule_timeout(timeout)
...
expire = timeout + jiffies;
so expire == jiffies here and the timer would expire immediately
for systems with HZ<1000 due to msecs_to_jiffies(2) == 1 and the
following timeout /= 2 -> timeout == 0, which is probably a bit
more that a "slightly higher rate".
This was only compile tested for exynos_defconfig + CONFIG_COMPILE_TEST=y,
SND_SOC_ALL_CODECS=m (implies CONFIG_SND_SOC_WM8996=m)
Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)
sound/soc/codecs/wm8996.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 24d9705..5ded102 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2110,7 +2110,8 @@ static int wm8996_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
if (i2c->irq)
timeout *= 10;
else
- timeout /= 2;
+ /* ensure timeout of atleast 1 jiffies */
+ timeout = timeout/2 ? : 1;
for (retry = 0; retry < 10; retry++) {
time_left = wait_for_completion_timeout(&wm8996->fll_lock,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
On 8 March 2015 at 01:57, Brian Norris wrote: > 2. Endianness is a known issue with at least one other platform. On many > chips (spanning MIPS LE, MIPS BE, and ARM LE), NAND has been integrated > such that data can just be read/programmed in the native endianness > through the FLASH_CACHE registers (as this driver does), but there are a > few (on ARM, LE) that require a be32_to_cpu()/cpu_to_be32() swap. I'm > considering supporting DT properties like one of the following: > > brcm,nand-cache-be > brcm,nand-cache-big-endian > brcm,nand-cache-reverse-endian > > You might also check (though I might actually be better equipped for > this) if there is a separate register that can tell the NAND data bus to > automatically endian-swap data into the native endianness. I know a lot > of the buses and peripherals in BCG, at least, are designed such that > either (1) they can work naturally in the CPU's native endianness or > else (2) they can be configured to swap endianness into either format. > > But if such a register does not exist, then we'll definitely have to do > something like the DT property above. It seems there is such a magic register. Please take a look at bcm_nand.c: https://dev.openwrt.org/browser/trunk/target/linux/bcm53xx/patches-3.18/420-mtd-bcm5301x_nand.patch There are multiple places (data, OOB, reads, writes) with: /* Set controller to Little Endian mode for copying */ bcmnand_reg_awrite(ctrl, NANDC_IDM_APB_LITTLE_ENDIAN, 1); /* Return to Big Endian mode for commands etc */ bcmnand_reg_awrite(ctrl, NANDC_IDM_APB_LITTLE_ENDIAN, 0); That register is 0x408, but it's in "agent" core (AKA wrapper), so it's separated mapping. I'm not sure what address is it right now, as we read them from the EROM. > Do the bad block markers look OK without extra endian swapping? I'm > wondering whether the swapping will have to occur on both the > FLASH_CACHE and SPARE_AREA registers. I don't know, I didn't try nand-on-flash-bbt. -- Rafał -- 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] Driver core: Fix missing whitespace in function argument
Found this using checkpatch.pl.
Signed-off-by: Florin Papa
---
drivers/base/property.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index c458458..423df59 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -365,7 +365,7 @@ int fwnode_property_read_string(struct fwnode_handle
*fwnode,
const char *propname, const char **val)
{
if (is_of_node(fwnode))
- return of_property_read_string(of_node(fwnode),propname, val);
+ return of_property_read_string(of_node(fwnode), propname, val);
else if (is_acpi_node(fwnode))
return acpi_dev_prop_read(acpi_node(fwnode), propname,
DEV_PROP_STRING, val, 1);
--
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/
iptables problem upgrading kernel from 3.18.8 to 3.19.1
I've just had an exception to my "uneventful kernel upgrade" monotony. My boot scripts failed when setting up the firewall due to this :- xt_recent: hitcount (1) is larger than packets to be remembered (1) for table This is a completely straightforward iptables -A -j REJECT -p tcp --reject-with tcp-reset -m recent --set --name --rsource Looking at the history for xt_recent.c it looks like this was introduced in abc86d0f99242b7f142b7cb8f90e30081dd3c256 but maybe corrected in cef9ed86ed62eeffcd017882278bbece32001f86 ? Whatever, 3.19.1 is still affected, it can be worked around by setting ip_pkt_list_tot in the module parameters. Cheers David -- 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] drivers: base: map: Use kmalloc_array instead of kmalloc
Reported by checkpatch.pl While at it, removed blank line between function call and error checking. Signed-off-by: Andrei Poenaru --- drivers/base/map.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/base/map.c b/drivers/base/map.c index e87017f..c1d3823 100644 --- a/drivers/base/map.c +++ b/drivers/base/map.c @@ -41,8 +41,7 @@ int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range, if (n > 255) n = 255; - p = kmalloc(sizeof(struct probe) * n, GFP_KERNEL); - + p = kmalloc_array(n, sizeof(struct probe), GFP_KERNEL); if (p == NULL) return -ENOMEM; -- 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] drivers: base: memory: Fix switch indent
From: IoanaCiornei
Signed-off-by: Ioana Ciornei
---
drivers/base/memory.c | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 0c871c9..9b5dc89 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -152,20 +152,20 @@ static ssize_t show_mem_state(struct device *dev,
* so that they're not open-coded
*/
switch (mem->state) {
- case MEM_ONLINE:
- len = sprintf(buf, "online\n");
- break;
- case MEM_OFFLINE:
- len = sprintf(buf, "offline\n");
- break;
- case MEM_GOING_OFFLINE:
- len = sprintf(buf, "going-offline\n");
- break;
- default:
- len = sprintf(buf, "ERROR-UNKNOWN-%ld\n",
- mem->state);
- WARN_ON(1);
- break;
+ case MEM_ONLINE:
+ len = sprintf(buf, "online\n");
+ break;
+ case MEM_OFFLINE:
+ len = sprintf(buf, "offline\n");
+ break;
+ case MEM_GOING_OFFLINE:
+ len = sprintf(buf, "going-offline\n");
+ break;
+ default:
+ len = sprintf(buf, "ERROR-UNKNOWN-%ld\n",
+ mem->state);
+ WARN_ON(1);
+ break;
}
return len;
@@ -233,19 +233,19 @@ memory_block_action(unsigned long phys_index, unsigned
long action, int online_t
first_page = pfn_to_page(start_pfn);
switch (action) {
- case MEM_ONLINE:
- if (!pages_correctly_reserved(start_pfn))
- return -EBUSY;
-
- ret = online_pages(start_pfn, nr_pages, online_type);
- break;
- case MEM_OFFLINE:
- ret = offline_pages(start_pfn, nr_pages);
- break;
- default:
- WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
-"%ld\n", __func__, phys_index, action, action);
- ret = -EINVAL;
+ case MEM_ONLINE:
+ if (!pages_correctly_reserved(start_pfn))
+ return -EBUSY;
+
+ ret = online_pages(start_pfn, nr_pages, online_type);
+ break;
+ case MEM_OFFLINE:
+ ret = offline_pages(start_pfn, nr_pages);
+ break;
+ default:
+ WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
+"%ld\n", __func__, phys_index, action, action);
+ ret = -EINVAL;
}
return ret;
--
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] attribute_container: fix missing blank lines after declarations
Found with checkpatch.pl
Signed-off-by: Cosmin Dragomir
---
drivers/base/attribute_container.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/attribute_container.c
b/drivers/base/attribute_container.c
index 3ead3af..2ba4cac 100644
--- a/drivers/base/attribute_container.c
+++ b/drivers/base/attribute_container.c
@@ -94,6 +94,7 @@ int
attribute_container_unregister(struct attribute_container *cont)
{
int retval = -EBUSY;
+
mutex_lock(&attribute_container_mutex);
spin_lock(&cont->containers.k_lock);
if (!list_empty(&cont->containers.k_list))
@@ -349,6 +350,7 @@ int
attribute_container_add_class_device(struct device *classdev)
{
int error = device_add(classdev);
+
if (error)
return error;
return attribute_container_add_attrs(classdev);
--
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] drivers: base: class: Add a blank line after declarations
This patch fixes the following warning found by checkpatch.pl:
WARNING: Missing a black line after declarations
Signed-off-by: Cosmin Tomulescu
---
drivers/base/class.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/class.c b/drivers/base/class.c
index f96f704..6e81088 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -90,6 +90,7 @@ int class_create_file_ns(struct class *cls, const struct
class_attribute *attr,
const void *ns)
{
int error;
+
if (cls)
error = sysfs_create_file_ns(&cls->p->subsys.kobj,
&attr->attr, ns);
@@ -488,6 +489,7 @@ ssize_t show_class_attr_string(struct class *class,
struct class_attribute *attr, char *buf)
{
struct class_attribute_string *cs;
+
cs = container_of(attr, struct class_attribute_string, attr);
return snprintf(buf, PAGE_SIZE, "%s\n", cs->str);
}
--
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] drivers: base: dma-mapping: Erase blank space after pointer
This patch fixes the following checkpatch.pl error:
ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Marius Cristian Eseanu
---
drivers/base/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 9e8bbdd..d95c597 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -62,7 +62,7 @@ static int dmam_match(struct device *dev, void *res, void
*match_data)
* RETURNS:
* Pointer to allocated memory on success, NULL on failure.
*/
-void * dmam_alloc_coherent(struct device *dev, size_t size,
+void *dmam_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp)
{
struct dma_devres *dr;
--
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] rt2x00: use rt2x00queue_flush_queues() instead of implementing the same action
On Sat, Mar 07, 2015 at 08:45:50PM +02iee80211_ops00, Giedrius Statkevičius wrote: > Use rt2x00queue_flush_queues() in rt2x00mac_flush() instead of > reimplementing the same actions the second time. Also, now it flushes > the rx queue aswell which it didn't before and that makes it completely > do what it's supposed to do according to struct iee80211_ops: flush() > must flush all queues. NACK, RX queue should not be flushed, mac80211 flush is about TX queues only. Stanislaw -- 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] firmware_class: Fix whitespace and indentation
Fix checkpatch.pl issues with coding style. Removed whitespace and
fixed indentation
Signed-off-by: Andrei Oprea
---
drivers/base/firmware_class.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..710540f 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -181,7 +181,7 @@ static struct firmware_buf *__allocate_fw_buf(const char
*fw_name,
{
struct firmware_buf *buf;
- buf = kzalloc(sizeof(*buf) + strlen(fw_name) + 1 , GFP_ATOMIC);
+ buf = kzalloc(sizeof(*buf) + strlen(fw_name) + 1, GFP_ATOMIC);
if (!buf)
return buf;
@@ -1168,7 +1168,7 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
**/
int
request_firmware(const struct firmware **firmware_p, const char *name,
- struct device *device)
+struct device *device)
{
int ret;
@@ -1196,6 +1196,7 @@ int request_firmware_direct(const struct firmware
**firmware_p,
const char *name, struct device *device)
{
int ret;
+
__module_get(THIS_MODULE);
ret = _request_firmware(firmware_p, name, device,
FW_OPT_UEVENT | FW_OPT_NO_WARN);
@@ -1276,7 +1277,7 @@ request_firmware_nowait(
{
struct firmware_work *fw_work;
- fw_work = kzalloc(sizeof (struct firmware_work), gfp);
+ fw_work = kzalloc(sizeof(struct firmware_work), gfp);
if (!fw_work)
return -ENOMEM;
--
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] drivers: base: memory: Use tabs instead of spaces
This patch changes spaces to tabs. Found using checkpatch.pl
Signed-off-by: Ioana Ciornei
---
drivers/base/memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 9b5dc89..2804aed 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,13 +52,13 @@ static BLOCKING_NOTIFIER_HEAD(memory_chain);
int register_memory_notifier(struct notifier_block *nb)
{
-return blocking_notifier_chain_register(&memory_chain, nb);
+ return blocking_notifier_chain_register(&memory_chain, nb);
}
EXPORT_SYMBOL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
-blocking_notifier_chain_unregister(&memory_chain, nb);
+ blocking_notifier_chain_unregister(&memory_chain, nb);
}
EXPORT_SYMBOL(unregister_memory_notifier);
--
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] drivers: base: node: Delete space after pointer declaration
This patch fixes the following error found by checkpatch.pl:
ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Ana Nedelcu
---
drivers/base/node.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 36fabe43..910754b 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -180,7 +180,7 @@ static ssize_t node_read_vmstat(struct device *dev,
static DEVICE_ATTR(vmstat, S_IRUGO, node_read_vmstat, NULL);
static ssize_t node_read_distance(struct device *dev,
- struct device_attribute *attr, char * buf)
+ struct device_attribute *attr, char *buf)
{
int nid = dev->id;
int len = 0;
--
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] driver core: add missing blank line after declaration
Found using checkpatch.pl
Signed-off-by: Lavinia Tache
---
drivers/base/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 9e29943..4eabfe2 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -103,6 +103,7 @@ int driver_create_file(struct device_driver *drv,
const struct driver_attribute *attr)
{
int error;
+
if (drv)
error = sysfs_create_file(&drv->p->kobj, &attr->attr);
else
--
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] nits: fix several coding style warnings
Fix checkpatch.pl warnings such as:
* missing blank line after declarations
* line over 80 characters
Signed-off-by: Ioana Antoche
---
drivers/base/bus.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 876bae5..9e448e1 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -128,6 +128,7 @@ static const struct sysfs_ops bus_sysfs_ops = {
int bus_create_file(struct bus_type *bus, struct bus_attribute *attr)
{
int error;
+
if (bus_get(bus)) {
error = sysfs_create_file(&bus->p->subsys.kobj, &attr->attr);
bus_put(bus);
@@ -298,8 +299,7 @@ static struct device *next_device(struct klist_iter *i)
* count in the supplied callback.
*/
int bus_for_each_dev(struct bus_type *bus, struct device *start,
-void *data, int (*fn)(struct device *, void *))
-{
+void *data, int (*fn)(struct device *, void *)) {
struct klist_iter i;
struct device *dev;
int error = 0;
@@ -385,8 +385,8 @@ EXPORT_SYMBOL_GPL(bus_find_device_by_name);
* otherwise, fall back to a full list search. Either way a reference for
* the returned object is taken.
*/
-struct device *subsys_find_device_by_id(struct bus_type *subsys, unsigned int
id,
- struct device *hint)
+struct device *subsys_find_device_by_id(struct bus_type *subsys,
+ unsigned int id, struct device *hint)
{
struct klist_iter i;
struct device *dev;
@@ -395,7 +395,8 @@ struct device *subsys_find_device_by_id(struct bus_type
*subsys, unsigned int id
return NULL;
if (hint) {
- klist_iter_init_node(&subsys->p->klist_devices, &i,
&hint->p->knode_bus);
+ klist_iter_init_node(&subsys->p->klist_devices, &i,
+ &hint->p->knode_bus);
dev = next_device(&i);
if (dev && dev->id == id && get_device(dev)) {
klist_iter_exit(&i);
@@ -448,8 +449,7 @@ static struct device_driver *next_driver(struct klist_iter
*i)
* so it doesn't disappear before returning to the caller.
*/
int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
-void *data, int (*fn)(struct device_driver *, void *))
-{
+void *data, int (*fn)(struct device_driver *, void *)) {
struct klist_iter i;
struct device_driver *drv;
int error = 0;
@@ -509,7 +509,8 @@ int bus_add_device(struct device *dev)
int error = 0;
if (bus) {
- pr_debug("bus: '%s': add device %s\n", bus->name,
dev_name(dev));
+ pr_debug("bus: '%s': add device %s\n", bus->name,
+ dev_name(dev));
error = device_add_attrs(bus, dev);
if (error)
goto out_put;
@@ -819,6 +820,7 @@ EXPORT_SYMBOL_GPL(device_reprobe);
struct bus_type *find_bus(char *name)
{
struct kobject *k = kset_find_obj(bus_kset, name);
+
return k ? to_bus(k) : NULL;
}
#endif /* 0 */
@@ -1000,7 +1002,8 @@ EXPORT_SYMBOL_GPL(bus_get_device_klist);
* holding the lock for the list, so objects can't otherwise be
* added/removed while we're swizzling.
*/
-static void device_insertion_sort_klist(struct device *a, struct list_head
*list,
+static void device_insertion_sort_klist(struct device *a,
+ struct list_head *list,
int (*compare)(const struct device *a,
const struct device *b))
{
@@ -1092,7 +1095,8 @@ struct device *subsys_dev_iter_next(struct
subsys_dev_iter *iter)
knode = klist_next(&iter->ki);
if (!knode)
return NULL;
- dev = container_of(knode, struct device_private,
knode_bus)->device;
+ dev = container_of(knode, struct device_private, knode_bus)
+ ->device;
if (!iter->type || iter->type == dev->type)
return dev;
}
--
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/4] Cleaned hexadecimal dump
On Sun, Mar 8, 2015 at 4:22 AM, Joe Perches wrote:
> On Sat, 2015-03-07 at 12:56 -0500, Adrian Remonda wrote:
>> +static void hexDump(const void *src, size_t length, size_t bLine, char
>> *prefix)
>> +{
>
> Is there something necessary that print_hex_dump can't do?
As far as I can see the tool is running in user space. Do we have
possibility to use print_hex_dump() in user space?
--
With Best Regards,
Andy Shevchenko
--
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: wm5100: match wait_for_completion_timeout return type
return type of wait_for_completion_timeout is unsigned long not int. An
appropriately named unsigned long is added and the assignment fixed up.
Signed-off-by: Nicholas Mc Guire
---
This was only compile tested for exynos_defconfig + CONFIG_COMPILE_TEST=y,
SND_SOC_ALL_CODECS=m (implies CONFIG_SND_SOC_WM5100=m)
Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)
sound/soc/codecs/wm5100.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c
index ea09db5..9674037 100644
--- a/sound/soc/codecs/wm5100.c
+++ b/sound/soc/codecs/wm5100.c
@@ -1762,6 +1762,7 @@ static int wm5100_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
struct _fll_div factors;
struct wm5100_fll *fll;
int ret, base, lock, i, timeout;
+ unsigned long time_left;
switch (fll_id) {
case WM5100_FLL1:
@@ -1842,9 +1843,9 @@ static int wm5100_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
/* Poll for the lock; will use interrupt when we can test */
for (i = 0; i < timeout; i++) {
if (i2c->irq) {
- ret = wait_for_completion_timeout(&fll->lock,
- msecs_to_jiffies(25));
- if (ret > 0)
+ time_left = wait_for_completion_timeout(&fll->lock,
+ msecs_to_jiffies(25));
+ if (time_left > 0)
break;
} else {
msleep(1);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio:inv-mpu6050: Fix inconsistency for the scale channel
On 04/03/15 13:57, Suman, Viorel wrote:
>
>> -Original Message-
>> From: linux-iio-ow...@vger.kernel.org [mailto:linux-iio-
>> ow...@vger.kernel.org] On Behalf Of Adriana Reus
>> Sent: Monday, February 23, 2015 4:41 PM
>> To: ji...@kernel.org; linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; Pandruvada, Srinivas; Reus, Adriana
>> Subject: [PATCH] iio:inv-mpu6050: Fix inconsistency for the scale channel
>>
>> Fix inconsistency in the semantics of the scale attribute.
>> For scale the write_raw function was considering the scale table index and
>> writing the appropriate value into the range register, while for read_raw it
>> was outputting the actual scale.
>> Fix this behaviour and adhere to the iio ABI specification.
>>
>> Signed-off-by: Adriana Reus
>
> Reviewed-by: Viorel Suman
Good catch. I'd just like to give Ge an opportunity to comment
before applying it.
Please do CC the original driver author as often they've moved on to
other stuff and aren't actively reading linux-iio anymore.
Jonathan
>
>> ---
>> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 56 --
>>
>> 1 file changed, 30 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> index 9be9b20..4cf056d 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> @@ -401,42 +401,46 @@ error_read_raw:
>> }
>> }
>>
>> -static int inv_mpu6050_write_fsr(struct inv_mpu6050_state *st, int fsr)
>> +static int inv_mpu6050_write_gyro_scale(struct inv_mpu6050_state *st,
>> +int val)
>> {
>> -int result;
>> +int result, i;
>> u8 d;
>>
>> -if (fsr < 0 || fsr > INV_MPU6050_MAX_GYRO_FS_PARAM)
>> -return -EINVAL;
>> -if (fsr == st->chip_config.fsr)
>> -return 0;
>> +for (i = 0; i < ARRAY_SIZE(gyro_scale_6050); ++i) {
>> +if (gyro_scale_6050[i] == val) {
>> +d = (i <<
>> INV_MPU6050_GYRO_CONFIG_FSR_SHIFT);
>> +result = inv_mpu6050_write_reg(st,
>> +st->reg->gyro_config, d);
>> +if (result)
>> +return result;
>>
>> -d = (fsr << INV_MPU6050_GYRO_CONFIG_FSR_SHIFT);
>> -result = inv_mpu6050_write_reg(st, st->reg->gyro_config, d);
>> -if (result)
>> -return result;
>> -st->chip_config.fsr = fsr;
>> +st->chip_config.fsr = i;
>> +return 0;
>> +}
>> +}
>>
>> -return 0;
>> +return -EINVAL;
>> }
>>
>> -static int inv_mpu6050_write_accel_fs(struct inv_mpu6050_state *st, int
>> fs)
>> +static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st,
>> +int val)
>> {
>> -int result;
>> +int result, i;
>> u8 d;
>>
>> -if (fs < 0 || fs > INV_MPU6050_MAX_ACCL_FS_PARAM)
>> -return -EINVAL;
>> -if (fs == st->chip_config.accl_fs)
>> -return 0;
>> +for (i = 0; i < ARRAY_SIZE(accel_scale); ++i) {
>> +if (accel_scale[i] == val) {
>> +d = (i << INV_MPU6050_ACCL_CONFIG_FSR_SHIFT);
>> +result = inv_mpu6050_write_reg(st,
>> +st->reg->accl_config, d);
>> +if (result)
>> +return result;
>>
>> -d = (fs << INV_MPU6050_ACCL_CONFIG_FSR_SHIFT);
>> -result = inv_mpu6050_write_reg(st, st->reg->accl_config, d);
>> -if (result)
>> -return result;
>> -st->chip_config.accl_fs = fs;
>> +st->chip_config.accl_fs = i;
>> +return 0;
>> +}
>> +}
>>
>> -return 0;
>> +return -EINVAL;
>> }
>>
>> static int inv_mpu6050_write_raw(struct iio_dev *indio_dev, @@ -463,10
>> +467,10 @@ static int inv_mpu6050_write_raw(struct iio_dev *indio_dev,
>> case IIO_CHAN_INFO_SCALE:
>> switch (chan->type) {
>> case IIO_ANGL_VEL:
>> -result = inv_mpu6050_write_fsr(st, val);
>> +result = inv_mpu6050_write_gyro_scale(st, val2);
>> break;
>> case IIO_ACCEL:
>> -result = inv_mpu6050_write_accel_fs(st, val);
>> +result = inv_mpu6050_write_accel_scale(st, val2);
>> break;
>> default:
>> result = -EINVAL;
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in the
>> body of a message to majord...@vger.kernel.org More majordomo info
>> at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscr
[PATCH] ASoC: wm2200: match wait_for_completion_timeout return type
return type of wait_for_completion_timeout is unsigned long not int. An
appropriately named unsigned long is added and the assignment fixed up.
Signed-off-by: Nicholas Mc Guire
---
This was only compile tested for exynos_defconfig + CONFIG_COMPILE_TEST=y,
SND_SOC_ALL_CODECS=m (implies CONFIG_SND_SOC_WM2200=m)
Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)
sound/soc/codecs/wm2200.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c
index 1559984..b48694a 100644
--- a/sound/soc/codecs/wm2200.c
+++ b/sound/soc/codecs/wm2200.c
@@ -1942,6 +1942,7 @@ static int wm2200_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
struct wm2200_priv *wm2200 = snd_soc_codec_get_drvdata(codec);
struct _fll_div factors;
int ret, i, timeout;
+ unsigned long time_left;
if (!Fout) {
dev_dbg(codec->dev, "FLL disabled");
@@ -2021,9 +2022,10 @@ static int wm2200_set_fll(struct snd_soc_codec *codec,
int fll_id, int source,
/* Poll for the lock; will use the interrupt to exit quickly */
for (i = 0; i < timeout; i++) {
if (i2c->irq) {
- ret = wait_for_completion_timeout(&wm2200->fll_lock,
- msecs_to_jiffies(25));
- if (ret > 0)
+ time_left = wait_for_completion_timeout(
+ &wm2200->fll_lock,
+ msecs_to_jiffies(25));
+ if (time_left > 0)
break;
} else {
msleep(1);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
On 8 March 2015 at 01:57, Brian Norris wrote: > 3. I was told that there were only 2 or 3 chips that were released with > a v6.1 NAND controller, and BCM4708 wasn't one of them. Apparently I was > told wrong... I'll have to see if there are any other quirks we should > be accounting for. Please note I'm speaking about 6.01, not 6.10. Maybe it make a difference? Buffalo WZR-600DHP2 (BCM47081) [0.325732] [brcmnand_revision_init:371] ctrl->nand_version:0x0601 [4.838105] bcma: bus0: Found chip with id 53010, rev 0x00 and package 0x02 Buffalo WZR-1750DHP (BCM4708) [0.326823] [brcmnand_revision_init:371] ctrl->nand_version:0x0601 [6.674288] bcma: bus0: Found chip with id 53010, rev 0x00 and package 0x02 Netgear R6250 V1 (BCM4708) [0.326248] [brcmnand_revision_init:371] ctrl->nand_version:0x0601 [8.721335] bcma: bus0: Found chip with id 53010, rev 0x00 and package 0x02 Netgear R8000 (BCM4709) [0.241961] bcma: bus0: Found chip with id 53010, rev 0x00 and package 0x00 [1.990330] bcm_nand bcma0:18: NAND Controller rev 6.01 -- Rafał -- 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] spi: qup: Add DMA capabilities
On 03/07/2015 08:43 PM, Andy Shevchenko wrote: On Sat, Mar 7, 2015 at 1:21 PM, Mark Brown wrote: On Wed, Mar 04, 2015 at 12:02:05PM +0200, Stanimir Varbanov wrote: From: Andy Gross This patch adds DMA capabilities to the spi-qup driver. If DMA channels are present, the QUP will use DMA instead of block mode for transfers to/from SPI peripherals for transactions larger than the length of a block. Applied, but why is there no devm_dma_request_slave_channel_reason()? I suppose the answer would be "we have a lot of slightly different cases and we have to get rid of current mess with legacy API calls". The most problematic stuff now inside DMA slave subsystem is so called "filter function". It's a main impediment right now as I understand. dma_request_slave_channel_reason() is the sane API though and does not use the filter functions. Adding a devm version of it seems reasonable. - Lars -- 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 0/7] Add initial support for DA9150 Charger & Fuel-Gauge IC
On 25/02/15 20:33, Sebastian Reichel wrote: > Hi, > > On Wed, Feb 18, 2015 at 02:08:19PM +, Adam Thomson wrote: >> This patch set adds initial support for the Dialog DA9150 Integrated Charger >> & >> Fuel-Gauge IC. The device also provides GPIO and GPADC functionality. >> >> In this patch set the following is provided: >> - MFD Core support and DT bindings documentation. >> - IIO GPADC support and DT bindings documentation. >> - Power Supply Charger support and DT bindings documentation. >> - Update to MAINTAINERS file to add DA9150 files to Dialog support list. >> >> To keep patch submission from being too large, support for GPIO and >> Fuel-Gauge >> will come after initial support patches are accepted. >> >> This patch set is baselined against the v3.19 kernel version. > > I pulled in patches 3-7 into battery-2.6.git (patch 1 was already > applied by Lee in 4.0-rc1 and patch 2 can simply be pulled in by > Lee). > > Jonathan: I have prepared an immutable branch "da9150-charger-fuelgauge" > based on 4.0-rc1, which contains the IIO bits, so that you can pull them > in, too: > > git://git.infradead.org/battery-2.6.git da9150-charger-fuelgauge I'll grab these only if I get patches on top of them in this cycle. Things get a little fiddly otherwise with my pull requests to Greg and I'm lazy ;) Thanks for sorting this Sebastian. Good to see this series all sorted out at last! Jonathan > > --Sebastian > -- 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] staging: iio: hmc5843: Set iio name property in sysfs
On 28/02/15 20:54, Marek Belisko wrote: > Without this change file name for hmc5843 is empty in > /sys/bus/iio/devices/iio\:device*/name > > With this change name is reported correctly: > cat /sys/bus/iio/devices/iio\:device*/name > hmc5843 > > Signed-off-by: Marek Belisko Good catch, thanks. Applied to the fixes-togreg branch of iio.git. Jonathan > --- > drivers/staging/iio/magnetometer/hmc5843_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/iio/magnetometer/hmc5843_core.c > b/drivers/staging/iio/magnetometer/hmc5843_core.c > index fd171d8..90cc18b 100644 > --- a/drivers/staging/iio/magnetometer/hmc5843_core.c > +++ b/drivers/staging/iio/magnetometer/hmc5843_core.c > @@ -592,6 +592,7 @@ int hmc5843_common_probe(struct device *dev, struct > regmap *regmap, > mutex_init(&data->lock); > > indio_dev->dev.parent = dev; > + indio_dev->name = dev->driver->name; > indio_dev->info = &hmc5843_info; > indio_dev->modes = INDIO_DIRECT_MODE; > indio_dev->channels = data->variant->channels; > -- 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: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
Hi Ivan, On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote: > On 03/05/2015 09:46 AM, Jean Delvare wrote: > > It's not just two tables (I don't expect a lot of BIOSes to provide two > > tables in practice, and they would have essentially the same format > > anyway) but more importantly two entry points. The _SM3_ entry point is > > brand new and most applications (including dmidecode) don't support it > > yet. It doesn't matter if the kernel itself can parse it, as it passes > > the raw entry point to applications anyway. > > > > It happens that we are introducing this new sysfs raw interface at the > > same time _SM3_ is being introduced, so we do not have to care about > > backwards compatibility. Both the kernel and dmidecode will need to be > > updated to support the new interface, so we can keep things simple and > > let the kernel expose only the best entry point. > > > > If the sysfs raw interface was already present at the time _SM3_ > > support was being added, then we would have had to present both entry > > points for backwards compatibility. And if some _SM4_ entry point is > > ever added in the future with a new format, we will have to export it > > as a new sysfs attribute so as to not break compatibility. > > > > As a summary, I agree that a single entry point file is OK for now, but > > only because we are lucky that the timing is right. > > Despite of timing is right. > > The specification doesn't oblige firmware to provide two entry points. > An implementation may provide either the 32-bit entry point or the 64-bit > entry point, or both. For compatibility with existing SMBIOS parsers, an > implementation should provide the 32-bit entry point, but it's not required. I expect most implementations will do, as it's trivial to implement. > Another case if specification requires to provide two entry points. Then > you can > be sure in backward compatibility. But at least for now you can't. > > It's obvious, if kernel found two entry points then it can create two > sysfs attributes. > But, what kernel should do in case if only one new entry point is present. > Generate entry point of old version..., sorry but it's bad idea. At > least because > where guarantee that we have enough information for this. Only field we > can bring > thought entry point versions is magic string _SM*_, and based on it, if util > don't support new version it can warn. It's used for differ versions and > there is nothing we can do more. I agree that the kernel should not fake an entry point which does not exist (I'm not sure if you misunderstood me but I never suggested that.) -- Jean Delvare SUSE L3 Support -- 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] iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo
On 26/02/15 18:35, Ge Gao wrote:
> Look fine to me.
> Thanks.
>
> Best Regards,
>
> Ge GAO
>
Formal Acks preferred ;)
Anyhow, applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
>
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: Saturday, February 21, 2015 11:01 AM
> To: Viorel Suman; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Srinivas Pandruvada; Ge Gao
> Subject: Re: [PATCH v2] iio: inv_mpu6050: Clear timestamps fifo while
> resetting hardware fifo
>
> On 18/02/15 18:05, Viorel Suman wrote:
>> A hardware fifo reset always imply an invalidation of the existing
>> timestamps, so we'll clear timestamps fifo on successfull hardware
>> fifo reset.
>>
>> Signed-off-by: Viorel Suman
> Looks sensible to me. Ge / Srinivas?
>> ---
>> v2: Addressed Jonathan's comment regarding the subject prefix.
>>
>> drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 25
>> ++---
>> 1 file changed, 14 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>> index 0cd306a..ba27e27 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>> @@ -24,6 +24,16 @@
>> #include
>> #include "inv_mpu_iio.h"
>>
>> +static void inv_clear_kfifo(struct inv_mpu6050_state *st) {
>> +unsigned long flags;
>> +
>> +/* take the spin lock sem to avoid interrupt kick in */
>> +spin_lock_irqsave(&st->time_stamp_lock, flags);
>> +kfifo_reset(&st->timestamps);
>> +spin_unlock_irqrestore(&st->time_stamp_lock, flags); }
>> +
>> int inv_reset_fifo(struct iio_dev *indio_dev) {
>> int result;
>> @@ -50,6 +60,10 @@ int inv_reset_fifo(struct iio_dev *indio_dev)
>> INV_MPU6050_BIT_FIFO_RST);
>> if (result)
>> goto reset_fifo_fail;
>> +
>> +/* clear timestamps fifo */
>> +inv_clear_kfifo(st);
>> +
>> /* enable interrupt */
>> if (st->chip_config.accl_fifo_enable ||
>> st->chip_config.gyro_fifo_enable) { @@ -83,16 +97,6 @@
>> reset_fifo_fail:
>> return result;
>> }
>>
>> -static void inv_clear_kfifo(struct inv_mpu6050_state *st) -{
>> -unsigned long flags;
>> -
>> -/* take the spin lock sem to avoid interrupt kick in */
>> -spin_lock_irqsave(&st->time_stamp_lock, flags);
>> -kfifo_reset(&st->timestamps);
>> -spin_unlock_irqrestore(&st->time_stamp_lock, flags);
>> -}
>> -
>> /**
>> * inv_mpu6050_irq_handler() - Cache a timestamp at each data ready
>> interrupt.
>> */
>> @@ -184,7 +188,6 @@ end_session:
>> flush_fifo:
>> /* Flush HW and SW FIFOs. */
>> inv_reset_fifo(indio_dev);
>> -inv_clear_kfifo(st);
>> mutex_unlock(&indio_dev->mlock);
>> iio_trigger_notify_done(indio_dev->trig);
>>
>>
>
--
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] iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo
On 08/03/15 11:31, Jonathan Cameron wrote:
> On 26/02/15 18:35, Ge Gao wrote:
>> Look fine to me.
>> Thanks.
>>
>> Best Regards,
>>
>> Ge GAO
>>
> Formal Acks preferred ;)
>
> Anyhow, applied to the fixes-togreg branch of iio.git.
Forgot to say - marked for stable as well.
>
> Thanks,
>
> Jonathan
>>
>> -Original Message-
>> From: Jonathan Cameron [mailto:ji...@kernel.org]
>> Sent: Saturday, February 21, 2015 11:01 AM
>> To: Viorel Suman; linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; Srinivas Pandruvada; Ge Gao
>> Subject: Re: [PATCH v2] iio: inv_mpu6050: Clear timestamps fifo while
>> resetting hardware fifo
>>
>> On 18/02/15 18:05, Viorel Suman wrote:
>>> A hardware fifo reset always imply an invalidation of the existing
>>> timestamps, so we'll clear timestamps fifo on successfull hardware
>>> fifo reset.
>>>
>>> Signed-off-by: Viorel Suman
>> Looks sensible to me. Ge / Srinivas?
>>> ---
>>> v2: Addressed Jonathan's comment regarding the subject prefix.
>>>
>>> drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 25
>>> ++---
>>> 1 file changed, 14 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>>> index 0cd306a..ba27e27 100644
>>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
>>> @@ -24,6 +24,16 @@
>>> #include
>>> #include "inv_mpu_iio.h"
>>>
>>> +static void inv_clear_kfifo(struct inv_mpu6050_state *st) {
>>> + unsigned long flags;
>>> +
>>> + /* take the spin lock sem to avoid interrupt kick in */
>>> + spin_lock_irqsave(&st->time_stamp_lock, flags);
>>> + kfifo_reset(&st->timestamps);
>>> + spin_unlock_irqrestore(&st->time_stamp_lock, flags); }
>>> +
>>> int inv_reset_fifo(struct iio_dev *indio_dev) {
>>> int result;
>>> @@ -50,6 +60,10 @@ int inv_reset_fifo(struct iio_dev *indio_dev)
>>> INV_MPU6050_BIT_FIFO_RST);
>>> if (result)
>>> goto reset_fifo_fail;
>>> +
>>> + /* clear timestamps fifo */
>>> + inv_clear_kfifo(st);
>>> +
>>> /* enable interrupt */
>>> if (st->chip_config.accl_fifo_enable ||
>>> st->chip_config.gyro_fifo_enable) { @@ -83,16 +97,6 @@
>>> reset_fifo_fail:
>>> return result;
>>> }
>>>
>>> -static void inv_clear_kfifo(struct inv_mpu6050_state *st) -{
>>> - unsigned long flags;
>>> -
>>> - /* take the spin lock sem to avoid interrupt kick in */
>>> - spin_lock_irqsave(&st->time_stamp_lock, flags);
>>> - kfifo_reset(&st->timestamps);
>>> - spin_unlock_irqrestore(&st->time_stamp_lock, flags);
>>> -}
>>> -
>>> /**
>>> * inv_mpu6050_irq_handler() - Cache a timestamp at each data ready
>>> interrupt.
>>> */
>>> @@ -184,7 +188,6 @@ end_session:
>>> flush_fifo:
>>> /* Flush HW and SW FIFOs. */
>>> inv_reset_fifo(indio_dev);
>>> - inv_clear_kfifo(st);
>>> mutex_unlock(&indio_dev->mlock);
>>> iio_trigger_notify_done(indio_dev->trig);
>>>
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.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/
[PATCH v4] media: i2c: add support for omnivision's ov2659 sensor
From: Benoit Parrot
this patch adds support for omnivision's ov2659
sensor, the driver supports following features:
1: Asynchronous probing
2: DT support
3: Media controller support
Signed-off-by: Benoit Parrot
Signed-off-by: Lad, Prabhakar
---
Sorry quick new version, I need to get this merged for next
merge window.
Changes for v4:
1: Renamed target frequency property to 'link-frequencies'
as per Sakari's suggestion.
2: Changed the copyright to "GPL v2"
v3: https://patchwork.kernel.org/patch/5959401/
v2: https://patchwork.kernel.org/patch/5859801/
v1: https://patchwork.linuxtv.org/patch/27919/
.../devicetree/bindings/media/i2c/ov2659.txt | 38 +
MAINTAINERS| 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov2659.c | 1439
include/media/ov2659.h | 33 +
6 files changed, 1532 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
create mode 100644 drivers/media/i2c/ov2659.c
create mode 100644 include/media/ov2659.h
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2659.txt
b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
new file mode 100644
index 000..a655500
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
@@ -0,0 +1,38 @@
+* OV2659 1/5-Inch 2Mp SOC Camera
+
+The Omnivision OV2659 is a 1/5-inch SOC camera, with an active array size of
+1632H x 1212V. It is programmable through a SCCB. The OV2659 sensor supports
+multiple resolutions output, such as UXGA, SVGA, 720p. It also can support
+YUV422, RGB565/555 or raw RGB output formats.
+
+Required Properties:
+- compatible: Must be "ovti,ov2659"
+- reg: I2C slave address
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+- link-frequencies: target pixel clock frequency.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ov2659@30 {
+ compatible = "ovti,ov2659";
+ reg = <0x30>;
+
+ clocks = <&clk_ov2659 0>;
+ clock-names = "xvclk";
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = <&vpfe_ep>;
+ link-frequencies = <7000>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..4006cc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8910,6 +8910,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar
+L: linux-me...@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate "OmniVision OV2659 sensor support"
+ depends on VIDEO_V4L2 && I2C
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL)+= smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..eca96b7
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
@@ -0,0 +1,1439 @@
+/*
+ * Omnivision OV2659 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * Benoit Parrot
+ * Lad, Prabhakar
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under th
Re: [PATCH 1/1] x86/fpu: math_state_restore() should not blindly disable irqs
* Ingo Molnar wrote: > Doing that would give us four (theoretical) performance advantages: > > - No implicit irq disabling overhead when the syscall instruction is > executed: we could change MSR_SYSCALL_MASK from 0xc084 to > 0xc284, which removes the implicit CLI on syscall entry. > > - No explicit irq enabling overhead via ENABLE_INTERRUPTS() [STI] in > system_call. > > - No explicit irq disabling overhead in the ret_from_sys_call fast > path, i.e. no DISABLE_INTERRUPTS() [CLI]. > > - No implicit irq enabling overhead in ret_from_sys_call's > USERGS_SYSRET64: the SYSRETQ instruction would not have to > re-enable irqs as the user-space IF in R11 would match that of the > current IF. > > whether that's an actual performance win in practice as well needs > to be measured, but I'd be (very!) shocked if it wasn't in the 20+ > cycles range: which is absolutely huge in terms of system_call > optimizations. So just to quantify the potential 64-bit system call entry fast path performance savings a bit, I tried to simulate the effects in user-space via a 'best case' simulation, where we do a PUSHFQ+CLI+STI ... CLI+POPFQ simulated syscall sequence (beginning and end sufficiently far from each other to not be interacting), on Intel family 6 model 62 CPUs (slightly dated but still relevant): with irq disabling/enabling: new best speed: 2710739 loops (158 cycles per iteration). fully preemptible: new best speed: 3389503 loops (113 cycles per iteration). now that's an about 40 cycles difference, but admittedly the cost very much depends on the way we save flags and on the way we restore flags and depends on how intelligently the CPU can hide the irq disabling and the restoration amongst other processing it has to do on entry/exit, which it can do pretty well in a number of important cases. I don't think I can simulate the real thing in user-space: - The hardest bit to simulate is SYSRET: POPFQ is expensive, but SYSRET might be able to 'cheat' on the enabling side - I _think_ it cannot cheat because user-space might have come in with irqs disabled itself (we still have iopl(3)), so it's a POPFQ equivalent instruction. - OTOH the CPU might be able to hide the latency of the POPFQ amongst other SYSRET return work (which is significant) - so this is really hard to estimate. So "we'll have to try it to see it" :-/ [and maybe Intel knows.] But even if just half of the suspected savings can be realized: a 20 cycles speedup is very tempting IMHO, given that our 64-bit system calls cost around 110 cycles these days. Yes, it's scary, crazy, potentially fragile, might not even work, etc. - but it's also very tempting nevertheless ... So I'll try to write a prototype of this, just to be able to get some numbers - but shoot me down if you think I'm being stupid and if the concept is an absolute non-starter to begin with! Thanks, Ingo -- 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: no release on Monday
Hi all, There will be no release on Monday (next-20150309) as we take a day off to celebrate our wonderful city :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp3Vwi92NHNI.pgp Description: OpenPGP digital signature
Re: [PATCH 1/3] Staging: iio: meter: ade7854-i2c: code style improvements
On 15/02/15 04:32, Tolga Ceylan wrote:
> Code reformatting based on checkpatch.pl with --strict:
> Alignment should match open paranthesis cases corrected
>
> Signed-off-by: Tolga Ceylan
Applied to the togreg branch of iio.git - will initially be pushed
out as testing for the autobuilders to play.
Thanks
Jonathan
> ---
> drivers/staging/iio/meter/ade7854-i2c.c | 34
> -
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/staging/iio/meter/ade7854-i2c.c
> b/drivers/staging/iio/meter/ade7854-i2c.c
> index 5b33c7f..85a7e84 100644
> --- a/drivers/staging/iio/meter/ade7854-i2c.c
> +++ b/drivers/staging/iio/meter/ade7854-i2c.c
> @@ -16,8 +16,8 @@
> #include "ade7854.h"
>
> static int ade7854_i2c_write_reg_8(struct device *dev,
> - u16 reg_address,
> - u8 value)
> +u16 reg_address,
> +u8 value)
> {
> int ret;
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> @@ -35,8 +35,8 @@ static int ade7854_i2c_write_reg_8(struct device *dev,
> }
>
> static int ade7854_i2c_write_reg_16(struct device *dev,
> - u16 reg_address,
> - u16 value)
> + u16 reg_address,
> + u16 value)
> {
> int ret;
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> @@ -55,8 +55,8 @@ static int ade7854_i2c_write_reg_16(struct device *dev,
> }
>
> static int ade7854_i2c_write_reg_24(struct device *dev,
> - u16 reg_address,
> - u32 value)
> + u16 reg_address,
> + u32 value)
> {
> int ret;
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> @@ -76,8 +76,8 @@ static int ade7854_i2c_write_reg_24(struct device *dev,
> }
>
> static int ade7854_i2c_write_reg_32(struct device *dev,
> - u16 reg_address,
> - u32 value)
> + u16 reg_address,
> + u32 value)
> {
> int ret;
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> @@ -98,8 +98,8 @@ static int ade7854_i2c_write_reg_32(struct device *dev,
> }
>
> static int ade7854_i2c_read_reg_8(struct device *dev,
> - u16 reg_address,
> - u8 *val)
> + u16 reg_address,
> + u8 *val)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ade7854_state *st = iio_priv(indio_dev);
> @@ -124,8 +124,8 @@ out:
> }
>
> static int ade7854_i2c_read_reg_16(struct device *dev,
> - u16 reg_address,
> - u16 *val)
> +u16 reg_address,
> +u16 *val)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ade7854_state *st = iio_priv(indio_dev);
> @@ -150,8 +150,8 @@ out:
> }
>
> static int ade7854_i2c_read_reg_24(struct device *dev,
> - u16 reg_address,
> - u32 *val)
> +u16 reg_address,
> +u32 *val)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ade7854_state *st = iio_priv(indio_dev);
> @@ -176,8 +176,8 @@ out:
> }
>
> static int ade7854_i2c_read_reg_32(struct device *dev,
> - u16 reg_address,
> - u32 *val)
> +u16 reg_address,
> +u32 *val)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ade7854_state *st = iio_priv(indio_dev);
> @@ -202,7 +202,7 @@ out:
> }
>
> static int ade7854_i2c_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> + const struct i2c_device_id *id)
> {
> int ret;
> struct ade7854_state *st;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Staging: iio: meter: ade7854-i2c: code style improvements
On 15/02/15 04:32, Tolga Ceylan wrote: > Code reformatting based on checkpatch.pl with --strict: > Lines over 80 characters were fixed > > Signed-off-by: Tolga Ceylan You sent me a patch for this a week before this one which was applied. So already done :) > --- > drivers/staging/iio/meter/ade7854-i2c.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/meter/ade7854-i2c.c > b/drivers/staging/iio/meter/ade7854-i2c.c > index 85a7e84..5e6fbe4 100644 > --- a/drivers/staging/iio/meter/ade7854-i2c.c > +++ b/drivers/staging/iio/meter/ade7854-i2c.c > @@ -195,7 +195,8 @@ static int ade7854_i2c_read_reg_32(struct device *dev, > if (ret) > goto out; > > - *val = (st->rx[0] << 24) | (st->rx[1] << 16) | (st->rx[2] << 8) | > st->rx[3]; > + *val = (st->rx[0] << 24) | (st->rx[1] << 16) | > + (st->rx[2] << 8) | st->rx[3]; > out: > mutex_unlock(&st->buf_lock); > return ret; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Staging: iio: meter: ade7854-i2c: code style improvements
On 15/02/15 04:32, Tolga Ceylan wrote: > Code reformatting based on checkpatch.pl with --strict: > Comparison to NULL rewritten as !indio_dev > > Signed-off-by: Tolga Ceylan Whilst I find it hard to care on this particular fix.. what the heck. Applied to the togreg branch of iio.git. Thanks, Jonathan > --- > drivers/staging/iio/meter/ade7854-i2c.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/meter/ade7854-i2c.c > b/drivers/staging/iio/meter/ade7854-i2c.c > index 5e6fbe4..4e7a382 100644 > --- a/drivers/staging/iio/meter/ade7854-i2c.c > +++ b/drivers/staging/iio/meter/ade7854-i2c.c > @@ -210,7 +210,7 @@ static int ade7854_i2c_probe(struct i2c_client *client, > struct iio_dev *indio_dev; > > indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*st)); > - if (indio_dev == NULL) > + if (!indio_dev) > return -ENOMEM; > st = iio_priv(indio_dev); > i2c_set_clientdata(client, indio_dev); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/1] iio: light: Added PM support for Capella CM3232 ambient light sensor driver.
On 19/02/15 23:02, Kevin Tsai wrote:
> Added Power Management Support.
>
> Signed-off-by: Kevin Tsai
Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play.
Thanks,
Jonathan
> ---
> v2:
> Added CONFIG_PM_SLEEP to suspend/resume functions to fix the build warning
> when CONFIG_PM_SLEEP is not selected.
>
> v1:
> Added Power Management support.
>
> drivers/iio/light/cm3232.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c
> index 90e3519..39c8d99 100644
> --- a/drivers/iio/light/cm3232.c
> +++ b/drivers/iio/light/cm3232.c
> @@ -378,6 +378,39 @@ static const struct i2c_device_id cm3232_id[] = {
> {}
> };
>
> +#ifdef CONFIG_PM_SLEEP
> +static int cm3232_suspend(struct device *dev)
> +{
> + struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> + struct cm3232_chip *chip = iio_priv(indio_dev);
> + struct i2c_client *client = chip->client;
> + int ret;
> +
> + chip->regs_cmd |= CM3232_CMD_ALS_DISABLE;
> + ret = i2c_smbus_write_byte_data(client, CM3232_REG_ADDR_CMD,
> + chip->regs_cmd);
> +
> + return ret;
> +}
> +
> +static int cm3232_resume(struct device *dev)
> +{
> + struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> + struct cm3232_chip *chip = iio_priv(indio_dev);
> + struct i2c_client *client = chip->client;
> + int ret;
> +
> + chip->regs_cmd &= ~CM3232_CMD_ALS_DISABLE;
> + ret = i2c_smbus_write_byte_data(client, CM3232_REG_ADDR_CMD,
> + chip->regs_cmd | CM3232_CMD_ALS_RESET);
> +
> + return ret;
> +}
> +
> +static const struct dev_pm_ops cm3232_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(cm3232_suspend, cm3232_resume)};
> +#endif
> +
> MODULE_DEVICE_TABLE(i2c, cm3232_id);
>
> static const struct of_device_id cm3232_of_match[] = {
> @@ -390,6 +423,9 @@ static struct i2c_driver cm3232_driver = {
> .name = "cm3232",
> .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(cm3232_of_match),
> +#ifdef CONFIG_PM_SLEEP
> + .pm = &cm3232_pm_ops,
> +#endif
> },
> .id_table = cm3232_id,
> .probe = cm3232_probe,
>
--
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] spi: qup: Add DMA capabilities
On Sun, Mar 8, 2015 at 1:21 PM, Lars-Peter Clausen wrote: > On 03/07/2015 08:43 PM, Andy Shevchenko wrote: >> >> On Sat, Mar 7, 2015 at 1:21 PM, Mark Brown wrote: >>> Applied, but why is there no devm_dma_request_slave_channel_reason()? >> >> I suppose the answer would be "we have a lot of slightly different >> cases and we have to get rid of current mess with legacy API calls". >> The most problematic stuff now inside DMA slave subsystem is so called >> "filter function". It's a main impediment right now as I understand. > > dma_request_slave_channel_reason() is the sane API though and does not use > the filter functions. Adding a devm version of it seems reasonable. It would be dma_request_slave_channel() in the first place, but legacy stuff didn't allow to do that, so here we are. I wouldn't like the idea of creating devm_dma_* before we will have stable function names without legacy involving. -- With Best Regards, Andy Shevchenko -- 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 4/4] staging: sm750fb: fix undeclared function
kbuild test robot reported that for microblaze-allyesconfig
chan_to_field() and lynxfb_ops_set_par() were not defined. These two
functions were defined under CONFIG_PM, so for any archtecture if
CONFIG_PM is not defined we will have this error.
while moving the lynxfb_suspend() function some very obvious
checkpatch errors were taken care of.
Reported-by: kbuild test robot
Signed-off-by: Sudip Mukherjee
---
drivers/staging/sm750fb/sm750.c | 109 +++-
1 file changed, 52 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 753869e..8a78ea5 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -303,62 +303,6 @@ static int lynxfb_ops_pan_display(struct fb_var_screeninfo
*var,
return ret;
}
-
-
-
-#ifdef CONFIG_PM
-static int lynxfb_suspend(struct pci_dev * pdev,pm_message_t mesg)
-{
- struct fb_info * info;
- struct lynx_share * share;
- int ret;
-
-
- if(mesg.event == pdev->dev.power.power_state.event)
- return 0;
-
- ret = 0;
- share = pci_get_drvdata(pdev);
- switch (mesg.event) {
- case PM_EVENT_FREEZE:
- case PM_EVENT_PRETHAW:
- pdev->dev.power.power_state = mesg;
- return 0;
- }
-
- console_lock();
- if (mesg.event & PM_EVENT_SLEEP) {
- info = share->fbinfo[0];
- if(info)
- fb_set_suspend(info, 1);/* 1 means do suspend*/
-
- info = share->fbinfo[1];
- if(info)
- fb_set_suspend(info, 1);/* 1 means do suspend*/
-
- ret = pci_save_state(pdev);
- if(ret){
- pr_err("error:%d occured in pci_save_state\n",ret);
- return ret;
- }
-
- /* set chip to sleep mode */
- if(share->suspend)
- (*share->suspend)(share);
-
- pci_disable_device(pdev);
- ret = pci_set_power_state(pdev,pci_choose_state(pdev,mesg));
- if(ret){
- pr_err("error:%d occured in pci_set_power_state\n",ret);
- return ret;
- }
- }
-
- pdev->dev.power.power_state = mesg;
- console_unlock();
- return ret;
-}
-
static int lynxfb_ops_set_par(struct fb_info * info)
{
struct lynxfb_par * par;
@@ -369,7 +313,6 @@ static int lynxfb_ops_set_par(struct fb_info * info)
struct fb_fix_screeninfo * fix;
int ret;
unsigned int line_length;
-
if(!info)
return -EINVAL;
@@ -441,6 +384,7 @@ static int lynxfb_ops_set_par(struct fb_info * info)
ret = output->proc_setMode(output,var,fix);
return ret;
}
+
static inline unsigned int chan_to_field(unsigned int chan,struct fb_bitfield
* bf)
{
chan &= 0x;
@@ -448,6 +392,57 @@ static inline unsigned int chan_to_field(unsigned int
chan,struct fb_bitfield *
return chan << bf->offset;
}
+#ifdef CONFIG_PM
+static int lynxfb_suspend(struct pci_dev *pdev, pm_message_t mesg)
+{
+ struct fb_info *info;
+ struct lynx_share *share;
+ int ret;
+
+ if (mesg.event == pdev->dev.power.power_state.event)
+ return 0;
+
+ ret = 0;
+ share = pci_get_drvdata(pdev);
+ switch (mesg.event) {
+ case PM_EVENT_FREEZE:
+ case PM_EVENT_PRETHAW:
+ pdev->dev.power.power_state = mesg;
+ return 0;
+ }
+
+ console_lock();
+ if (mesg.event & PM_EVENT_SLEEP) {
+ info = share->fbinfo[0];
+ if (info)
+ fb_set_suspend(info, 1);/* 1 means do suspend*/
+
+ info = share->fbinfo[1];
+ if (info)
+ fb_set_suspend(info, 1);/* 1 means do suspend*/
+
+ ret = pci_save_state(pdev);
+ if (ret) {
+ pr_err("error:%d occurred in pci_save_state\n", ret);
+ return ret;
+ }
+
+ /* set chip to sleep mode */
+ if (share->suspend)
+ (*share->suspend)(share);
+
+ pci_disable_device(pdev);
+ ret = pci_set_power_state(pdev, pci_choose_state(pdev, mesg));
+ if (ret) {
+ pr_err("error:%d occurred in pci_set_power_state\n",
ret);
+ return ret;
+ }
+ }
+
+ pdev->dev.power.power_state = mesg;
+ console_unlock();
+ return ret;
+}
static int lynxfb_resume(struct pci_dev* pdev)
{
--
1.8.1.2
--
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
Pl
[PATCH 2/4] staging: sm750fb: remove pragma optimize
remove use of #pragma optimize which will usually be ignored by the compiler. Signed-off-by: Sudip Mukherjee --- drivers/staging/sm750fb/ddk750_swi2c.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c index b53407b..cae6b9b 100644 --- a/drivers/staging/sm750fb/ddk750_swi2c.c +++ b/drivers/staging/sm750fb/ddk750_swi2c.c @@ -217,8 +217,6 @@ static unsigned char swI2CReadSDA(void) return 0; } -#pragma optimize( "", off ) - /* * This function sends ACK signal */ @@ -356,7 +354,6 @@ unsigned char swI2CReadByte(unsigned char ack) return data; } -#pragma optimize( "", on ) /* * This function initializes GPIO port for SW I2C communication. -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] staging: sm750fb: wrong type for print
mention correct format specifier while printing
Signed-off-by: Sudip Mukherjee
---
this patch will give checkpatch warnings about use of printk.
this patch was mainly to fix the build warnings. printk will be
converted to pr_* and dev_* in a later patch.
drivers/staging/sm750fb/sm750.c| 24
drivers/staging/sm750fb/sm750.h| 8
drivers/staging/sm750fb/sm750_hw.c | 4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 520c69e..753869e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -530,20 +530,20 @@ static int lynxfb_ops_mmap(struct fb_info * info, struct
vm_area_struct * vma)
if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
return -EINVAL;
off = vma->vm_pgoff << PAGE_SHIFT;
- printk("lynxfb mmap pgoff: %x\n", vma->vm_pgoff);
- printk("lynxfb mmap off 1: %x\n", off);
+ printk("lynxfb mmap pgoff: %lx\n", vma->vm_pgoff);
+ printk("lynxfb mmap off 1: %lx\n", off);
/* frame buffer memory */
start = info->fix.smem_start;
len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.smem_len);
- printk("lynxfb mmap start 1: %x\n", start);
+ printk("lynxfb mmap start 1: %lx\n", start);
printk("lynxfb mmap len 1: %x\n", len);
if (off >= len) {
/* memory mapped io */
off -= len;
- printk("lynxfb mmap off 2: %x\n", off);
+ printk("lynxfb mmap off 2: %lx\n", off);
if (info->var.accel_flags) {
printk("lynxfb mmap accel flags true");
return -EINVAL;
@@ -551,28 +551,28 @@ static int lynxfb_ops_mmap(struct fb_info * info, struct
vm_area_struct * vma)
start = info->fix.mmio_start;
len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.mmio_len);
- printk("lynxfb mmap start 2: %x\n", start);
+ printk("lynxfb mmap start 2: %lx\n", start);
printk("lynxfb mmap len 2: %x\n", len);
}
start &= PAGE_MASK;
- printk("lynxfb mmap start 3: %x\n", start);
- printk("lynxfb mmap vm start: %x\n", vma->vm_start);
- printk("lynxfb mmap vm end: %x\n", vma->vm_end);
+ printk("lynxfb mmap start 3: %lx\n", start);
+ printk("lynxfb mmap vm start: %lx\n", vma->vm_start);
+ printk("lynxfb mmap vm end: %lx\n", vma->vm_end);
printk("lynxfb mmap len: %x\n", len);
- printk("lynxfb mmap off: %x\n", off);
+ printk("lynxfb mmap off: %lx\n", off);
if ((vma->vm_end - vma->vm_start + off) > len)
{
return -EINVAL;
}
off += start;
- printk("lynxfb mmap off 3: %x\n", off);
+ printk("lynxfb mmap off 3: %lx\n", off);
vma->vm_pgoff = off >> PAGE_SHIFT;
/* This is an IO map - tell maydump to skip this VMA */
vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
fb_pgprotect(file, vma, off);
- printk("lynxfb mmap off 4: %x\n", off);
- printk("lynxfb mmap pgprot: %x\n", vma->vm_page_prot);
+ printk("lynxfb mmap off 4: %lx\n", off);
+ printk("lynxfb mmap pgprot: %lx\n", (unsigned long)
pgprot_val(vma->vm_page_prot));
if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 711676c..2ab7b74 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -59,10 +59,10 @@ struct lynx_share{
}mtrr;
#endif
/* all smi graphic adaptor got below attributes */
- resource_size_t vidmem_start;
- resource_size_t vidreg_start;
- resource_size_t vidmem_size;
- resource_size_t vidreg_size;
+ unsigned long vidmem_start;
+ unsigned long vidreg_start;
+ unsigned long vidmem_size;
+ unsigned long vidreg_size;
volatile unsigned char __iomem * pvReg;
unsigned char __iomem * pvMem;
/* locks*/
diff --git a/drivers/staging/sm750fb/sm750_hw.c
b/drivers/staging/sm750fb/sm750_hw.c
index cd971bd..5a62721 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -36,7 +36,7 @@ int hw_sm750_map(struct lynx_share* share,struct pci_dev*
pdev)
share->vidreg_start = pci_resource_start(pdev,1);
share->vidreg_size = MB(2);
- pr_info("mmio phyAddr = %x\n",share->vidreg_start);
+ pr_info("mmio phyAddr = %lx\n", share->vidreg_start);
/* reserve the vidreg space of smi adaptor
* if you do this, u need to add release region code
@@ -73,7 +73,7 @@ int hw_sm750_
[PATCH 3/4] staging: sm750fb: correctly define SM750LE_REVISION_ID
check if it is already defined before defining SM750LE_REVISION_ID again and at the same time mention correct data type. Signed-off-by: Sudip Mukherjee --- drivers/staging/sm750fb/ddk750_chip.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/sm750fb/ddk750_chip.h b/drivers/staging/sm750fb/ddk750_chip.h index 1c78875..e7d27e8 100644 --- a/drivers/staging/sm750fb/ddk750_chip.h +++ b/drivers/staging/sm750fb/ddk750_chip.h @@ -1,7 +1,9 @@ #ifndef DDK750_CHIP_H__ #define DDK750_CHIP_H__ #define DEFAULT_INPUT_CLOCK 14318181 /* Default reference clock */ -#define SM750LE_REVISION_ID (char)0xfe +#ifndef SM750LE_REVISION_ID +#define SM750LE_REVISION_ID ((unsigned char)0xfe) +#endif /* This is all the chips recognized by this library */ typedef enum _logical_chip_type_t -- 1.8.1.2 -- 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/4] staging: sm750fb: wrong type for print
On 2015.03.08 14:31, Sudip Mukherjee wrote:
> mention correct format specifier while printing
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> this patch will give checkpatch warnings about use of printk.
> this patch was mainly to fix the build warnings. printk will be
> converted to pr_* and dev_* in a later patch.
>
> drivers/staging/sm750fb/sm750.c| 24
> drivers/staging/sm750fb/sm750.h| 8
> drivers/staging/sm750fb/sm750_hw.c | 4 ++--
> 3 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 520c69e..753869e 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -530,20 +530,20 @@ static int lynxfb_ops_mmap(struct fb_info * info,
> struct vm_area_struct * vma)
> if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
> return -EINVAL;
> off = vma->vm_pgoff << PAGE_SHIFT;
> - printk("lynxfb mmap pgoff: %x\n", vma->vm_pgoff);
> - printk("lynxfb mmap off 1: %x\n", off);
> + printk("lynxfb mmap pgoff: %lx\n", vma->vm_pgoff);
> + printk("lynxfb mmap off 1: %lx\n", off);
>
> /* frame buffer memory */
> start = info->fix.smem_start;
> len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.smem_len);
>
> - printk("lynxfb mmap start 1: %x\n", start);
> + printk("lynxfb mmap start 1: %lx\n", start);
> printk("lynxfb mmap len 1: %x\n", len);
>
> if (off >= len) {
> /* memory mapped io */
> off -= len;
> - printk("lynxfb mmap off 2: %x\n", off);
> + printk("lynxfb mmap off 2: %lx\n", off);
> if (info->var.accel_flags) {
> printk("lynxfb mmap accel flags true");
> return -EINVAL;
> @@ -551,28 +551,28 @@ static int lynxfb_ops_mmap(struct fb_info * info,
> struct vm_area_struct * vma)
> start = info->fix.mmio_start;
> len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.mmio_len);
>
> - printk("lynxfb mmap start 2: %x\n", start);
> + printk("lynxfb mmap start 2: %lx\n", start);
> printk("lynxfb mmap len 2: %x\n", len);
> }
> start &= PAGE_MASK;
> - printk("lynxfb mmap start 3: %x\n", start);
> - printk("lynxfb mmap vm start: %x\n", vma->vm_start);
> - printk("lynxfb mmap vm end: %x\n", vma->vm_end);
> + printk("lynxfb mmap start 3: %lx\n", start);
> + printk("lynxfb mmap vm start: %lx\n", vma->vm_start);
> + printk("lynxfb mmap vm end: %lx\n", vma->vm_end);
> printk("lynxfb mmap len: %x\n", len);
> - printk("lynxfb mmap off: %x\n", off);
> + printk("lynxfb mmap off: %lx\n", off);
> if ((vma->vm_end - vma->vm_start + off) > len)
> {
> return -EINVAL;
> }
> off += start;
> - printk("lynxfb mmap off 3: %x\n", off);
> + printk("lynxfb mmap off 3: %lx\n", off);
> vma->vm_pgoff = off >> PAGE_SHIFT;
> /* This is an IO map - tell maydump to skip this VMA */
> vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> fb_pgprotect(file, vma, off);
> - printk("lynxfb mmap off 4: %x\n", off);
> - printk("lynxfb mmap pgprot: %x\n", vma->vm_page_prot);
> + printk("lynxfb mmap off 4: %lx\n", off);
> + printk("lynxfb mmap pgprot: %lx\n", (unsigned long)
> pgprot_val(vma->vm_page_prot));
> if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
>vma->vm_end - vma->vm_start, vma->vm_page_prot))
> return -EAGAIN;
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index 711676c..2ab7b74 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -59,10 +59,10 @@ struct lynx_share{
> }mtrr;
> #endif
> /* all smi graphic adaptor got below attributes */
> - resource_size_t vidmem_start;
> - resource_size_t vidreg_start;
> - resource_size_t vidmem_size;
> - resource_size_t vidreg_size;
> + unsigned long vidmem_start;
> + unsigned long vidreg_start;
> + unsigned long vidmem_size;
> + unsigned long vidreg_size;
Have you checked other places where these are used? resource_size_t can
be either u64 or u32 depending on if CONFIG_PHYS_ADDR_T_64BIT is
#defined. Are you sure you aren't losing information when results of
functions are being assigned to this? Maybe there should be a function
similar to printk that changes between %u and %llu depending on whether
that is defined?
--
Thanks,
Giedrius
--
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] nits: fix several coding style warnings
On Sun, Mar 08, 2015 at 12:53:17PM +0200, Ioana Antoche wrote: > Fix checkpatch.pl warnings such as: > * missing blank line after declarations > * line over 80 characters > > Signed-off-by: Ioana Antoche The subject: of "nits" doesn't really say where in the kernel the patch is for, please use "driver core" instead. Can you please resend? And was this part of a class project? I got about 10 of these all at once, which is really odd. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] char/misc driver fixes for 4.0-rc3
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/char-misc-4.0-rc3 for you to fetch changes up to 6c15a8516b8118eb19a59fd0bd22df41b9101c32: mei: make device disabled on stop unconditionally (2015-03-01 19:34:50 -0800) char/misc driver fixes for 4.0-rc3 Here are 2 char/misc fixes for 4.0-rc3. One is a reported binder driver fix needed due to a change in the mm core that happened in 4.0-rc1. Another is a mei driver fix that resolves a reported issue in that driver. Both have been in linux-next for a while. Signed-off-by: Greg Kroah-Hartman Alexander Usyskin (1): mei: make device disabled on stop unconditionally Andrey Ryabinin (1): android: binder: fix binder mmap failures drivers/android/binder.c | 10 +- drivers/misc/mei/init.c | 2 ++ 2 files changed, 7 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Staging driver fixes for 4.0-rc3
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.0-rc3 for you to fetch changes up to abe46b8932dd9a6dfc3698e3eb121809b7b9ed28: staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel (2015-03-01 19:25:59 -0800) staging driver fixes for 4.0-rc3 Here are some IIO and staging driver fixes for 4.0-rc3. Details are in the shortlog, nothing major, mostly IIO fixes for reported issues. All have been in linux-next successfully. Signed-off-by: Greg Kroah-Hartman Andrey Smirnov (1): IIO: si7020: Allocate correct amount of memory in devm_iio_device_alloc Angelo Compagnucci (1): iio:adc:mcp3422 Fix incorrect scales table Arnd Bergmann (1): iio: ak8975: fix AK09911 dependencies Geert Uytterhoeven (1): iio: common: ssp_sensors: Protect PM-only functions to kill warning Greg Kroah-Hartman (2): Merge tag 'iio-fixes-for-4.0a' of git://git.kernel.org/.../jic23/iio into staging-linus Merge tag 'iio-fixes-for-4.0b' of git://git.kernel.org/.../jic23/iio into staging-linus H Hartley Sweeten (2): staging: comedi: comedi_isadma: fix "stalled" detect in comedi_isadma_disable_on_sample() staging: comedi: vmk80xx: remove "firmware version" kernel messages Ian Abbott (1): staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel Jonathan Cameron (1): Revert "iio:humidity:si7020: fix pointer to i2c client" Kristina Martšenko (4): iio: mxs-lradc: separate touchscreen and buffer virtual channels iio: mxs-lradc: make ADC reads not disable touchscreen interrupts iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions iio: mxs-lradc: only update the buffer when its conversions have finished Nicholas Mc Guire (1): iio: iadc: wait_for_completion_timeout time in jiffies Rasmus Villemoes (2): staging: iio: ad2s1200: Fix sign extension iio: imu: adis16400: Fix sign extension Richard Weinberger (3): iio: dht11: Fix out-of-bounds read iio: dht11: Add locking iio: dht11: IRQ fixes Roberta Dobrescu (2): iio: light: jsa1212: Select REGMAP_I2C iio: light: gp2ap020a00f: Select REGMAP_I2C Srinivas Pandruvada (1): iio: imu: inv_mpu6050: Prevent dereferencing NULL Stefan Wahren (1): iio: mxs-lradc: fix iio channel map regression Urs Fässler (1): iio: ad5686: fix optional reference voltage declaration drivers/iio/adc/mcp3422.c | 17 +- drivers/iio/adc/qcom-spmi-iadc.c | 3 +- drivers/iio/common/ssp_sensors/ssp_dev.c | 2 + drivers/iio/dac/ad5686.c | 2 +- drivers/iio/humidity/dht11.c | 69 + drivers/iio/humidity/si7020.c | 6 +- drivers/iio/imu/adis16400_core.c | 3 +- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 6 +- drivers/iio/light/Kconfig | 2 + drivers/iio/magnetometer/Kconfig | 2 + drivers/staging/comedi/drivers/adv_pci1710.c | 3 +- drivers/staging/comedi/drivers/comedi_isadma.c | 5 +- drivers/staging/comedi/drivers/vmk80xx.c | 71 - drivers/staging/iio/adc/mxs-lradc.c| 207 + drivers/staging/iio/resolver/ad2s1200.c| 3 +- 15 files changed, 175 insertions(+), 226 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] TTY/Serial fixes for 4.0-rc3
The following changes since commit 13a7a6ac0a11197edcd0f756a035f472b42cdf8b: Linux 4.0-rc2 (2015-03-03 09:04:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.0-rc3 for you to fetch changes up to c37bc682e30b8027054356214eb8a3aafbda8e37: TTY: fix tty_wait_until_sent maximum timeout (2015-03-07 03:44:15 +0100) TTY/Serial fixes for 4.0-rc3 Here are some tty and serial driver fixes for 4.0-rc3. Along with the atime fix that you know about, here are some other serial driver bugfixes as well. Most notable is a wait_until_sent bugfix that was traced back to being around since before 2.6.12 that Johan has fixed up. All have been in linux-next successfully. Signed-off-by: Greg Kroah-Hartman Axel Lin (1): serial: sprd: Fix missing spin_unlock in sprd_handle_irq() Baruch Siach (1): Revert "tty/serial: of_serial: add DT alias ID handling" Desmond Liu (1): serial: 8250_dw: Fix get_mctrl behaviour Jiri Slaby (1): tty: fix up atime/mtime mess, take four Johan Hovold (5): net: irda: fix wait_until_sent poll timeout TTY: bfin_jtag_comm: remove incorrect wait_until_sent operation USB: serial: fix infinite wait_until_sent timeout TTY: fix tty_wait_until_sent on 64-bit machines TTY: fix tty_wait_until_sent maximum timeout Peter Hurley (3): console: Fix console name size mismatch serial: core: Fix iotype userspace breakage serial: uapi: Declare all userspace-visible io types Russell King (1): Change email address for 8250_pci Sebastian Andrzej Siewior (1): serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO" Wang YanQing (2): serial:8250:8250_pci: fix redundant entry report for WCH_CH352_2S serial:8250:8250_pci: delete unneeded quirk entries .../bindings/serial/snps-dw-apb-uart.txt | 16 +++ drivers/tty/bfin_jtag_comm.c | 13 - drivers/tty/serial/8250/8250_core.c| 11 drivers/tty/serial/8250/8250_dw.c | 32 ++ drivers/tty/serial/8250/8250_pci.c | 20 +- drivers/tty/serial/of_serial.c | 4 --- drivers/tty/serial/sprd_serial.c | 4 ++- drivers/tty/tty_io.c | 4 +-- drivers/tty/tty_ioctl.c| 16 +++ drivers/usb/serial/generic.c | 5 ++-- include/linux/serial_core.h| 14 +- include/uapi/linux/serial.h| 4 +++ kernel/printk/console_cmdline.h| 2 +- kernel/printk/printk.c | 1 + net/irda/ircomm/ircomm_tty.c | 4 ++- 15 files changed, 89 insertions(+), 61 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] USB driver fixes for 4.0-rc3
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.0-rc3 for you to fetch changes up to b8cb91e058cd0c0f02059c1207293c5b31d350fa: xhci: Workaround for PME stuck issues in Intel xhci (2015-03-06 09:47:48 -0800) USB fixes for 4.0-rc3 Here's a round of USB fixes for 4.0-rc3. Nothing major, the usual gadget, xhci and usb-serial fixes and a few new device ids as well. All have been in linux-next successfully. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: usbfs: don't leak kernel data in siginfo Aleksander Morgado (1): xhci: fix reporting of 0-sized URBs in control endpoint Andrzej Pietrasiewicz (1): usb: gadget: configfs: don't NUL-terminate (sub)compatible ids Arnd Bergmann (1): usb: renesas: fix extcon dependency Björn Gerhart (1): cdc-acm: Add support for Denso cradle CU-321 Felipe Balbi (2): usb: gadget: function: phonet: balance usb_ep_disable calls usb: musb: core: add pm_runtime_irq_safe() George Cherian (2): usb: musb: musb_host: Enable HCD_BH flag to handle urb return in bottom half usb: dwc3: dwc3-omap: Fix disable IRQ Greg Kroah-Hartman (2): Merge tag 'fixes-for-v4.0-rc2' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'usb-serial-4.0-rc3' of git://git.kernel.org/.../johan/usb-serial into usb-linus Hans de Goede (1): uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539 Johan Hovold (8): Revert "USB: serial: make bulk_out_size a lower limit" USB: console: add dummy __module_get USB: serial: fix potential use-after-free after failed probe USB: serial: fix tty-device error handling at probe USB: serial: fix port attribute-creation race USB: serial: clean up bus probe error handling USB: mxuport: fix null deref when used as a console USB: pl2303: disable break on shutdown Lad, Prabhakar (6): usb: gadget: function: f_hid: fix sparse warning usb: gadget: function: f_uac2: fix sparse warnings usb: gadget: function: f_sourcesink: fix sparse warning usb: gadget: function: uvc: fix sparse warnings usb: gadget: gadgetfs: fix sparse warnings usb: gadget: function: uvc_v4l2.c: fix sparse warnings Mark Glover (1): USB: ftdi_sio: add PIDs for Actisense USB devices Mathias Nyman (3): xhci: Allocate correct amount of scratchpad buffers xhci: Clear the host side toggle manually when endpoint is 'soft reset' xhci: Workaround for PME stuck issues in Intel xhci Max Mansfield (1): usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards Maxime Ripard (1): usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks Michiel vd Garde (1): USB: serial: cp210x: Adding Seletek device id's Nicholas Mc Guire (1): usb: isp1760: use msecs_to_jiffies for time conversion Nicolas PLANEL (1): USB: ch341: set tty baud speed according to tty struct Oliver Neukum (1): usb-storage: support for more than 8 LUNs Tony Lindgren (2): usb: musb: Fix use for of_property_read_bool for disabled multipoint usb: musb: Fix getting a generic phy for musb_dsps drivers/usb/class/cdc-acm.c| 2 + drivers/usb/core/devio.c | 2 + drivers/usb/dwc3/dwc3-omap.c | 30 - drivers/usb/gadget/configfs.c | 2 - drivers/usb/gadget/function/f_hid.c| 2 +- drivers/usb/gadget/function/f_phonet.c | 5 +- drivers/usb/gadget/function/f_sourcesink.c | 4 +- drivers/usb/gadget/function/f_uac2.c | 34 +- drivers/usb/gadget/function/uvc_v4l2.c | 1 + drivers/usb/gadget/function/uvc_video.c| 1 + drivers/usb/gadget/legacy/g_ffs.c | 6 +- drivers/usb/host/xhci-pci.c| 30 + drivers/usb/host/xhci-plat.c | 19 +++--- drivers/usb/host/xhci-ring.c | 12 +++- drivers/usb/host/xhci.c| 100 ++--- drivers/usb/host/xhci.h| 11 +++- drivers/usb/isp1760/isp1760-hcd.c | 6 +- drivers/usb/musb/musb_core.c | 10 +-- drivers/usb/musb/musb_dsps.c | 32 - drivers/usb/musb/musb_host.c | 2 +- drivers/usb/musb/omap2430.c| 7 +- drivers/usb/renesas_usbhs/Kconfig | 1 + drivers/usb/serial/bus.c | 45 ++--- drivers/usb/serial/ch341.c | 15 ++--- drivers/usb/serial/console.c | 2 + drivers/usb/serial/cp210x.c| 2 + drivers/usb/serial/ftdi_sio.c | 19 ++
Re: [PATCH 1/4] staging: sm750fb: wrong type for print
On Sun, Mar 08, 2015 at 02:40:03PM +0200, Giedrius Statkevičius wrote:
> On 2015.03.08 14:31, Sudip Mukherjee wrote:
> > mention correct format specifier while printing
> > index 711676c..2ab7b74 100644
> > --- a/drivers/staging/sm750fb/sm750.h
> > +++ b/drivers/staging/sm750fb/sm750.h
> > @@ -59,10 +59,10 @@ struct lynx_share{
> > }mtrr;
> > #endif
> > /* all smi graphic adaptor got below attributes */
> > - resource_size_t vidmem_start;
> > - resource_size_t vidreg_start;
> > - resource_size_t vidmem_size;
> > - resource_size_t vidreg_size;
> > + unsigned long vidmem_start;
> > + unsigned long vidreg_start;
> > + unsigned long vidmem_size;
> > + unsigned long vidreg_size;
>
> Have you checked other places where these are used? resource_size_t can
> be either u64 or u32 depending on if CONFIG_PHYS_ADDR_T_64BIT is
> #defined. Are you sure you aren't losing information when results of
> functions are being assigned to this? Maybe there should be a function
> similar to printk that changes between %u and %llu depending on whether
> that is defined?
oops .. no .. :(
i checked in other framebuffer drivers and saw they are mostly unsigned long.
I will check further on this.
Greg: can you please drop this patch (1/4) from your queue and not apply this
to your tree.
I will send it as a v2.
regards
sudip
>
> --
> Thanks,
> Giedrius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] staging: sm750fb: correctly define SM750LE_REVISION_ID
On 2015.03.08 14:31, Sudip Mukherjee wrote:
> check if it is already defined before defining SM750LE_REVISION_ID
> again and at the same time mention correct data type.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/staging/sm750fb/ddk750_chip.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_chip.h
> b/drivers/staging/sm750fb/ddk750_chip.h
> index 1c78875..e7d27e8 100644
> --- a/drivers/staging/sm750fb/ddk750_chip.h
> +++ b/drivers/staging/sm750fb/ddk750_chip.h
> @@ -1,7 +1,9 @@
> #ifndef DDK750_CHIP_H__
> #define DDK750_CHIP_H__
> #define DEFAULT_INPUT_CLOCK 14318181 /* Default reference clock */
> -#define SM750LE_REVISION_ID (char)0xfe
> +#ifndef SM750LE_REVISION_ID
> +#define SM750LE_REVISION_ID ((unsigned char)0xfe)
> +#endif
Do you need these parantheses? Also, you can now then fix up this line
too to avoid a redundant cast in the same patch:
sm750_hw.c: if(share->revid == (unsigned char)SM750LE_REVISION_ID){
--
Thanks,
Giedrius
--
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 4/4] staging: sm750fb: fix undeclared function
On 2015.03.08 14:31, Sudip Mukherjee wrote: > kbuild test robot reported that for microblaze-allyesconfig > chan_to_field() and lynxfb_ops_set_par() were not defined. These two > functions were defined under CONFIG_PM, so for any archtecture if > CONFIG_PM is not defined we will have this error. > while moving the lynxfb_suspend() function some very obvious > checkpatch errors were taken care of. Such as? If you do you could also fix up the poor things with that function too such as the comment style here (no space between ; and the comment): > + if (info) > + fb_set_suspend(info, 1);/* 1 means do suspend*/ > + or here (extra unneeded spaces): > + > + /* set chip to sleep mode */ > + if (share->suspend) > + (*share->suspend)(share); -- Thanks, Giedrius -- 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/
dev_get_by_name example
Hello, How should we use dev_get_by_name ? What should be the 1st parameter should it be a pointer ? (without allocation required) ? struct net_device *dev_get_by_name(struct net *net, const char *name); I get an exception when using it for unallocated pointer in 1st argument, but succeeded with the following: ndev = dev_get_by_name(&init_net, "eth0"); Is it alloweed to use init_net ? Regards, Ran -- 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: arizona: match wait_for_completion_timeout return type
return type of wait_for_completion_timeout is unsigned long not int. An
appropriately named unsigned long is added and the assignment fixed up.
Signed-off-by: Nicholas Mc Guire
---
Note that the error message
"Timed out waiting for lock"
might not be that clear in a kernel log message as it
could probably be read as relating to a kernel lock
"Timed out waiting for FLL lock"
might be clearer.
This was only compile tested for exynos_defconfig + CONFIG_COMPILE_TEST=y
SND_SOC_ALL_CODECS=m, EXTCON_ARIZONA=m, CONFIG_MFD_ARIZONA_SPI=m,
CONFIG_MFD_WM5102=y, (implies SND_SOC_ARIZONA=m)
Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)
sound/soc/codecs/arizona.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 95d31d6..57da0ce 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -1902,7 +1902,7 @@ static int arizona_is_enabled_fll(struct arizona_fll *fll)
static int arizona_enable_fll(struct arizona_fll *fll)
{
struct arizona *arizona = fll->arizona;
- int ret;
+ unsigned long time_left;
bool use_sync = false;
int already_enabled = arizona_is_enabled_fll(fll);
struct arizona_fll_cfg cfg;
@@ -1978,9 +1978,9 @@ static int arizona_enable_fll(struct arizona_fll *fll)
regmap_update_bits_async(arizona->regmap, fll->base + 1,
ARIZONA_FLL1_FREERUN, 0);
- ret = wait_for_completion_timeout(&fll->ok,
+ time_left = wait_for_completion_timeout(&fll->ok,
msecs_to_jiffies(250));
- if (ret == 0)
+ if (time_left == 0)
arizona_fll_warn(fll, "Timed out waiting for lock\n");
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
On 8 March 2015 at 12:31, Jean Delvare wrote: > Hi Ivan, > > On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote: >> On 03/05/2015 09:46 AM, Jean Delvare wrote: >> > It's not just two tables (I don't expect a lot of BIOSes to provide two >> > tables in practice, and they would have essentially the same format >> > anyway) but more importantly two entry points. The _SM3_ entry point is >> > brand new and most applications (including dmidecode) don't support it >> > yet. It doesn't matter if the kernel itself can parse it, as it passes >> > the raw entry point to applications anyway. >> > >> > It happens that we are introducing this new sysfs raw interface at the >> > same time _SM3_ is being introduced, so we do not have to care about >> > backwards compatibility. Both the kernel and dmidecode will need to be >> > updated to support the new interface, so we can keep things simple and >> > let the kernel expose only the best entry point. >> > >> > If the sysfs raw interface was already present at the time _SM3_ >> > support was being added, then we would have had to present both entry >> > points for backwards compatibility. And if some _SM4_ entry point is >> > ever added in the future with a new format, we will have to export it >> > as a new sysfs attribute so as to not break compatibility. >> > >> > As a summary, I agree that a single entry point file is OK for now, but >> > only because we are lucky that the timing is right. >> >> Despite of timing is right. >> >> The specification doesn't oblige firmware to provide two entry points. >> An implementation may provide either the 32-bit entry point or the 64-bit >> entry point, or both. For compatibility with existing SMBIOS parsers, an >> implementation should provide the 32-bit entry point, but it's not required. > > I expect most implementations will do, as it's trivial to implement. > Not quite. First of all, some 64-bit ARM systems do not have any system RAM below 4 GB, so there is not way they can implement the 32-bit entry point. Also, the 64-bit entry point does not limit the structure size or the entire table to 64 KB like the 32-bit one does, so it may be necessary to create a whole separate table with a subset of the contents of the real table to stay within limits for the 32-bit entry point. And the 32-bit entry point could well be 3.0 anyway, if it uses any of the new enum values for the data items that were undefined before 3.0. More info here: http://sourceforge.net/p/edk2/mailman/message/33550425/ Regards, Ard. >> you can >> be sure in backward compatibility. But at least for now you can't. >> >> It's obvious, if kernel found two entry points then it can create two >> sysfs attributes. >> But, what kernel should do in case if only one new entry point is present. >> Generate entry point of old version..., sorry but it's bad idea. At >> least because >> where guarantee that we have enough information for this. Only field we >> can bring >> thought entry point versions is magic string _SM*_, and based on it, if util >> don't support new version it can warn. It's used for differ versions and >> there is nothing we can do more. > > I agree that the kernel should not fake an entry point which does not > exist (I'm not sure if you misunderstood me but I never suggested that.) > > -- > Jean Delvare > SUSE L3 Support -- 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 3/7] x86, kaslr: Add two functions which will be used later
Hello, May be necessary to add comments that they will be used later, to prevent patches like 'removed unused..' 2015-03-08 11:38 GMT+06:00 Baoquan He : > > Add two functions mem_min_overlap() and store_slot_info() which will be > used later. -- 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/1] x86/fpu: math_state_restore() should not blindly disable irqs
On Mar 8, 2015 4:55 AM, "Ingo Molnar" wrote: > > > * Linus Torvalds wrote: > > > On Sat, Mar 7, 2015 at 2:36 AM, Ingo Molnar wrote: > > > > > > We could save the same 10 cycles from page fault overhead as well, > > > AFAICS. > > > > Are trap gates actually noticeably faster? Or is it just he > > "conditional_sti()" you're worried about? > > ( I'll talk about the CR2 complication later, please ignore that > problem for a moment. ) > > So I base my thinking on the following hierarchy of fast paths. In a > typical x86 system there are 4 main types of 'context switches', in > order of decreasing frequency: > >- syscall'context switch': entry/exit from syscall >- trap/fault 'context switch': entry/exit from trap/fault >- irq'context switch': entry/exit from irqs >- task 'context switch': scheduler context-switch > > Where each successive level is about an order of magnitude less > frequently executed on a typical system than the previous one, so to > optimize a level we are willing to push overhead to the next one(s). > > So the primary payoff in executing much of the entry code with irqs > enabled would be to allow 64-bit *syscalls* to be made without irqs > disabled: the first, most important level of context entries. > > Doing that would give us four (theoretical) performance advantages: > > - No implicit irq disabling overhead when the syscall instruction is > executed: we could change MSR_SYSCALL_MASK from 0xc084 to > 0xc284, which removes the implicit CLI on syscall entry. > > - No explicit irq enabling overhead via ENABLE_INTERRUPTS() [STI] in > system_call. > > - No explicit irq disabling overhead in the ret_from_sys_call fast > path, i.e. no DISABLE_INTERRUPTS() [CLI]. > > - No implicit irq enabling overhead in ret_from_sys_call's > USERGS_SYSRET64: the SYSRETQ instruction would not have to > re-enable irqs as the user-space IF in R11 would match that of the > current IF. > > whether that's an actual performance win in practice as well needs to > be measured, but I'd be (very!) shocked if it wasn't in the 20+ cycles > range: which is absolutely huge in terms of system_call optimizations. > > Now do I think this could be done realistically? I think yes (by > re-using the NMI code's paranoid entry codepaths for the irq code as > well, essentially fixing up the effects of any partial entries in an > irq entry slow path), but I could be wrong about that. > > My main worry isn't even feasibility but maintainability and general > robustness: all these asm cleanups we are doing now could enable such > a trick to be pulled off robustly. > > But I think it could be done technically, because the NMI code already > has to be careful about 'preempting' partial entries, so we have the > logic. > > Complications: > > - We now enable double partial entries: partial syscall interrupted >by an irq interrupted by an NMI context. I think it should all work >out fine but it's a new scenario. > > - We'd enable interruptible return from system call, which caused >trouble in the past. Solvable IMHO, by being careful in the irq >entry code. > > - We'd now have to be extra careful about the possibility of >exceptions triggered in the entry/exit code itself, triggered by >any sort of unusual register content or MMU fault. > > Simplifications: > > - I'd ruthlessly disable IRQs for any sort of non fast path: for >example 32-bit compat entries, ptrace or any other slowpath - at >least initially until we map out the long term effects of this >optimization. > > Does this scare me? Yes, I think it should scare any sane person, but > I don't think it's all that bad: all the NMI paranoidentry work has > already the trail blazed, and most of the races will be readily > triggerable via regular irq loads, so it's not like we'll leave subtle > bugs in there. > > Being able to do the same with certain traps, because irq entry is > careful about partial entry state, would just be a secondary bonus. > > Regarding the CR2 value on page faults: > > > Anyway, for page faulting, we traditionally actually wanted an > > interrupt gate, because of how we wanted to avoid interrupts coming > > in and possibly messing up %cr2 due to vmalloc faults, but more > > importantly for preemption. [...] > > Here too I think we could take a page from the NMI code: save cr2 in > the page fault asm code, recognize from the irq code when we are > interrupting that and dropping into a slowpath that saves cr2 right > there. Potentially task-context-switching will be safe after that. > > Saving cr2 in the early page fault code should be much less of an > overhead than what the IRQ disabling/enabling costs, so this should be > a win. The potential win could be similar to that of system calls: > > - Removal of an implicit 'CLI' in irq gates > > - Removal of the explicit 'STI' in conditional_sti in your proposed > code > > - Removal of an e
Re: [PATCH 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips
On Mar 7, 2015 6:39 AM, "Guenter Roeck" wrote: > > On 03/06/2015 06:50 PM, Andy Lutomirski wrote: >> >> Sandy Bridge Xeon and Extreme chips have integrated memory >> controllers with (rather limited) onboard SMBUS masters. This >> driver gives access to the bus. >> >> There are various groups working on standardizing a way to arbitrate >> access to the bus between the OS, SMM firmware, a BMC, hardware >> thermal control, etc. In the mean time, running this driver is >> unsafe except under special circumstances. Nonetheless, this driver >> has real users. >> >> As a compromise, the driver will refuse to load unless >> i2c_imc.allow_unsafe_access=Y. When safe access becomes available, >> we can leave this option as a way for legacy users to run the >> driver, and we'll allow the driver to load by default if safe bus >> access is available. >> >> Signed-off-by: Andy Lutomirski >> --- > > > Please consider running your patch through checkpatch --strict, or at least > checkpatch. > [ I won't comment on the checkpatch problems below ] > > >> drivers/i2c/busses/Kconfig | 18 ++ >> drivers/i2c/busses/Makefile | 1 + >> drivers/i2c/busses/i2c-imc.c | 583 >> +++ >> 3 files changed, 602 insertions(+) >> create mode 100644 drivers/i2c/busses/i2c-imc.c >> >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index ab838d9e28b6..d6b9ce164fbf 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> @@ -149,6 +149,24 @@ config I2C_ISMT >> This driver can also be built as a module. If so, the module will >> be >> called i2c-ismt. >> >> +config I2C_IMC >> + tristate "Intel iMC (LGA 2011) SMBus Controller" >> + depends on PCI && X86 >> + select I2C_DIMM_BUS >> + help >> + If you say yes to this option, support will be included for the >> Intel >> + Integrated Memory Controller SMBus host controller interface. This >> + controller is found on LGA 2011 Xeons and Core i7 Extremes. >> + >> + There are currently no systems on which the kernel knows that it >> can >> + safely enable this driver. For now, you need to pass this driver a >> + scary module parameter, and you should only pass that parameter if >> you >> + have a special motherboard and know exactly what you are doing. >> + Special motherboards include the Supermicro X9DRH-iF-NV. >> + >> + This driver can also be built as a module. If so, the module will >> be >> + called i2c-imc. >> + >> config I2C_PIIX4 >> tristate "Intel PIIX4 and compatible >> (ATI/AMD/Serverworks/Broadcom/SMSC)" >> depends on PCI >> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile >> index 56388f658d2f..4287c891e782 100644 >> --- a/drivers/i2c/busses/Makefile >> +++ b/drivers/i2c/busses/Makefile >> @@ -15,6 +15,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o >> obj-$(CONFIG_I2C_I801)+= i2c-i801.o >> obj-$(CONFIG_I2C_ISCH)+= i2c-isch.o >> obj-$(CONFIG_I2C_ISMT)+= i2c-ismt.o >> +obj-$(CONFIG_I2C_IMC) += i2c-imc.o >> obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o >> obj-$(CONFIG_I2C_NFORCE2_S4985) += i2c-nforce2-s4985.o >> obj-$(CONFIG_I2C_PIIX4) += i2c-piix4.o >> diff --git a/drivers/i2c/busses/i2c-imc.c b/drivers/i2c/busses/i2c-imc.c >> new file mode 100644 >> index ..2dbf171114c6 >> --- /dev/null >> +++ b/drivers/i2c/busses/i2c-imc.c >> @@ -0,0 +1,583 @@ >> +/* >> + * Copyright (c) 2013 Andrew Lutomirski >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 >> + * as published by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. >> + */ >> + >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* >> + * The datasheet can be found here, for example: >> + * >> http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-1600-2600-vol-2-datasheet.pdf >> + * >> + * There seem to be quite a few bugs or spec errors, though: >> + * >> + * - A successful transaction sets WOD and RDO. >> + * >> + * - The docs for TSOD_POLL_EN make no sense (see imc_channel_claim). >> + * >> + * - Erratum BT109, which says: >> + * >> + * The processor may not complete SMBus (System Managemen
Re: dev_get_by_name example
On Sun, Mar 8, 2015 at 2:04 PM, Ran Shalit wrote: > Hello, > > How should we use dev_get_by_name ? > What should be the 1st parameter should it be a pointer ? (without > allocation required) ? The network namespace you want to use. > struct net_device *dev_get_by_name(struct net *net, const char *name); > I get an exception when using it for unallocated pointer in 1st > argument, but succeeded with the following: > ndev = dev_get_by_name(&init_net, "eth0"); > Is it alloweed to use init_net ? Only if you want to do a lookup in the initial network namespace. If you're in process context you better use the current network namespace. But I don't know your use case. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c, i2c_imc: Add DIMM bus code
On Sat, Mar 7, 2015 at 8:03 AM, Guenter Roeck wrote:
> On 03/06/2015 06:50 PM, Andy Lutomirski wrote:
>>
>> Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
>> contains DIMMs. This will probe (and autoload modules!) for useful
>> SMBUS devices that live on DIMMs. i2c_imc calls it.
>>
>> As more SMBUS-addressable DIMM components become supported, this
>> code can be extended to probe for them.
>>
>> Signed-off-by: Andy Lutomirski
>
>
> Similar to the other patch, I would suggest to run it through checkpatch.
>
Done for both patches.
>
>> ---
>> drivers/i2c/busses/Kconfig| 4 ++
>> drivers/i2c/busses/Makefile | 4 ++
>> drivers/i2c/busses/dimm-bus.c | 97
>> +++
>> drivers/i2c/busses/i2c-imc.c | 3 ++
>> include/linux/i2c/dimm-bus.h | 24 +++
>> 5 files changed, 132 insertions(+)
>> create mode 100644 drivers/i2c/busses/dimm-bus.c
>> create mode 100644 include/linux/i2c/dimm-bus.h
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index d6b9ce164fbf..2ea6648492eb 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -149,6 +149,10 @@ config I2C_ISMT
>> This driver can also be built as a module. If so, the module
>> will be
>> called i2c-ismt.
>>
>> +config I2C_DIMM_BUS
>> + tristate
>> + default n
>> +
>> config I2C_IMC
>> tristate "Intel iMC (LGA 2011) SMBus Controller"
>> depends on PCI && X86
>> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
>> index 4287c891e782..a01bdcc0e239 100644
>> --- a/drivers/i2c/busses/Makefile
>> +++ b/drivers/i2c/busses/Makefile
>> @@ -25,6 +25,10 @@ obj-$(CONFIG_I2C_SIS96X) += i2c-sis96x.o
>> obj-$(CONFIG_I2C_VIA) += i2c-via.o
>> obj-$(CONFIG_I2C_VIAPRO) += i2c-viapro.o
>>
>> +# DIMM busses
>> +obj-$(CONFIG_I2C_DIMM_BUS) += dimm-bus.o
>> +obj-$(CONFIG_I2C_IMC) += i2c-imc.o
>> +
>> # Mac SMBus host controller drivers
>> obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
>> obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
>> diff --git a/drivers/i2c/busses/dimm-bus.c b/drivers/i2c/busses/dimm-bus.c
>> new file mode 100644
>> index ..096842811199
>> --- /dev/null
>> +++ b/drivers/i2c/busses/dimm-bus.c
>> @@ -0,0 +1,97 @@
>> +/*
>> + * Copyright (c) 2013 Andrew Lutomirski
>
>
> 2013 ?
>
Fixed. It's been a long time since I wrote most of this code...
>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2
>> + * as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static bool probe_addr(struct i2c_adapter *adapter, int addr)
>> +{
>> + /*
>> +* So far, all known devices that live on DIMMs can be safely
>> +* and reliably detected by trying to read a byte at address
>> +* zero. (The exception is the SPD write protection control,
>> +* which can't be probed and requires special hardware and/or
>> +* quick writes to access, and has no driver.)
>> +*/
>
>
> That leads to the question if the controller supports quick commands,
> and if it does, if would make sense to add support for it,
> just for the purpose of reducing risk here.
I don't think it supports them, and even if it did, I don't know how
to test them since I don't have an obvious i2c slave device to poke at
with them. I have a friend with logic analyzers, though...
>
>
>> + union i2c_smbus_data dummy;
>> + return i2c_smbus_xfer(adapter, addr, 0, I2C_SMBUS_READ, 0,
>> + I2C_SMBUS_BYTE_DATA, &dummy) >= 0;
>> +}
>> +
>> +/**
>> + * i2c_scan_dimm_bus() - Scans an SMBUS segment known to contain DIMMs
>> + * @adapter: The SMBUS adapter to scan
>> + *
>> + * This function tells the DIMM-bus code that the adapter is known to
>> + * contain DIMMs. i2c_scan_dimm_bus will probe for devices known to
>> + * live on DIMMs.
>> + *
>> + * Do NOT call this function on general-purpose system SMBUS segments
>> + * unless you know that the only things on the bus are DIMMs.
>> + * Otherwise is it very likely to mis-identify other things on the
>> + * bus.
>> + *
>> + * Callers are advised not to set adapter->class = I2C_CLASS_SPD.
>
>
> Why not ?
>
It could make the legacy eeprom driver try to bind to the bus if it's
loaded. I improv
[PATCH 1/2] serial: 8250: allow specifying iomem size in addition to address
This adds a mapsize field to struct uart_port to be used in
conjunction with mapbase. If set, it overrides whatever value
serial8250_port_size() would otherwise report.
Signed-off-by: Mans Rullgard
---
drivers/tty/serial/8250/8250_core.c | 4
include/linux/serial_core.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 58a9283..60bf876 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2722,6 +2722,8 @@ serial8250_pm(struct uart_port *port, unsigned int state,
static unsigned int serial8250_port_size(struct uart_8250_port *pt)
{
+ if (pt->port.mapsize)
+ return pt->port.mapsize;
if (pt->port.iotype == UPIO_AU) {
if (pt->port.type == PORT_RT2880)
return 0x100;
@@ -3415,6 +3417,7 @@ int __init early_serial_setup(struct uart_port *port)
p->iotype = port->iotype;
p->flags= port->flags;
p->mapbase = port->mapbase;
+ p->mapsize = port->mapsize;
p->private_data = port->private_data;
p->type = port->type;
p->line = port->line;
@@ -3669,6 +3672,7 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
uart->port.flags= up->port.flags | UPF_BOOT_AUTOCONF;
uart->bugs = up->bugs;
uart->port.mapbase = up->port.mapbase;
+ uart->port.mapsize = up->port.mapsize;
uart->port.private_data = up->port.private_data;
uart->port.fifosize = up->port.fifosize;
uart->tx_loadsz = up->tx_loadsz;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index baf3e1d..74a2647 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -236,6 +236,7 @@ struct uart_port {
unsigned intcustom_divisor;
unsigned intline; /* port index */
resource_size_t mapbase;/* for ioremap */
+ resource_size_t mapsize;
struct device *dev; /* parent device */
unsigned char hub6; /* this should be in
the 8250 driver */
unsigned char suspended;
--
2.3.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 2/2] serial: of: set port iomem size from devicetree
Make the 8250 driver reserve exactly the mmio region specified in the devicetree. This prevents conflicts between UPIO_AU type UARTs and other devices mapped closer than the default size of 0x1000 (or 0x100 for RT2880). Signed-off-by: Mans Rullgard --- drivers/tty/serial/of_serial.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c index 7ff61e2..b1d4744 100644 --- a/drivers/tty/serial/of_serial.c +++ b/drivers/tty/serial/of_serial.c @@ -89,6 +89,7 @@ static int of_platform_serial_setup(struct platform_device *ofdev, spin_lock_init(&port->lock); port->mapbase = resource.start; + port->mapsize = resource_size(&resource); /* Check for shifted address mapping */ if (of_property_read_u32(np, "reg-offset", &prop) == 0) -- 2.3.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/1] x86/fpu: math_state_restore() should not blindly disable irqs
On Sun, Mar 8, 2015 at 6:59 AM, Andy Lutomirski wrote: > There's another problem, though: We don't have a real stack pointer > just after syscall and just before sysexit, and therefore we *must* > use IST for anything that can happen while we still have > user-controlled rsp. That includes #DB, #NM, and #MC. I think I faked myself out here. Why do #DB and #BP use IST? We could remove a decent (large?) amount of crud if we changed that. --Andy -- 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] drivers/base: use tabs where possible in code indentation
Found problem checkpatch.pl
Signed-off-by: Lavinia Tache
---
drivers/base/soc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 72b5e72..39fca01 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -43,8 +43,8 @@ struct device *soc_device_to_device(struct soc_device
*soc_dev)
}
static umode_t soc_attribute_mode(struct kobject *kobj,
- struct attribute *attr,
- int index)
+ struct attribute *attr,
+ int index)
{
struct device *dev = container_of(kobj, struct device, kobj);
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
@@ -60,7 +60,7 @@ static umode_t soc_attribute_mode(struct kobject *kobj,
return attr->mode;
if ((attr == &dev_attr_soc_id.attr)
&& (soc_dev->attr->soc_id != NULL))
- return attr->mode;
+ return attr->mode;
/* Unknown or unfilled attribute. */
return 0;
@@ -117,7 +117,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
soc_dev = kzalloc(sizeof(*soc_dev), GFP_KERNEL);
if (!soc_dev) {
- ret = -ENOMEM;
+ ret = -ENOMEM;
goto out1;
}
@@ -135,7 +135,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
} while (ret == -EAGAIN);
if (ret)
-goto out2;
+ goto out2;
soc_dev->attr = soc_dev_attr;
soc_dev->dev.bus = &soc_bus_type;
--
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 v4 00/17] media: blackfin: bfin_capture enhancements
From: "Lad, Prabhakar" This patch series, enhances blackfin capture driver with vb2 helpers. Changes for v4: 1: Improved commit message for path 4/17 and 5/17. 2: Added Ack's from Scott to patches 1-15 3: Two new patches 16/17 and 17/17 Lad, Prabhakar (17): media: blackfin: bfin_capture: drop buf_init() callback media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails media: blackfin: bfin_capture: set min_buffers_needed media: blackfin: bfin_capture: set vb2 buffer field media: blackfin: bfin_capture: improve queue_setup() callback media: blackfin: bfin_capture: use vb2_fop_mmap/poll media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release media: blackfin: bfin_capture: use vb2_ioctl_* helpers media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback media: blackfin: bfin_capture: return -ENODATA for *std calls media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls media: blackfin: bfin_capture: add support for vidioc_create_bufs media: blackfin: bfin_capture: add support for VB2_DMABUF media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF media: blackfin: bfin_capture: set v4l2 buffer sequence media: blackfin: bfin_capture: drop bcap_get_unmapped_area() media: blackfin: bfin_capture: embed video_device struct in bcap_device drivers/media/platform/blackfin/bfin_capture.c | 348 - 1 file changed, 103 insertions(+), 245 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 13/17] media: blackfin: bfin_capture: add support for VB2_DMABUF
From: "Lad, Prabhakar" this patch adds support for VB2_DMABUF. Signed-off-by: Lad, Prabhakar Acked-by: Scott Jiang Tested-by: Scott Jiang --- drivers/media/platform/blackfin/bfin_capture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/blackfin/bfin_capture.c b/drivers/media/platform/blackfin/bfin_capture.c index ec8227f..6c58cea 100644 --- a/drivers/media/platform/blackfin/bfin_capture.c +++ b/drivers/media/platform/blackfin/bfin_capture.c @@ -856,7 +856,7 @@ static int bcap_probe(struct platform_device *pdev) /* initialize queue */ q = &bcap_dev->buffer_queue; q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; - q->io_modes = VB2_MMAP; + q->io_modes = VB2_MMAP | VB2_DMABUF; q->drv_priv = bcap_dev; q->buf_struct_size = sizeof(struct bcap_buffer); q->ops = &bcap_video_qops; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 17/17] media: blackfin: bfin_capture: embed video_device struct in bcap_device
From: "Lad, Prabhakar"
Embed video_device struct (video_dev) in bcap_device and
Unregister path doesn't need to free the video_device
structure, hence, change the video_device.release callback
point to video_device_release_empty.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/blackfin/bfin_capture.c | 27 --
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index d390f7c..6a437f8 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -64,7 +64,7 @@ struct bcap_device {
/* v4l2 control handler */
struct v4l2_ctrl_handler ctrl_handler;
/* device node data */
- struct video_device *video_dev;
+ struct video_device video_dev;
/* sub device instance */
struct v4l2_subdev *sd;
/* capture config */
@@ -809,27 +809,20 @@ static int bcap_probe(struct platform_device *pdev)
goto err_free_ppi;
}
- vfd = video_device_alloc();
- if (!vfd) {
- ret = -ENOMEM;
- v4l2_err(pdev->dev.driver, "Unable to alloc video device\n");
- goto err_cleanup_ctx;
- }
-
+ vfd = &bcap_dev->video_dev;
/* initialize field of video device */
- vfd->release= video_device_release;
+ vfd->release= video_device_release_empty;
vfd->fops = &bcap_fops;
vfd->ioctl_ops = &bcap_ioctl_ops;
vfd->tvnorms= 0;
vfd->v4l2_dev = &bcap_dev->v4l2_dev;
strncpy(vfd->name, CAPTURE_DRV_NAME, sizeof(vfd->name));
- bcap_dev->video_dev = vfd;
ret = v4l2_device_register(&pdev->dev, &bcap_dev->v4l2_dev);
if (ret) {
v4l2_err(pdev->dev.driver,
"Unable to register v4l2 device\n");
- goto err_release_vdev;
+ goto err_cleanup_ctx;
}
v4l2_info(&bcap_dev->v4l2_dev, "v4l2 device registered\n");
@@ -868,13 +861,13 @@ static int bcap_probe(struct platform_device *pdev)
vfd->queue = q;
/* register video device */
- ret = video_register_device(bcap_dev->video_dev, VFL_TYPE_GRABBER, -1);
+ ret = video_register_device(&bcap_dev->video_dev, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(&bcap_dev->v4l2_dev,
"Unable to register video device\n");
goto err_free_handler;
}
- video_set_drvdata(bcap_dev->video_dev, bcap_dev);
+ video_set_drvdata(&bcap_dev->video_dev, bcap_dev);
v4l2_info(&bcap_dev->v4l2_dev, "video device registered as: %s\n",
video_device_node_name(vfd));
@@ -952,15 +945,11 @@ static int bcap_probe(struct platform_device *pdev)
}
return 0;
err_unreg_vdev:
- video_unregister_device(bcap_dev->video_dev);
- bcap_dev->video_dev = NULL;
+ video_unregister_device(&bcap_dev->video_dev);
err_free_handler:
v4l2_ctrl_handler_free(&bcap_dev->ctrl_handler);
err_unreg_v4l2:
v4l2_device_unregister(&bcap_dev->v4l2_dev);
-err_release_vdev:
- if (bcap_dev->video_dev)
- video_device_release(bcap_dev->video_dev);
err_cleanup_ctx:
vb2_dma_contig_cleanup_ctx(bcap_dev->alloc_ctx);
err_free_ppi:
@@ -977,7 +966,7 @@ static int bcap_remove(struct platform_device *pdev)
struct bcap_device, v4l2_dev);
bcap_free_sensor_formats(bcap_dev);
- video_unregister_device(bcap_dev->video_dev);
+ video_unregister_device(&bcap_dev->video_dev);
v4l2_ctrl_handler_free(&bcap_dev->ctrl_handler);
v4l2_device_unregister(v4l2_dev);
vb2_dma_contig_cleanup_ctx(bcap_dev->alloc_ctx);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 15/17] media: blackfin: bfin_capture: set v4l2 buffer sequence
From: "Lad, Prabhakar"
this patch adds support to set the v4l2 buffer sequence.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index c3ede0d..306798e 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -103,6 +103,8 @@ struct bcap_device {
struct completion comp;
/* prepare to stop */
bool stop;
+ /* vb2 buffer sequence counter */
+ unsigned sequence;
};
static const struct bcap_format bcap_formats[] = {
@@ -333,6 +335,8 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
goto err;
}
+ bcap_dev->sequence = 0;
+
reinit_completion(&bcap_dev->comp);
bcap_dev->stop = false;
@@ -411,6 +415,7 @@ static irqreturn_t bcap_isr(int irq, void *dev_id)
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
ppi->err = false;
} else {
+ vb->v4l2_buf.sequence = bcap_dev->sequence++;
vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
bcap_dev->cur_frm = list_entry(bcap_dev->dma_queue.next,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 16/17] media: blackfin: bfin_capture: drop bcap_get_unmapped_area()
From: "Lad, Prabhakar"
this patch drops bcap_get_unmapped_area() and uses
vb2_fop_get_unmapped_area() helper provided by the vb2 core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/blackfin/bfin_capture.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 306798e..d390f7c 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -196,23 +196,6 @@ static void bcap_free_sensor_formats(struct bcap_device
*bcap_dev)
bcap_dev->sensor_formats = NULL;
}
-#ifndef CONFIG_MMU
-static unsigned long bcap_get_unmapped_area(struct file *file,
- unsigned long addr,
- unsigned long len,
- unsigned long pgoff,
- unsigned long flags)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
-
- return vb2_get_unmapped_area(&bcap_dev->buffer_queue,
-addr,
-len,
-pgoff,
-flags);
-}
-#endif
-
static int bcap_queue_setup(struct vb2_queue *vq,
const struct v4l2_format *fmt,
unsigned int *nbuffers, unsigned int *nplanes,
@@ -783,7 +766,7 @@ static struct v4l2_file_operations bcap_fops = {
.unlocked_ioctl = video_ioctl2,
.mmap = vb2_fop_mmap,
#ifndef CONFIG_MMU
- .get_unmapped_area = bcap_get_unmapped_area,
+ .get_unmapped_area = vb2_fop_get_unmapped_area,
#endif
.poll = vb2_fop_poll
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 12/17] media: blackfin: bfin_capture: add support for vidioc_create_bufs
From: "Lad, Prabhakar"
this patch adds support for vidioc_create_bufs.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 2dead84..ec8227f 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -759,6 +759,7 @@ static const struct v4l2_ioctl_ops bcap_ioctl_ops = {
.vidioc_query_dv_timings = bcap_query_dv_timings,
.vidioc_enum_dv_timings = bcap_enum_dv_timings,
.vidioc_reqbufs = vb2_ioctl_reqbufs,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf= vb2_ioctl_dqbuf,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/17] media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release
From: "Lad, Prabhakar"
this patch adds support to use v4l2_fh_open() and vb2_fop_release,
which allows to drop driver specific struct bcap_fh, as this is handled
by core.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 79 +-
1 file changed, 2 insertions(+), 77 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 84827d2..01e778d 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -105,12 +105,6 @@ struct bcap_device {
bool stop;
};
-struct bcap_fh {
- struct v4l2_fh fh;
- /* indicates whether this file handle is doing IO */
- bool io_allowed;
-};
-
static const struct bcap_format bcap_formats[] = {
{
.desc= "YCbCr 4:2:2 Interleaved UYVY",
@@ -200,50 +194,6 @@ static void bcap_free_sensor_formats(struct bcap_device
*bcap_dev)
bcap_dev->sensor_formats = NULL;
}
-static int bcap_open(struct file *file)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
- struct video_device *vfd = bcap_dev->video_dev;
- struct bcap_fh *bcap_fh;
-
- if (!bcap_dev->sd) {
- v4l2_err(&bcap_dev->v4l2_dev, "No sub device registered\n");
- return -ENODEV;
- }
-
- bcap_fh = kzalloc(sizeof(*bcap_fh), GFP_KERNEL);
- if (!bcap_fh) {
- v4l2_err(&bcap_dev->v4l2_dev,
-"unable to allocate memory for file handle object\n");
- return -ENOMEM;
- }
-
- v4l2_fh_init(&bcap_fh->fh, vfd);
-
- /* store pointer to v4l2_fh in private_data member of file */
- file->private_data = &bcap_fh->fh;
- v4l2_fh_add(&bcap_fh->fh);
- bcap_fh->io_allowed = false;
- return 0;
-}
-
-static int bcap_release(struct file *file)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
- struct v4l2_fh *fh = file->private_data;
- struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
-
- /* if this instance is doing IO */
- if (bcap_fh->io_allowed)
- vb2_queue_release(&bcap_dev->buffer_queue);
-
- file->private_data = NULL;
- v4l2_fh_del(&bcap_fh->fh);
- v4l2_fh_exit(&bcap_fh->fh);
- kfree(bcap_fh);
- return 0;
-}
-
#ifndef CONFIG_MMU
static unsigned long bcap_get_unmapped_area(struct file *file,
unsigned long addr,
@@ -436,13 +386,6 @@ static int bcap_reqbufs(struct file *file, void *priv,
{
struct bcap_device *bcap_dev = video_drvdata(file);
struct vb2_queue *vq = &bcap_dev->buffer_queue;
- struct v4l2_fh *fh = file->private_data;
- struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
-
- if (vb2_is_busy(vq))
- return -EBUSY;
-
- bcap_fh->io_allowed = true;
return vb2_reqbufs(vq, req_buf);
}
@@ -459,11 +402,6 @@ static int bcap_qbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
{
struct bcap_device *bcap_dev = video_drvdata(file);
- struct v4l2_fh *fh = file->private_data;
- struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
-
- if (!bcap_fh->io_allowed)
- return -EBUSY;
return vb2_qbuf(&bcap_dev->buffer_queue, buf);
}
@@ -472,11 +410,6 @@ static int bcap_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
{
struct bcap_device *bcap_dev = video_drvdata(file);
- struct v4l2_fh *fh = file->private_data;
- struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
-
- if (!bcap_fh->io_allowed)
- return -EBUSY;
return vb2_dqbuf(&bcap_dev->buffer_queue,
buf, file->f_flags & O_NONBLOCK);
@@ -527,14 +460,10 @@ static int bcap_streamon(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct bcap_device *bcap_dev = video_drvdata(file);
- struct bcap_fh *fh = file->private_data;
struct ppi_if *ppi = bcap_dev->ppi;
dma_addr_t addr;
int ret;
- if (!fh->io_allowed)
- return -EBUSY;
-
/* call streamon to start streaming in videobuf */
ret = vb2_streamon(&bcap_dev->buffer_queue, buf_type);
if (ret)
@@ -568,10 +497,6 @@ static int bcap_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct bcap_device *bcap_dev = video_drvdata(file);
- struct bcap_fh *fh = file->private_data;
-
- if (!fh->io_allowed)
- return -EBUSY;
return vb2_streamoff(&bcap_dev->buffer_queue, buf_type);
}
@@ -874,8 +799,8 @@ static const struct v4l2_ioctl_ops bcap_ioctl_ops = {
[PATCH v4 14/17] media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF
From: "Lad, Prabhakar"
this patch adds support for VIDIOC_EXPBUF.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 6c58cea..c3ede0d 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -763,6 +763,7 @@ static const struct v4l2_ioctl_ops bcap_ioctl_ops = {
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf= vb2_ioctl_dqbuf,
+ .vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon = vb2_ioctl_streamon,
.vidioc_streamoff= vb2_ioctl_streamoff,
.vidioc_g_parm = bcap_g_parm,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/base: use tabs where possible in code indentation
Found problem checkpatch.pl
Signed-off-by: Lavinia Tache
---
drivers/base/soc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 72b5e72..39fca01 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -43,8 +43,8 @@ struct device *soc_device_to_device(struct soc_device
*soc_dev)
}
static umode_t soc_attribute_mode(struct kobject *kobj,
- struct attribute *attr,
- int index)
+ struct attribute *attr,
+ int index)
{
struct device *dev = container_of(kobj, struct device, kobj);
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
@@ -60,7 +60,7 @@ static umode_t soc_attribute_mode(struct kobject *kobj,
return attr->mode;
if ((attr == &dev_attr_soc_id.attr)
&& (soc_dev->attr->soc_id != NULL))
- return attr->mode;
+ return attr->mode;
/* Unknown or unfilled attribute. */
return 0;
@@ -117,7 +117,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
soc_dev = kzalloc(sizeof(*soc_dev), GFP_KERNEL);
if (!soc_dev) {
- ret = -ENOMEM;
+ ret = -ENOMEM;
goto out1;
}
@@ -135,7 +135,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
} while (ret == -EAGAIN);
if (ret)
-goto out2;
+ goto out2;
soc_dev->attr = soc_dev_attr;
soc_dev->dev.bus = &soc_bus_type;
--
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 v4 10/17] media: blackfin: bfin_capture: return -ENODATA for *std calls
From: "Lad, Prabhakar"
this patch adds supports to return -ENODATA to *_std calls
if the selected output does not support it.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index f2b1a23..f97d94d 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -440,6 +440,11 @@ static irqreturn_t bcap_isr(int irq, void *dev_id)
static int bcap_querystd(struct file *file, void *priv, v4l2_std_id *std)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
+
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_STD))
+ return -ENODATA;
return v4l2_subdev_call(bcap_dev->sd, video, querystd, std);
}
@@ -447,6 +452,11 @@ static int bcap_querystd(struct file *file, void *priv,
v4l2_std_id *std)
static int bcap_g_std(struct file *file, void *priv, v4l2_std_id *std)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
+
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_STD))
+ return -ENODATA;
*std = bcap_dev->std;
return 0;
@@ -455,8 +465,13 @@ static int bcap_g_std(struct file *file, void *priv,
v4l2_std_id *std)
static int bcap_s_std(struct file *file, void *priv, v4l2_std_id std)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
int ret;
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_STD))
+ return -ENODATA;
+
if (vb2_is_busy(&bcap_dev->buffer_queue))
return -EBUSY;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 03/17] media: blackfin: bfin_capture: set min_buffers_needed
From: "Lad, Prabhakar" this patch sets the min_buffers_needed field of the vb2 queue so that the vb2 core will make sure start_streaming() callback is called only when we have minimum buffers queued. Signed-off-by: Lad, Prabhakar Acked-by: Scott Jiang Tested-by: Scott Jiang --- drivers/media/platform/blackfin/bfin_capture.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/blackfin/bfin_capture.c b/drivers/media/platform/blackfin/bfin_capture.c index 2c720bc..332f8c9 100644 --- a/drivers/media/platform/blackfin/bfin_capture.c +++ b/drivers/media/platform/blackfin/bfin_capture.c @@ -986,6 +986,7 @@ static int bcap_probe(struct platform_device *pdev) q->mem_ops = &vb2_dma_contig_memops; q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; q->lock = &bcap_dev->mutex; + q->min_buffers_needed = 1; ret = vb2_queue_init(q); if (ret) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 11/17] media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls
From: "Lad, Prabhakar"
this patch adds support to return -ENODATA for *dv_timings calls
if the current output does not support it.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index f97d94d..2dead84 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -487,6 +487,11 @@ static int bcap_enum_dv_timings(struct file *file, void
*priv,
struct v4l2_enum_dv_timings *timings)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
+
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_DV_TIMINGS))
+ return -ENODATA;
timings->pad = 0;
@@ -498,6 +503,11 @@ static int bcap_query_dv_timings(struct file *file, void
*priv,
struct v4l2_dv_timings *timings)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
+
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_DV_TIMINGS))
+ return -ENODATA;
return v4l2_subdev_call(bcap_dev->sd, video,
query_dv_timings, timings);
@@ -507,6 +517,11 @@ static int bcap_g_dv_timings(struct file *file, void *priv,
struct v4l2_dv_timings *timings)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
+
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_DV_TIMINGS))
+ return -ENODATA;
*timings = bcap_dev->dv_timings;
return 0;
@@ -516,7 +531,13 @@ static int bcap_s_dv_timings(struct file *file, void *priv,
struct v4l2_dv_timings *timings)
{
struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_input input;
int ret;
+
+ input = bcap_dev->cfg->inputs[bcap_dev->cur_input];
+ if (!(input.capabilities & V4L2_IN_CAP_DV_TIMINGS))
+ return -ENODATA;
+
if (vb2_is_busy(&bcap_dev->buffer_queue))
return -EBUSY;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 05/17] media: blackfin: bfin_capture: improve queue_setup() callback
From: "Lad, Prabhakar"
This patch does the following:
a: returns -EINVAL in case format image size is less
then current image size.
b: assigns nbuffers to two in case the total of vq->num_buffers
and nbuffers is less then the number of buffers required by driver.
c: sets the sizes[0] of plane according to the fmt passed or which is
being set in the device.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index a588129..bf7e999 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -44,7 +44,6 @@
#include
#define CAPTURE_DRV_NAME"bfin_capture"
-#define BCAP_MIN_NUM_BUF2
struct bcap_format {
char *desc;
@@ -292,11 +291,14 @@ static int bcap_queue_setup(struct vb2_queue *vq,
{
struct bcap_device *bcap_dev = vb2_get_drv_priv(vq);
- if (*nbuffers < BCAP_MIN_NUM_BUF)
- *nbuffers = BCAP_MIN_NUM_BUF;
+ if (fmt && fmt->fmt.pix.sizeimage < bcap_dev->fmt.sizeimage)
+ return -EINVAL;
+
+ if (vq->num_buffers + *nbuffers < 2)
+ *nbuffers = 2;
*nplanes = 1;
- sizes[0] = bcap_dev->fmt.sizeimage;
+ sizes[0] = fmt ? fmt->fmt.pix.sizeimage : bcap_dev->fmt.sizeimage;
alloc_ctxs[0] = bcap_dev->alloc_ctx;
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 09/17] media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback
From: "Lad, Prabhakar"
In start_streaming() callback the buffer is removed from the
dma_queue list and assigned to cur_frm, this patch makes sure
that is returned to vb2 core with VB2_BUF_STATE_ERROR flag.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 2a9e933..f2b1a23 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -374,6 +374,9 @@ static void bcap_stop_streaming(struct vb2_queue *vq)
"stream off failed in subdev\n");
/* release all active buffers */
+ if (bcap_dev->cur_frm)
+ vb2_buffer_done(&bcap_dev->cur_frm->vb, VB2_BUF_STATE_ERROR);
+
while (!list_empty(&bcap_dev->dma_queue)) {
bcap_dev->cur_frm = list_entry(bcap_dev->dma_queue.next,
struct bcap_buffer, list);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 02/17] media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails
From: "Lad, Prabhakar"
this patch adds support to release the buffer by calling
vb2_buffer_done(), with state marked as VB2_BUF_STATE_QUEUED
if start_streaming() call back fails.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index c6d8b95..2c720bc 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -345,6 +345,7 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
{
struct bcap_device *bcap_dev = vb2_get_drv_priv(vq);
struct ppi_if *ppi = bcap_dev->ppi;
+ struct bcap_buffer *buf, *tmp;
struct ppi_params params;
int ret;
@@ -352,7 +353,7 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
ret = v4l2_subdev_call(bcap_dev->sd, video, s_stream, 1);
if (ret && (ret != -ENOIOCTLCMD)) {
v4l2_err(&bcap_dev->v4l2_dev, "stream on failed in subdev\n");
- return ret;
+ goto err;
}
/* set ppi params */
@@ -391,7 +392,7 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
if (ret < 0) {
v4l2_err(&bcap_dev->v4l2_dev,
"Error in setting ppi params\n");
- return ret;
+ goto err;
}
/* attach ppi DMA irq handler */
@@ -399,12 +400,21 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
if (ret < 0) {
v4l2_err(&bcap_dev->v4l2_dev,
"Error in attaching interrupt handler\n");
- return ret;
+ goto err;
}
reinit_completion(&bcap_dev->comp);
bcap_dev->stop = false;
+
return 0;
+
+err:
+ list_for_each_entry_safe(buf, tmp, &bcap_dev->dma_queue, list) {
+ list_del(&buf->list);
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_QUEUED);
+ }
+
+ return ret;
}
static void bcap_stop_streaming(struct vb2_queue *vq)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 08/17] media: blackfin: bfin_capture: use vb2_ioctl_* helpers
From: "Lad, Prabhakar"
this patch adds support to vb2_ioctl_* helpers.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 103 +
1 file changed, 18 insertions(+), 85 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 01e778d..2a9e933 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -276,6 +276,7 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
struct ppi_if *ppi = bcap_dev->ppi;
struct bcap_buffer *buf, *tmp;
struct ppi_params params;
+ dma_addr_t addr;
int ret;
/* enable streamon on the sub device */
@@ -335,6 +336,17 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
reinit_completion(&bcap_dev->comp);
bcap_dev->stop = false;
+ /* get the next frame from the dma queue */
+ bcap_dev->cur_frm = list_entry(bcap_dev->dma_queue.next,
+ struct bcap_buffer, list);
+ /* remove buffer from the dma queue */
+ list_del_init(&bcap_dev->cur_frm->list);
+ addr = vb2_dma_contig_plane_dma_addr(&bcap_dev->cur_frm->vb, 0);
+ /* update DMA address */
+ ppi->ops->update_addr(ppi, (unsigned long)addr);
+ /* enable ppi */
+ ppi->ops->start(ppi);
+
return 0;
err:
@@ -381,40 +393,6 @@ static struct vb2_ops bcap_video_qops = {
.stop_streaming = bcap_stop_streaming,
};
-static int bcap_reqbufs(struct file *file, void *priv,
- struct v4l2_requestbuffers *req_buf)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
- struct vb2_queue *vq = &bcap_dev->buffer_queue;
-
- return vb2_reqbufs(vq, req_buf);
-}
-
-static int bcap_querybuf(struct file *file, void *priv,
- struct v4l2_buffer *buf)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
-
- return vb2_querybuf(&bcap_dev->buffer_queue, buf);
-}
-
-static int bcap_qbuf(struct file *file, void *priv,
- struct v4l2_buffer *buf)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
-
- return vb2_qbuf(&bcap_dev->buffer_queue, buf);
-}
-
-static int bcap_dqbuf(struct file *file, void *priv,
- struct v4l2_buffer *buf)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
-
- return vb2_dqbuf(&bcap_dev->buffer_queue,
- buf, file->f_flags & O_NONBLOCK);
-}
-
static irqreturn_t bcap_isr(int irq, void *dev_id)
{
struct ppi_if *ppi = dev_id;
@@ -456,51 +434,6 @@ static irqreturn_t bcap_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int bcap_streamon(struct file *file, void *priv,
- enum v4l2_buf_type buf_type)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
- struct ppi_if *ppi = bcap_dev->ppi;
- dma_addr_t addr;
- int ret;
-
- /* call streamon to start streaming in videobuf */
- ret = vb2_streamon(&bcap_dev->buffer_queue, buf_type);
- if (ret)
- return ret;
-
- /* if dma queue is empty, return error */
- if (list_empty(&bcap_dev->dma_queue)) {
- v4l2_err(&bcap_dev->v4l2_dev, "dma queue is empty\n");
- ret = -EINVAL;
- goto err;
- }
-
- /* get the next frame from the dma queue */
- bcap_dev->cur_frm = list_entry(bcap_dev->dma_queue.next,
- struct bcap_buffer, list);
- /* remove buffer from the dma queue */
- list_del_init(&bcap_dev->cur_frm->list);
- addr = vb2_dma_contig_plane_dma_addr(&bcap_dev->cur_frm->vb, 0);
- /* update DMA address */
- ppi->ops->update_addr(ppi, (unsigned long)addr);
- /* enable ppi */
- ppi->ops->start(ppi);
-
- return 0;
-err:
- vb2_streamoff(&bcap_dev->buffer_queue, buf_type);
- return ret;
-}
-
-static int bcap_streamoff(struct file *file, void *priv,
- enum v4l2_buf_type buf_type)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
-
- return vb2_streamoff(&bcap_dev->buffer_queue, buf_type);
-}
-
static int bcap_querystd(struct file *file, void *priv, v4l2_std_id *std)
{
struct bcap_device *bcap_dev = video_drvdata(file);
@@ -786,12 +719,12 @@ static const struct v4l2_ioctl_ops bcap_ioctl_ops = {
.vidioc_g_dv_timings = bcap_g_dv_timings,
.vidioc_query_dv_timings = bcap_query_dv_timings,
.vidioc_enum_dv_timings = bcap_enum_dv_timings,
- .vidioc_reqbufs = bcap_reqbufs,
- .vidioc_querybuf = bcap_querybuf,
- .vidioc_qbuf = bcap_qbuf,
- .vidioc_dqbuf
[PATCH v4 06/17] media: blackfin: bfin_capture: use vb2_fop_mmap/poll
From: "Lad, Prabhakar"
No need to reinvent the wheel. Just use the already existing
functions provided by vb2.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 28 +++---
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index bf7e999..84827d2 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -244,18 +244,6 @@ static int bcap_release(struct file *file)
return 0;
}
-static int bcap_mmap(struct file *file, struct vm_area_struct *vma)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
- int ret;
-
- if (mutex_lock_interruptible(&bcap_dev->mutex))
- return -ERESTARTSYS;
- ret = vb2_mmap(&bcap_dev->buffer_queue, vma);
- mutex_unlock(&bcap_dev->mutex);
- return ret;
-}
-
#ifndef CONFIG_MMU
static unsigned long bcap_get_unmapped_area(struct file *file,
unsigned long addr,
@@ -273,17 +261,6 @@ static unsigned long bcap_get_unmapped_area(struct file
*file,
}
#endif
-static unsigned int bcap_poll(struct file *file, poll_table *wait)
-{
- struct bcap_device *bcap_dev = video_drvdata(file);
- unsigned int res;
-
- mutex_lock(&bcap_dev->mutex);
- res = vb2_poll(&bcap_dev->buffer_queue, file, wait);
- mutex_unlock(&bcap_dev->mutex);
- return res;
-}
-
static int bcap_queue_setup(struct vb2_queue *vq,
const struct v4l2_format *fmt,
unsigned int *nbuffers, unsigned int *nplanes,
@@ -900,11 +877,11 @@ static struct v4l2_file_operations bcap_fops = {
.open = bcap_open,
.release = bcap_release,
.unlocked_ioctl = video_ioctl2,
- .mmap = bcap_mmap,
+ .mmap = vb2_fop_mmap,
#ifndef CONFIG_MMU
.get_unmapped_area = bcap_get_unmapped_area,
#endif
- .poll = bcap_poll
+ .poll = vb2_fop_poll
};
static int bcap_probe(struct platform_device *pdev)
@@ -1001,6 +978,7 @@ static int bcap_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&bcap_dev->dma_queue);
vfd->lock = &bcap_dev->mutex;
+ vfd->queue = q;
/* register video device */
ret = video_register_device(bcap_dev->video_dev, VFL_TYPE_GRABBER, -1);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 01/17] media: blackfin: bfin_capture: drop buf_init() callback
From: "Lad, Prabhakar"
this patch drops the buf_init() callback as init
of buf list is not required.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 8f66986..c6d8b95 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -302,14 +302,6 @@ static int bcap_queue_setup(struct vb2_queue *vq,
return 0;
}
-static int bcap_buffer_init(struct vb2_buffer *vb)
-{
- struct bcap_buffer *buf = to_bcap_vb(vb);
-
- INIT_LIST_HEAD(&buf->list);
- return 0;
-}
-
static int bcap_buffer_prepare(struct vb2_buffer *vb)
{
struct bcap_device *bcap_dev = vb2_get_drv_priv(vb->vb2_queue);
@@ -441,7 +433,6 @@ static void bcap_stop_streaming(struct vb2_queue *vq)
static struct vb2_ops bcap_video_qops = {
.queue_setup= bcap_queue_setup,
- .buf_init = bcap_buffer_init,
.buf_prepare= bcap_buffer_prepare,
.buf_cleanup= bcap_buffer_cleanup,
.buf_queue = bcap_buffer_queue,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 04/17] media: blackfin: bfin_capture: set vb2 buffer field
From: "Lad, Prabhakar"
set the vb2 buffer field in buf_prepare() callback,
alongside drop local variable buf as we already have
a pointer to vb2 buffer.
Signed-off-by: Lad, Prabhakar
Acked-by: Scott Jiang
Tested-by: Scott Jiang
---
drivers/media/platform/blackfin/bfin_capture.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 332f8c9..a588129 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -305,16 +305,16 @@ static int bcap_queue_setup(struct vb2_queue *vq,
static int bcap_buffer_prepare(struct vb2_buffer *vb)
{
struct bcap_device *bcap_dev = vb2_get_drv_priv(vb->vb2_queue);
- struct bcap_buffer *buf = to_bcap_vb(vb);
- unsigned long size;
+ unsigned long size = bcap_dev->fmt.sizeimage;
- size = bcap_dev->fmt.sizeimage;
if (vb2_plane_size(vb, 0) < size) {
v4l2_err(&bcap_dev->v4l2_dev, "buffer too small (%lu < %lu)\n",
vb2_plane_size(vb, 0), size);
return -EINVAL;
}
- vb2_set_plane_payload(&buf->vb, 0, size);
+ vb2_set_plane_payload(vb, 0, size);
+
+ vb->v4l2_buf.field = bcap_dev->fmt.field;
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] resource: remove deprecated __check_region() and friends
All users of __check_region(), check_region(), and check_mem_region()
are gone. We got rid of the last user in v4.0-rc1. Remove them.
bloat-o-meter on x86_64 shows:
add/remove: 0/3 grow/shrink: 0/0 up/down: 0/-102 (-102)
function old new delta
__kstrtab___check_region 15 - -15
__ksymtab___check_region 16 - -16
__check_region71 - -71
Signed-off-by: Jakub Sitnicki
---
include/linux/ioport.h | 8
kernel/resource.c | 32
2 files changed, 40 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 2c525022..388e3ae 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -196,10 +196,8 @@ extern struct resource * __request_region(struct resource
*,
/* Compatibility cruft */
#define release_region(start,n)__release_region(&ioport_resource,
(start), (n))
-#define check_mem_region(start,n) __check_region(&iomem_resource,
(start), (n))
#define release_mem_region(start,n)__release_region(&iomem_resource,
(start), (n))
-extern int __check_region(struct resource *, resource_size_t, resource_size_t);
extern void __release_region(struct resource *, resource_size_t,
resource_size_t);
#ifdef CONFIG_MEMORY_HOTREMOVE
@@ -207,12 +205,6 @@ extern int release_mem_region_adjustable(struct resource
*, resource_size_t,
resource_size_t);
#endif
-static inline int __deprecated check_region(resource_size_t s,
- resource_size_t n)
-{
- return __check_region(&ioport_resource, s, n);
-}
-
/* Wrappers for managed devices */
struct device;
diff --git a/kernel/resource.c b/kernel/resource.c
index 19f2357..90552aa 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1034,8 +1034,6 @@ resource_size_t resource_alignment(struct resource *res)
*
* request_region creates a new busy region.
*
- * check_region returns non-zero if the area is already busy.
- *
* release_region releases a matching busy region.
*/
@@ -1098,36 +1096,6 @@ struct resource * __request_region(struct resource
*parent,
EXPORT_SYMBOL(__request_region);
/**
- * __check_region - check if a resource region is busy or free
- * @parent: parent resource descriptor
- * @start: resource start address
- * @n: resource region size
- *
- * Returns 0 if the region is free at the moment it is checked,
- * returns %-EBUSY if the region is busy.
- *
- * NOTE:
- * This function is deprecated because its use is racy.
- * Even if it returns 0, a subsequent call to request_region()
- * may fail because another driver etc. just allocated the region.
- * Do NOT use it. It will be removed from the kernel.
- */
-int __check_region(struct resource *parent, resource_size_t start,
- resource_size_t n)
-{
- struct resource * res;
-
- res = __request_region(parent, start, n, "check-region", 0);
- if (!res)
- return -EBUSY;
-
- release_resource(res);
- free_resource(res);
- return 0;
-}
-EXPORT_SYMBOL(__check_region);
-
-/**
* __release_region - release a previously reserved resource region
* @parent: parent resource descriptor
* @start: resource start address
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
LAON AANBIEDING OP 1,5% rente
Goede dag, We zijn Diamond Zwitserse lening bedrijf het geven van leningen per post advertentie. Wij bieden verschillende soorten leningen (korte en lange termijn leningen, persoonlijke leningen, leningen aan bedrijven etc.) met 1,5% rente. We geven leningen aan mensen in nood niet, ongeacht hun locatie, geslacht, burgerlijke staat, opleiding, status van de taak, maar moet een juridisch middel van terugbetaling hebben. Onze leningen variëren van 5.000,00 tot 10.000.000,00 US Dollar of Euro of Pound met een maximale looptijd van 20 jaar. Als u geïnteresseerd bent in meer informatie, vul dan onderstaand formulier in en stuur deze naar ons e-mailadres: diamondswissloanscompa...@gmail.com Gelieve in te vullen: naam: adres: leeftijd: Geslacht: Contact-Phone: beroep: Maandelijks inkomen: Het benodigde bedrag van de lening: Duur van de lening: Het doel van de lening: land: Postcode: "Wij tonen u een betere manier om uw financiële vrijheid" Met vriendelijke groet, De heer Diamond Peters (Managing Director). De heer Bill Anthony (Marketing Manager). -- 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/1] usb: xhci: handle Config Error Change (CEC) in xhci driver
On Sun, 8 Mar 2015, Lu, Baolu wrote: > Hi Alan, > > Do you have any comments for this patch? No comments. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb gadget: remove size limitation for storage cdrom
On Sun, 8 Mar 2015, Dave Young wrote:
> I used usb cdrom emulation to play video dvd for my daughter, but I got below
> error:
>
> [dave@darkstar tmp]$ cat /mnt/sr1/VIDEO_TS/VTS_01_5.VOB >/dev/null
> cat: /mnt/sr1/VIDEO_TS/VTS_01_5.VOB: Input/output error
> [dave@darkstar tmp]$ dmesg|tail -1
> [ 3349.371857] sr1: rw=0, want=8028824, limit=4607996
>
> The assumption of cdrom size is not right, we can create data dvd large then
> 4G, also mkisofs can create an iso with only one blank directory, the size is
> less than 300 sectors. The size limit does not make sense, thus remove them.
>
> Signed-off-by: Dave Young
> ---
> drivers/usb/gadget/function/storage_common.c |9 -
> 1 file changed, 9 deletions(-)
>
> --- linux.orig/drivers/usb/gadget/function/storage_common.c
> +++ linux/drivers/usb/gadget/function/storage_common.c
> @@ -247,15 +247,6 @@ int fsg_lun_open(struct fsg_lun *curlun,
>
> num_sectors = size >> blkbits; /* File size in logic-block-size blocks
> */
> min_sectors = 1;
> - if (curlun->cdrom) {
> - min_sectors = 300; /* Smallest track is 300 frames */
> - if (num_sectors >= 256*60*75) {
> - num_sectors = 256*60*75 - 1;
> - LINFO(curlun, "file too big: %s\n", filename);
> - LINFO(curlun, "using only first %d blocks\n",
> - (int) num_sectors);
> - }
> - }
> if (num_sectors < min_sectors) {
> LINFO(curlun, "file too small: %s\n", filename);
> rc = -ETOOSMALL;
NAK. This patch is wrong, for a very simple reason. You wrote:
> I used usb cdrom emulation to play video dvd for my daughter
and this demonstrates the error quite plainly. You can't use _CD_
emulation to imitate a _DVD_ -- they are different sorts of media.
Just think of what happens when you try playing a DVD on a CD player.
A more suitable approach would be to add DVD emulation to the driver.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions
On Sat, 7 Mar 2015, Rafael J. Wysocki wrote: > > > Well right now it's using threaded irq, and I'd like to get rid of > > > I'll verify again, but I believe the issue was that without doing > > > mark_last_busy here the device falls back asleep right away. > > > That probably should be fixed in pm_runtime in general if that's > > > the case. > > > > It's up to the subsystem to handle this. For example, the USB > > subsystem's runtime-resume routine calls pm_runtime_mark_last_busy. > > I'm wondering, though, if there's any reason for us to avoid updating > power.last_busy in rpm_resume(). > > If I was a driver writer, I'd expect the core to do that for me quite frankly. In theory, you might want to wake up a device to perform some very limited operation (like reading an internal register) and then put it back into suspend very quickly, without waiting for the autosuspend delay to elapse. Apart from that, I can't think of any reason not to update last_busy in rpm_resume. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips
On 03/08/2015 07:03 AM, Andy Lutomirski wrote:
On Mar 7, 2015 6:39 AM, "Guenter Roeck" wrote:
On 03/06/2015 06:50 PM, Andy Lutomirski wrote:
Sandy Bridge Xeon and Extreme chips have integrated memory
controllers with (rather limited) onboard SMBUS masters. This
driver gives access to the bus.
There are various groups working on standardizing a way to arbitrate
access to the bus between the OS, SMM firmware, a BMC, hardware
thermal control, etc. In the mean time, running this driver is
unsafe except under special circumstances. Nonetheless, this driver
has real users.
As a compromise, the driver will refuse to load unless
i2c_imc.allow_unsafe_access=Y. When safe access becomes available,
we can leave this option as a way for legacy users to run the
driver, and we'll allow the driver to load by default if safe bus
access is available.
Signed-off-by: Andy Lutomirski
---
[ ... ]
+
+ if (imc_wait_not_busy(priv, chan, &stat) != 0) {
+ /* Timeout. TODO: Reset the controller? */
+ ret = -EIO;
timeout -> -ETIMEDOUT ?
OK
Actually, I just realized that imc_wait_not_busy returns a valid error code.
Given that, some static analysis checkers (and now me) will ask you
why you don't just use the error code from imc_wait_not_busy.
This applies to other calls to the same function as well.
+ dev_err(&priv->pci_dev->dev, "controller is wedged\n");
If this happens, it will presumably happen all the time and the message will
pollute the log. Is the message really necessary ?
I'd rather log something to help diagnose. Would rate-limiting it be okay?
It would still pollute the log because it doesn't happen that often.
A message once a second still fills the log.
If it is for diagnose/debugging, why not dev_dbg ?
+ goto out_release;
+ }
+
+ /*
+* Be paranoid: try to detect races. This will only detect races
+* against BIOS, not against hardware. (I've never seen this happen.)
+*/
+ pci_read_config_dword(priv->pci_dev, SMBCMD(chan), &final_cmd);
+ pci_read_config_dword(priv->pci_dev, SMBCNTL(chan), &final_cntl);
+ if (((cmd ^ final_cmd) & SMBCMD_OUR_BITS) ||
+ ((cntl ^ final_cntl) & SMBCNTL_OUR_BITS)) {
+ WARN(1, "iMC SMBUS raced against firmware");
+ dev_emerg(&priv->pci_dev->dev,
Is a stack trace and dev_emerg really warranted here ?
If this happens, something's very wrong and the user should stop using
the driver. We could potentially write the wrong address, and, if we
manage to screw up thermal management, we could potentially corrupt
data for to an inappropriate refresh interval.
IOW, I want to hear about it if this happens.
Ok, that explains the WARN. Still not an "emergency", though.
+ "Access to channel %d raced: cmd 0x%08X->0x%08X, cntl
0x%08X->0x%08X\n",
+ chan, cmd, final_cmd, cntl, final_cntl);
+ atomic_set(&imc_raced, 1);
+ ret = -EIO;
+ goto out_release;
+ }
+
+ if (stat & SMBSTAT_SBE) {
+ /*
+* Clear the error to re-enable TSOD polling. The docs say
+* that, as long as SBE is set, TSOD polling won't happen.
+* The docs also say that writing zero to this bit (which is
+* the only writable bit in the whole register) will clear
+* the error. Empirically, writing 0 does not clear SBE, but
+* it's probably still good to do the write in compliance with
+* the spec. (TSOD polling still happens and seems to
+* clear SBE on its own.)
+*/
+ pci_write_config_dword(priv->pci_dev, SMBSTAT(chan), 0);
+ ret = -ENXIO;
+ goto out_release;
+ }
+
+ if (read_write == I2C_SMBUS_READ) {
+ if (stat & SMBSTAT_RDO) {
+ /*
+* The iMC SMBUS controller thinks of SMBUS
+* words as being big-endian (MSB first).
+* Linux treats them as little-endian, so we need
+* to swap them.
+*
+* Note: the controller will often (always?) set
+* WOD here. This is probably a bug.
+*/
+ if (size == I2C_SMBUS_WORD_DATA)
+ data->word = swab16(stat & SMBSTAT_RDATA_MASK);
+ else
+ data->byte = stat & 0xFF;
+ ret = 0;
ret is already guaranteed to be 0 here.
+ } else {
+ dev_err(&priv->pci_dev->dev,
+ "Unexpected read status 0x%08X\n", stat);
+ ret = -EIO;
+ }
+ } else {
+
Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions
On Fri, 6 Mar 2015, Tony Lindgren wrote: > > > I'll verify again, but I believe the issue was that without doing > > > mark_last_busy here the device falls back asleep right away. As it should. If you don't increment the usage counter (for example, by calling pm_runtime_get instead of pm_request_resume) and you don't update last_busy then you are telling the PM core that the device currently isn't busy and it hasn't been in use since the last time it was suspended. Under those circumstances, the PM core is _supposed_ to suspend the device right away. > > > That probably should be fixed in pm_runtime in general if that's > > > the case. > > > > It's up to the subsystem to handle this. For example, the USB > > subsystem's runtime-resume routine calls pm_runtime_mark_last_busy. > > Hmm.. OK thanks this probably explains why pm_request_resume() did > not work. > > For omaps, I could call this from the interconnect related code, > but then how dow we deal with the subsystems that don't call it? Start by determining _why_ they don't call it. Maybe they have a good reason. If they don't then fix them. > > > Considering the above, should we add a new function something like > > > pm_resume_complete() that does not need irq_safe set but does > > > not return until the device has completed resume? > > > > That doesn't make sense. You're asking for a routine that is allowed > > to sleep but can safely be called in interrupt context. > > Oh it naturally would not work in irq context, it's for the bottom > half again. In other words, you're suggesting we add a function that runs in process context and doesn't return until the device is fully resumed? That's exactly what pm_runtime_resume does right now. > But I'll take a look if we can just call > pm_request_resume() and disable_irq() on the wakeirq in without > waiting for the device driver runtime_suspend to disable the wakeirq. > That would minimize the interface to just dev_pm_request_wakeirq() > and dev_pm_free_wakeirq(). Will that be acceptable in systems with shared IRQ lines? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions
On Sat, 7 Mar 2015, Rafael J. Wysocki wrote:
> But this is part of a bigger picture. Namely, if a separete wakeup interrupt
> is required for a device, the device's power.can_wakeup flag cannot be set
> until that interrupt has been successfully requested. Also for devices that
> can signal wakeup via their own IO interrupts, it would make sense to allow
> those interrupts to be registered somehow as "wakeup interrupts".
>
> So I wonder if we can define a new struct along the lines of your
> struct wakeirq_source, but call it struct wake_irq and make it look
> something like this:
>
> struct wake_irq {
>struct device *dev;
>int irq;
>irq_handler_t handler;
> };
>
> Then, add a struct wake_irq pointer to struct dev_pm_info *and* to
> struct wakeup_source. Next, make dev_pm_request_wake_irq() allocate the
> structure and request the interrupt and only set the pointer to it from
> struct dev_pm_info *along* *with* power.can_wakeup if all that was
> successful.
>
> For devices that use their own IO IRQ for wakeup, we can add something
> like dev_pm_set_wake_irq() that will work analogously, but without requesting
> the interrupt. It will just set the dev and irq members of struct wake_irq
> and point struct dev_pm_info to it and set its power.can_wakeup flag.
>
> Then, device_wakeup_enable() will be able to see that the device has a
> wakeup IRQ and it may then point its own struct wake_irq pointer to that.
> The core may then use that pointer to trigger enable_irq_wake() for the
> IRQ in question and it will cover the devices that don't need separate
> wakeup interrupts too.
>
> Does that make sense to you?
Can we back up a little? What is the basic problem the two of you are
trying to solve?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8188eu: use %*ph specifier instead of passing direct values
The %*ph specifier allows to pass a pointer and length instead of
pushing each byte via stack. The patch converts code to use it.
Signed-off-by: Mike Krinkin
---
drivers/staging/rtl8188eu/hal/usb_halinit.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c
b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index 122e9b3..960a7a5 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -1096,10 +1096,8 @@ static void Hal_EfuseParseMACAddr_8188EU(struct adapter
*adapt, u8 *hwinfo, bool
memcpy(eeprom->mac_addr, &hwinfo[EEPROM_MAC_ADDR_88EU],
ETH_ALEN);
}
RT_TRACE(_module_hci_hal_init_c_, _drv_notice_,
-("Hal_EfuseParseMACAddr_8188EU: Permanent Address =
%02x-%02x-%02x-%02x-%02x-%02x\n",
-eeprom->mac_addr[0], eeprom->mac_addr[1],
-eeprom->mac_addr[2], eeprom->mac_addr[3],
-eeprom->mac_addr[4], eeprom->mac_addr[5]));
+("Hal_EfuseParseMACAddr_8188EU: Permanent Address = %6phD\n",
+eeprom->mac_addr));
}
static void
--
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/4] Cleaned hexadecimal dump
On Sun, 2015-03-08 at 12:53 +0200, Andy Shevchenko wrote: > On Sun, Mar 8, 2015 at 4:22 AM, Joe Perches wrote: > > On Sat, 2015-03-07 at 12:56 -0500, Adrian Remonda wrote: > > >> +static void hexDump(const void *src, size_t length, size_t bLine, char > >> *prefix) > > Is there something necessary that print_hex_dump can't do? > As far as I can see the tool is running in user space. OK, I skipped over that bit. Nevermind. > Do we have > possibility to use print_hex_dump() in user space? No. -- 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/
