Re: [PATCH] i2c-designware: fixup of wait_for_completion_timeout return handling
On Tue, 10 Feb 2015, Jarkko Nikula wrote:
> Hi
>
> On 02/09/2015 06:35 PM, Nicholas Mc Guire wrote:
>> return type of wait_for_completion_timeout is unsigned long not int.
>> An appropriate return variable is introduced and assignment fixed up.
>>
>> Signed-off-by: Nicholas Mc Guire
>> ---
>>
>> Patch was compile tested with x86_64_defconfig +
>> CONFIG_X86_AMD_PLATFORM_DEVICE=y, CONFIG_I2C_DESIGNWARE_PLATFORM=m
>> (implies CONFIG_I2C_DESIGNWARE_CORE=y)
>>
>> Patch is against 3.19.0-rc7 (localversion-next is -next-20150209)
>>
>> drivers/i2c/busses/i2c-designware-core.c |5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-core.c
>> b/drivers/i2c/busses/i2c-designware-core.c
>> index 6e25c01..05934e0 100644
>> --- a/drivers/i2c/busses/i2c-designware-core.c
>> +++ b/drivers/i2c/busses/i2c-designware-core.c
>> @@ -623,6 +623,7 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
>> msgs[], int num)
>> {
>> struct dw_i2c_dev *dev = i2c_get_adapdata(adap);
>> int ret;
>> +unsigned int timeout;
>>
> Not unsigned long.
oops thats braindead - yes of course unsigned long
sorry - thats a careless mistake.
>
>> @@ -656,8 +657,8 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
>> msgs[], int num)
>> i2c_dw_xfer_init(dev);
>>
>> /* wait for tx to complete */
>> -ret = wait_for_completion_timeout(>cmd_complete, HZ);
>> -if (ret == 0) {
>> +timeout = wait_for_completion_timeout(>cmd_complete, HZ);
>> +if (timeout == 0) {
>> dev_err(dev->dev, "controller timed out\n");
>> /* i2c_dw_init implicitly disables the adapter */
>> i2c_dw_init(dev);
>>
> I'd say better to test directly with "if
> (!wait_for_completion_timeout())" since remaining jiffies or potential
> error code from wait_for_completion_timeout() is not used here.
>
Yup - that would eliminate the need for an additional variable
but some maintainers did not like that solution.
Thanks for your comments - Will fix it up and repost.
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.19: device name associates with IRQ's for ahci controllers operating with a single IRQ changed from "ahci?" to ""
On 09.02.2015 20:54, Sander Eikelenboom wrote: > Hi. > > In 3.19 the device name associates with IRQ's for ahci controllers operating > with a single IRQ changed from "ahci?" to "", was this intentional ? > > It's probably commit 18dcf433f3ded61eb140a55e7048ec2fef79e723 (or another one > in that series). Oh, looking at that commit that might make sense. In ahci_host_activate_single_irq it now uses dev_driver_name instead of dev_name as it did before (from ata_host_activate). The description sounds like before the driver is registered this will return the bus. And registering an interrupt would likely be before the driver is fully registered... But you probably saw that, too. Whether that really was intentional is still the question. :) -Stefan > > -- > Sander > > > /proc/interrupts of an ahci controller with a single irq: > 52: 13529 0 0 0 xen-pirq-msi > :00:1f.2 > > /proc/interrupts of an ahci controller with multiple irq's: > 114: 412535 0 0 0 0 0 > xen-pirq-msi ahci0 > 115: 0 0 0 0 0 0 > xen-pirq-msi ahci1 > 116: 16717 0 0 0 0 0 > xen-pirq-msi ahci2 > 117: 0 0 0 0 0 0 > xen-pirq-msi ahci3 > 118: 0 0 0 0 0 0 > xen-pirq-msi ahci4 > 119: 0 0 0 0 0 0 > xen-pirq-msi ahci5 > > signature.asc Description: OpenPGP digital signature
Re: [PATCH] kvm: add halt_poll_ns module parameter
On 09/02/2015 22:00, Christian Borntraeger wrote: > I can confirm that this also helps uperf with a 1/1 byte round trip work load > between guests on s390. And I can confirm the higher CPU load. This is > normally > a no-go for the typical s390 users, which utilize their systems as much as > possible. Your check for single_task_running could actually solve that > problem because on overcommitment this will never switch to polling if the > runqueues get full. > Since this is also runtime configurable and defaults to 0 it should be pretty > painless. > > The only question is: is there a sane way of doing autotuning? The answer is: we'll see. :) I have some ideas, I have to run them through the necessary experiments. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: atmel_ssc_dai: Allow more rates
On Mon, Feb 09, 2015 at 04:08:25PM +0100, Peter Rosin wrote: > From: Peter Rosin > > When the SSC acts as BCK master, use a ratnum rule to limit > the rate instead of only doing the standard rates. When the SSC > acts as BCK slave, allow any BCK frequency up to the SSC master > clock, divided by either of 2, 3 or 6. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/9] regulator: core: Introduce set_optimum_mode op
On Mon, Feb 09, 2015 at 02:08:41PM -0800, Bjorn Andersson wrote: > You said something when we talked that I interpreted to > regulator_set_optimum_mode() is not a good name for the consumer API; > was that a correct interpretation or was your comment limited to the > driver facing API? > Should we go ahead and rename it to regulator_notify_load() > (regulator_set_load() perhaps?) before we get more consumers as well? > (would be a separate patch set) This can be _set_load() I think since we are actually telling the framework about the expected load but yes, we should rename it to reflect what we're actually doing. > But if we're only considering load in drms_uA_update() does it make > sense to check this against the valid ranges of min_uA, max_uA and > hence instead of checking REGULATOR_CHANGE_DRMS just check for > REGULATOR_CHANGE_CURRENT? > We have reduced the interface to not necessarily be dynamic _mode_ setting. No, _CHANGE_CURRENT is about current reglators which are a different thing to voltage regulators. > >> I think this covers your concern about patch 3-7 as well, please let me > >> know what you think. > > Possibly. > Well, my question is still there: > Unless we replace the get_optimum_mode()/set_mode() pair with > notify_load() the driver API logic will become confusing; so for the > regulators that to day implement that combo I think we need patch 3-7 > as well. That's not a question, that's a statement... Since we don't currently have a notify_load() interface we obviously don't have any drivers using it so I'm not sure what drivers will become confusing here or how this addresses the part about keeping the operations split for the common pattern? signature.asc Description: Digital signature
Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables
On Thu, 05 Feb 2015, Brian Norris wrote: > On Wed, Jan 21, 2015 at 03:24:20PM +, Lee Jones wrote: > > To trim down on the amount of properties used by this driver and to conform > > to the newly agreed method of acquiring syscfg registers/offsets, we now > > obtain this information using match tables. > > Where did this agreement happen? Are you only referring to the previous > patch? I think your interpretation of the above text and my intentions are not the same. I have no idea why there is a different configuration depending on if we booted from SPI NOR or not and hence can not answer your query below. The description above is pertaining to the different/new way in which we obtain and request syscfg registers. In previous incarnations of this patchset, we were defining new vendor specific properties in order to request and register and the mask: st,boot-device-reg = <0x958>; st,boot-device-spi = <0x1a>; ... this is not optimal, as DT properties should only be created if there are no other way to obtain platform specific information. As there are few supported platforms and this configuration does not change through variants, we are now supplying it via static tables, which can be obtained easily using the DT match framework. > I think I asked this previously, and I didn't get an answer. Not sure if you did or not to be honest. > Also, I realized that all this boot device / syscfg gymnastics is just > for one simple fact; your driver is trying to hide the fact that your > system can't reliably handle 4-byte addressing for the boot device. Even > if you try your best at toggling 4-byte addressing before/after each > read/write/erase, you still are vulnerable to power cuts during the > operation. This is a bad design, and we have consistently agreed that we > aren't going to work around that in Linux. > > Better solutions: hook up a reset line to your flash; improve your boot > ROM / bootloader to handle 4-byte addressing for large flash. You have reached the boundaries of my knowledge on this. Perhaps Angus (BCC'ed) would be kind enough to assist. > What's the possibility of dropping all this 4-byte address toggling > shenanigans? This will be a blocker to merging with spi-nor.c. > > > In the process we are deprecating the old generic compatible string and > > providing 3 shiny new ones for each of the support platforms. The > > deprecated compatible string will be removed in due course. > > Aren't you already removing the compatible string? (You changed this in > the latest revision.) You're right. I need to remove this line from the commit log. > > Cc: devicet...@vger.kernel.org > > Signed-off-by: Lee Jones > > [snip] > > Brian -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] thinkpad_acpi: unhandled hkey event
Pressing Fn+Esc in a Lenovo Thinkpad x240 to lock the Fn keys generates
an unhandled hkey event
Signed-off-by: Xavier Naveira
---
drivers/platform/x86/thinkpad_acpi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index cf0f893..ce63610 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -196,6 +196,7 @@ enum tpacpi_hkey_event_t {
/* Key-related user-interface events */
TP_HKEY_EV_KEY_NUMLOCK = 0x6000, /* NumLock key pressed */
TP_HKEY_EV_KEY_FN = 0x6005, /* Fn key pressed? E420 */
+ TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
/* Thermal events */
TP_HKEY_EV_ALARM_BAT_HOT= 0x6011, /* battery too hot */
@@ -3714,6 +3715,7 @@ static bool hotkey_notify_6xxx(const u32 hkey,
case TP_HKEY_EV_KEY_NUMLOCK:
case TP_HKEY_EV_KEY_FN:
+ case TP_HKEY_EV_KEY_FN_ESC:
/* key press events, we just ignore them as long as the EC
* is still reporting them in the normal keyboard stream */
*send_acpi_ev = false;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: tegra: Write xfer_mode, CMD regs in together
On 9 February 2015 at 07:22, Alexandre Courbot wrote:
> On Thu, Jan 29, 2015 at 1:30 AM, Rhyland Klein wrote:
>> On 1/28/2015 1:06 AM, Alexandre Courbot wrote:
>>> On Wed, Jan 28, 2015 at 2:23 AM, Rhyland Klein wrote:
From: Pavan Kunapuli
If there is a gap between xfer mode and command register writes,
tegra SDMMC controller can sometimes issue a spurious command before
the CMD register is written. To avoid this, these two registers need
to be written together in a single write operation.
Signed-off-by: Pavan Kunapuli
Signed-off-by: Rhyland Klein
---
drivers/mmc/host/sdhci-tegra.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c
b/drivers/mmc/host/sdhci-tegra.c
index 59797106af93..3d34de47e57e 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -41,6 +41,7 @@
#define NVQUIRK_DISABLE_SDR50 BIT(3)
#define NVQUIRK_DISABLE_SDR104 BIT(4)
#define NVQUIRK_DISABLE_DDR50 BIT(5)
+#define NVQUIRK_SHADOW_XFER_MODE_REG BIT(6)
struct sdhci_tegra_soc_data {
const struct sdhci_pltfm_data *pdata;
@@ -67,6 +68,32 @@ static u16 tegra_sdhci_readw(struct sdhci_host *host,
int reg)
return readw(host->ioaddr + reg);
}
+static void tegra_sdhci_writew(struct sdhci_host *host, u16 val, int reg)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_tegra *tegra_host = pltfm_host->priv;
+ const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
+
+ if (soc_data->nvquirks * NVQUIRK_SHADOW_XFER_MODE_REG) {
>>>
>>> Isn't the '*' supposed to be a '&' here?
>>
>> Yah .. not sure how that happened, but it should be '&' good catch.
>>
>>>
+ switch (reg) {
+ case SDHCI_TRANSFER_MODE:
+ /*
+* Postpone this write, we must do it together
with a
+* command write that is down below.
+*/
+ pltfm_host->xfer_mode_shadow = val;
+ return;
+ case SDHCI_COMMAND:
+ writel((val << 16) | pltfm_host->xfer_mode_shadow,
+ host->ioaddr + SDHCI_TRANSFER_MODE);
+ pltfm_host->xfer_mode_shadow = 0;
>>>
>>> That last line is probably not needed and could actually be harmful -
>>> if we try to write SDHCI_COMMAND twice in a raw without a write to
>>> SDHCI_TRANSFER_MODE in between, the zero will overwrite the previous
>>> value of SDHCI_TRANSFER_MODE.
>>
>> True, will remove it.
>>
>>>
+ return;
+ }
+ }
+
+ writew(val, host->ioaddr + reg);
+}
+
static void tegra_sdhci_writel(struct sdhci_host *host, u32 val, int reg)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -147,6 +174,7 @@ static void tegra_sdhci_set_bus_width(struct
sdhci_host *host, int bus_width)
static const struct sdhci_ops tegra_sdhci_ops = {
.get_ro = tegra_sdhci_get_ro,
.read_w = tegra_sdhci_readw,
+ .write_w= tegra_sdhci_writew,
.write_l= tegra_sdhci_writel,
.set_clock = sdhci_set_clock,
.set_bus_width = tegra_sdhci_set_bus_width,
@@ -201,7 +229,8 @@ static struct sdhci_tegra_soc_data soc_data_tegra114 =
{
.pdata = _tegra114_pdata,
.nvquirks = NVQUIRK_DISABLE_SDR50 |
NVQUIRK_DISABLE_DDR50 |
- NVQUIRK_DISABLE_SDR104,
+ NVQUIRK_DISABLE_SDR104 |
+ NVQUIRK_SHADOW_XFER_MODE_REG,
};
>>>
>>> Since this only applies to Tegra114 (?), I wonder whether it would not
>>> be better to have a dedicated tegra114_sdhci_ops that implements
>>> tegra_sdhci_writew, and use it only in tegra_sdhci_writew. That way
>>> you could get rid of the NVQUIRK_SHADOW_XFER_MODE_REG and the test for
>>> it in tegra_sdhci_writew(), and chips prior to Tegra114 will not have
>>> to needlessly check for it every time they write a register.
>>
>> The reason I did it this way, is that this doesn't explicitly just apply
>> to T114. It actually applies to T114, T124 and T132. In that case, I
>> think it makes sense to keep the QUIRK and I can update the commit
>> description to reflect that.
>
> All the same, I don't see what advantage we have checking for that
> condition for every single write while we could simply set the right
> function to use at probe time?
The above seems like a reasonable optimization to do!
Now, since $subject patch has been
Re: [PATCH v3 04/20] power_supply: sysfs: Use power_supply_*() API for accessing function attrs
On pon, 2015-02-09 at 20:02 +0100, Stefan Wahren wrote: > Hi Krzysztof, > > > Krzysztof Kozlowski hat am 30. Januar 2015 um > > 15:47 > > geschrieben: > > > > > > Replace direct calls to power supply function attributes with wrappers. > > Wrappers provide safe access in case of unregistering the power > > supply (e.g. by removing the driver). Replace: > > - get_property -> power_supply_get_property > > - set_property -> power_supply_set_property > > - property_is_writeable -> power_supply_property_is_writeable > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Jonghwa Lee > > just a nit. It looks like a typo in the mail address which is also in patch 5 > - > 10. Right, I copied it directly from Jonghwa's response. Thank you for noticing it. > > I applied patch 1 - 14 to my repo with a upcoming power driver (mxs_power) and > didn't see any problems with your patches. Great, thanks! Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 2/5] mfd: AXP20x: Add bindings documentation
On Mon, Feb 2, 2015 at 4:53 PM, Lee Jones wrote: > On Sat, 31 Jan 2015, Chen-Yu Tsai wrote: > >> Hi Lee, >> >> On Thu, Jan 22, 2015 at 5:02 PM, Lee Jones wrote: >> > On Thu, 22 Jan 2015, Chen-Yu Tsai wrote: >> > >> >> From: Carlo Caione >> >> >> >> Bindings documentation for the AXP20x driver. In this file also >> >> sub-nodes are documented. >> >> >> >> Signed-off-by: Carlo Caione >> >> Acked-by: Maxime Ripard >> >> [w...@csie.org: clarify interrupt source for the axp PMIC] >> >> [w...@csie.org: explain dcdc-workmode in detail and trim lines to 80 >> >> chars] >> >> [w...@csie.org: make regulator supplies optional if using unregulated >> >> input] >> >> [w...@csie.org: use cubieboard2 regulator nodes as example] >> >> [w...@csie.org: change dcdc-workmode to dcdc-workmode-pwm boolean >> >> property] >> >> [w...@csie.org: use clock-frequency for dcdc regulator work frequency] >> >> Signed-off-by: Chen-Yu Tsai >> >> --- >> >> Documentation/devicetree/bindings/mfd/axp20x.txt | 102 >> >> +++ >> >> 1 file changed, 102 insertions(+) >> >> create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt >> > >> > This looks okay to me now. >> > >> > If Mark is happy with the remainder, I'll merge this. >> >> So Mark is not happy with this actually, for a few reasons: >> >> 1. The driver was already merged a couple versions back, and >>we have been using the dcdc-freq binding. >> >> 2. Furthermore, the dcdc-freq binding has nothing to do with >>the common clock framework. Using the clock-frequencies >>binding implies it does. >> >> 3. The change from a integer value to a boolean flag for >>dcdc-mode makes it less capable, i.e. the kernel can't >>just accept the current state of the hardware, which >>should be a valid option for regulators to not screw >>up the system accidentally. >> >> Any chance you could merge the previous version (v8)? > > You'll have to re-send it as v10 and obtain Acks in the normal way. OK. Before I do, would it be easier on you and Mark to have separate binding files for the mfd and regulator bits? I noticed a few PMICs have separate files. Thanks ChenYu >> > For my own reference: >> > Acked-by: Lee Jones >> > >> >> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt >> >> b/Documentation/devicetree/bindings/mfd/axp20x.txt >> >> new file mode 100644 >> >> index ..c3c80db242c7 >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt >> >> @@ -0,0 +1,102 @@ >> >> +AXP202/AXP209 device tree bindings >> >> + >> >> +The axp20x family current members : >> >> +axp202 (X-Powers) >> >> +axp209 (X-Powers) >> >> + >> >> +Required properties: >> >> +- compatible: "x-powers,axp202" or "x-powers,axp209" >> >> +- reg: The I2C slave address for the AXP chip >> >> +- interrupt-parent: The parent interrupt controller >> >> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin >> >> +- interrupt-controller: axp20x has its own internal IRQs >> >> +- #interrupt-cells: Should be set to 1 >> >> +- regulators: A node that houses a sub-node for each regulator. The >> >> regulators >> >> + are bound using their name as listed here: dcdc2, dcdc3, ldo1, >> >> + ldo2, ldo3, ldo4, ldo5. The bindings details of individual >> >> + regulator device can be found in: >> >> + Documentation/devicetree/bindings/regulator/regulator.txt with >> >> + the exception of x-powers,dcdc-freq. Regulators not used >> >> should >> >> + still be listed for completeness and that the regulator >> >> subsystem >> >> + properly registers them. >> >> + >> >> +Optional properties: >> >> +- regulator supplies - may be omitted if inputs are unregulated, such as >> >> using >> >> +the IPSOUT output from the PMIC >> >> + - acin-supply: The input supply for LDO1 >> >> + - vin2-supply: The input supply for DCDC2 >> >> + - vin3-supply: The input supply for DCDC3 >> >> + - ldo24in-supply: The input supply for LDO2, LDO4 >> >> + - ldo3in-supply: The input supply for LDO3 >> >> + - ldo5in-supply: The input supply for LDO5 >> >> + >> >> +Optional properties for regulators node: >> >> +- clock-frequency: defines the work frequency of DC-DC regulators >> >> +(range: 750kHz - 1875kHz). Default: 1.5MHz >> >> + >> >> +Optional properties for DCDC regulators: >> >> +- x-powers,dcdc-workmode-pwm: Force the DCDC regulators to run in PWM >> >> mode >> >> + The DCDC regulators rormally work in a mixed >> >> + PWM/PFM mode, using PFM under light loads and >> >> + switching to PWM for heavier loads. Forcing >> >> + PWM mode trades efficiency under light loads >> >> + for lower output noise. This probably makes >> >> + sense for HiFi audio related applications that
[RESEND][PATCH v2] ntp: Fixup adjtimex freq validation on 32bit systems
For tip/timers/urgent
Additional validation of adjtimex freq values to avoid
potential multiplication overflows were added in commit
5e5aeb4367b (time: adjtimex: Validate the ADJ_FREQUENCY values)
Unfortunately the patch used LONG_MAX/MIN instead of
LLONG_MAX/MIN, which was fine on 64bit systems, but being
much smaller on 32bit systems caused false positives
resulting in most direct frequency adjustments to fail w/
EINVAL.
ntpd only does direct frequency adjustments at startup, so
the issue was not as easily observed there, but other time
sync applications like ptpd and chrony were more effected by
the bug.
See bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=92481
https://bugzilla.redhat.com/show_bug.cgi?id=1188074
This patch changes the checks to use LLONG_MAX for
clarity, and additionally the checks are disabled
on 32bit systems since LLONG_MAX/PPM_SCALE is always
larger then the 32bit long freq value, so mult
overflows aren't possible there.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Sasha Levin
Cc: sta...@vger.kernel.org
Reported-by: Josh Boyer
Reported-by: George Joseph
Tested-by: George Joseph
Signed-off-by: John Stultz
---
v2: Included the BITS_PER_LONG check to disable
the check on 32bit systems, since it generates
build warnings in some settings.
kernel/time/ntp.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 4b585e0..35b25d0 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -633,10 +633,14 @@ int ntp_validate_timex(struct timex *txc)
if ((txc->modes & ADJ_SETOFFSET) && (!capable(CAP_SYS_TIME)))
return -EPERM;
- if (txc->modes & ADJ_FREQUENCY) {
- if (LONG_MIN / PPM_SCALE > txc->freq)
+ /*
+* Check for potential mult overflows that can
+* only happen on 64bit systems.
+*/
+ if ((txc->modes & ADJ_FREQUENCY) && (BITS_PER_LONG == 64)) {
+ if (LLONG_MIN / PPM_SCALE > txc->freq)
return -EINVAL;
- if (LONG_MAX / PPM_SCALE < txc->freq)
+ if (LLONG_MAX / PPM_SCALE < txc->freq)
return -EINVAL;
}
--
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: [LKP] [sched/core] 9edfbfed3f5: +88.2% hackbench.time.involuntary_context_switches
Hi,
On Mon, Feb 09, 2015 at 09:31:20AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 09, 2015 at 01:58:33PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
> > commit 9edfbfed3f544a7830d99b341f0c175995a02950 ("sched/core: Rework
> > rq->clock update skips")
> >
> >
> > testbox/testcase/testparams: xps2/hackbench/performance-1600%-process-socket
> >
> > cebde6d681aa45f9 9edfbfed3f544a7830d99b341f
> > --
> > %stddev %change %stddev
> > \ |\
> >1839273 ± 6% +88.2%3462337 ± 4%
> > hackbench.time.involuntary_context_switches
> > 41965851 ± 5% +5.6% 44307403 ± 1%
> > hackbench.time.voluntary_context_switches
> >388 ± 39% -58.6%160 ± 10%
> > sched_debug.cfs_rq[1]:/.tg_load_contrib
> > 12957 ± 14% -60.5% 5117 ± 11%
> > sched_debug.cfs_rq[2]:/.tg_load_avg
> > 30505 ± 14% -57.7% 12905 ± 6%
> > sched_debug.cfs_rq[3]:/.tg_load_avg
> > 2790 ± 24% -65.4%964 ± 32%
> > sched_debug.cfs_rq[3]:/.blocked_load_avg
> > 2915 ± 23% -62.2% 1101 ± 29%
> > sched_debug.cfs_rq[3]:/.tg_load_contrib
> >1839273 ± 6% +88.2%3462337 ± 4%
> > time.involuntary_context_switches
> > 1474 ± 28% -61.7%565 ± 43%
> > sched_debug.cfs_rq[2]:/.tg_load_contrib
> > 11830 ± 15% +63.0% 19285 ± 11% sched_debug.cpu#4.sched_goidle
> > 19319 ± 29% +91.1% 36913 ± 7% sched_debug.cpu#3.sched_goidle
> > 5899 ± 31% -35.6% 3801 ± 11%
> > sched_debug.cfs_rq[4]:/.blocked_load_avg
> > 5999 ± 30% -34.5% 3929 ± 11%
> > sched_debug.cfs_rq[4]:/.tg_load_contrib
> > 37884 ± 13% -33.5% 25207 ± 7%
> > sched_debug.cfs_rq[4]:/.tg_load_avg
> > 229547 ± 5% +47.9% 339519 ± 5% cpuidle.C1-NHM.usage
> > 35712 ± 3% +31.7% 47036 ± 9% cpuidle.C3-NHM.usage
> > 5010 ± 9% -29.0% 3556 ± 20%
> > sched_debug.cfs_rq[6]:/.blocked_load_avg
> > 5139 ± 9% -28.2% 3690 ± 19%
> > sched_debug.cfs_rq[6]:/.tg_load_contrib
> > 49568 ± 6% +24.8% 61867 ± 7% sched_debug.cpu#1.sched_goidle
> > 26369 ± 35% -42.0% 15289 ± 29% cpuidle.C6-NHM.usage
> > 18 ± 16% +36.5% 25 ± 7% sched_debug.cpu#4.nr_running
> > 1.41 ± 12% -19.3% 1.14 ± 13%
> > perf-profile.cpu-cycles.sock_wfree.unix_destruct_scm.skb_release_head_state.skb_release_all.consume_skb
> > 25 ± 15% +28.7% 32 ± 9% sched_debug.cpu#3.nr_running
> > 1.63 ± 11% -18.0% 1.34 ± 12%
> > perf-profile.cpu-cycles.unix_destruct_scm.skb_release_head_state.skb_release_all.consume_skb.unix_stream_recvmsg
> > 0.57 ± 8% +9.6% 0.62 ± 5% turbostat.CPU%c1
> >148 ± 11% -16.7%123 ± 7% sched_debug.cfs_rq[1]:/.load
> >109 ± 6% +17.1%128 ± 6% sched_debug.cpu#6.cpu_load[0]
> > 2.41 ± 8% -13.3% 2.09 ± 11%
> > perf-profile.cpu-cycles.skb_release_head_state.skb_release_all.consume_skb.unix_stream_recvmsg.sock_aio_read
> >147 ± 12% -16.4%123 ± 7% sched_debug.cpu#1.load
> >111 ± 5% +15.4%129 ± 5% sched_debug.cpu#6.cpu_load[2]
> >110 ± 5% +14.9%127 ± 5%
> > sched_debug.cfs_rq[6]:/.runnable_load_avg
> >112 ± 5% +14.5%128 ± 4% sched_debug.cpu#6.cpu_load[3]
> >113 ± 5% +13.2%128 ± 3% sched_debug.cpu#6.cpu_load[4]
> > 789953 ± 2% -10.8% 704528 ± 4% sched_debug.cpu#3.avg_idle
> > 15471 ± 5% -7.7% 14278 ± 2% sched_debug.cpu#5.curr->pid
> >2675106 ± 10% +16.2%3109411 ± 1% sched_debug.cpu#4.nr_switches
> >2675140 ± 10% +16.2%3109440 ± 1% sched_debug.cpu#4.sched_count
> > 155201 ± 5% +14.6% 177901 ± 3% softirqs.RCU
> > 8.64 ± 6% -9.6% 7.82 ± 5%
> > perf-profile.cpu-cycles.skb_release_all.consume_skb.unix_stream_recvmsg.sock_aio_read.sock_aio_read
> >2658351 ± 11% +13.7%3021564 ± 2% sched_debug.cpu#5.sched_count
> >2658326 ± 11% +13.7%3021539 ± 2% sched_debug.cpu#5.nr_switches
> > 71443 ± 5% +9.9% 78486 ± 0% vmstat.system.cs
> > 8209 ± 5% +7.3% 8805 ± 0% vmstat.system.in
> >
>
> OK, so the interesting number is total runtime; I cannot find it.
> Therefore I cannot say what if anything changed. This is just a bunch of
> random numbers afaict.
The total runtime of hackbench in v3.19 compared to v3.15 to v3.18 is
shown here [1] (Group 5 -> linux_perf.hackbench). It is not the same
project so the profiling data is not related and not recorded. The
results should be reproducable by simply running hackbench with the same
Re: [PATCH 3.18 00/39] 3.18.7-stable review
On Mon, Feb 9, 2015 at 5:02 PM, Sedat Dilek wrote: > On Mon, Feb 9, 2015 at 4:58 PM, Sedat Dilek wrote: >> On Mon, Feb 9, 2015 at 4:44 PM, Greg Kroah-Hartman >> wrote: >>> On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote: Hi Greg, nice to see the kbuild and trace patches I was involved are in this series. Unfortunately, I see the following in my logs... [2.117022] Request for unknown module key 'Magrathea: Glacier signing key: 009aa341bb673735a51dc34b238a0ca481d68098' err -11 [2.117114] mii: module verification failed: signature and/or required key missing - tainting kernel Not sure whom to CC. I CCed Jeff as he worked on MII. Signing key ---> Dave Howells? Attached are my kernel-config and dmesg output. Hope this helps. BTW, with v3.18.6 I haven't seen such output. >>> >>> Any way you could take the patches at >>> https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/ >>> in the queue-3.18 directory and bisect them to see which patch causes >>> the problem? I don't see any obvious patch in this series that would be >>> the issue. >>> >> >> [ CC Dave Howells ] >> >> Unfortunately, I make-distclean-ed my build-dir. >> >> Is simply the sign-key missing? >> >>> mii: module verification failed: signature and/or required key missing < >> > > To name it's called "x509.genkey". > > From [1]: > > [ QUOTE ] > > Most notably, in the x509.genkey file, the req_distinguished_name section > should be altered from the default: > > [ req_distinguished_name ] > O = Magrathea > CN = Glacier signing key > emailAddress = slartibartfast@magrathea.h2g2 > > [ /QUOTE ] > > - Sedat - > > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/module-signing.txt#n118 > > >> Documentation/module-signing.txt lists Magrathea, so I CCed Dave. >> Let's see what he says before doing a git-bisect session. >> >> I wanted to trough out the complete module-signing kernel-options for >> a long time. >> For test kernels it is simply not needed here. >> >> Sorry, for resending my files - build-log is attached as a new file. >> >> Hope this helps. >> >> BTW, why is there no MII maintainer listed in MAINTAINERS? >> >> ( No clue what MII has to do with module-signing, can someone explain? ) >> >> - Sedat - >> >> P.S.: Check the logs for mii and x509 patterns. >> >> $ egrep 'mii|x509' build-log_3.18.7-rc1-1-iniza-small.txt >> ASN.1 crypto/asymmetric_keys/x509-asn1.c >> ASN.1 crypto/asymmetric_keys/x509_rsakey-asn1.c >> CC crypto/asymmetric_keys/x509_public_key.o >> CC crypto/asymmetric_keys/x509-asn1.o >> CC crypto/asymmetric_keys/x509_rsakey-asn1.o >> CC crypto/asymmetric_keys/x509_cert_parser.o >> LD crypto/asymmetric_keys/x509_key_parser.o >> -batch -x509 -config x509.genkey \ >> -outform DER -out signing_key.x509 \ >> CERTS kernel/x509_certificate_list >> - Including cert ./signing_key.x509 >> CC [M] drivers/net/mii.o >> CC drivers/net/mii.mod.o >> LD [M] drivers/net/mii.ko >> INSTALL drivers/net/mii.ko >> >> - EOT - I have rebuilt a -2 kernel and take care that the x509 files are shipped... $ LC_ALL=C ll x509-files_3.18.7-rc1-2-iniza-small/*x509* -rw-r--r-- 1 wearefam wearefam 1446 Feb 10 08:02 x509-files_3.18.7-rc1-2-iniza-small/signing_key.x509 -rw-r--r-- 1 wearefam wearefam 372 Feb 10 08:01 x509-files_3.18.7-rc1-2-iniza-small/x509.genkey ...and the warnings are gone. So, indeed these files were missing or one of them. - Sedat - [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.18.7-rc1-2-iniza-small (sedat.di...@gmail.com@fambox) (gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~12.04) ) #1 SMP Tue Feb 10 08:14:20 CET 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.7-rc1-2-iniza-small root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable [0.00] BIOS-e820: [mem
Re: [RFC PATCH 0/9] livepatch: consistency model
On Mon, 9 Feb 2015, Josh Poimboeuf wrote: > > The way how do detect whether given CPU is running in userspace > > (without interfering with it too much, like, say, sending costly IPI) > > is rather tricky though. On kernels with CONFIG_CONTEXT_TRACKING we > > could make use of that feature, but my gut feeling is that most people > > keep that disabled. > Yeah, that seems to be related to nohz. I think we'd have to have it > enabled 100% of the time on all CPUs, even when not patching. Sounds > like a lot of unnecessary overhead (unless the user already has it > enabled on all CPUs). Agreed, we could make use of it when it's enabled in kernel config anyway, but it would be impractical for us to hard require it. > > Another alternative is what we are doing in kgraft with > > kgr_needs_lazy_migration(), but admittedly that's very far from being > > pretty. > > Hm, is it really safe to read a stack while the task could be writing to > it? It might indeed look like that on a first sight :) but let's look at the possible race scenarios: (1) task is running in userspace when you start looking at its kernel stack, and while you are examining it, it enters the kernel. That's not a problem, because no matter what verdict kgr_needs_lazy_migration() yields, the migration to new universe happens during kernel entry anyway (2) task is actively running in kernelspace. There is no way for print_context_stack() to result it that small number of nr_entries. The stack context might be bogus due to the race, but it always starts at a valid bp which can't be that low. (3) task is running in kernelspace, but is about to exit to userspace, and looking at the kernel stack races with this. That's again not a problem, because no matter what verdict kgr_needs_lazy_migration() yields, the migration to the new unuverse happens during kernel exit anyway So I agree that this is ugly as hell, and depends on architecture-specific implementation of print_context_stack(); but architectures are free to give up this optimization if it can't be used. But yes, we should be able to come up with something better if we want to use this optimization upstream. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Recommendations for a new MFD device driver?
On Fri, 06 Feb 2015, Sascha Hauer wrote: > Hi All, > > We are adding support for a new pretty typical MFD device, the MediaTek > MT6397. Initial patches are already posted. It's a PMIC which among other > things has regulators and a RTC. The same RTC is reused on another PMIC, > but with another register offset and another interrupt. > > Now the question is where shall we put the register/irq resource > information? > > 1) Put it into the RTC device driver. > 2) Put it into the .resource field of struct mfd_cell > 3) Put it into the device tree using standard reg, interrupt properties and >a) Let the RTC driver interpret these >b) Let the MFD driver create resources in the .resource field of struct > mfd_cell >c) Let the MFD core create the resources I have no problem with 2, if that's the route you'd like to take. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c-designware: fixup of wait_for_completion_timeout return handling
Hi
On 02/09/2015 06:35 PM, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int.
An appropriate return variable is introduced and assignment fixed up.
Signed-off-by: Nicholas Mc Guire
---
Patch was compile tested with x86_64_defconfig +
CONFIG_X86_AMD_PLATFORM_DEVICE=y, CONFIG_I2C_DESIGNWARE_PLATFORM=m
(implies CONFIG_I2C_DESIGNWARE_CORE=y)
Patch is against 3.19.0-rc7 (localversion-next is -next-20150209)
drivers/i2c/busses/i2c-designware-core.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 6e25c01..05934e0 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -623,6 +623,7 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
{
struct dw_i2c_dev *dev = i2c_get_adapdata(adap);
int ret;
+ unsigned int timeout;
Not unsigned long.
@@ -656,8 +657,8 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
i2c_dw_xfer_init(dev);
/* wait for tx to complete */
- ret = wait_for_completion_timeout(>cmd_complete, HZ);
- if (ret == 0) {
+ timeout = wait_for_completion_timeout(>cmd_complete, HZ);
+ if (timeout == 0) {
dev_err(dev->dev, "controller timed out\n");
/* i2c_dw_init implicitly disables the adapter */
i2c_dw_init(dev);
I'd say better to test directly with "if
(!wait_for_completion_timeout())" since remaining jiffies or potential
error code from wait_for_completion_timeout() is not used here.
--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add initial DT support for Qualcomm SPMI PMIC devices
On Tue, 2015-02-03 at 12:38 -0800, Bjorn Andersson wrote: > On Tue, Feb 3, 2015 at 4:17 AM, Ivan T. Ivanov wrote: > > Following set of patches add initial DT support for PMIC devices > > found on recent Quqalcomm chipsets. Details for SPMI bus and PMIC arbiter > > could be found here [1]. > > > > Regards, > > Ivan > > > > [1] http://lwn.net/Articles/564637/ > > > > Ivan T. Ivanov (3): > > ARM: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974 > > ARM: dts: qcom: Add 8x74 chipset SPMI PMIC's nodes > > ARM: dts: qcom: Add APQ8084 chipset SPMI PMIC's nodes > > > > Looks good. > > Reviewed-by: Bjorn Andersson anders...@sonymobile.com> > Thank you. Any other comments? Kumar? Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On Tue, 10 Feb 2015, Lee Jones wrote: > On Mon, 09 Feb 2015, Bjorn Andersson wrote: > > > On Thu, Jan 29, 2015 at 5:51 PM, Bjorn Andersson > > wrote: > > > Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings. > > > > > > Signed-off-by: Bjorn Andersson > > > --- > > > After discussing this back and forth we've concluded that we should be > > > future compatible with these bindings, so let's make an attempt to make > > > it possible to use the Qualcomm family A regulators. > > > > > > > ping? > > Pings don't work. If I haven't replied, there is a reason. > > I've been hectic at 'proper work' lately -- I'll get to you. In fact, this needs a DT Ack. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On Mon, 09 Feb 2015, Bjorn Andersson wrote: > On Thu, Jan 29, 2015 at 5:51 PM, Bjorn Andersson > wrote: > > Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings. > > > > Signed-off-by: Bjorn Andersson > > --- > > After discussing this back and forth we've concluded that we should be > > future compatible with these bindings, so let's make an attempt to make > > it possible to use the Qualcomm family A regulators. > > > > ping? Pings don't work. If I haven't replied, there is a reason. I've been hectic at 'proper work' lately -- I'll get to you. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC V2] test_bit before clear files_struct bits
add test_bit() before clear close_on_exec and open_fds,
by trace __clear_bit(), these 2 place are false in most times,
we test it so that we don't need clear_bit, and we can win
in most time.
Signed-off-by: Yalin Wang
---
fs/file.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index ee738ea..b0e059c 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -209,7 +209,8 @@ static inline void __set_close_on_exec(int fd, struct
fdtable *fdt)
static inline void __clear_close_on_exec(int fd, struct fdtable *fdt)
{
- __clear_bit(fd, fdt->close_on_exec);
+ if (test_bit(fd, fdt->close_on_exec))
+ __clear_bit(fd, fdt->close_on_exec);
}
static inline void __set_open_fd(int fd, struct fdtable *fdt)
@@ -309,7 +310,7 @@ struct files_struct *dup_fd(struct files_struct *oldf, int
*errorp)
struct file *f = *old_fds++;
if (f) {
get_file(f);
- } else {
+ } else if (test_bit(open_files - i, new_fdt->open_fds)) {
/*
* The fd may be claimed in the fd bitmap but not yet
* instantiated in the files array if a sibling thread
--
2.2.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: linux-next: Tree for Feb 9 (build failures)
Am 09.02.2015 um 18:20 schrieb Guenter Roeck: > On Mon, Feb 09, 2015 at 09:18:27PM +1100, Stephen Rothwell wrote: >> Hi all, >> >> Please oo not add any material destined for v3.21 to your linux-next >> included trees until after v3.20-rc1 has been released. >> > > Build failures: > > Building arm:efm32_defconfig ... failed > -- > Error log: > arm-poky-linux-gnueabi-ld: Text section oversize > > [ wonder if I need a new/different compiler ] > > --- > > Building mips:allmodconfig ... failed > -- > Error log: > > sound/soc/codecs/max98357a.c: In function 'max98357a_daiops_trigger': > sound/soc/codecs/max98357a.c:30:3: error: implicit declaration of function > 'gpiod_set_value' > sound/soc/codecs/max98357a.c: In function 'max98357a_codec_probe': > sound/soc/codecs/max98357a.c:55:2: error: implicit declaration of function > 'devm_gpiod_get' > sound/soc/codecs/max98357a.c:61:2: error: implicit declaration of function > 'gpiod_direction_output' > > Looks like this driver depends on GPIOLIB but does not select it, > and MIPS doesn't seem to support GPIOLIB. Missing dependencies ? > > --- > > Building sparc64:allmodconfig ... failed > -- > Error log: > asm9260_timer.c:(.init.text+0x60d4): undefined reference to > `of_io_request_and_map' The patch for this issue was send for two weeks: https://lkml.org/lkml/2015/1/31/21 Should i resend it? -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
[RFC] test_bit before clear files_struct bits
add test_bit() before clear close_on_exec and open_fds,
by trace __clear_bit(), these 2 place are false in most times,
we test it so that we don't need dirty cacheline, and we can win
in most time.
Signed-off-by: Yalin Wang
---
fs/file.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index ee738ea..2fd296b 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -209,7 +209,8 @@ static inline void __set_close_on_exec(int fd, struct
fdtable *fdt)
static inline void __clear_close_on_exec(int fd, struct fdtable *fdt)
{
- __clear_bit(fd, fdt->close_on_exec);
+ if (test_bit(fd, fdt->close_on_exec))
+ __clear_bit(fd, fdt->close_on_exec);
}
static inline void __set_open_fd(int fd, struct fdtable *fdt)
@@ -309,7 +310,7 @@ struct files_struct *dup_fd(struct files_struct *oldf, int
*errorp)
struct file *f = *old_fds++;
if (f) {
get_file(f);
- } else {
+ } else if (test_bit(open_files - i, new_fdt)) {
/*
* The fd may be claimed in the fd bitmap but not yet
* instantiated in the files array if a sibling thread
--
2.2.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: [RFC] change non-atomic bitops method
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Tuesday, February 10, 2015 4:34 AM
> To: Wang, Yalin
> Cc: 'Kirill A. Shutemov'; 'a...@arndb.de'; 'linux-a...@vger.kernel.org';
> 'linux-kernel@vger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
>
> On Mon, 9 Feb 2015 16:18:10 +0800 "Wang, Yalin"
> wrote:
>
> > > That we're running clear_bit against a cleared bit 10% of the time is a
> > > bit alarming. I wonder where that's coming from.
> > >
> > > The enormous miss count in test_and_clear_bit() might indicate an
> > > inefficiency somewhere.
> > I te-test the patch on 3.10 kernel.
> > The result like this:
> >
> > VmallocChunk: 251498164 kB
> > __set_bit_miss_count:11730 __set_bit_success_count:1036316
> > __clear_bit_miss_count:209640 __clear_bit_success_count:4806556
> > __test_and_set_bit_miss_count:0 __test_and_set_bit_success_count:121
> > __test_and_clear_bit_miss_count:0 __test_and_clear_bit_success_count:445
> >
> > __clear_bit miss rate is a little high,
> > I check the log, and most miss coming from this code:
> >
> > <6>[ 442.701798] [] warn_slowpath_fmt+0x4c/0x58
> > <6>[ 442.701805] [] __clear_bit+0x98/0xa4
> > <6>[ 442.701813] [] __alloc_fd+0xc8/0x124
> > <6>[ 442.701821] [] get_unused_fd_flags+0x28/0x34
> > <6>[ 442.701828] [] do_sys_open+0x10c/0x1c0
> > <6>[ 442.701835] [] SyS_openat+0xc/0x18
> > In __clear_close_on_exec(fd, fdt);
> >
> >
> >
> > <6>[ 442.695354] [] warn_slowpath_fmt+0x4c/0x58
> > <6>[ 442.695359] [] __clear_bit+0x98/0xa4
> > <6>[ 442.695367] [] dup_fd+0x1d4/0x280
> > <6>[ 442.695375] [] copy_process.part.56+0x42c/0xe38
> > <6>[ 442.695382] [] do_fork+0xe0/0x360
> > <6>[ 442.695389] [] SyS_clone+0x10/0x1c
> > In __clear_open_fd(open_files - i, new_fdt);
> >
> > Do we need test_bit() before clear_bit()at these 2 place?
>
> I don't know. I was happily typing in this:
>
> diff -puN include/linux/bitops.h~a include/linux/bitops.h
> --- a/include/linux/bitops.h~a
> +++ a/include/linux/bitops.h
> @@ -226,5 +226,37 @@ extern unsigned long find_last_bit(const
> unsigned long size);
> #endif
>
> +/**
> + * __set_clear_bit - non-atomically set a bit if it is presently clear
> + * @nr: The bit number
> + * @addr: The base address of the operation
> + *
> + * __set_clear_bit() and similar functions avoid unnecessarily dirtying a
> + * cacheline when the operation will have no effect.
> + */
> +static inline void __set_clear_bit(unsigned nr, volatile unsigned long
> *addr)
> +{
> + if (!test_bit(nr, addr))
> + __set_bit(nr, addr);
> +}
> +
> +static inline void __clear_set_bit(unsigned nr, volatile unsigned long
> *addr)
> +{
> + if (test_bit(nr, addr))
> + __clear_bit(nr, addr);
> +}
> +
> +static inline void set_clear_bit(unsigned nr, volatile unsigned long
> *addr)
> +{
> + if (!test_bit(nr, addr))
> + set_bit(nr, addr);
> +}
> +
> +static inline void clear_set_bit(unsigned nr, volatile unsigned long
> *addr)
> +{
> + if (test_bit(nr, addr))
> + clear_bit(nr, addr);
> +}
> +
> #endif /* __KERNEL__ */
> #endif
>
> (maybe __set_bit_if_clear would be a better name)
>
> But I don't know if it will do anything useful. The CPU *should* be
> able to avoid dirtying the cacheline on its own: it has all the info it
> needs to know that no writeback will be needed. But I don't know which
> (if any) CPUs perform this optimisation.
I will send a new patch for your review .
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] staging: unisys: remove unused variable
On Tue, Feb 10, 2015 at 02:34:15PM +0800, Greg Kroah-Hartman wrote: > On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote: > > Nothing to do on your side, I am on the road this week and will move > those to my -next branch right now, thanks for reminding me. welcome sir. If you ever need an assisstant (for reminding or for coding) you can count me in :) I can see that you are in HongKong now, please do let us know if you ever plan to be on the roads in India. I am sure all of us here will like to meet you. we can have a beer or two while learning few things from you. sudip > > 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/
Re: [PATCH] virtio_pci: use 16-bit accessor for queue_enable.
On Tue, Feb 10, 2015 at 05:05:01PM +1030, Rusty Russell wrote:
> Since PCI is little endian, 8-bit access might work, but the spec section
> is very clear on this:
>
> 4.1.3.1 Driver Requirements: PCI Device Layout
>
> The driver MUST access each field using the “natural” access method,
> i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit
> fields and 8-bit accesses for 8-bit fields.
>
> Signed-off-by: Rusty Russell
Acked-by: Michael S. Tsirkin
> diff --git a/drivers/virtio/virtio_pci_modern.c
> b/drivers/virtio/virtio_pci_modern.c
> index f16e462cb4ef..2aa38e59db2e 100644
> --- a/drivers/virtio/virtio_pci_modern.c
> +++ b/drivers/virtio/virtio_pci_modern.c
> @@ -294,7 +294,7 @@ static struct virtqueue *setup_vq(struct
> virtio_pci_device *vp_dev,
>
> /* Check if queue is either not available or already active. */
> num = ioread16(>queue_size);
> - if (!num || ioread8(>queue_enable))
> + if (!num || ioread16(>queue_enable))
> return ERR_PTR(-ENOENT);
>
> if (num & (num - 1)) {
> @@ -394,7 +394,7 @@ static int vp_modern_find_vqs(struct virtio_device *vdev,
> unsigned nvqs,
>*/
> list_for_each_entry(vq, >vqs, list) {
> iowrite16(vq->index, _dev->common->queue_select);
> - iowrite8(1, _dev->common->queue_enable);
> + iowrite16(1, _dev->common->queue_enable);
> }
>
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: set_freq: ntp_loopfilter.c line 955: invalid struct timex "constant" element value: 0
On Mon, Feb 9, 2015 at 10:57 PM, Toralf Förster wrote: > At a 32 bit Gentoo stable KVM machine I do realized since 3.19.0-rc6 : > > Feb 2 15:40:55 n22kvm kernel: [0.00] Linux version 3.19.0-rc6 > (root@n22kvm) (gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #9 SMP Fri > Jan 30 18:55:05 CET 2015 > Feb 2 15:41:17 n22kvm ntpd[1980]: set_freq: ntp_loopfilter.c line 955: > invalid struct timex "constant" element value: 0 Yes. That's a known issue with a fix that unfortunately missed the 3.19 release. An early version of the fix is in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=92481 thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v5 net-next 4/6] virtio-net: add basic interrupt coalescing support
On Tue, Feb 10, 2015 at 9:32 AM, Rusty Russell
wrote:
Jason Wang writes:
This patch enables the interrupt coalescing setting through ethtool.
The problem is that there's nothing network specific about interrupt
coalescing. I can see other devices wanting exactly the same thing,
which means we'd deprecate this in the next virtio standard.
I think the right answer is to extend like we did with
vring_used_event(), eg:
1) Add a new feature VIRTIO_F_RING_COALESCE.
2) Add another a 32-bit field after vring_used_event(), eg:
#define vring_used_delay(vr) (*(u32
*)((vr)->avail->ring[(vr)->num + 2]))
Yes. This looks better and we don't even need device specific
configuration method.
This loses the ability to coalesce by number of frames, but we can
still
do number of sg entries, as we do now with used_event, and we could
change virtqueue_enable_cb_delayed() to take a precise number if we
wanted.
Can we give a device specific meaning for this? For virtio-net, we want
to expose the coalescing settings through ethtool (tx-frames). And it
was usually used with a timer, so probably another field after
vring_used_delay() for this timer interval to trigger the interrupt if
no new used buffers come after this interval.
My feeling is that this should be a v1.0-only feature though
(eg. feature bit 33).
Yes it should.
Cheers,
Rusty.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c| 67
+
include/uapi/linux/virtio_net.h | 12
2 files changed, 79 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cc5f5de..2b958fb 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -145,6 +145,11 @@ struct virtnet_info {
/* Budget for polling tx completion */
u32 tx_work_limit;
+
+ __u32 rx_coalesce_usecs;
+ __u32 rx_max_coalesced_frames;
+ __u32 tx_coalesce_usecs;
+ __u32 tx_max_coalesced_frames;
};
struct padded_vnet_hdr {
@@ -1404,12 +1409,73 @@ static void virtnet_get_channels(struct
net_device *dev,
channels->other_count = 0;
}
+static int virtnet_set_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ec)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct scatterlist sg;
+ struct virtio_net_ctrl_coalesce c;
+
+ if (!vi->has_cvq ||
+ !virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_COALESCE))
+ return -EOPNOTSUPP;
+ if (vi->rx_coalesce_usecs != ec->rx_coalesce_usecs ||
+ vi->rx_max_coalesced_frames != ec->rx_max_coalesced_frames) {
+ c.coalesce_usecs = ec->rx_coalesce_usecs;
+ c.max_coalesced_frames = ec->rx_max_coalesced_frames;
+ sg_init_one(, , sizeof(c));
+ if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_COALESCE,
+VIRTIO_NET_CTRL_COALESCE_RX_SET,
+)) {
+ dev_warn(>dev, "Fail to set rx coalescing\n");
+ return -EINVAL;
+ }
+ vi->rx_coalesce_usecs = ec->rx_coalesce_usecs;
+ vi->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
+ }
+
+ if (vi->tx_coalesce_usecs != ec->tx_coalesce_usecs ||
+ vi->tx_max_coalesced_frames != ec->tx_max_coalesced_frames) {
+ c.coalesce_usecs = ec->tx_coalesce_usecs;
+ c.max_coalesced_frames = ec->tx_max_coalesced_frames;
+ sg_init_one(, , sizeof(c));
+ if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_COALESCE,
+VIRTIO_NET_CTRL_COALESCE_TX_SET,
+)) {
+ dev_warn(>dev, "Fail to set tx coalescing\n");
+ return -EINVAL;
+ }
+ vi->tx_coalesce_usecs = ec->tx_coalesce_usecs;
+ vi->tx_max_coalesced_frames = ec->tx_max_coalesced_frames;
+ }
+
+ vi->tx_work_limit = ec->tx_max_coalesced_frames_irq;
+
+ return 0;
+}
+
+static int virtnet_get_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ec)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ ec->rx_coalesce_usecs = vi->rx_coalesce_usecs;
+ ec->rx_max_coalesced_frames = vi->rx_max_coalesced_frames;
+ ec->tx_coalesce_usecs = vi->tx_coalesce_usecs;
+ ec->tx_max_coalesced_frames = vi->tx_max_coalesced_frames;
+ ec->tx_max_coalesced_frames_irq = vi->tx_work_limit;
+
+ return 0;
+}
+
static const struct ethtool_ops virtnet_ethtool_ops = {
.get_drvinfo = virtnet_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_ringparam = virtnet_get_ringparam,
.set_channels =
[PATCH] virtio_pci: use 16-bit accessor for queue_enable.
Since PCI is little endian, 8-bit access might work, but the spec section
is very clear on this:
4.1.3.1 Driver Requirements: PCI Device Layout
The driver MUST access each field using the “natural” access method,
i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit
fields and 8-bit accesses for 8-bit fields.
Signed-off-by: Rusty Russell
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index f16e462cb4ef..2aa38e59db2e 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -294,7 +294,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
/* Check if queue is either not available or already active. */
num = ioread16(>queue_size);
- if (!num || ioread8(>queue_enable))
+ if (!num || ioread16(>queue_enable))
return ERR_PTR(-ENOENT);
if (num & (num - 1)) {
@@ -394,7 +394,7 @@ static int vp_modern_find_vqs(struct virtio_device *vdev,
unsigned nvqs,
*/
list_for_each_entry(vq, >vqs, list) {
iowrite16(vq->index, _dev->common->queue_select);
- iowrite8(1, _dev->common->queue_enable);
+ iowrite16(1, _dev->common->queue_enable);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx
In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of PWMSS. The schematics and TRMs show that there is only one input clock to the PWMSS. But currently, tbclk is wrongly shown to be deriving from dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT. Fixing ehrpwm tbclk data to reflect the right clk source. Tested on beaglebone and am437x-gp-evm. Vignesh R (2): ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx arch/arm/boot/dts/am33xx-clocks.dtsi | 6 +++--- arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes: 9e100ebafb91: ("Fix ehrpwm tbclk data")
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/am33xx-clocks.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 712edce7d6fb..071b56aa0c7e 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -99,7 +99,7 @@
ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <0>;
reg = <0x0664>;
};
@@ -107,7 +107,7 @@
ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <1>;
reg = <0x0664>;
};
@@ -115,7 +115,7 @@
ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <2>;
reg = <0x0664>;
};
--
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 2/2] ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes: 4da1c67719f61 ("add tbclk data for ehrpwm")
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index c7dc9dab93a4..cfb49686ab6a 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -107,7 +107,7 @@
ehrpwm0_tbclk: ehrpwm0_tbclk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <0>;
reg = <0x0664>;
};
@@ -115,7 +115,7 @@
ehrpwm1_tbclk: ehrpwm1_tbclk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <1>;
reg = <0x0664>;
};
@@ -123,7 +123,7 @@
ehrpwm2_tbclk: ehrpwm2_tbclk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <2>;
reg = <0x0664>;
};
@@ -131,7 +131,7 @@
ehrpwm3_tbclk: ehrpwm3_tbclk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <4>;
reg = <0x0664>;
};
@@ -139,7 +139,7 @@
ehrpwm4_tbclk: ehrpwm4_tbclk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <5>;
reg = <0x0664>;
};
@@ -147,7 +147,7 @@
ehrpwm5_tbclk: ehrpwm5_tbclk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <_per_m2_ck>;
+ clocks = <_gclk>;
ti,bit-shift = <6>;
reg = <0x0664>;
};
--
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/2] staging: unisys: remove unused variable
On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote: > > > if you want I can add an extra From: line, but Dan has already given his > > > commments for that at https://lkml.org/lkml/2014/9/3/135 > > > quoting him : > > > > > > "If everyone starts using From headers like this then it becomes a pain > > > to deal with." > > > > It's not a pain to deal with on my end at all. > > > > But as I've missed this in the past, nevermind, I'll take it as is. Can > > you resend your outstanding patches and I'll queue them up after > > 3.20-rc1 is out. > i will resend them now or should i send after the merge window closes? You can send patches any time, I'll batch them up and apply them to my trees at the proper time. > and on 07th feb you have added my two patches to staging-testing, but > it still is not in linux-next, do i need to resend them also or they > are in process so nothing to do from my side? Nothing to do on your side, I am on the road this week and will move those to my -next branch right now, thanks for reminding me. 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/
Re: [PATCH RFC v5 net-next 1/6] virtio_ring: fix virtqueue_enable_cb() when only 1 buffers were pending
On Tue, Feb 10, 2015 at 9:03 AM, Rusty Russell
wrote:
Jason Wang writes:
We currently does:
bufs = (avail->idx - last_used_idx) * 3 / 4;
This is ok now since we only try to enable the delayed callbacks
when
the queue is about to be full. This may not work well when there is
only one pending buffer in the virtqueue (this may be the case after
tx interrupt was enabled). Since virtqueue_enable_cb() will return
false which may cause unnecessary triggering of napis. This patch
correct this by only calculate the four thirds when bufs is not one.
I mildly prefer to avoid the branch, by changing the calculation like
so:
/* Set bufs >= 1, even if there's only one pending buffer */
bufs = (bufs + 1) * 3 / 4;
Ok.
But it's not clear to me how much this happens.
Depends on the traffic type. In some case e.g one session TCP_RR test
(which has at most 1 pending packet), it may happen very often.
I'm happy with the
patch though, as currently virtqueue_enable_cb_delayed() is the same
as virtqueue_enable_cb() if there's only been one buffer added.
Yes. Thanks.
Cheers,
Rusty.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_ring.c
b/drivers/virtio/virtio_ring.c
index 00ec6b3..545fed5 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -636,7 +636,10 @@ bool virtqueue_enable_cb_delayed(struct
virtqueue *_vq)
* entry. Always do both to keep code simple. */
vq->vring.avail->flags &= cpu_to_virtio16(_vq->vdev,
~VRING_AVAIL_F_NO_INTERRUPT);
/* TODO: tune this threshold */
- bufs = (u16)(virtio16_to_cpu(_vq->vdev, vq->vring.avail->idx) -
vq->last_used_idx) * 3 / 4;
+ bufs = (u16)(virtio16_to_cpu(_vq->vdev, vq->vring.avail->idx) -
+ vq->last_used_idx);
+ if (bufs != 1)
+ bufs = bufs * 3 / 4;
vring_used_event(>vring) = cpu_to_virtio16(_vq->vdev,
vq->last_used_idx + bufs);
virtio_mb(vq->weak_barriers);
if (unlikely((u16)(virtio16_to_cpu(_vq->vdev,
vq->vring.used->idx) - vq->last_used_idx) > bufs)) {
--
1.8.3.1
___
Virtualization mailing list
virtualizat...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: mmp: add GPIO driver for Marvell MMP series
On Tue, Feb 3, 2015 at 9:21 PM, Linus Walleij wrote: > On Wed, Jan 28, 2015 at 3:30 AM, Chao Xie wrote: > >> From: Chao Xie >> >> For some old PXA series, they used PXA GPIO driver. >> The IP of GPIO changes since PXA988 which is Marvell MMP >> series. >> It will use new way to control the GPIO level, direction >> and edge status. >> >> Signed-off-by: Chao Xie > > (...) > Just a silly question. What's the meaning of (...)? There're a lot of comments as (...). It's my first time to see this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [trivial PATCH] mod_devicetable.h: Make the definition of struct of_device_id easier to find
On Tue, 2015-02-10 at 00:11 -0600, Rob Herring wrote: > On Mon, Feb 9, 2015 at 9:26 PM, Joe Perches wrote: > > On Mon, 2015-02-09 at 19:35 -0600, Rob Herring wrote: > >> On Mon, Feb 9, 2015 at 3:15 PM, Joe Perches wrote: > >> > Move the open brace so the definition matches the more > >> > common kernel style. This makes grep a bit easier. > > > > Hey Rob. > > > >> I've got the same fix in -next for 3.20 already: > > > > Then you should push that change to Stephen's -next > > 'cause it's not there. > > Huh? I just double checked that it is in fact in 20150209. It is in next-20150209, but not in anything earlier. That'd might have been in _your_ branch, but it wasn't in linux-next as of 20150204 when I made that patch. You should make sure that Stephen merges the right branch and not want for the Linus' tagged release. There's no real reason I can see for you to wait to push your -next branch immediately. cheers, Joe $ git checkout next-20150204 HEAD is now at 29d56e4... Add linux-next specific files for 20150209 $ git log --pretty=oneline include/linux/mod_devicetable.h 32357605ce7bcd36cb6215a21cad12cd8f51b74e USB: Add missing word to comment in mod_devicetable.h de869917c663f44b5b032bff238bad22e15dda56 mod_devicetable.h: grammar fix in comment c4586256f0c440bc2bdb29d2cbb915f0ca785d26 x86: LLVMLinux: Fix "incomplete type const struct x86cpu_device_id" 158e0d3621683ee0cdfeeba56f0e5ddd97ae984f Merge tag 'driver-core-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core 3764e82e5150d87b205c10cd78a9c9ab86fbfa51 drivers: Introduce MEN Chameleon Bus 67bad2fdb754dbef14596c0b5d28b3a12c8dfe84 cpu: add generic support for CPU feature based module autoloading 5a86bf343976b9c8ab2f240bc866451fa67e5573 spmi: Linux driver framework for SPMI b04c99e3b845892d754ee8052d6324c39c4040de Revert "Input: introduce BTN/ABS bits for drums and guitars" 63faf15dba4a7d6fb18ed5c45670a152d0c5330b Merge branches 'for-3.12/devm', 'for-3.12/i2c-hid', 'for-3.12/i2c-hid-dt', 'for-3.12/logitech', 'for-3. 61e00655e9cb82e034eb72b95a51072e718d14a7 Input: introduce BTN/ABS bits for drums and guitars b01a60be7a4a161ac0a11df30569d21a20795aef ssb: fix alignment of struct bcma_device_id 3bdbb62fe97537252b22f79863eeb51aa750 rapidio: add udev notification 5017b2851373ee15c7035151853bb1448800cae2 dmi: add support for exact DMI matches in addition to substring matching e5354107e14755991da82e0d2a4791db92908d9d mei: bus: Initial MEI Client bus type implementation 6543becf26fff612cdadeed7250ccc8d49f67f27 mod/file2alias: make modalias generation safe for cross compiling -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] Add another clock for use with the soft lockup watchdog.
On 01/09/2015 11:34 AM, Cyril Bur wrote:
> This permits the use of arch specific clocks for which virtualised kernels can
> use their notion of 'running' time, not the elpased wall time which will
s/elpased/elapsed/
thanks
chai wen
> include host execution time.
>
> Signed-off-by: Cyril Bur
> ---
> V2:
>Remove the export of running_clock
>Use local_clock instead of sched_clock as was initally used in the
> softlockup detector
>
> ---
> include/linux/sched.h | 1 +
> kernel/sched/clock.c | 13 +
> kernel/watchdog.c | 2 +-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8db31ef..e400162 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2145,6 +2145,7 @@ extern unsigned long long notrace sched_clock(void);
> */
> extern u64 cpu_clock(int cpu);
> extern u64 local_clock(void);
> +extern u64 running_clock(void);
> extern u64 sched_clock_cpu(int cpu);
>
>
> diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> index c27e4f8..c0a2051 100644
> --- a/kernel/sched/clock.c
> +++ b/kernel/sched/clock.c
> @@ -420,3 +420,16 @@ u64 local_clock(void)
>
> EXPORT_SYMBOL_GPL(cpu_clock);
> EXPORT_SYMBOL_GPL(local_clock);
> +
> +/*
> + * Running clock - returns the time that has elapsed while a guest has been
> + * running.
> + * On a guest this value should be local_clock minus the time the guest was
> + * suspended by the hypervisor (for any reason).
> + * On bare metal this function should return the same as local_clock.
> + * Architectures and sub-architectures can override this.
> + */
> +u64 __weak running_clock(void)
> +{
> + return local_clock();
> +}
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index 70bf118..3174bf8 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -154,7 +154,7 @@ static int get_softlockup_thresh(void)
> */
> static unsigned long get_timestamp(void)
> {
> - return local_clock() >> 30LL; /* 2^30 ~= 10^9 */
> + return running_clock() >> 30LL; /* 2^30 ~= 10^9 */
> }
>
> static void set_sample_period(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Loan Offer At 0.2%... Apply now
Guarantee and trusted loan at 0.2% to process a loan with us please send
Name:Country:Amount:Duration:Purpose For Loan:Phone Number:Loan Firm Loan
Offer at 0.2%. Contact us for more info.{financiersworldw...@rogers.com}
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: Add of_device_id to structs that should be const
On Mon, Feb 9, 2015 at 11:34 AM, Joe Perches wrote:
> Uses of struct of_device_id are most commonly const.
>
> Suggest using it as such.
>
> Signed-off-by: Joe Perches
Acked-by: Rob Herring
> ---
> scripts/checkpatch.pl | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3642b0d..368db0d 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5216,8 +5216,9 @@ sub process {
> "please use device_initcall() or more
> appropriate function instead of __initcall() (see include/linux/init.h)\n" .
> $herecurr);
> }
>
> -# check for various ops structs, ensure they are const.
> - my $struct_ops = qr{acpi_dock_ops|
> +# check for various structs that are normally const (ops, kgdb, device_tree)
> + my $const_structs = qr{
> + acpi_dock_ops|
> address_space_operations|
> backlight_ops|
> block_device_operations|
> @@ -5240,6 +5241,7 @@ sub process {
> mtrr_ops|
> neigh_ops|
> nlmsvc_binding|
> + of_device_id|
> pci_raw_ops|
> pipe_buf_operations|
> platform_hibernation_ops|
> @@ -5255,7 +5257,7 @@ sub process {
> usb_mon_operations|
> wd_ops}x;
> if ($line !~ /\bconst\b/ &&
> - $line =~ /\bstruct\s+($struct_ops)\b/) {
> + $line =~ /\bstruct\s+($const_structs)\b/) {
> WARN("CONST_STRUCT",
> "struct $1 should normally be const\n" .
> $herecurr);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [trivial PATCH] mod_devicetable.h: Make the definition of struct of_device_id easier to find
On Mon, Feb 9, 2015 at 9:26 PM, Joe Perches wrote: > On Mon, 2015-02-09 at 19:35 -0600, Rob Herring wrote: >> On Mon, Feb 9, 2015 at 3:15 PM, Joe Perches wrote: >> > Move the open brace so the definition matches the more >> > common kernel style. This makes grep a bit easier. > > Hey Rob. > >> I've got the same fix in -next for 3.20 already: > > Then you should push that change to Stephen's -next > 'cause it's not there. Huh? I just double checked that it is in fact in 20150209. Rob > >> commit 851c63e3b381fdbf5aca1a797f37d8606b5588d2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Mon, Feb 9, 2015 at 9:13 PM, Steven Rostedt wrote:
>> \
>> + if (prog) { \
>> + __maybe_unused const u64 z = 0; \
>> + struct bpf_context __ctx = ((struct bpf_context) { \
>> + __BPF_CAST6(args, z, z, z, z, z)\
>
> Note, there is no guarantee that args is at most 6. For example, in
> drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.h, the
> trace_event brcms_txstatus has 8 args.
>
> But I guess that's OK if you do not need those last args, right?
yeah, some tracepoints pass a lot of things.
That's rare and in most of the cases they can be fetched
from parent structure.
> I'm nervous about showing args of tracepoints too, because we don't want
> that to become a strict ABI either.
One can argue that current TP_printk format is already an ABI,
because somebody might be parsing the text output.
so in some cases we cannot change tracepoints without
somebody complaining that his tool broke.
In other cases tracepoints are used for debugging only
and no one will notice when they change...
It was and still a grey area.
bpf doesn't change any of that.
It actually makes addition of new tracepoints easier.
In the future we might add a tracepoint and pass a single
pointer to interesting data struct to it. bpf programs will walk
data structures 'as safe modules' via bpf_fetch*() methods
without exposing it as ABI.
whereas today we pass a lot of fields to tracepoints and
make all of these fields immutable.
To me tracepoints are like gdb breakpoints.
and bpf programs like live debugger that examine things.
the next step is to be able to write bpf scripts on the fly
without leaving debugger. Something like perf probe +
editor + live execution. Truly like gdb for kernel.
while kernel is running.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Mon, Feb 9, 2015 at 8:46 PM, Steven Rostedt wrote: > > Looks like this is entirely perf based and does not interact with > ftrace at all. In other words, it's perf not tracing. > > It makes more sense to go through tip than the tracing tree. well, all of earlier series were based on ftrace only, but I was given convincing enough arguments that perf_even_open+ioctl is a better interface :) Ok. will rebase on tip in the next version. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: qcom_bam_dma: Add support for BAM v1.7.0
On 01/22/2015 11:48 PM, Andy Gross wrote: On Thu, Jan 22, 2015 at 12:34:26PM +0530, Archit Taneja wrote: Add register offset table entry for the newer (v1.7.0) version of the BAM IP found on MSM8916. Update the DT bindings documentation. Signed-off-by: Archit Taneja --- Looks good. Reviewed-by: Andy Gross Reviewed-by: Stanimir Varbanov Vinod, is that one OK with you? If so could you merge it in your tree. regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-trace 4/8] samples: bpf: simple tracing example in C
On Mon, Feb 9, 2015 at 9:45 PM, Alexei Starovoitov wrote: > I thought we already stated that. > Here is the quote from perf_event.h: > * # The RAW record below is opaque data wrt the ABI > * # > * # That is, the ABI doesn't make any promises wrt to > * # the stability of its content, it may vary depending > * # on event, hardware, kernel version and phase of > * # the moon. > * # > * # In other words, PERF_SAMPLE_RAW contents are not an ABI. > > and this example is reading PERF_SAMPLE_RAW events and > uses locally defined structs to print them for simplicity. to underline my point once more: addition of bpf doesn't change at all what PERF_SAMPLE_RAW already delivers to user space. so no new ABIs anywhere. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-trace 4/8] samples: bpf: simple tracing example in C
On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt wrote: > On Mon, 9 Feb 2015 23:08:36 -0500 > Steven Rostedt wrote: > >> I don't want to get stuck with pinned kernel data structures again. We >> had 4 blank bytes of data for every event, because latency top hard >> coded the field. Luckily, the 64 bit / 32 bit interface caused latency >> top to have to use the event_parse code to work, and we were able to >> remove that field after it was converted. I think your main point boils down to: > But I still do not want any hard coded event structures. All access to > data from the binary code must be parsed by looking at the event/format > files. Otherwise you will lock internals of the kernel as userspace > ABI, because eBPF programs will break if those internals change, and > that could severely limit progress in the future. and I completely agree. the patch 4 is an example. It doesn't mean in any way that structs defined here is an ABI. To be compatible across kernels the user space must read format file as you mentioned in your other reply. > I'm wondering if we should label eBPF programs as "modules". That is, > they have no guarantee of working from one kernel to the next. They > execute in the kernel, thus they are very similar to modules. > > If we can get Linus to say that eBPF programs are not user space, and > that they are treated the same as modules (no internal ABI), then I > think we can be a bit more free at what we allow. I thought we already stated that. Here is the quote from perf_event.h: * # The RAW record below is opaque data wrt the ABI * # * # That is, the ABI doesn't make any promises wrt to * # the stability of its content, it may vary depending * # on event, hardware, kernel version and phase of * # the moon. * # * # In other words, PERF_SAMPLE_RAW contents are not an ABI. and this example is reading PERF_SAMPLE_RAW events and uses locally defined structs to print them for simplicity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
On 2/9/2015 9:34 PM, Florian Fainelli wrote: > Le 09/02/2015 21:24, Ray Jui a écrit : >> >> >> On 2/9/2015 4:11 AM, Wolfram Sang wrote: >>> On Sat, Feb 07, 2015 at 09:25:26PM -0800, Ray Jui wrote: Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep them disabled there. Individual I2C devices can be enabled in board specific dts file when I2C slave devices are enabled in the future Signed-off-by: Ray Jui Reviewed-by: Scott Branden Reviewed-by: Kevin Cernekee >>> >>> I usually don't take DTS patches. They should go via arm-soc. Please say >>> so if there are reasons I should take them. >>> >> Okay. I'll send this as an individual patch to arm-soc. > > Could you put in in a branch somewhere on github.comù/cygnus-linus.git > so it's easy for me to pull from there? > -- > Florian > Hi Florian, It's in branch cygnus-i2c-v9. Thanks! Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
Le 09/02/2015 21:24, Ray Jui a écrit : > > > On 2/9/2015 4:11 AM, Wolfram Sang wrote: >> On Sat, Feb 07, 2015 at 09:25:26PM -0800, Ray Jui wrote: >>> Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep >>> them disabled there. Individual I2C devices can be enabled in board >>> specific dts file when I2C slave devices are enabled in the future >>> >>> Signed-off-by: Ray Jui >>> Reviewed-by: Scott Branden >>> Reviewed-by: Kevin Cernekee >> >> I usually don't take DTS patches. They should go via arm-soc. Please say >> so if there are reasons I should take them. >> > Okay. I'll send this as an individual patch to arm-soc. Could you put in in a branch somewhere on github.comù/cygnus-linus.git so it's easy for me to pull from there? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: gpio-pxa: getting GPIOs by devicetree phandle broken
On Tue, Feb 10, 2015 at 2:38 AM, Robert Jarzmik wrote:
> Tyler Hall writes:
>
>>> The issue with multiple gpiochips per of-node could be worked around as
>>> followed I believe, comments?
>>>
>>> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
>>> index 08261f2..43984ab 100644
>>> --- a/drivers/gpio/gpiolib-of.c
>>> +++ b/drivers/gpio/gpiolib-of.c
>>> @@ -47,11 +47,12 @@ static int of_gpiochip_find_and_xlate(struct gpio_chip
>>> *gc, void *data)
>>> ret = gc->of_xlate(gc, _data->gpiospec, gg_data->flags);
>>> if (ret < 0) {
>>> /* We've found the gpio chip, but the translation failed.
>>> -* Return true to stop looking and return the translation
>>> -* error via out_gpio
>>> +* Store translation error in out_gpio.
>>> +* Return false to keep looking, as more than one GPIO chip
>>> +* could be registered per of-node.
>>> */
>>> gg_data->out_gpio = ERR_PTR(ret);
>>> - return true;
>>> + return false;
>>> }
>>>
>>> gg_data->out_gpio = gpiochip_get_desc(gc, ret);
>>
>> As long as we're ok with multiple gpiochips per of-node, this would
>> work for me. It'll change the preference of which chip returns the
>> error in the case of multiple chips, but that's already undefined
>> behavior.
>
> Looks good to me too, this will solve my issue, and the global behavior would
> be
> consistent with the former one.
>
> Would you care submitting a proper patch so that we can apply our Reviewed-by,
> Tested-by etc ... ?
Looks ok to me too, if only a little bit hackish. A patch would be
appreciated so we can send it for -fixes as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 5/6] toshiba_acpi: Add support to enable/disable USB 3
On Mon, Feb 09, 2015 at 08:55:52PM -0800, Darren Hart wrote: > I'd welcome the thoughts of the previous maintainers as to whether we want to > include these kinds of OS-parity changes in the kernel. I'm probably leaning > toward taking them. The only real thing is whether there's any way to create a generic interface for it. In this case, I suspect not and that this is fine. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
On 2/9/2015 4:11 AM, Wolfram Sang wrote: > On Sat, Feb 07, 2015 at 09:25:26PM -0800, Ray Jui wrote: >> Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep >> them disabled there. Individual I2C devices can be enabled in board >> specific dts file when I2C slave devices are enabled in the future >> >> Signed-off-by: Ray Jui >> Reviewed-by: Scott Branden >> Reviewed-by: Kevin Cernekee > > I usually don't take DTS patches. They should go via arm-soc. Please say > so if there are reasons I should take them. > Okay. I'll send this as an individual patch to arm-soc. Thanks, Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 2/9/2015 4:10 AM, Wolfram Sang wrote: > On Sat, Feb 07, 2015 at 09:25:25PM -0800, Ray Jui wrote: >> Add initial support to the Broadcom iProc I2C controller found in the >> iProc family of SoCs. >> >> The iProc I2C controller has separate internal TX and RX FIFOs, each has >> a size of 64 bytes. The iProc I2C controller supports two bus speeds >> including standard mode (100kHz) and fast mode (400kHz) >> >> Signed-off-by: Ray Jui >> Reviewed-by: Scott Branden >> Reviewed-by: Kevin Cernekee > > Applied to for-next, thanks! > > Next time, please send new patches as seperate threads, not as a reply > to the old series. > Thanks, Wolfram. I think I'm missing something here and would like to get it clarified, so I don't make the same mistake again in the future: I thought I've already sent these patches as a new thread, i.e., [PATCH v9 ...], isn't it? Thanks, Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: unisys: remove unused variable
On Tue, Feb 10, 2015 at 05:35:40AM +0800, Greg Kroah-Hartman wrote: > On Sun, Feb 08, 2015 at 04:31:07PM +0530, Sudip Mukherjee wrote: > > On Sat, Feb 07, 2015 at 05:22:16PM +0800, Greg Kroah-Hartman wrote: > > > On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote: > > > > we were getting lots of warnings about _tempresult set but not used. > > > > _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY > > > > which was again using another macro ISSUE_IO_EXTENDED_VMCALL. > > > > but the vallue assigned to it was never used. > > > > > > > > Signed-off-by: Sudip Mukherjee > > > > > > Your From: address, and this address don't match, so I can't take this > > > :( > > > > all my patches have been like this way, and you have taken them before :) > > the reason its like this way - (already discussed with Dan Carpenter, > > reference https://lkml.org/lkml/2014/9/3/473) > > > > we have strict DMARC check for the corporate mail server. DMARC = domain > > based message authentication. > > So the mail i sent reached all the list subscriber from a different server > > than our designated server, > > and as a result it is marked as spam in many places and I have already > > received a few complaints regarding that. > > > > so at https://lkml.org/lkml/2014/9/3/535 Dan said its ok for him, but > > depends on you if you want to accept. > > And since you have accepted all my patches before so i thought it is ok > > with you. > > I didn't notice it before, sorry. no problem. we all know how much busy you are .. :) > > > if you want I can add an extra From: line, but Dan has already given his > > commments for that at https://lkml.org/lkml/2014/9/3/135 > > quoting him : > > > > "If everyone starts using From headers like this then it becomes a pain to > > deal with." > > It's not a pain to deal with on my end at all. > > But as I've missed this in the past, nevermind, I'll take it as is. Can > you resend your outstanding patches and I'll queue them up after > 3.20-rc1 is out. i will resend them now or should i send after the merge window closes? and on 07th feb you have added my two patches to staging-testing, but it still is not in linux-next, do i need to resend them also or they are in process so nothing to do from my side? regards sudip > > 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/
Re: [PATCH v3] ASoC: atmel_ssc_dai: Allow more rates
Hi Peter,
On 02/09/2015 11:08 PM, Peter Rosin wrote:
From: Peter Rosin
When the SSC acts as BCK master, use a ratnum rule to limit
the rate instead of only doing the standard rates. When the SSC
acts as BCK slave, allow any BCK frequency up to the SSC master
clock, divided by either of 2, 3 or 6.
Put a cap at 384kHz. Who's /ever/ going to need more than that?
The divider of 2, 3 or 6 is selected based on the Serial Clock Ratio
Considerations section from the SSC documentation:
The Transmitter and the Receiver can be programmed to operate
with the clock signals provided on either the TK or RK pins.
This allows the SSC to support many slave-mode data transfers.
In this case, the maximum clock speed allowed on the RK pin is:
- Peripheral clock divided by 2 if Receiver Frame Synchro is input
- Peripheral clock divided by 3 if Receiver Frame Synchro is output
In addition, the maximum clock speed allowed on the TK pin is:
- Peripheral clock divided by 6 if Transmit Frame Synchro is input
- Peripheral clock divided by 2 if Transmit Frame Synchro is output
Signed-off-by: Peter Rosin
Thanks for your patch.
Acked-by: Bo Shen
---
sound/soc/atmel/atmel_ssc_dai.c | 111 +--
sound/soc/atmel/atmel_ssc_dai.h |1 +
2 files changed, 108 insertions(+), 4 deletions(-)
Changes since v2:
- Killed the 500ppm reduction. Just trust the nominal clock
rates of the given clocks.
- Don't multiply the given SSC clk rate by two to get to the
SSC master clock rate. That factor was the result of some
confusion on my part. The SSC clk *is* the SSC master clock.
Changes since v1:
- I have checked all Atmel datasheets I could get my hands on (and
that seemed relevant), and in every instance where they have
described the SSC, the description have the exact rate limitations
on the RK and TK pin that I have implemented here.
- Improved the comments.
- Rebased on top of the latest patches from Bo Chen.
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 379ac2a6ab16..6b8e64899205 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -187,6 +187,94 @@ static irqreturn_t atmel_ssc_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+/*
+ * When the bit clock is input, limit the maximum rate according to the
+ * Serial Clock Ratio Considerations section from the SSC documentation:
+ *
+ * The Transmitter and the Receiver can be programmed to operate
+ * with the clock signals provided on either the TK or RK pins.
+ * This allows the SSC to support many slave-mode data transfers.
+ * In this case, the maximum clock speed allowed on the RK pin is:
+ * - Peripheral clock divided by 2 if Receiver Frame Synchro is input
+ * - Peripheral clock divided by 3 if Receiver Frame Synchro is output
+ * In addition, the maximum clock speed allowed on the TK pin is:
+ * - Peripheral clock divided by 6 if Transmit Frame Synchro is input
+ * - Peripheral clock divided by 2 if Transmit Frame Synchro is output
+ *
+ * When the bit clock is output, limit the rate according to the
+ * SSC divider restrictions.
+ */
+static int atmel_ssc_hw_rule_rate(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct atmel_ssc_info *ssc_p = rule->private;
+ struct ssc_device *ssc = ssc_p->ssc;
+ struct snd_interval *i = hw_param_interval(params, rule->var);
+ struct snd_interval t;
+ struct snd_ratnum r = {
+ .den_min = 1,
+ .den_max = 4095,
+ .den_step = 1,
+ };
+ unsigned int num = 0, den = 0;
+ int frame_size;
+ int mck_div = 2;
+ int ret;
+
+ frame_size = snd_soc_params_to_frame_size(params);
+ if (frame_size < 0)
+ return frame_size;
+
+ switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFS:
+ if ((ssc_p->dir_mask & SSC_DIR_MASK_CAPTURE)
+ && ssc->clk_from_rk_pin)
+ /* Receiver Frame Synchro (i.e. capture)
+* is output (format is _CFS) and the RK pin
+* is used for input (format is _CBM_).
+*/
+ mck_div = 3;
+ break;
+
+ case SND_SOC_DAIFMT_CBM_CFM:
+ if ((ssc_p->dir_mask & SSC_DIR_MASK_PLAYBACK)
+ && !ssc->clk_from_rk_pin)
+ /* Transmit Frame Synchro (i.e. playback)
+* is input (format is _CFM) and the TK pin
+* is used for input (format _CBM_ but not
+* using the RK pin).
+*/
+ mck_div = 6;
+ break;
+ }
+
+ switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
+
Re: [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C
On Mon, 9 Feb 2015 23:08:36 -0500 Steven Rostedt wrote: > I don't want to get stuck with pinned kernel data structures again. We > had 4 blank bytes of data for every event, because latency top hard > coded the field. Luckily, the 64 bit / 32 bit interface caused latency > top to have to use the event_parse code to work, and we were able to > remove that field after it was converted. I'm wondering if we should label eBPF programs as "modules". That is, they have no guarantee of working from one kernel to the next. They execute in the kernel, thus they are very similar to modules. If we can get Linus to say that eBPF programs are not user space, and that they are treated the same as modules (no internal ABI), then I think we can be a bit more free at what we allow. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Mon, 9 Feb 2015 19:45:54 -0800
Alexei Starovoitov wrote:
> +/* For tracepoint filters argN fields match one to one to arguments
> + * passed to tracepoint events
> + *
> + * For syscall entry filters argN fields match syscall arguments
> + * For syscall exit filters arg1 is a return value
> + */
> +struct bpf_context {
> + u64 arg1;
> + u64 arg2;
> + u64 arg3;
> + u64 arg4;
> + u64 arg5;
> + u64 arg6;
> +};
> +
> +#endif /* _LINUX_KERNEL_BPF_TRACE_H */
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index 139b5067345b..4c275ce2dcf0 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -17,6 +17,7 @@
> */
>
> #include
> +#include
>
> /*
> * DECLARE_EVENT_CLASS can be used to add a generic function
> @@ -755,12 +756,32 @@ __attribute__((section("_ftrace_events")))
> *__event_##call = _##call
> #undef __perf_task
> #define __perf_task(t) (__task = (t))
>
> +/* zero extend integer, pointer or aggregate type to u64 without warnings */
> +#define __CAST_TO_U64(EXPR) ({ \
> + u64 ret = 0; \
> + typeof(EXPR) expr = EXPR; \
> + switch (sizeof(expr)) { \
> + case 8: ret = *(u64 *) break; \
> + case 4: ret = *(u32 *) break; \
> + case 2: ret = *(u16 *) break; \
> + case 1: ret = *(u8 *) break; \
> + } \
> + ret; })
> +
> +#define __BPF_CAST1(a,...) __CAST_TO_U64(a)
> +#define __BPF_CAST2(a,...) __CAST_TO_U64(a), __BPF_CAST1(__VA_ARGS__)
> +#define __BPF_CAST3(a,...) __CAST_TO_U64(a), __BPF_CAST2(__VA_ARGS__)
> +#define __BPF_CAST4(a,...) __CAST_TO_U64(a), __BPF_CAST3(__VA_ARGS__)
> +#define __BPF_CAST5(a,...) __CAST_TO_U64(a), __BPF_CAST4(__VA_ARGS__)
> +#define __BPF_CAST6(a,...) __CAST_TO_U64(a), __BPF_CAST5(__VA_ARGS__)
> +
> #undef DECLARE_EVENT_CLASS
> #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print)
> \
> static notrace void \
> perf_trace_##call(void *__data, proto)
> \
> {\
> struct ftrace_event_call *event_call = __data; \
> + struct bpf_prog *prog = event_call->prog; \
> struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
> struct ftrace_raw_##call *entry;\
> struct pt_regs __regs; \
> @@ -771,6 +792,16 @@ perf_trace_##call(void *__data, proto)
> \
> int __data_size;\
> int rctx; \
> \
> + if (prog) { \
> + __maybe_unused const u64 z = 0; \
> + struct bpf_context __ctx = ((struct bpf_context) { \
> + __BPF_CAST6(args, z, z, z, z, z)\
Note, there is no guarantee that args is at most 6. For example, in
drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.h, the
trace_event brcms_txstatus has 8 args.
But I guess that's OK if you do not need those last args, right?
Also, there's no interface the lets us know what the args are. I may be
able to come up with something. That's the reason I never filtered
before tracing. Because we had no way of knowing what to filter on,
because the args were never visible.
I'm nervous about showing args of tracepoints too, because we don't want
that to become a strict ABI either.
-- Steve
> + }); \
> + \
> + if (!trace_call_bpf(prog, &__ctx)) \
> + return; \
> + } \
> + \
> __data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/18] sync opal.h with firmware
Michael Ellerman writes: > I'm going to be a total pain, and suggest that this is the wrong approach :) > > I was on board until patch 15, where you have to add an #ifdef SKIBOOT to > guard > an include, and you have to remove an include on the Linux side. (the Linux include was actually not used it seems) > I think the better solution would be to pull all the common parts out into a > new file, opal-api.h. That file would define the API between Linux & Skiboot, > and absolutely nothing else. Sounds fine. > Both Linux and Skiboot would continue to have an opal.h, which would include > opal-api.h, and then anything else needed on either side to make a functioning > opal.h - eg. other includes & definitions (SG_ENTRIES_PER_NODE). > > It would also have the advantage that because opal-api.h is a new file, we can > get it synced from the beginning and not worry about all the whitespace & > rearranging patches. ie. there'd just be one patch on both sides to add the > new > file and move definitions into it from opal.h. Sure. I was doing it bit by bit just so that it was reviewable that I didn't miss anything or violently screw anything up. Plus, there were things that should be changed in skiboot as well. > If you don't violently disagree I'll do a patch for that and we can see how it > looks? Not violently :) I'd go back and do a similar thing to skiboot to make them match again though, having linux/opal-api.h match skiboot/opal.h would just cause swearing fits :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 5/6] toshiba_acpi: Add support to enable/disable USB 3
Hi Darren, 2015-02-09 21:55 GMT-07:00 Darren Hart : > On Mon, Feb 09, 2015 at 09:46:07PM -0700, Azael Avalos wrote: >> Hi Darren, >> >> 2015-02-09 21:11 GMT-07:00 Darren Hart : >> > On Mon, Feb 09, 2015 at 08:34:53PM -0700, Azael Avalos wrote: >> >> Toshiba laptops that come with USB 3 ports have a feature that lets >> >> them disable USB 3 functionality and act as a regular USB 2 port, and >> >> thus, saving power. >> >> >> >> This patch adds support to that feature, by creating a sysfs entry >> >> named "usb_three", acceptig only two parameters, 0 to disable the >> >> USB 3 (acting as a USB 2) and 1 to enable it. >> >> >> > >> > Similar question, does the system BIOS allow you to configure this >> > setting? If >> > so, what would be the value for enabling it in the OS directly? >> >> Yes. > > Yes it's available in the BIOS? Yes, it is available in the BIOS, sorry for not making that clear. > >> A Toshiba provided app lets you configure all these parameters from Windows, >> and so, I'm developing a similar app for this, a few clicks and your >> settings are >> changed on the next reboot :-) >> > > And I understand now that independent of the BIOS question, Windows has a > program to make these changes. Blech. Going to think on these overnight and > get > back to you. > > I'd welcome the thoughts of the previous maintainers as to whether we want to > include these kinds of OS-parity changes in the kernel. I'm probably leaning > toward taking them. Just let me know as to send a refreshed set of patches. > > Matthew, Len, is there some kind of precedent I need to be aware of here? > > -- > Darren Hart > Intel Open Source Technology Center Cheers Azael -- -- El mundo apesta y vosotros apestais tambien -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] toshiba_acpi: Make toshiba_eco_mode_available more robust
Hi Darren, 2015-02-09 21:22 GMT-07:00 Darren Hart : > On Mon, Feb 09, 2015 at 08:55:02PM -0700, Azael Avalos wrote: >> Some Toshiba laptops do not come with the ECO led installed, however, >> the driver is registering support for it when it should not. >> >> This patch makes the toshiba_eco_mode_available function more robust >> in detecting ECO led capabilities, not registering the led on laptops >> that do not support it and registering the led when it really does. >> >> The ECO led function now returns 0x8e00 (Not Installed) by querying >> with in[3] = 0, whenever theres no physical LED installed, and >> returning 0x8300 (Input Data Error) when it is, however, there are >> some BIOSes that have stub function calls not returning anything and >> and the LED device was being registered too, hence the change of the >> default return value from 1 to 0. >> >> Signed-off-by: Azael Avalos > > Careful with whitespace errors caught by checkpatch. Fixed that and corrected > a minor > grammatical issue in the comment block - since I was late in reviewing ;-) Apologies for that, between my bit of dyslexia (I tend to switch numbers and letters) and my bad English... Good thing I'm not working at a bank or stock exchange ;-) > > Applied and queued, thanks. > > -- > Darren Hart > Intel Open Source Technology Center Cheers Azael -- -- El mundo apesta y vosotros apestais tambien -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 5/6] toshiba_acpi: Add support to enable/disable USB 3
On Mon, Feb 09, 2015 at 09:46:07PM -0700, Azael Avalos wrote: > Hi Darren, > > 2015-02-09 21:11 GMT-07:00 Darren Hart : > > On Mon, Feb 09, 2015 at 08:34:53PM -0700, Azael Avalos wrote: > >> Toshiba laptops that come with USB 3 ports have a feature that lets > >> them disable USB 3 functionality and act as a regular USB 2 port, and > >> thus, saving power. > >> > >> This patch adds support to that feature, by creating a sysfs entry > >> named "usb_three", acceptig only two parameters, 0 to disable the > >> USB 3 (acting as a USB 2) and 1 to enable it. > >> > > > > Similar question, does the system BIOS allow you to configure this setting? > > If > > so, what would be the value for enabling it in the OS directly? > > Yes. Yes it's available in the BIOS? > A Toshiba provided app lets you configure all these parameters from Windows, > and so, I'm developing a similar app for this, a few clicks and your > settings are > changed on the next reboot :-) > And I understand now that independent of the BIOS question, Windows has a program to make these changes. Blech. Going to think on these overnight and get back to you. I'd welcome the thoughts of the previous maintainers as to whether we want to include these kinds of OS-parity changes in the kernel. I'm probably leaning toward taking them. Matthew, Len, is there some kind of precedent I need to be aware of here? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT] Networking
From: Linus Torvalds
Date: Mon, 9 Feb 2015 20:37:13 -0800
> It's a NULL pointer derefernce (at offset 0x18) where the callchain
> looks like this:
>
> RIP: skcipher_recvmsg+0x360/0x410
> Call Trace:
> sock_read_iter+0xd0/0x120
> new_sync_read+0x79/0xb0
> __vfs_read+0x13/0x50
> SyS_read+0x41/0x0b0
> system_call_fastpath
>
> which I assume is related to the iov_iter conversion.
>
> That oops then is followed immediately by another that is a NULL
> pointer dereference in skcipher_sock_destruct, but the callchain for
> that is just the exit as part of killing of the original oops, so that
> second oops seems to be just a result of the first one.
>
> I'm assuming the culrpit is 1d10eb2f156f ("crypto: switch
> af_alg_make_sg() to iov_iter") but haven't tested.
I think the handling of the 'used' local variable for function
skcipher_recvmsg() in that commit is suspect.
The problem is that if we go to the skcipher_wait_for_data() code
path, ctx->used is updated.
But the way skcipher_recvmsg() is was changed, that update won't
propagate into the caller because the old ctx->used value is cached in
the local 'used' variable.
The fix could be as simple as:
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 37110fd..4d1c315 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -444,6 +444,7 @@ static int skcipher_recvmsg(struct kiocb *unused, struct
socket *sock,
err = skcipher_wait_for_data(sk, flags);
if (err)
goto unlock;
+ used = ctx->used;
}
used = min_t(unsigned long, used,
iov_iter_count(>msg_iter));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] epoll: introduce EPOLLEXCLUSIVE and EPOLLROUNDROBIN
Jason Baron wrote: > On 02/09/2015 05:45 PM, Andy Lutomirski wrote: > > On Mon, Feb 9, 2015 at 1:32 PM, Jason Baron wrote: > >> On 02/09/2015 03:18 PM, Andy Lutomirski wrote: > >>> On 02/09/2015 12:06 PM, Jason Baron wrote: > Epoll file descriptors that are added to a shared wakeup source are > always > added in a non-exclusive manner. That means that when we have multiple > epoll > fds attached to a shared wakeup source they are all woken up. This can > lead to excessive cpu usage and uneven load distribution. > > This patch introduces two new 'events' flags that are intended to be used > with EPOLL_CTL_ADD operations. EPOLLEXCLUSIVE, adds the epoll fd to the > event > source in an exclusive manner such that the minimum number of threads are > woken. EPOLLROUNDROBIN, which depends on EPOLLEXCLUSIVE also being set, > can > also be added to the 'events' flag, such that we round robin around the > set > of waiting threads. > > An implementation note is that in the epoll wakeup routine, > 'ep_poll_callback()', if EPOLLROUNDROBIN is set, we return 1, for a > successful > wakeup, only when there are current waiters. The idea is to use this > additional > heuristic in order minimize wakeup latencies. > >>> I don't understand what this is intended to do. > >>> > >>> If an event has EPOLLONESHOT, then this only one thread should be woken > >>> regardless, right? If not, isn't that just a bug that should be fixed? > >>> > >> hmm...so with EPOLLONESHOT you basically get notified once about an event. > >> If i have multiple epoll fds (say 1 per-thread) attached to a single > >> source in EPOLLONESHOT, then all threads will potentially get woken up > >> once per event. Then, I would have to re-arm all of them. So I don't think > >> this addresses this particular usecase...what I am trying to avoid is this > >> mass wakeup or thundering herd for a shared event source. > > Now I understand. Why are you using multiple epollfds? > > > > --Andy > > So the multiple epollfds is really a way to partition the set of > events. Otherwise, I have all the threads contending on all the events > that are being generated. So I'm not sure if that is scalable. I wonder if EPOLLONESHOT + epoll_wait with a sufficiently large maxevents value is sufficient for you. All events would be shared, so they can migrate between threads(*). Each thread takes a largish set of events on every epoll_wait call and doesn't call epoll_wait again until it's done with the whole set it got. You'll hit more contention on EPOLL_CTL_MOD with shared events and a single epoll, but I think it's a better goal to make that lock-free. (*) Too large a maxevents will lead to head-of-line blocking, but from what I'm inferring, you already risk that with multiple epollfds and separate threads working on them. Do you have a userland use case to share? > In the use-case I'm trying to describe, I've partitioned a large set > of the events, but there may still be some event sources that we wish > to share among all of the threads (or even subsets of them), so as not > to overload any one in particular. > More specifically, in the case of a single listen socket, its natural > to call accept() on the thread that has been woken up, but without > doing round robin, you quickly get into a very unbalanced load, and in > addition you waste a lot of cpu doing unnecessary wakeups. There are > other approaches to solve this, specifically using SO_REUSEPORT, which > creates a separate socket per-thread and gets one back to the > separately partitioned events case previously described. However, > SO_REUSEPORT, I believe is very specific to tcp/udp, and in addition > does not have knowledge of the threads that are actively waiting as > the epoll code does. Did you try my suggestion of using a dedicated thread (or thread pool) which does nothing but loop on accept() + EPOLL_CTL_ADD? Those dedicated threads could do its own round-robin in userland to pick a different epollfd to call EPOLL_CTL_ADD on. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 5/6] toshiba_acpi: Add support to enable/disable USB 3
Hi Darren, 2015-02-09 21:11 GMT-07:00 Darren Hart : > On Mon, Feb 09, 2015 at 08:34:53PM -0700, Azael Avalos wrote: >> Toshiba laptops that come with USB 3 ports have a feature that lets >> them disable USB 3 functionality and act as a regular USB 2 port, and >> thus, saving power. >> >> This patch adds support to that feature, by creating a sysfs entry >> named "usb_three", acceptig only two parameters, 0 to disable the >> USB 3 (acting as a USB 2) and 1 to enable it. >> > > Similar question, does the system BIOS allow you to configure this setting? If > so, what would be the value for enabling it in the OS directly? Yes. A Toshiba provided app lets you configure all these parameters from Windows, and so, I'm developing a similar app for this, a few clicks and your settings are changed on the next reboot :-) > > -- > Darren Hart > Intel Open Source Technology Center Cheers Azael -- -- El mundo apesta y vosotros apestais tambien -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Mon, 9 Feb 2015 19:45:54 -0800
Alexei Starovoitov wrote:
> +#endif /* _LINUX_KERNEL_BPF_TRACE_H */
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index 139b5067345b..4c275ce2dcf0 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -17,6 +17,7 @@
> */
>
> #include
> +#include
>
> /*
> * DECLARE_EVENT_CLASS can be used to add a generic function
> @@ -755,12 +756,32 @@ __attribute__((section("_ftrace_events")))
> *__event_##call = _##call
> #undef __perf_task
> #define __perf_task(t) (__task = (t))
>
> +/* zero extend integer, pointer or aggregate type to u64 without warnings */
> +#define __CAST_TO_U64(EXPR) ({ \
> + u64 ret = 0; \
> + typeof(EXPR) expr = EXPR; \
> + switch (sizeof(expr)) { \
> + case 8: ret = *(u64 *) break; \
> + case 4: ret = *(u32 *) break; \
> + case 2: ret = *(u16 *) break; \
> + case 1: ret = *(u8 *) break; \
> + } \
> + ret; })
> +
> +#define __BPF_CAST1(a,...) __CAST_TO_U64(a)
> +#define __BPF_CAST2(a,...) __CAST_TO_U64(a), __BPF_CAST1(__VA_ARGS__)
> +#define __BPF_CAST3(a,...) __CAST_TO_U64(a), __BPF_CAST2(__VA_ARGS__)
> +#define __BPF_CAST4(a,...) __CAST_TO_U64(a), __BPF_CAST3(__VA_ARGS__)
> +#define __BPF_CAST5(a,...) __CAST_TO_U64(a), __BPF_CAST4(__VA_ARGS__)
> +#define __BPF_CAST6(a,...) __CAST_TO_U64(a), __BPF_CAST5(__VA_ARGS__)
> +
> #undef DECLARE_EVENT_CLASS
> #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print)
> \
> static notrace void \
> perf_trace_##call(void *__data, proto)
> \
> {\
> struct ftrace_event_call *event_call = __data; \
> + struct bpf_prog *prog = event_call->prog; \
Looks like this is entirely perf based and does not interact with
ftrace at all. In other words, it's perf not tracing.
It makes more sense to go through tip than the tracing tree.
But I still do not want any hard coded event structures. All access to
data from the binary code must be parsed by looking at the event/format
files. Otherwise you will lock internals of the kernel as userspace
ABI, because eBPF programs will break if those internals change, and
that could severely limit progress in the future.
-- Steve
> struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
> struct ftrace_raw_##call *entry;\
> struct pt_regs __regs; \
> @@ -771,6 +792,16 @@ perf_trace_##call(void *__data, proto)
> \
> int __data_size;\
> int rctx; \
> \
> + if (prog) { \
> + __maybe_unused const u64 z = 0; \
> + struct bpf_context __ctx = ((struct bpf_context) { \
> + __BPF_CAST6(args, z, z, z, z, z)\
> + }); \
> + \
> + if (!trace_call_bpf(prog, &__ctx)) \
> + return; \
> + } \
> + \
> __data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
> \
> head = this_cpu_ptr(event_call->perf_events); \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: hwpoison: drop lru_add_drain_all() in __soft_offline_page()
A race condition starts to be visible in recent mmotm, where a PG_hwpoison
flag is set on a migration source page *before* it's back in buddy page pool.
This is problematic because no page flag is supposed to be set when freeing
(see __free_one_page().) So the user-visible effect of this race is that it
could trigger the BUG_ON() when soft-offlining is called.
The root cause is that we call lru_add_drain_all() to make sure that the
page is in buddy, but that doesn't work because this function just schedules
a work item and doesn't wait its completion. drain_all_pages() does draining
directly, so simply dropping lru_add_drain_all() solves this problem.
Fixes: commit f15bdfa802bf ("mm/memory-failure.c: fix memory leak in successful
soft offlining")
Signed-off-by: Naoya Horiguchi
Cc: [3.11+]
---
mm/memory-failure.c | 2 --
1 file changed, 2 deletions(-)
diff --git mmotm-2015-02-03-16-38.orig/mm/memory-failure.c
mmotm-2015-02-03-16-38/mm/memory-failure.c
index b2a68bde8058..fa44054c205f 100644
--- mmotm-2015-02-03-16-38.orig/mm/memory-failure.c
+++ mmotm-2015-02-03-16-38/mm/memory-failure.c
@@ -1647,8 +1647,6 @@ static int __soft_offline_page(struct page *page, int
flags)
* setting PG_hwpoison.
*/
if (!is_free_buddy_page(page))
- lru_add_drain_all();
- if (!is_free_buddy_page(page))
drain_all_pages(page_zone(page));
SetPageHWPoison(page);
if (!is_free_buddy_page(page))
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 3/6] toshiba_acpi: Add support for Keyboard functions mode
Hi Darren,
2015-02-09 21:08 GMT-07:00 Darren Hart :
> On Mon, Feb 09, 2015 at 08:34:51PM -0700, Azael Avalos wrote:
>> Recent Toshiba laptops that come with the new keyboard layout have
>> the Special Functions (hotkeys) enabled by default, which, in order to
>> access the F{1-12} keys, you need to press the FN-F{1-12} key to
>> access such key.
>>
>> This patch adds support to toggle the Keyboard Functions operation
>> mode by creating the sysfs entry "kbd_functions_keys", accepting only
>> two parameters, 0 to set the "Normal Operation" mode and 1 to set the
>> "Special Functions" mode, however, everytime the mode is toggled, a
>> restart is needed.
>
> Erm... that's kinda horrible :-/
>
> A couple of questions then.
>
> 1) Does the system BIOS offer a way to select one mode or the other? If so, no
> point in adding it here if a reboot is required.
Yes, I just wanted to make the driver on Linux on par with its Windows
counterpart.
>
> 2) Where Toshiba supports this (Windows?) is a reboot required?
Windows 7 and up, and yes, a reboot is required on Windows too.
>
> Rather than having to reboot, would a userspace mapping possibly be
> preferable?
> Could be done without a reboot.
Nope, it sets some value into a BIOS variable (register?), not even
unloading/loading
the module helps.
>
> Finally, if we keep this, we need to print something to the system log
> indicating success - and that a reboot is required to take effect.
Sure, that's no problem, its your call to keep it or drop it, just let me know
as to send an updated version.
>
> --
> Darren Hart
> Intel Open Source Technology Center
Cheers
Azael
--
-- El mundo apesta y vosotros apestais tambien --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT] Networking
On Mon, Feb 9, 2015 at 7:16 PM, David Miller wrote:
>
> 1) More iov_iter conversion work from Al Viro.
> ...
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
I pulled, but had to unpull.
This doesn't work for me AT ALL.
I get an oops early during boot (in "systemd-cryptse.." - it happens
immediately after typing in my disk encryption key so it's
possible/likely that you need an md-crypt setup to see this).
It's a NULL pointer derefernce (at offset 0x18) where the callchain
looks like this:
RIP: skcipher_recvmsg+0x360/0x410
Call Trace:
sock_read_iter+0xd0/0x120
new_sync_read+0x79/0xb0
__vfs_read+0x13/0x50
SyS_read+0x41/0x0b0
system_call_fastpath
which I assume is related to the iov_iter conversion.
That oops then is followed immediately by another that is a NULL
pointer dereference in skcipher_sock_destruct, but the callchain for
that is just the exit as part of killing of the original oops, so that
second oops seems to be just a result of the first one.
I'm assuming the culrpit is 1d10eb2f156f ("crypto: switch
af_alg_make_sg() to iov_iter") but haven't tested.
Sorry for the lack of full dmesg, but the oops happens before the
system is actually usable, so I just have a camera screenshot of it.
Any ideas?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 mtd] mtd:devices: Add Altera EPCQ Driver
Sorry for multiple emails.
On Mon, Feb 9, 2015 at 2:42 PM, Viet Nga Dao wrote:
> Please ignore previous 2 emails of mine ^^
>
> On Thu, Feb 5, 2015 at 4:37 AM, Brian Norris
> wrote:
>> On Tue, Jan 27, 2015 at 02:53:59PM +0800, Viet Nga Dao wrote:
>>> On Tue, Jan 20, 2015 at 10:05 AM, Viet Nga Dao wrote:
>>> > On Thu, Jan 15, 2015 at 5:27 PM, Viet Nga Dao wrote:
>>> >> On Tue, Jan 13, 2015 at 11:33 AM, Brian Norris
>>> >> wrote:
>>> >>> On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote:
>>> From: Viet Nga Dao
>>
>>> >> That is why if rewrite the drivers to follow spi-nor structure, it
>>> >> will require extra decoding works for the only few used opcodes.
>>> >>
>>> >I think you'd only have some very trivial work here.
>>> >
>>> >There would be some small work to reintroduce a properly-replaceable ID
>>> >table, and callbacks like ->lock() and ->unlock(), but those should be
>>> >implemented in spi-nor.c sooner or later anyway.
>>> >
>>>
>>> I am trying to modify the code to follow your recommendation. However,
>>> for lock and unlock functions, i have to implement it in spi_nor.c ,
>>> am i right? If yes, currently we already have existing spi_nor_lock
>>> and spi_nor_unlock functions but they could not apply for my driver.
>>> Should i create a new functions named altera_epcq_lock and unlock and
>>> then map it to callback functions or i should the put those code
>>> sunder existing spi_nor_lock/unlock?
>>
>> We probably want a replaceable spi_nor callback that does the
>> flash-specific unlock. spi_nor_lock/unlock would then call the
>> nor->unlock() / nor->lock() functions for you, when present.
>> Some of the existing code should move into their own spi_nor_st_lock() /
>> spi_nor_st_unlock() functions.
>>
>
> This changes will be made by me or maintainers? If current this
> functions are not supported, i decide not to implement my lock, unlock
> function as well.
>
I made the changes at my side here. However, there are something i
want to confirm with you:
- in spi-nor.h, i add 2 functions. _lock and _unlock instead of lock
and unlock. It is because we already have struct mutex lock with the
same name.
int (*_lock)(struct spi_nor *nor, loff_t offs, uint64_t len);
int (*_unlock)(struct spi_nor *nor, loff_t offs, uint64_t len);
- in spi-nor.c, i change the current spi_nor_lock and spi_nor_unlock
to stmicro_spi_nor_lock and stmirco_spi_nor_unlock
- in spi-nor.c, i add 2 functions:
static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret = 0;
ret = spi_nor_lock_and_prep(nor, SPI_NOR_OPS_LOCK);
if (ret)
return ret;
/* Wait until finished previous command */
ret = wait_till_ready(nor);
if (ret)
goto err;
ret = nor->_lock(nor, ofs, len);
err:
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK);
return ret;
}
static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret = 0;
ret = spi_nor_lock_and_prep(nor, SPI_NOR_OPS_LOCK);
if (ret)
return ret;
/* Wait until finished previous command */
ret = wait_till_ready(nor);
if (ret)
goto err;
ret = nor->_unlock(nor, ofs, len);
err:
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK);
return ret;
}
- Then under spi_nor_scan function, i add these few lines:
/* nor protection support for STmicro chips */
if (JEDEC_MFR(info->jedec_id) == CFI_MFR_ST) {
mtd->_lock = stmicro_spi_nor_lock;
mtd->_unlock = stmicro_spi_nor_unlock;
} else {
mtd->_lock = spi_nor_lock;
mtd->_unlock = spi_nor_unlock;
}
What is your comment?
>>> diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>>> b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>>> new file mode 100644
>>> index 000..d14f50e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>>> @@ -0,0 +1,45 @@
>>> +* MTD Altera EPCQ driver
>>> +
>>> +Required properties:
>>> +- compatible: Should be "altr,epcq-1.0"
>>> +- reg: Address and length of the register set for the device. It
>>> contains
>>> + the information of registers in the same order as described by
>>> reg-names
>>> +- reg-names: Should contain the reg names
>>> + "csr_base": Should contain the register configuration base address
>>> + "data_base": Should contain the data base address
>>> +- is-epcs: boolean type.
>>> + If present, the device contains EPCS flashes.
>>> + Otherwise, it contains EPCQ flashes.
>>> +- #address-cells: Must be <1>.
>>> +- #size-cells: Must be <0>.
>>> +- flash device tree subnode, there must be a node with the following
>>> fields:
>>> >>>
>>> >>> These subnodes definitely require a 'compatible' string.
Re: [PATCH resend 2/6] toshiba_acpi: Add fan entry to sysfs
Hi Darren,
2015-02-09 21:02 GMT-07:00 Darren Hart :
> On Mon, Feb 09, 2015 at 08:34:50PM -0700, Azael Avalos wrote:
>> This patch adds a fan entry to sysfs, enabling the user to get and
>> set the fan status.
>>
>
> Hi Azael,
>
> I was finally getting around to these when you resent them. Apologies for the
> delay. Travel and still fighting a cold/flu/bug. Sigh. Anyway... on to patch
> review :-)
Sorry for the rushing of the patches, hope you're better now, in case you're
still in recovery, take my motto "la cerveza cura todo" into account XD
>
>> Signed-off-by: Azael Avalos
>> ---
>> drivers/platform/x86/toshiba_acpi.c | 51
>> -
>> 1 file changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/toshiba_acpi.c
>> b/drivers/platform/x86/toshiba_acpi.c
>> index 334b65e..413af60 100644
>> --- a/drivers/platform/x86/toshiba_acpi.c
>> +++ b/drivers/platform/x86/toshiba_acpi.c
>> @@ -1516,6 +1516,11 @@ static const struct backlight_ops
>> toshiba_backlight_data = {
>> */
>> static ssize_t toshiba_version_show(struct device *dev,
>> struct device_attribute *attr, char *buf);
>> +static ssize_t toshiba_fan_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count);
>> +static ssize_t toshiba_fan_show(struct device *dev,
>> + struct device_attribute *attr, char *buf);
>> static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
>>struct device_attribute *attr,
>>const char *buf, size_t count);
>> @@ -1569,6 +1574,8 @@ static ssize_t toshiba_usb_sleep_music_store(struct
>> device *dev,
>>const char *buf, size_t count);
>>
>> static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
>> +static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
>> +toshiba_fan_show, toshiba_fan_store);
>> static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
>> toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
>> static DEVICE_ATTR(kbd_type, S_IRUGO, toshiba_kbd_type_show, NULL);
>
> At some point, before we add too much more, it would be nice to convert these
> over to DEVICE_ATTR_RW and DEVICE_ATTR_RO. Any reason not to do this sooner
> rather than later?
I have patches ready for all the functions in sysfs regarding this change,
I just wanted the patches to land in you tree (or next) to send them for 3.21,
I'll be in janitor mode after these patches, cleaning the driver according to
coding style, add files to Documentation/ABI, etc..
>
>> @@ -1594,6 +1601,7 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
>>
>> static struct attribute *toshiba_attributes[] = {
>> _attr_version.attr,
>> + _attr_fan.attr,
>> _attr_kbd_backlight_mode.attr,
>> _attr_kbd_type.attr,
>> _attr_available_kbd_modes.attr,
>> @@ -1621,6 +1629,45 @@ static ssize_t toshiba_version_show(struct device
>> *dev,
>> return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
>> }
>>
>> +static ssize_t toshiba_fan_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
>> + u32 result;
>> + int state;
>> + int ret;
>> +
>> + ret = kstrtoint(buf, 0, );
>> + if (ret)
>> + return ret;
>> +
>> + if (state != 0 && state != 1)
>> + return -EINVAL;
>> +
>> + result = hci_write1(toshiba, HCI_FAN, state);
>> + if (result == TOS_FAILURE)
>> + return -EIO;
>> + else if (result == TOS_NOT_SUPPORTED)
>> + return -ENODEV;
>> +
>
> A quick scan of hci_write1 makes me wonder if there are more than two possible
> failures. Should we also have an "else if (result)" or "else if (result !=
> WHATEVER_SUCCESS_IS)" before we assume success and return count?
Can't really tell you, I just ported the code "as-is" from the procfs files,
and to be honest, I haven't seen this function in any recent Toshiba
laptop out there,
I just wanted to port this in case some old laptop/app/script/etc. is
still using this.
>
> --
> Darren Hart
> Intel Open Source Technology Center
Cheers
Azael
--
-- El mundo apesta y vosotros apestais tambien --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] toshiba_acpi: Make toshiba_eco_mode_available more robust
On Mon, Feb 09, 2015 at 08:55:02PM -0700, Azael Avalos wrote: > Some Toshiba laptops do not come with the ECO led installed, however, > the driver is registering support for it when it should not. > > This patch makes the toshiba_eco_mode_available function more robust > in detecting ECO led capabilities, not registering the led on laptops > that do not support it and registering the led when it really does. > > The ECO led function now returns 0x8e00 (Not Installed) by querying > with in[3] = 0, whenever theres no physical LED installed, and > returning 0x8300 (Input Data Error) when it is, however, there are > some BIOSes that have stub function calls not returning anything and > and the LED device was being registered too, hence the change of the > default return value from 1 to 0. > > Signed-off-by: Azael Avalos Careful with whitespace errors caught by checkpatch. Fixed that and corrected a minor grammatical issue in the comment block - since I was late in reviewing ;-) Applied and queued, thanks. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 5/6] toshiba_acpi: Add support to enable/disable USB 3
On Mon, Feb 09, 2015 at 08:34:53PM -0700, Azael Avalos wrote: > Toshiba laptops that come with USB 3 ports have a feature that lets > them disable USB 3 functionality and act as a regular USB 2 port, and > thus, saving power. > > This patch adds support to that feature, by creating a sysfs entry > named "usb_three", acceptig only two parameters, 0 to disable the > USB 3 (acting as a USB 2) and 1 to enable it. > Similar question, does the system BIOS allow you to configure this setting? If so, what would be the value for enabling it in the OS directly? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-trace 4/8] samples: bpf: simple tracing example in C
On Mon, 9 Feb 2015 19:45:57 -0800
Alexei Starovoitov wrote:
> +static void print_netif_receive_skb(void *data, int size)
> +{
> + struct ftrace_raw_netif_receive_skb {
> + struct trace_entry t;
> + void *skb;
> + __u32 len;
> + __u32 name;
> + } *e = data;
Same here, there's no guarantee that this structure will always match.
cat /sys/kernel/debug/tracing/events/net/netif_receive_skb/format
name: netif_receive_skb
ID: 975
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; offset:2; size:1;
signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;
signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:void * skbaddr; offset:8; size:8; signed:0;
field:unsigned int len; offset:16; size:4; signed:0;
field:__data_loc char[] name; offset:20; size:4; signed:1;
print fmt: "dev=%s skbaddr=%p len=%u", __get_str(name), REC->skbaddr, REC->len
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 3/6] toshiba_acpi: Add support for Keyboard functions mode
On Mon, Feb 09, 2015 at 08:34:51PM -0700, Azael Avalos wrote:
> Recent Toshiba laptops that come with the new keyboard layout have
> the Special Functions (hotkeys) enabled by default, which, in order to
> access the F{1-12} keys, you need to press the FN-F{1-12} key to
> access such key.
>
> This patch adds support to toggle the Keyboard Functions operation
> mode by creating the sysfs entry "kbd_functions_keys", accepting only
> two parameters, 0 to set the "Normal Operation" mode and 1 to set the
> "Special Functions" mode, however, everytime the mode is toggled, a
> restart is needed.
Erm... that's kinda horrible :-/
A couple of questions then.
1) Does the system BIOS offer a way to select one mode or the other? If so, no
point in adding it here if a reboot is required.
2) Where Toshiba supports this (Windows?) is a reboot required?
Rather than having to reboot, would a userspace mapping possibly be preferable?
Could be done without a reboot.
Finally, if we keep this, we need to print something to the system log
indicating success - and that a reboot is required to take effect.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-trace 4/8] samples: bpf: simple tracing example in C
On Mon, 9 Feb 2015 19:45:57 -0800
Alexei Starovoitov wrote:
> +int perf_event_mmap(int fd);
> +int perf_event_poll(int fd);
> +typedef void (*print_fn)(void *data, int size);
> +void perf_event_read(print_fn fn);
> +struct trace_entry {
> + unsigned short type;
> + unsigned char flags;
> + unsigned char preempt_count;
> + int pid;
> +};
> +
Please do not hard code any structures. This is not a stable ABI, and
it may not even match if you are running 32 bit userspace on top of a
64 bit kernel.
Please parse the format files. libtraceevent does this for you. If need
be, link to that. But if you look at the event format files you'll see
the offsets and sizes in the binary code:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; offset:2; size:1;
signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;
signed:0;
field:int common_pid; offset:4; size:4; signed:1;
I don't want to get stuck with pinned kernel data structures again. We
had 4 blank bytes of data for every event, because latency top hard
coded the field. Luckily, the 64 bit / 32 bit interface caused latency
top to have to use the event_parse code to work, and we were able to
remove that field after it was converted.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched/wait: add round robin wakeup mode
On 02/09/2015 04:50 PM, Peter Zijlstra wrote:
> On Mon, Feb 09, 2015 at 08:05:57PM +, Jason Baron wrote:
>> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
>> index 852143a..17d1039 100644
>> --- a/kernel/sched/wait.c
>> +++ b/kernel/sched/wait.c
>> @@ -71,8 +71,11 @@ static void __wake_up_common(wait_queue_head_t *q,
>> unsigned int mode,
>> unsigned flags = curr->flags;
>>
>> if (curr->func(curr, mode, wake_flags, key) &&
>> -(flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)
>> + (flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive) {
>> +if (flags & WQ_FLAG_ROUND_ROBIN)
>> +list_move_tail(>task_list, >task_list);
>> break;
>> +}
>> }
>> }
> I think you meant to write something like:
>
> if (curr->func(curr, mode, wake_flags, key) &&
> (flags & WQ_FLAG_EXCLUSIVE)) {
> if (flag & WQ_FLAG_ROUND_ROBIN)
> list_move_tail(>task_list, >task_list);
> if (!--nr_exclusive)
> break;
> }
>
> Otherwise can only work for nr_exclusive==1.
Indeed. I'm also wondering if its worth avoiding the list_move_tail() for the
case where nr_exclusive is initially 0. IE the wake all case, where we are just
going to end up doing a bunch of list_move_tail() calls, but end up in the same
state.
Thanks,
-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: nand: gpmi: fixup return type of wait_for_completion_timeout
On Sun, Feb 08, 2015 at 11:37:33AM -0500, Nicholas Mc Guire wrote: > return type of wait_for_completion_timeout is unsigned long not int. The > return variable is renamed to reflect its use and the type adjusted to > unsigned long. > > Signed-off-by: Nicholas Mc Guire Acked-by: Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 2/6] toshiba_acpi: Add fan entry to sysfs
On Mon, Feb 09, 2015 at 08:34:50PM -0700, Azael Avalos wrote:
> This patch adds a fan entry to sysfs, enabling the user to get and
> set the fan status.
>
Hi Azael,
I was finally getting around to these when you resent them. Apologies for the
delay. Travel and still fighting a cold/flu/bug. Sigh. Anyway... on to patch
review :-)
> Signed-off-by: Azael Avalos
> ---
> drivers/platform/x86/toshiba_acpi.c | 51
> -
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/toshiba_acpi.c
> b/drivers/platform/x86/toshiba_acpi.c
> index 334b65e..413af60 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -1516,6 +1516,11 @@ static const struct backlight_ops
> toshiba_backlight_data = {
> */
> static ssize_t toshiba_version_show(struct device *dev,
> struct device_attribute *attr, char *buf);
> +static ssize_t toshiba_fan_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count);
> +static ssize_t toshiba_fan_show(struct device *dev,
> + struct device_attribute *attr, char *buf);
> static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
>struct device_attribute *attr,
>const char *buf, size_t count);
> @@ -1569,6 +1574,8 @@ static ssize_t toshiba_usb_sleep_music_store(struct
> device *dev,
>const char *buf, size_t count);
>
> static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
> +static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
> +toshiba_fan_show, toshiba_fan_store);
> static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
> toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
> static DEVICE_ATTR(kbd_type, S_IRUGO, toshiba_kbd_type_show, NULL);
At some point, before we add too much more, it would be nice to convert these
over to DEVICE_ATTR_RW and DEVICE_ATTR_RO. Any reason not to do this sooner
rather than later?
> @@ -1594,6 +1601,7 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
>
> static struct attribute *toshiba_attributes[] = {
> _attr_version.attr,
> + _attr_fan.attr,
> _attr_kbd_backlight_mode.attr,
> _attr_kbd_type.attr,
> _attr_available_kbd_modes.attr,
> @@ -1621,6 +1629,45 @@ static ssize_t toshiba_version_show(struct device *dev,
> return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
> }
>
> +static ssize_t toshiba_fan_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
> + u32 result;
> + int state;
> + int ret;
> +
> + ret = kstrtoint(buf, 0, );
> + if (ret)
> + return ret;
> +
> + if (state != 0 && state != 1)
> + return -EINVAL;
> +
> + result = hci_write1(toshiba, HCI_FAN, state);
> + if (result == TOS_FAILURE)
> + return -EIO;
> + else if (result == TOS_NOT_SUPPORTED)
> + return -ENODEV;
> +
A quick scan of hci_write1 makes me wonder if there are more than two possible
failures. Should we also have an "else if (result)" or "else if (result !=
WHATEVER_SUCCESS_IS)" before we assume success and return count?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] m25p80, spi-nor: Update id list of Macronix chips
On Fri, Feb 06, 2015 at 11:09:50AM -0800, Brian Norris wrote:
> (fixed Huang's current email)
>
> Hi,
>
> On Fri, Feb 06, 2015 at 10:33:29PM +0800, Jim-Ting Kuo wrote:
> > On Fri, Feb 6, 2015 at 9:18 AM, Brian Norris
> > wrote:
> > > On Fri, Feb 06, 2015 at 02:44:04AM +0800, Jim Kuo wrote:
> > >> --- a/drivers/mtd/devices/m25p80.c
> > >> +++ b/drivers/mtd/devices/m25p80.c
> > >> @@ -170,6 +170,74 @@ static int m25p80_erase(struct spi_nor *nor, loff_t
> > >> offset)
> > >> return 0;
> > >> }
> > >>
> > >> +static int m25p80_write_xfer(struct spi_nor *nor,
> > >> + struct spi_nor_xfer_cfg *cfg, u8 *buf, size_t len)
> > >> +{
> ...
> > >> +}
> > >> +
> > >> +static int m25p80_read_xfer(struct spi_nor *nor,
> > >> + struct spi_nor_xfer_cfg *cfg, u8 *buf, size_t len)
> > >> +{
> ...
> > >> +}
> > >> +
> > >
> > > All of the above is pointless. The write_xfer/read_xfer functions are
> > > not even used. (They should probably just be dropped, since they're
> > > doing nothing as-is.)
> > >
> > >> /*
> > >> * board specific setup should have ensured the SPI clock used here
> > >> * matches what the READ command supports, at least until this driver
> > >> @@ -199,6 +267,8 @@ static int m25p_probe(struct spi_device *spi)
> > >> nor->erase = m25p80_erase;
> > >> nor->write_reg = m25p80_write_reg;
> > >> nor->read_reg = m25p80_read_reg;
> > >> + nor->write_xfer = m25p80_write_xfer;
> > >> + nor->read_xfer = m25p80_read_xfer;
> > >>
> > >> nor->dev = >dev;
> > >> nor->mtd = >mtd;
> > >> @@ -261,10 +331,15 @@ static const struct spi_device_id m25p_ids[] = {
> > >> {"mr25h256"}, {"mr25h10"},
> > >> {"gd25q32"},{"gd25q64"},
> > >> {"160s33b"},{"320s33b"},{"640s33b"},
> > >> - {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
> > >> - {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
> > >> - {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
> > >> - {"mx66l1g55g"},
> > >> + {"mx25l512e"}, {"mx25l5121e"}, {"mx25l1006e"}, {"mx25l1021e"},
> > >> + {"mx25l2006e"}, {"mx25l4006e"}, {"mx25u4035"}, {"mx25v4035"},
> > >> + {"mx25l8006e"}, {"mx25u8035"}, {"mx25v8035"}, {"mx25l1606e"},
> > >> + {"mx25l1633e"}, {"mx25l1635e"}, {"mx25u1635e"}, {"mx25l3206e"},
> > >> + {"mx25l3239e"}, {"mx25l3225d"}, {"mx25l3255e"}, {"mx25l6406e"},
> > >> + {"mx25l6439e"}, {"mx25l12839f"},{"mx25l12855e"},
> > >> + {"mx25u12835f"},{"mx25l25635e"},{"mx25l25655e"},
> > >> + {"mx25u25635f"},{"mx66l51235f"},{"mx66u51235f"},
> > >> + {"mx66l1g45g"}, {"mx66l1g55g"},
> > >> {"n25q064"},{"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
> > >> {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
> > >> {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
> > >> diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > >> b/drivers/mtd/spi-nor/spi-nor.c
> > >> index 0f8ec3c..a6c7337 100644
> > >> --- a/drivers/mtd/spi-nor/spi-nor.c
> > >> +++ b/drivers/mtd/spi-nor/spi-nor.c
> > >> @@ -545,19 +545,37 @@ static const struct spi_device_id spi_nor_ids[] = {
> > >> { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
> > >>
> > >> /* Macronix */
> > >> - { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
> > >
> > > Nak.
> > >
> > >> - { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
> > >
> > > Nak.
> > >
> > >> - { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
> > >
> > > Nak.
> > >
> > > (you get the picture)
> > >
> [...]
> > >
> > > You need to do a lot better job of documenting your patches (i.e.,
> > > describe why you're doing these things) if you want me to take them.
> > >
> > > What's more, the SFDP support you're trying to add should be done in a
> > > way where you *don't* need to muck with the ID table every time. With
> > > SFDP you can get most/all this information anyway, and devices should
> > > just be able to bind to this driver using a generic name like
> > > "spi-nor,sfdp" or something like that, instead of having to expand this
> > > table.
> >
> > The write_xfer/read_xfer functions actually are used in patch 2.
> > - read_xfer: for macronix_block_lock function.
> > - write_xfer: for sfdp_read, macronix_read_lock_status function.
> > Original read/write fcuntions can only support one type transfer I/O (such
> > as
> > FAST_READ, DUAL_READ or QUAD_READ which was detected at begin),
> > and they also only support fixed cycle of dummy (bind with transfer
> > command).
> > So the commands not related to data transfer, such as sfdp read, lock/unlock
> > are hard to use original read/write. That's why I built these two of
> > functions.
> > I thought they are suitable for this condition.
>
> OK, I suppose that's a little more reasonable. But I want to make sure
> this is actually necessary. I suppose we can't get this functionality
> with the
Re: [PATCH 2/2] epoll: introduce EPOLLEXCLUSIVE and EPOLLROUNDROBIN
On 02/09/2015 05:45 PM, Andy Lutomirski wrote: > On Mon, Feb 9, 2015 at 1:32 PM, Jason Baron wrote: >> On 02/09/2015 03:18 PM, Andy Lutomirski wrote: >>> On 02/09/2015 12:06 PM, Jason Baron wrote: Epoll file descriptors that are added to a shared wakeup source are always added in a non-exclusive manner. That means that when we have multiple epoll fds attached to a shared wakeup source they are all woken up. This can lead to excessive cpu usage and uneven load distribution. This patch introduces two new 'events' flags that are intended to be used with EPOLL_CTL_ADD operations. EPOLLEXCLUSIVE, adds the epoll fd to the event source in an exclusive manner such that the minimum number of threads are woken. EPOLLROUNDROBIN, which depends on EPOLLEXCLUSIVE also being set, can also be added to the 'events' flag, such that we round robin around the set of waiting threads. An implementation note is that in the epoll wakeup routine, 'ep_poll_callback()', if EPOLLROUNDROBIN is set, we return 1, for a successful wakeup, only when there are current waiters. The idea is to use this additional heuristic in order minimize wakeup latencies. >>> I don't understand what this is intended to do. >>> >>> If an event has EPOLLONESHOT, then this only one thread should be woken >>> regardless, right? If not, isn't that just a bug that should be fixed? >>> >> hmm...so with EPOLLONESHOT you basically get notified once about an event. >> If i have multiple epoll fds (say 1 per-thread) attached to a single source >> in EPOLLONESHOT, then all threads will potentially get woken up once per >> event. Then, I would have to re-arm all of them. So I don't think this >> addresses this particular usecase...what I am trying to avoid is this mass >> wakeup or thundering herd for a shared event source. > Now I understand. Why are you using multiple epollfds? > > --Andy So the multiple epollfds is really a way to partition the set of events. Otherwise, I have all the threads contending on all the events that are being generated. So I'm not sure if that is scalable. In the use-case I'm trying to describe, I've partitioned a large set of the events, but there may still be some event sources that we wish to share among all of the threads (or even subsets of them), so as not to overload any one in particular. More specifically, in the case of a single listen socket, its natural to call accept() on the thread that has been woken up, but without doing round robin, you quickly get into a very unbalanced load, and in addition you waste a lot of cpu doing unnecessary wakeups. There are other approaches to solve this, specifically using SO_REUSEPORT, which creates a separate socket per-thread and gets one back to the separately partitioned events case previously described. However, SO_REUSEPORT, I believe is very specific to tcp/udp, and in addition does not have knowledge of the threads that are actively waiting as the epoll code does. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/18] sync opal.h with firmware
On Tue, 2015-02-10 at 13:26 +1100, Stewart Smith wrote: > This patch series takes a careful step-by-step process to sync the > opal.h header file (definition of interface to OPAL firmware) with > opal.h in firmware. > > Each patch is designed to be as obvious as possible so that it's > easy for someone else to prove that I haven't messed it up anywhere. > > In the process of doing this, I fixed a few things in firmware too, > so this matches skiboot at 4681ed9, which is a little after the most > recent skiboot release (4.1.1). > > The biggest change is moving the function prototypes for API calls > out to opal-api.h. Hi Stewart, I'm going to be a total pain, and suggest that this is the wrong approach :) I was on board until patch 15, where you have to add an #ifdef SKIBOOT to guard an include, and you have to remove an include on the Linux side. I think the better solution would be to pull all the common parts out into a new file, opal-api.h. That file would define the API between Linux & Skiboot, and absolutely nothing else. Both Linux and Skiboot would continue to have an opal.h, which would include opal-api.h, and then anything else needed on either side to make a functioning opal.h - eg. other includes & definitions (SG_ENTRIES_PER_NODE). It would also have the advantage that because opal-api.h is a new file, we can get it synced from the beginning and not worry about all the whitespace & rearranging patches. ie. there'd just be one patch on both sides to add the new file and move definitions into it from opal.h. If you don't violently disagree I'll do a patch for that and we can see how it looks? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] toshiba_acpi: Make toshiba_eco_mode_available more robust
Some Toshiba laptops do not come with the ECO led installed, however,
the driver is registering support for it when it should not.
This patch makes the toshiba_eco_mode_available function more robust
in detecting ECO led capabilities, not registering the led on laptops
that do not support it and registering the led when it really does.
The ECO led function now returns 0x8e00 (Not Installed) by querying
with in[3] = 0, whenever theres no physical LED installed, and
returning 0x8300 (Input Data Error) when it is, however, there are
some BIOSes that have stub function calls not returning anything and
and the LED device was being registered too, hence the change of the
default return value from 1 to 0.
Signed-off-by: Azael Avalos
---
Changes since v1:
- Removed the comment block from the TOS_NOT_INSTALLED check, the
error code as well as the pr_info message is self explanatory.
- Expanded the comment block from the TOS_INPUT_DATA_ERROR check.
- Expanded the commit log a bit explaining some of the changes made
in this patch
drivers/platform/x86/toshiba_acpi.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 8b4a78b..278b4bb 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -108,6 +108,7 @@ MODULE_LICENSE("GPL");
#define TOS_FIFO_EMPTY 0x8c00
#define TOS_DATA_NOT_AVAILABLE 0x8d20
#define TOS_NOT_INITIALIZED0x8d50
+#define TOS_NOT_INSTALLED 0x8e00
/* registers */
#define HCI_FAN0x0004
@@ -701,16 +702,32 @@ static int toshiba_touchpad_get(struct toshiba_acpi_dev
*dev, u32 *state)
static int toshiba_eco_mode_available(struct toshiba_acpi_dev *dev)
{
acpi_status status;
- u32 in[TCI_WORDS] = { HCI_GET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 in[TCI_WORDS] = { HCI_GET, HCI_ECO_MODE, 0, 0, 0, 0 };
u32 out[TCI_WORDS];
status = tci_raw(dev, in, out);
- if (ACPI_FAILURE(status) || out[0] == TOS_INPUT_DATA_ERROR) {
- pr_info("ACPI call to get ECO led failed\n");
- return 0;
+ if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
+ pr_err("ACPI call to get ECO led failed\n");
+ } else if (out[0] == TOS_NOT_INSTALLED) {
+ pr_info("ECO led not installed");
+ } else if (out[0] == TOS_INPUT_DATA_ERROR) {
+ /* If we receive 0x8300 (Input Data Error), it means that the
+* LED device is present, but that we just screwed the input
+* parameters.
+*
+* Let's query the status of the LED to see if we really have a
+* success response, indicating the truly presense of the LED,
+* bail out otherwise.
+*/
+ in[3] = 1;
+ status = tci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE)
+ pr_err("ACPI call to get ECO led failed\n");
+ else if (out[0] == TOS_SUCCESS)
+ return 1;
}
- return 1;
+ return 0;
}
static enum led_brightness toshiba_eco_mode_get_status(struct led_classdev
*cdev)
--
2.2.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 v3 linux-trace 0/8] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
Hi Steven,
This patch set is for linux-trace/for-next
It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
Obviously too late for 3.20, but please review. I'll rebase and repost when
merge window closes.
Main difference in V3 is different attaching mechanism:
- load program via bpf() syscall and receive prog_fd
- event_fd = perf_event_open()
- ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd) to attach program to event
- close(event_fd) will destroy event and detach the program
kernel diff became smaller and in general this approach is cleaner
(thanks to Masami and Namhyung for suggesting it)
The programs are run before ring buffer is allocated to have minimal
impact on a system, which can be demonstrated by
'dd if=/dev/zero of=/dev/null count=2000' test:
4.80074 s, 2.1 GB/s - no tracing (raw base line)
5.62705 s, 1.8 GB/s - attached bpf program does 'map[log2(count)]++' without JIT
5.05963 s, 2.0 GB/s - attached bpf program does 'map[log2(count)]++' with JIT
4.91715 s, 2.1 GB/s - attached bpf program does 'return 0'
perf record -e skb:sys_write dd if=/dev/zero of=/dev/null count=2000
8.75686 s, 1.2 GB/s
Warning: Processed 20355236 events and lost 44 chunks!
perf record -e skb:sys_write --filter cnt==1234 dd if=/dev/zero of=/dev/null
count=2000
5.69732 s, 1.8 GB/s
6.13730 s, 1.7 GB/s - echo 1 > /sys/../events/skb/sys_write/enable
6.50091 s, 1.6 GB/s - echo 'cnt == 1234' > /sys/../events/skb/sys_write/filter
(skb:sys_write is a temporary tracepoint in write() syscall)
So the overhead of realistic bpf program is 5.05963/4.80074 = ~5%
which is faster than perf_event filtering: 5.69732/4.80074 = ~18%
or ftrace filtering: 6.50091/4.80074 = ~35%
V2->V3:
- changed program attach interface from tracefs into perf_event ioctl
- rewrote user space helpers to use perf_events
- rewrote tracex1 example to use mmap-ed ring_buffer instead of trace_pipe
- as suggested by Arnaldo renamed bpf_memcmp to bpf_probe_memcmp to better
indicate function logic
- added ifdefs to make bpf check a nop when CONFIG_BPF_SYSCALL is not set
V1->V2:
- dropped bpf_dump_stack() and bpf_printk() helpers
- disabled running programs in_nmi
- other minor cleanups
Program attach point and input arguments:
- programs attached to kprobes receive 'struct pt_regs *' as an input.
See tracex4_kern.c that demonstrates how users can write a C program like:
SEC("events/kprobes/sys_write")
int bpf_prog4(struct pt_regs *regs)
{
long write_size = regs->dx;
// here user need to know the proto of sys_write() from kernel
// sources and x64 calling convention to know that register $rdx
// contains 3rd argument to sys_write() which is 'size_t count'
it's obviously architecture dependent, but allows building sophisticated
user tools on top, that can see from debug info of vmlinux which variables
are in which registers or stack locations and fetch it from there.
'perf probe' can potentialy use this hook to generate programs in user space
and insert them instead of letting kernel parse string during kprobe creation.
- programs attached to tracepoints and syscalls receive 'struct bpf_context *':
u64 arg1, arg2, ..., arg6;
for syscalls they match syscall arguments.
for tracepoints these args match arguments passed to tracepoint.
For example:
trace_sched_migrate_task(p, new_cpu); from sched/core.c
arg1 <- pwhich is 'struct task_struct *'
arg2 <- new_cpu which is 'unsigned int'
arg3..arg6 = 0
the program can use bpf_fetch_u8/16/32/64/ptr() helpers to walk 'task_struct'
or any other kernel data structures.
These helpers are using probe_kernel_read() similar to 'perf probe' which is
not 100% safe in both cases, but good enough.
To access task_struct's pid inside 'sched_migrate_task' tracepoint
the program can do:
struct task_struct *task = (struct task_struct *)ctx->arg1;
u32 pid = bpf_fetch_u32(>pid);
Since struct layout is kernel configuration specific such programs are not
portable and require access to kernel headers to be compiled,
but in this case we don't need debug info.
llvm with bpf backend will statically compute task->pid offset as a constant
based on kernel headers only.
The example of this arbitrary pointer walking is tracex1_kern.c
which does skb->dev->name == "lo" filtering.
In all cases the programs are called before ring buffer is allocated to
minimize the overhead, since we want to filter huge number of events, but
perf_trace_buf_prepare/submit and argument copy for every event is too costly.
Note, tracepoint/syscall and kprobe programs are two different types:
BPF_PROG_TYPE_TRACEPOINT and BPF_PROG_TYPE_KPROBE,
since they expect different input.
Both use the same set of helper functions:
- map access (lookup/update/delete)
- fetch (probe_kernel_read wrappers)
- probe_memcmp (probe_kernel_read + memcmp)
Portability:
- kprobe programs are architecture dependent and need user scripting
language like
Re: [PATCH] thinkpad_acpi: unhandled hkey event
On Mon, Feb 09, 2015 at 08:44:26PM +0100, Xavier Naveira wrote:
> On 2015-02-07 05:22, Darren Hart wrote:
> >On Sat, Jan 31, 2015 at 07:52:03PM +0100, Xavier Naveira wrote:
> >>Pressing Fn+Esc in a Lenovo Thinkpad x240 to lock the Fn keys generates
> >>an unhandled hkey event
> >>
> >>Signed-off-by: Xavier Naveira
> >>---
> >> drivers/platform/x86/thinkpad_acpi.c | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >>diff --git a/drivers/platform/x86/thinkpad_acpi.c
> >>b/drivers/platform/x86/thinkpad_acpi.c
> >>index c3d11fa..e61c43b 100644
> >>--- a/drivers/platform/x86/thinkpad_acpi.c
> >>+++ b/drivers/platform/x86/thinkpad_acpi.c
> >>@@ -196,6 +196,7 @@ enum tpacpi_hkey_event_t {
> >>/* Key-related user-interface events */
> >>TP_HKEY_EV_KEY_NUMLOCK = 0x6000, /* NumLock key pressed */
> >>TP_HKEY_EV_KEY_FN = 0x6005, /* Fn key pressed? E420 */
> >>+ TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
> >>
> >>/* Thermal events */
> >>TP_HKEY_EV_ALARM_BAT_HOT= 0x6011, /* battery too hot */
> >>@@ -3717,6 +3718,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
> >>*send_acpi_ev = false;
> >>*ignore_acpi_ev = true;
> >>return true;
> >>+ case TP_HKEY_EV_KEY_FN_ESC:
> >>+ /* key press events, we just ignore them as long as the EC
> >>+* is still reporting them in the normal keyboard stream */
> >>+ *send_acpi_ev = false;
> >>+ *ignore_acpi_ev = true;
> >>+ return true;
> >
> >No need to duplicate the logic here, just add TP_HKEY_EV_KEY_FN_ESC to the
> >list
> >of fallthrough keys (right after TP_HKEY_EV_KEY_FN).
> >
> I don't see the list that you are referring to?
Just before where you add the new case, there is:
/* fallthrough */
case TP_HKEY_EV_KEY_NUMLOCK:
case TP_HKEY_EV_KEY_FN:
/* key press events, we just ignore them as long as the EC
* is still reporting them in the normal keyboard stream */
*send_acpi_ev = false;
*ignore_acpi_ev = true;
return true;
You should just be able to do:
case TP_HKEY_EV_KEY_FN:
+ case TP_HKEY_EV_KEY_FN_ESC:
Rather than duplicating the same logic below a new case block.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 linux-trace 2/8] tracing: allow eBPF programs to call ktime_get_ns()
bpf_ktime_get_ns() is used by programs to compue time delta between events
or as a timestamp
Signed-off-by: Alexei Starovoitov
---
include/uapi/linux/bpf.h |1 +
kernel/trace/bpf_trace.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index d73d7d0abe6e..ecae21e58ba3 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -169,6 +169,7 @@ enum bpf_func_id {
BPF_FUNC_fetch_u16, /* u16 bpf_fetch_u16(void *unsafe_ptr) */
BPF_FUNC_fetch_u8,/* u8 bpf_fetch_u8(void *unsafe_ptr) */
BPF_FUNC_probe_memcmp,/* int bpf_probe_memcmp(unsafe_ptr, safe_ptr,
size) */
+ BPF_FUNC_ktime_get_ns,/* u64 bpf_ktime_get_ns(void) */
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index ec065e0a364e..e3196266b72f 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -69,6 +69,11 @@ static u64 bpf_probe_memcmp(u64 r1, u64 r2, u64 r3, u64 r4,
u64 r5)
return -1;
}
+static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ return ktime_get_ns();
+}
+
static struct bpf_func_proto tp_prog_funcs[] = {
#define FETCH(SIZE)\
[BPF_FUNC_fetch_##SIZE] = { \
@@ -90,6 +95,11 @@ static struct bpf_func_proto tp_prog_funcs[] = {
.arg2_type = ARG_PTR_TO_STACK,
.arg3_type = ARG_CONST_STACK_SIZE,
},
+ [BPF_FUNC_ktime_get_ns] = {
+ .func = bpf_ktime_get_ns,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ },
};
static const struct bpf_func_proto *tp_prog_func_proto(enum bpf_func_id
func_id)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
User interface:
struct perf_event_attr attr = {.type = PERF_TYPE_TRACEPOINT, .config =
event_id, ...};
event_fd = perf_event_open(,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
prog_fd is a file descriptor associated with eBPF program previously loaded.
event_id is an ID of static tracepoint event or syscall.
(kprobe support is in next patch)
close(event_fd) - automatically detaches eBPF program from it
eBPF programs can call in-kernel helper functions to:
- lookup/update/delete elements in maps
- fetch_ptr/u64/u32/u16/u8 values from unsafe address via probe_kernel_read(),
so that eBPF program can walk any kernel data structures
- probe_memcmp - combination of probe_kernel_read() and memcmp()
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h |6 +-
include/linux/ftrace_event.h| 11 +++
include/trace/bpf_trace.h | 25 +++
include/trace/ftrace.h | 31 +
include/uapi/linux/bpf.h|7 ++
include/uapi/linux/perf_event.h |1 +
kernel/events/core.c| 55 +++
kernel/trace/Makefile |1 +
kernel/trace/bpf_trace.c| 145 +++
kernel/trace/trace_syscalls.c | 35 ++
10 files changed, 316 insertions(+), 1 deletion(-)
create mode 100644 include/trace/bpf_trace.h
create mode 100644 kernel/trace/bpf_trace.c
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index bbfceb756452..a0f6f636ced0 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -130,10 +130,14 @@ struct bpf_prog_aux {
#ifdef CONFIG_BPF_SYSCALL
void bpf_prog_put(struct bpf_prog *prog);
+struct bpf_prog *bpf_prog_get(u32 ufd);
#else
static inline void bpf_prog_put(struct bpf_prog *prog) {}
+static inline struct bpf_prog *bpf_prog_get(u32 ufd)
+{
+ return ERR_PTR(-ENOENT);
+}
#endif
-struct bpf_prog *bpf_prog_get(u32 ufd);
/* verify correctness of eBPF program */
int bpf_check(struct bpf_prog *fp, union bpf_attr *attr);
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 0bebb5c348b8..479d0a4a42b3 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -13,6 +13,7 @@ struct trace_array;
struct trace_buffer;
struct tracer;
struct dentry;
+struct bpf_prog;
struct trace_print_flags {
unsigned long mask;
@@ -299,6 +300,7 @@ struct ftrace_event_call {
#ifdef CONFIG_PERF_EVENTS
int perf_refcount;
struct hlist_head __percpu *perf_events;
+ struct bpf_prog *prog;
int (*perf_perm)(struct ftrace_event_call *,
struct perf_event *);
@@ -544,6 +546,15 @@ event_trigger_unlock_commit_regs(struct ftrace_event_file
*file,
event_triggers_post_call(file, tt);
}
+#ifdef CONFIG_BPF_SYSCALL
+unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx);
+#else
+static inline unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx)
+{
+ return 1;
+}
+#endif
+
enum {
FILTER_OTHER = 0,
FILTER_STATIC_STRING,
diff --git a/include/trace/bpf_trace.h b/include/trace/bpf_trace.h
new file mode 100644
index ..4e64f61f484d
--- /dev/null
+++ b/include/trace/bpf_trace.h
@@ -0,0 +1,25 @@
+/* Copyright (c) 2011-2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#ifndef _LINUX_KERNEL_BPF_TRACE_H
+#define _LINUX_KERNEL_BPF_TRACE_H
+
+/* For tracepoint filters argN fields match one to one to arguments
+ * passed to tracepoint events
+ *
+ * For syscall entry filters argN fields match syscall arguments
+ * For syscall exit filters arg1 is a return value
+ */
+struct bpf_context {
+ u64 arg1;
+ u64 arg2;
+ u64 arg3;
+ u64 arg4;
+ u64 arg5;
+ u64 arg6;
+};
+
+#endif /* _LINUX_KERNEL_BPF_TRACE_H */
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 139b5067345b..4c275ce2dcf0 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -17,6 +17,7 @@
*/
#include
+#include
/*
* DECLARE_EVENT_CLASS can be used to add a generic function
@@ -755,12 +756,32 @@ __attribute__((section("_ftrace_events")))
*__event_##call = _##call
#undef __perf_task
#define __perf_task(t) (__task = (t))
+/* zero extend integer, pointer or aggregate type to u64 without warnings */
+#define __CAST_TO_U64(EXPR) ({ \
+ u64 ret = 0; \
+ typeof(EXPR) expr = EXPR; \
+ switch (sizeof(expr)) { \
+ case 8: ret = *(u64 *) break; \
+ case 4: ret = *(u32 *) break; \
+ case 2: ret = *(u16 *) break; \
+ case 1: ret = *(u8 *) break; \
+ } \
+ ret; })
+
+#define __BPF_CAST1(a,...) __CAST_TO_U64(a)
+#define __BPF_CAST2(a,...) __CAST_TO_U64(a), __BPF_CAST1(__VA_ARGS__)
[PATCH v3 linux-trace 5/8] samples: bpf: counting example for kfree_skb tracepoint and write syscall
this example has two probes in one C file that attach to different tracepoints
and use two different maps.
1st probe is the similar to dropmon.c. It attaches to kfree_skb tracepoint and
count number of packet drops at different locations
2nd probe attaches to syscalls/sys_enter_write and computes a histogram of
different
write sizes
Usage:
$ sudo tracex2
location 0x816959a5 count 1
location 0x816959a5 count 2
557145+0 records in
557145+0 records out
285258240 bytes (285 MB) copied, 1.02379 s, 279 MB/s
syscall write() stats
byte_size : count distribution
1 -> 1: 3| |
2 -> 3: 0| |
4 -> 7: 0| |
8 -> 15 : 0| |
16 -> 31 : 2| |
32 -> 63 : 3| |
64 -> 127 : 1| |
128 -> 255 : 1| |
256 -> 511 : 0| |
512 -> 1023 : 1118968 |* |
Ctrl-C at any time. Kernel will auto cleanup maps and programs
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |4 ++
samples/bpf/tracex2_kern.c | 71 +
samples/bpf/tracex2_user.c | 95
3 files changed, 170 insertions(+)
create mode 100644 samples/bpf/tracex2_kern.c
create mode 100644 samples/bpf/tracex2_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index da28e1b6d3a6..416af24b01fd 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -8,6 +8,7 @@ hostprogs-y += sockex1
hostprogs-y += sockex2
hostprogs-y += dropmon
hostprogs-y += tracex1
+hostprogs-y += tracex2
dropmon-objs := dropmon.o libbpf.o
test_verifier-objs := test_verifier.o libbpf.o
@@ -16,12 +17,14 @@ sock_example-objs := sock_example.o libbpf.o
sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
+tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
always += sockex1_kern.o
always += sockex2_kern.o
always += tracex1_kern.o
+always += tracex2_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -29,6 +32,7 @@ HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include
-Wno-unused-variable
HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
HOSTLOADLIBES_tracex1 += -lelf
+HOSTLOADLIBES_tracex2 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex2_kern.c b/samples/bpf/tracex2_kern.c
new file mode 100644
index ..a789c456c1b4
--- /dev/null
+++ b/samples/bpf/tracex2_kern.c
@@ -0,0 +1,71 @@
+#include
+#include
+#include
+#include
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(long),
+ .value_size = sizeof(long),
+ .max_entries = 1024,
+};
+
+SEC("events/skb/kfree_skb")
+int bpf_prog2(struct bpf_context *ctx)
+{
+ long loc = ctx->arg2;
+ long init_val = 1;
+ long *value;
+
+ value = bpf_map_lookup_elem(_map, );
+ if (value)
+ *value += 1;
+ else
+ bpf_map_update_elem(_map, , _val, BPF_ANY);
+ return 0;
+}
+
+static unsigned int log2(unsigned int v)
+{
+ unsigned int r;
+ unsigned int shift;
+
+ r = (v > 0x) << 4; v >>= r;
+ shift = (v > 0xFF) << 3; v >>= shift; r |= shift;
+ shift = (v > 0xF) << 2; v >>= shift; r |= shift;
+ shift = (v > 0x3) << 1; v >>= shift; r |= shift;
+ r |= (v >> 1);
+ return r;
+}
+
+static unsigned int log2l(unsigned long v)
+{
+ unsigned int hi = v >> 32;
+ if (hi)
+ return log2(hi) + 32;
+ else
+ return log2(v);
+}
+
+struct bpf_map_def SEC("maps") my_hist_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(u32),
+ .value_size = sizeof(long),
+ .max_entries = 64,
+};
+
+SEC("events/syscalls/sys_enter_write")
+int bpf_prog3(struct bpf_context *ctx)
+{
+ long write_size = ctx->arg3;
+ long init_val = 1;
+ long *value;
+ u32 index = log2l(write_size);
+
+ value = bpf_map_lookup_elem(_hist_map, );
+ if (value)
+ __sync_fetch_and_add(value, 1);
+ return 0;
+}
+char _license[] SEC("license") = "GPL";
diff --git a/samples/bpf/tracex2_user.c b/samples/bpf/tracex2_user.c
new file mode 100644
index ..91b8d0896fbb
--- /dev/null
+++
[PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C
tracex1_kern.c - C program which will be compiled into eBPF
to filter netif_receive_skb events on skb->dev->name == "lo"
The programs returns 1 to store an event into ring_buffer
and returns 0 - to discard an event.
tracex1_user.c - corresponding user space component that:
- loads bpf program via bpf() syscall
- opens net:netif_receive_skb event via perf_event_open() syscall
- attaches the program to event via ioctl(event_fd, PERF_EVENT_IOC_SET_BPF,
prog_fd);
- mmaps event_fd
- polls event_fd, walks ring_buffer and prints events
Usage:
$ sudo tracex1
pid 29241 skb 0x88045e58c500 len 84 dev lo
pid 29241 skb 0x88045e58cd00 len 84 dev lo
pid 29241 skb 0x880074c35000 len 84 dev lo
pid 29241 skb 0x880074c35200 len 84 dev lo
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |4 ++
samples/bpf/bpf_helpers.h | 14 +
samples/bpf/bpf_load.c | 129 +---
samples/bpf/bpf_load.h | 12 +
samples/bpf/tracex1_kern.c | 28 ++
samples/bpf/tracex1_user.c | 50 +
6 files changed, 231 insertions(+), 6 deletions(-)
create mode 100644 samples/bpf/tracex1_kern.c
create mode 100644 samples/bpf/tracex1_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 789691374562..da28e1b6d3a6 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -7,6 +7,7 @@ hostprogs-y += sock_example
hostprogs-y += sockex1
hostprogs-y += sockex2
hostprogs-y += dropmon
+hostprogs-y += tracex1
dropmon-objs := dropmon.o libbpf.o
test_verifier-objs := test_verifier.o libbpf.o
@@ -14,17 +15,20 @@ test_maps-objs := test_maps.o libbpf.o
sock_example-objs := sock_example.o libbpf.o
sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
+tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
always += sockex1_kern.o
always += sockex2_kern.o
+always += tracex1_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
+HOSTLOADLIBES_tracex1 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index ca0333146006..406e9705d99e 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -15,6 +15,20 @@ static int (*bpf_map_update_elem)(void *map, void *key, void
*value,
(void *) BPF_FUNC_map_update_elem;
static int (*bpf_map_delete_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_delete_elem;
+static void *(*bpf_fetch_ptr)(void *unsafe_ptr) =
+ (void *) BPF_FUNC_fetch_ptr;
+static unsigned long long (*bpf_fetch_u64)(void *unsafe_ptr) =
+ (void *) BPF_FUNC_fetch_u64;
+static unsigned int (*bpf_fetch_u32)(void *unsafe_ptr) =
+ (void *) BPF_FUNC_fetch_u32;
+static unsigned short (*bpf_fetch_u16)(void *unsafe_ptr) =
+ (void *) BPF_FUNC_fetch_u16;
+static unsigned char (*bpf_fetch_u8)(void *unsafe_ptr) =
+ (void *) BPF_FUNC_fetch_u8;
+static int (*bpf_probe_memcmp)(void *unsafe_ptr, void *safe_ptr, int size) =
+ (void *) BPF_FUNC_probe_memcmp;
+static unsigned long long (*bpf_ktime_get_ns)(void) =
+ (void *) BPF_FUNC_ktime_get_ns;
/* llvm builtin functions that eBPF C program may use to
* emit BPF_LD_ABS and BPF_LD_IND instructions
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 1831d236382b..2aece65963e4 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -8,29 +8,47 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include "libbpf.h"
#include "bpf_helpers.h"
#include "bpf_load.h"
+#define DEBUGFS "/sys/kernel/debug/tracing/"
+
static char license[128];
static bool processed_sec[128];
int map_fd[MAX_MAPS];
int prog_fd[MAX_PROGS];
+int event_fd[MAX_PROGS];
int prog_cnt;
static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
{
- int fd;
bool is_socket = strncmp(event, "socket", 6) == 0;
+ enum bpf_prog_type prog_type;
+ char path[256] = DEBUGFS;
+ char buf[32];
+ int fd, efd, err, id;
+ struct perf_event_attr attr;
- if (!is_socket)
- /* tracing events tbd */
- return -1;
+ attr.type = PERF_TYPE_TRACEPOINT;
+ attr.sample_type = PERF_SAMPLE_RAW;
+ attr.sample_period = 1;
+ attr.wakeup_events = 1;
+
+ if (is_socket)
+ prog_type = BPF_PROG_TYPE_SOCKET_FILTER;
+ else
+ prog_type = BPF_PROG_TYPE_TRACEPOINT;
- fd = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER,
- prog, size, license);
+ fd = bpf_prog_load(prog_type, prog, size, license);
[PATCH v3 linux-trace 6/8] samples: bpf: IO latency analysis (iosnoop/heatmap)
eBPF C program attaches to block_rq_issue/block_rq_complete events to calculate
IO latency. Then it waits for the first 100 events to compute average latency
and uses range [0 .. ave_lat * 2] to record histogram of events in this latency
range.
User space reads this histogram map every 2 seconds and prints it as a 'heatmap'
using gray shades of text terminal. Black spaces have many events and white
spaces have very few events. Left most space is the smallest latency, right most
space is the largest latency in the range.
If kernel sees too many events that fall out of histogram range, user space
adjusts the range up, so heatmap for next 2 seconds will be more accurate.
Usage:
$ sudo ./tracex3
and do 'sudo dd if=/dev/sda of=/dev/null' in other terminal.
Observe IO latencies and how different activity (like 'make kernel') affects it.
Similar experiments can be done for network transmit latencies, syscalls, etc
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |4 ++
samples/bpf/tracex3_kern.c | 98
samples/bpf/tracex3_user.c | 152
3 files changed, 254 insertions(+)
create mode 100644 samples/bpf/tracex3_kern.c
create mode 100644 samples/bpf/tracex3_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 416af24b01fd..da0efd8032ab 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -9,6 +9,7 @@ hostprogs-y += sockex2
hostprogs-y += dropmon
hostprogs-y += tracex1
hostprogs-y += tracex2
+hostprogs-y += tracex3
dropmon-objs := dropmon.o libbpf.o
test_verifier-objs := test_verifier.o libbpf.o
@@ -18,6 +19,7 @@ sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
+tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -25,6 +27,7 @@ always += sockex1_kern.o
always += sockex2_kern.o
always += tracex1_kern.o
always += tracex2_kern.o
+always += tracex3_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -33,6 +36,7 @@ HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
HOSTLOADLIBES_tracex1 += -lelf
HOSTLOADLIBES_tracex2 += -lelf
+HOSTLOADLIBES_tracex3 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex3_kern.c b/samples/bpf/tracex3_kern.c
new file mode 100644
index ..961f3f373270
--- /dev/null
+++ b/samples/bpf/tracex3_kern.c
@@ -0,0 +1,98 @@
+/* Copyright (c) 2013-2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(long),
+ .value_size = sizeof(u64),
+ .max_entries = 4096,
+};
+
+SEC("events/block/block_rq_issue")
+int bpf_prog1(struct bpf_context *ctx)
+{
+ long rq = ctx->arg2;
+ u64 val = bpf_ktime_get_ns();
+
+ bpf_map_update_elem(_map, , , BPF_ANY);
+ return 0;
+}
+
+struct globals {
+ u64 lat_ave;
+ u64 lat_sum;
+ u64 missed;
+ u64 max_lat;
+ int num_samples;
+};
+
+struct bpf_map_def SEC("maps") global_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(struct globals),
+ .max_entries = 1,
+};
+
+#define MAX_SLOT 32
+
+struct bpf_map_def SEC("maps") lat_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(u64),
+ .max_entries = MAX_SLOT,
+};
+
+SEC("events/block/block_rq_complete")
+int bpf_prog2(struct bpf_context *ctx)
+{
+ long rq = ctx->arg2;
+ void *value;
+
+ value = bpf_map_lookup_elem(_map, );
+ if (!value)
+ return 0;
+
+ u64 cur_time = bpf_ktime_get_ns();
+ u64 delta = (cur_time - *(u64 *)value) / 1000;
+
+ bpf_map_delete_elem(_map, );
+
+ int ind = 0;
+ struct globals *g = bpf_map_lookup_elem(_map, );
+
+ if (!g)
+ return 0;
+ if (g->lat_ave == 0) {
+ g->num_samples++;
+ g->lat_sum += delta;
+ if (g->num_samples >= 100)
+ g->lat_ave = g->lat_sum / g->num_samples;
+ } else {
+ u64 max_lat = g->lat_ave * 2;
+
+ if (delta > max_lat) {
+ g->missed++;
+ if (delta > g->max_lat)
+ g->max_lat = delta;
+ return 0;
+ }
+
+ ind = delta * MAX_SLOT / max_lat;
+ value
[PATCH v3 linux-trace 7/8] tracing: attach eBPF programs to kprobe/kretprobe
introduce new type of eBPF programs BPF_PROG_TYPE_KPROBE.
Such programs are allowed to call the same helper functions
as tracing filters, but bpf_context is different:
For tracing filters bpf_context is 6 arguments of tracepoints or syscalls
For kprobe filters bpf_context == pt_regs
Signed-off-by: Alexei Starovoitov
---
include/linux/ftrace_event.h |3 +++
include/uapi/linux/bpf.h |1 +
kernel/events/core.c |5 -
kernel/trace/bpf_trace.c | 39 +++
kernel/trace/trace_kprobe.c | 10 +-
5 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 479d0a4a42b3..cd6efd23bfae 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -249,6 +249,7 @@ enum {
TRACE_EVENT_FL_WAS_ENABLED_BIT,
TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
TRACE_EVENT_FL_TRACEPOINT_BIT,
+ TRACE_EVENT_FL_KPROBE_BIT,
};
/*
@@ -262,6 +263,7 @@ enum {
* it is best to clear the buffers that used it).
* USE_CALL_FILTER - For ftrace internal events, don't use file filter
* TRACEPOINT- Event is a tracepoint
+ * KPROBE- Event is a kprobe
*/
enum {
TRACE_EVENT_FL_FILTERED = (1 << TRACE_EVENT_FL_FILTERED_BIT),
@@ -271,6 +273,7 @@ enum {
TRACE_EVENT_FL_WAS_ENABLED = (1 << TRACE_EVENT_FL_WAS_ENABLED_BIT),
TRACE_EVENT_FL_USE_CALL_FILTER = (1 <<
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
TRACE_EVENT_FL_TRACEPOINT = (1 << TRACE_EVENT_FL_TRACEPOINT_BIT),
+ TRACE_EVENT_FL_KPROBE = (1 << TRACE_EVENT_FL_KPROBE_BIT),
};
struct ftrace_event_call {
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index ecae21e58ba3..cf443900318d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -119,6 +119,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_UNSPEC,
BPF_PROG_TYPE_SOCKET_FILTER,
BPF_PROG_TYPE_TRACEPOINT,
+ BPF_PROG_TYPE_KPROBE,
};
/* flags for BPF_MAP_UPDATE_ELEM command */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 674a8ca17190..94de727a8c0c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6288,7 +6288,10 @@ static int perf_event_set_bpf_prog(struct perf_event
*event, u32 prog_fd)
if (IS_ERR(prog))
return PTR_ERR(prog);
- if (prog->aux->prog_type != BPF_PROG_TYPE_TRACEPOINT) {
+ if (((event->tp_event->flags & TRACE_EVENT_FL_KPROBE) &&
+prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) ||
+ (!(event->tp_event->flags & TRACE_EVENT_FL_KPROBE) &&
+prog->aux->prog_type != BPF_PROG_TYPE_TRACEPOINT)) {
/* valid fd, but invalid bpf program type */
bpf_prog_put(prog);
return -EINVAL;
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index e3196266b72f..52dbd1e7dc28 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -153,3 +153,42 @@ static int __init register_tp_prog_ops(void)
return 0;
}
late_initcall(register_tp_prog_ops);
+
+/* check access to fields of 'struct pt_regs' from BPF program */
+static bool kprobe_prog_is_valid_access(int off, int size, enum
bpf_access_type type)
+{
+ /* check bounds */
+ if (off < 0 || off >= sizeof(struct pt_regs))
+ return false;
+
+ /* only read is allowed */
+ if (type != BPF_READ)
+ return false;
+
+ /* disallow misaligned access */
+ if (off % size != 0)
+ return false;
+
+ return true;
+}
+/* kprobe filter programs are allowed to call the same helper functions
+ * as tracing filters, but bpf_context is different:
+ * For tracing filters bpf_context is 6 arguments of tracepoints or syscalls
+ * For kprobe filters bpf_context == pt_regs
+ */
+static struct bpf_verifier_ops kprobe_prog_ops = {
+ .get_func_proto = tp_prog_func_proto,
+ .is_valid_access = kprobe_prog_is_valid_access,
+};
+
+static struct bpf_prog_type_list kprobe_tl = {
+ .ops = _prog_ops,
+ .type = BPF_PROG_TYPE_KPROBE,
+};
+
+static int __init register_kprobe_prog_ops(void)
+{
+ bpf_register_prog_type(_tl);
+ return 0;
+}
+late_initcall(register_kprobe_prog_ops);
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 5edb518be345..d503ac43b85b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1134,11 +1134,15 @@ static void
kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs)
{
struct ftrace_event_call *call = >tp.call;
+ struct bpf_prog *prog = call->prog;
struct kprobe_trace_entry_head *entry;
struct hlist_head *head;
int size, __size, dsize;
int rctx;
+ if (prog && !trace_call_bpf(prog, regs))
+ return;
+
head = this_cpu_ptr(call->perf_events);
[PATCH v3 linux-trace 8/8] samples: bpf: simple kprobe example
the logic of the example is similar to tracex2, but syscall 'write' statistics
is capturead from kprobe placed at sys_write function instead of through
syscall instrumentation.
Also tracex4_kern.c has a different way of doing log2 in C.
Note, unlike tracepoint and syscall programs, kprobe programs receive
'struct pt_regs' as an input. It's responsibility of the program author
or higher level dynamic tracing tool to match registers to function arguments.
Since pt_regs are architecture dependent, programs are also arch dependent,
unlike tracepoint/syscalls programs which are universal.
Usage:
$ sudo tracex4
2216443+0 records in
2216442+0 records out
1134818304 bytes (1.1 GB) copied, 2.00746 s, 565 MB/s
kprobe sys_write() stats
byte_size : count distribution
1 -> 1: 0| |
2 -> 3: 0| |
4 -> 7: 0| |
8 -> 15 : 0| |
16 -> 31 : 0| |
32 -> 63 : 0| |
64 -> 127 : 1| |
128 -> 255 : 0| |
256 -> 511 : 0| |
512 -> 1023 : 2214734 |* |
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |4 +++
samples/bpf/bpf_load.c |3 ++
samples/bpf/tracex4_kern.c | 36 +++
samples/bpf/tracex4_user.c | 83
4 files changed, 126 insertions(+)
create mode 100644 samples/bpf/tracex4_kern.c
create mode 100644 samples/bpf/tracex4_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index da0efd8032ab..22c7a38f3f95 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -10,6 +10,7 @@ hostprogs-y += dropmon
hostprogs-y += tracex1
hostprogs-y += tracex2
hostprogs-y += tracex3
+hostprogs-y += tracex4
dropmon-objs := dropmon.o libbpf.o
test_verifier-objs := test_verifier.o libbpf.o
@@ -20,6 +21,7 @@ sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
+tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -28,6 +30,7 @@ always += sockex2_kern.o
always += tracex1_kern.o
always += tracex2_kern.o
always += tracex3_kern.o
+always += tracex4_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -37,6 +40,7 @@ HOSTLOADLIBES_sockex2 += -lelf
HOSTLOADLIBES_tracex1 += -lelf
HOSTLOADLIBES_tracex2 += -lelf
HOSTLOADLIBES_tracex3 += -lelf
+HOSTLOADLIBES_tracex4 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 2aece65963e4..2206b49df625 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -32,6 +32,7 @@ int prog_cnt;
static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
{
bool is_socket = strncmp(event, "socket", 6) == 0;
+ bool is_kprobe = strncmp(event, "events/kprobes/", 15) == 0;
enum bpf_prog_type prog_type;
char path[256] = DEBUGFS;
char buf[32];
@@ -45,6 +46,8 @@ static int load_and_attach(const char *event, struct bpf_insn
*prog, int size)
if (is_socket)
prog_type = BPF_PROG_TYPE_SOCKET_FILTER;
+ else if (is_kprobe)
+ prog_type = BPF_PROG_TYPE_KPROBE;
else
prog_type = BPF_PROG_TYPE_TRACEPOINT;
diff --git a/samples/bpf/tracex4_kern.c b/samples/bpf/tracex4_kern.c
new file mode 100644
index ..9646f9e43417
--- /dev/null
+++ b/samples/bpf/tracex4_kern.c
@@ -0,0 +1,36 @@
+#include
+#include
+#include
+#include
+#include "bpf_helpers.h"
+
+static unsigned int log2l(unsigned long long n)
+{
+#define S(k) if (n >= (1ull << k)) { i += k; n >>= k; }
+ int i = -(n == 0);
+ S(32); S(16); S(8); S(4); S(2); S(1);
+ return i;
+#undef S
+}
+
+struct bpf_map_def SEC("maps") my_hist_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(u32),
+ .value_size = sizeof(long),
+ .max_entries = 64,
+};
+
+SEC("events/kprobes/sys_write")
+int bpf_prog4(struct pt_regs *regs)
+{
+ long write_size = regs->dx; /* $rdx contains 3rd argument to a function
*/
+ long init_val = 1;
+ void *value;
+ u32 index = log2l(write_size);
+
+ value = bpf_map_lookup_elem(_hist_map, );
+ if (value)
+ __sync_fetch_and_add((long *)value, 1);
+ return 0;
+}
+char
[PATCH v3 linux-trace 3/8] samples: bpf: simple tracing example in eBPF assembler
simple packet drop monitor:
- in-kernel eBPF program attaches to skb:kfree_skb event and records number
of packet drops at given location
- userspace iterates over the map every second and prints stats
Usage:
$ sudo dropmon
location 0x81695995 count 1
location 0x816d0da9 count 2
location 0x81695995 count 2
location 0x816d0da9 count 2
location 0x81695995 count 3
location 0x816d0da9 count 2
$ addr2line -ape ./bld_x64/vmlinux 0x81695995 0x816d0da9
0x81695995: ./bld_x64/../net/ipv4/icmp.c:1038
0x816d0da9: ./bld_x64/../net/unix/af_unix.c:1231
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |2 +
samples/bpf/dropmon.c | 143 +
samples/bpf/libbpf.c |7 +++
samples/bpf/libbpf.h |4 ++
4 files changed, 156 insertions(+)
create mode 100644 samples/bpf/dropmon.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index b5b3600dcdf5..789691374562 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -6,7 +6,9 @@ hostprogs-y := test_verifier test_maps
hostprogs-y += sock_example
hostprogs-y += sockex1
hostprogs-y += sockex2
+hostprogs-y += dropmon
+dropmon-objs := dropmon.o libbpf.o
test_verifier-objs := test_verifier.o libbpf.o
test_maps-objs := test_maps.o libbpf.o
sock_example-objs := sock_example.o libbpf.o
diff --git a/samples/bpf/dropmon.c b/samples/bpf/dropmon.c
new file mode 100644
index ..515504f68506
--- /dev/null
+++ b/samples/bpf/dropmon.c
@@ -0,0 +1,143 @@
+/* simple packet drop monitor:
+ * - in-kernel eBPF program attaches to kfree_skb() event and records number
+ * of packet drops at given location
+ * - userspace iterates over the map every second and prints stats
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "libbpf.h"
+
+#define TRACEPOINT "/sys/kernel/debug/tracing/events/skb/kfree_skb/id"
+
+static int dropmon(void)
+{
+ long long key, next_key, value = 0;
+ int prog_fd, map_fd, i, event_fd, efd, err;
+ char buf[32];
+
+ map_fd = bpf_create_map(BPF_MAP_TYPE_HASH, sizeof(key), sizeof(value),
1024);
+ if (map_fd < 0) {
+ printf("failed to create map '%s'\n", strerror(errno));
+ goto cleanup;
+ }
+
+ /* the following eBPF program is equivalent to C:
+* int filter(struct bpf_context *ctx)
+* {
+* long loc = ctx->arg2;
+* long init_val = 1;
+* long *value;
+*
+* value = bpf_map_lookup_elem(MAP_ID, );
+* if (value) {
+* __sync_fetch_and_add(value, 1);
+* } else {
+* bpf_map_update_elem(MAP_ID, , _val, BPF_ANY);
+* }
+* return 0;
+* }
+*/
+ struct bpf_insn prog[] = {
+ BPF_LDX_MEM(BPF_DW, BPF_REG_2, BPF_REG_1, 8), /* r2 = *(u64
*)(r1 + 8) */
+ BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_2, -8), /* *(u64 *)(fp
- 8) = r2 */
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), /* r2 = fp - 8 */
+ BPF_LD_MAP_FD(BPF_REG_1, map_fd),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_map_lookup_elem),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 4),
+ BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */
+ BPF_RAW_INSN(BPF_STX | BPF_XADD | BPF_DW, BPF_REG_0, BPF_REG_1,
0, 0), /* xadd r0 += r1 */
+ BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
+ BPF_EXIT_INSN(),
+ BPF_ST_MEM(BPF_DW, BPF_REG_10, -16, 1), /* *(u64 *)(fp - 16) =
1 */
+ BPF_MOV64_IMM(BPF_REG_4, BPF_ANY),
+ BPF_MOV64_REG(BPF_REG_3, BPF_REG_10),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_3, -16), /* r3 = fp - 16 */
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), /* r2 = fp - 8 */
+ BPF_LD_MAP_FD(BPF_REG_1, map_fd),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_map_update_elem),
+ BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
+ BPF_EXIT_INSN(),
+ };
+
+ prog_fd = bpf_prog_load(BPF_PROG_TYPE_TRACEPOINT, prog,
+ sizeof(prog), "GPL");
+ if (prog_fd < 0) {
+ printf("failed to load prog '%s'\n%s",
+ strerror(errno), bpf_log_buf);
+ return -1;
+ }
+
+
+ event_fd = open(TRACEPOINT, O_RDONLY, 0);
+ if (event_fd < 0) {
+ printf("failed to open event %s\n", TRACEPOINT);
+ return -1;
+ }
+
+ err = read(event_fd, buf, sizeof(buf));
+ if (err < 0 || err >= sizeof(buf)) {
+ printf("read from '%s' failed '%s'\n",
+
Re: [PATCH] llist: Fix missing lockless_dereference()
- Original Message - > From: "Huang Ying" > To: "Mathieu Desnoyers" > Cc: "Michael Cree" , "Greg KH" > , linux-al...@vger.kernel.org, > "Richard Henderson" , "Ivan Kokshaysky" > , "Matt Turner" > , linux-kernel@vger.kernel.org, "Paul McKenney" > , "David Howells" > , "Pranith Kumar" , > sta...@vger.kernel.org > Sent: Monday, February 9, 2015 8:52:28 PM > Subject: Re: [PATCH] llist: Fix missing lockless_dereference() > > Hi, Mathieu, > > On Sun, 2015-02-08 at 04:25 +, Mathieu Desnoyers wrote: > > - Original Message - > > > From: "Michael Cree" > > > To: "Mathieu Desnoyers" > > > Cc: "Greg KH" , linux-al...@vger.kernel.org, > > > "Richard Henderson" , "Ivan > > > Kokshaysky" , "Matt Turner" > > > , "Huang Ying" , > > > linux-kernel@vger.kernel.org, "Paul McKenney" > > > , "David Howells" , > > > "Pranith Kumar" , sta...@vger.kernel.org > > > Sent: Saturday, February 7, 2015 7:47:29 PM > > > Subject: Re: [PATCH] llist: Fix missing lockless_dereference() > > > > > > On Sat, Feb 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote: > > > > > On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote: > > > > > > A lockless_dereference() appears to be missing in > > > > > > llist_del_first(). > > > > > > It should only matter for Alpha in practice. > > > > > > What could one anticipate to be the symptoms of such a missing > > > lockless_dereference()? > > > > This can trigger corruption of the lockless linked-list, which is > > used across a few subsystems. AFAIU, the scenario is as follows. > > Please bear with me, because it's been a while since I've read on > > the Alpha multi-cache-banks behavior. > > > > The list here would be initially non-empty. Initial state of > > new_last->next is unset (newly allocated); IOW: garbage. CPU A > > adds a node into the list while CPU B removes a node from the > > head of the list. > > > > CPU A CPU B > > llist_add_batch() > > - Stores to new_last->next > > - implicit full mb before cmpxchg makes the > > update to CPU A's cache bank containing > > new_last->next visible to other CPUs > > before CPU A's cache bank update making > > head->first visible to other CPUs. > > - cmpxchg updates head->first = new_first > >llist_del_first() > >- entry = load head->first > >-> here, lack of barrier on > >Alpha creates a window where > > CPU B's cache bank can see > > the updated "head->first", > > but the cache bank holding > > the next value did not > > receive the update yet, since > > each cache bank have > > their own channel, which can > > be independently > > saturated. > >- next = load entry->next > >(dereference entry pointer) > >- cmpxchg updates head->first = > >next > > -> can store unset "next" > > value into head->first, thus > > corrupting the linked list. > > If my understanding were correct, cmpxchg will imply a full mb before > and after it, so that there is a mb between load head->first in cmpxchg > and load entry->next. If so, the memory barrier is only needed before > the loop. Yes, indeed, and by using lockless_dereference(), this is what we end up doing. FWIW, the reason why I moved smp_read_barrier_depends() into the loop was to issue it after the check for NULL pointer, assuming that getting a NULL pointer was a relatively frequent case compared to a failing cmpxchg. But we're talking about very minor optimisations compared to the upside of lockless_dereference() making the code easier to understand. Thanks, Mathieu > > Best Regards, > Huang, Ying > > > > > > > The Alpha kernel is behaving pretty well provided one builds a machine > > > specific kernel and UP. When running an SMP kernel some packages > > > (most notably the java runtime, but there are a few others) occasionally > > > lock up in a pthread call --- could be a problem in libc rather then the > > > kernel. > > > > Are those lockups always occasional, or you have ways to reproduce them > > frequently with stress-tests ? > > > > Thanks, > > > > Mathieu > > > > > > > > > > Meta-comment, do we really care about
Re: [PATCH 03/18] powerpc/powernv: s/OPAL_PCI_SET_PHB_CXL_MODE/OPAL_PCI_SET_PHB_CAPI_MODE/ to match firmware
On Tue, 2015-02-10 at 13:26 +1100, Stewart Smith wrote: > --- a/arch/powerpc/platforms/powernv/pci-ioda.c > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c > @@ -1481,9 +1481,9 @@ int pnv_phb_to_cxl(struct pci_dev *dev) > > pe_info(pe, "Switching PHB to CXL\n"); > > - rc = opal_pci_set_phb_cxl_mode(phb->opal_id, 1, pe->pe_number); > + rc = opal_pci_set_phb_capi_mode(phb->opal_id, 1, pe->pe_number); > if (rc) > - dev_err(>dev, "opal_pci_set_phb_cxl_mode failed: %i\n", > rc); > + dev_err(>dev, "opal_pci_set_phb_capi_mode failed: %i\n", > rc); > > return rc; > } Add a comment above the call: /* CAPI is the IBM/Firmware name for "CXL" */ Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 resend 3/6] toshiba_acpi: Add support for Keyboard functions mode
Recent Toshiba laptops that come with the new keyboard layout have
the Special Functions (hotkeys) enabled by default, which, in order to
access the F{1-12} keys, you need to press the FN-F{1-12} key to
access such key.
This patch adds support to toggle the Keyboard Functions operation
mode by creating the sysfs entry "kbd_functions_keys", accepting only
two parameters, 0 to set the "Normal Operation" mode and 1 to set the
"Special Functions" mode, however, everytime the mode is toggled, a
restart is needed.
In the "Normal Operation" mode, the F{1-12} keys are as usual and
the hotkeys are accessed via FN-F{1-12}.
In the "Special Functions" mode, the F{1-12} keys trigger the hotkey
and the F{1-12} keys are accessed via FN-F{1-12}.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 98 +
1 file changed, 98 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 413af60..c79211a 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -126,6 +126,7 @@ MODULE_LICENSE("GPL");
#define SCI_KBD_ILLUM_STATUS 0x015c
#define SCI_USB_SLEEP_MUSIC0x015e
#define SCI_TOUCHPAD 0x050e
+#define SCI_KBD_FUNCTION_KEYS 0x0522
/* field definitions */
#define HCI_ACCEL_MASK 0x7fff
@@ -192,6 +193,7 @@ struct toshiba_acpi_dev {
unsigned int usb_sleep_charge_supported:1;
unsigned int usb_rapid_charge_supported:1;
unsigned int usb_sleep_music_supported:1;
+ unsigned int kbd_function_keys_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -988,6 +990,47 @@ static int toshiba_usb_sleep_music_set(struct
toshiba_acpi_dev *dev, u32 state)
return 0;
}
+/* Keyboard function keys */
+static int toshiba_function_keys_get(struct toshiba_acpi_dev *dev, u32 *mode)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_read(dev, SCI_KBD_FUNCTION_KEYS, mode);
+ sci_close(dev);
+ if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
+ pr_err("ACPI call to get KBD function keys failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("KBD function keys not supported\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int toshiba_function_keys_set(struct toshiba_acpi_dev *dev, u32 mode)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_write(dev, SCI_KBD_FUNCTION_KEYS, mode);
+ sci_close(dev);
+ if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
+ pr_err("ACPI call to set KBD function keys failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("KBD function keys not supported\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1572,6 +1615,12 @@ static ssize_t toshiba_usb_sleep_music_show(struct
device *dev,
static ssize_t toshiba_usb_sleep_music_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static ssize_t toshiba_kbd_function_keys_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static ssize_t toshiba_kbd_function_keys_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
@@ -1598,6 +1647,9 @@ static DEVICE_ATTR(usb_rapid_charge, S_IRUGO | S_IWUSR,
static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
toshiba_usb_sleep_music_show,
toshiba_usb_sleep_music_store);
+static DEVICE_ATTR(kbd_function_keys, S_IRUGO | S_IWUSR,
+ toshiba_kbd_function_keys_show,
+ toshiba_kbd_function_keys_store);
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
@@ -1612,6 +1664,7 @@ static struct attribute *toshiba_attributes[] = {
_attr_sleep_functions_on_battery.attr,
_attr_usb_rapid_charge.attr,
_attr_usb_sleep_music.attr,
+ _attr_kbd_function_keys.attr,
NULL,
};
@@ -2057,6 +2110,46 @@ static ssize_t toshiba_usb_sleep_music_store(struct
device *dev,
return count;
}
+static ssize_t toshiba_kbd_function_keys_show(struct device *dev,
+ struct
[PATCH resend 4/6] toshiba_acpi: Add support for Panel Power ON
Toshiba laptops come with a feature called "Panel Open - Power ON",
which makes the laptop turn on whenever the LID is opened.
This patch adds support for such feature, by creating a sysfs entry
named "panel_power_on", accepting only two values, 0 to disable and
1 to enable such feature.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 98 +
1 file changed, 98 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index c79211a..baf3376 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -121,6 +121,7 @@ MODULE_LICENSE("GPL");
#define HCI_KBD_ILLUMINATION 0x0095
#define HCI_ECO_MODE 0x0097
#define HCI_ACCELEROMETER2 0x00a6
+#define SCI_PANEL_POWER_ON 0x010d
#define SCI_ILLUMINATION 0x014e
#define SCI_USB_SLEEP_CHARGE 0x0150
#define SCI_KBD_ILLUM_STATUS 0x015c
@@ -194,6 +195,7 @@ struct toshiba_acpi_dev {
unsigned int usb_rapid_charge_supported:1;
unsigned int usb_sleep_music_supported:1;
unsigned int kbd_function_keys_supported:1;
+ unsigned int panel_power_on_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -1031,6 +1033,51 @@ static int toshiba_function_keys_set(struct
toshiba_acpi_dev *dev, u32 mode)
return 0;
}
+/* Panel Power ON */
+static int toshiba_panel_power_on_get(struct toshiba_acpi_dev *dev, u32 *state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_read(dev, SCI_PANEL_POWER_ON, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to get Panel Power ON failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("Panel Power on not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int toshiba_panel_power_on_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_write(dev, SCI_PANEL_POWER_ON, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to set Panel Power ON failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("Panel Power ON not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1621,6 +1668,12 @@ static ssize_t toshiba_kbd_function_keys_show(struct
device *dev,
static ssize_t toshiba_kbd_function_keys_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static ssize_t toshiba_panel_power_on_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static ssize_t toshiba_panel_power_on_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
@@ -1650,6 +1703,9 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
static DEVICE_ATTR(kbd_function_keys, S_IRUGO | S_IWUSR,
toshiba_kbd_function_keys_show,
toshiba_kbd_function_keys_store);
+static DEVICE_ATTR(panel_power_on, S_IRUGO | S_IWUSR,
+ toshiba_panel_power_on_show,
+ toshiba_panel_power_on_store);
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
@@ -1665,6 +1721,7 @@ static struct attribute *toshiba_attributes[] = {
_attr_usb_rapid_charge.attr,
_attr_usb_sleep_music.attr,
_attr_kbd_function_keys.attr,
+ _attr_panel_power_on.attr,
NULL,
};
@@ -2150,6 +2207,42 @@ static ssize_t toshiba_kbd_function_keys_store(struct
device *dev,
return count;
}
+static ssize_t toshiba_panel_power_on_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 state;
+ int ret;
+
+ ret = toshiba_panel_power_on_get(toshiba, );
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%d\n", state);
+}
+
+static ssize_t
[PATCH resend 6/6] toshiba_acpi: Bump version number to 0.21
Several new features were added on previous patches, so lets bump up the driver version. And also, update the copyright year. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index c5b1ab5..8b4a78b 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -5,7 +5,7 @@ * Copyright (C) 2002-2004 John Belmonte * Copyright (C) 2008 Philip Langdale * Copyright (C) 2010 Pierre Ducroquet - * Copyright (C) 2014 Azael Avalos + * Copyright (C) 2014-2015 Azael Avalos * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -38,7 +38,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#define TOSHIBA_ACPI_VERSION "0.20" +#define TOSHIBA_ACPI_VERSION "0.21" #define PROC_INTERFACE_VERSION 1 #include -- 2.2.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 resend 2/6] toshiba_acpi: Add fan entry to sysfs
This patch adds a fan entry to sysfs, enabling the user to get and
set the fan status.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 334b65e..413af60 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1516,6 +1516,11 @@ static const struct backlight_ops toshiba_backlight_data
= {
*/
static ssize_t toshiba_version_show(struct device *dev,
struct device_attribute *attr, char *buf);
+static ssize_t toshiba_fan_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count);
+static ssize_t toshiba_fan_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
@@ -1569,6 +1574,8 @@ static ssize_t toshiba_usb_sleep_music_store(struct
device *dev,
const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
+static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
+ toshiba_fan_show, toshiba_fan_store);
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_type, S_IRUGO, toshiba_kbd_type_show, NULL);
@@ -1594,6 +1601,7 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
+ _attr_fan.attr,
_attr_kbd_backlight_mode.attr,
_attr_kbd_type.attr,
_attr_available_kbd_modes.attr,
@@ -1621,6 +1629,45 @@ static ssize_t toshiba_version_show(struct device *dev,
return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
}
+static ssize_t toshiba_fan_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 result;
+ int state;
+ int ret;
+
+ ret = kstrtoint(buf, 0, );
+ if (ret)
+ return ret;
+
+ if (state != 0 && state != 1)
+ return -EINVAL;
+
+ result = hci_write1(toshiba, HCI_FAN, state);
+ if (result == TOS_FAILURE)
+ return -EIO;
+ else if (result == TOS_NOT_SUPPORTED)
+ return -ENODEV;
+
+ return count;
+}
+
+static ssize_t toshiba_fan_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 value;
+ int ret;
+
+ ret = get_fan_status(toshiba, );
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%d\n", value);
+}
+
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -2017,7 +2064,9 @@ static umode_t toshiba_sysfs_is_visible(struct kobject
*kobj,
struct toshiba_acpi_dev *drv = dev_get_drvdata(dev);
bool exists = true;
- if (attr == _attr_kbd_backlight_mode.attr)
+ if (attr == _attr_fan.attr)
+ exists = (drv->fan_supported) ? true : false;
+ else if (attr == _attr_kbd_backlight_mode.attr)
exists = (drv->kbd_illum_supported) ? true : false;
else if (attr == _attr_kbd_backlight_timeout.attr)
exists = (drv->kbd_mode == SCI_KBD_MODE_AUTO) ? true : false;
--
2.2.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 resend 0/6] toshiba_acpi: Add new features plus some procfs ports
These patches add five new files to sysfs. With the first two files we are paving the way to the (hopefully) future removal of the (now deprecated) proc entries. The remaining entries were not ported due to the fact that they duplicate existing kernel functionality (eg.: lcd <-> backlight, keys <-> input). The rest add support for new features found on recent Toshiba laptops. And the last one simply bump up the driver version. Azael Avalos (6): toshiba_acpi: Add version entry to sysfs toshiba_acpi: Add fan entry to sysfs toshiba_acpi: Add support for Keyboard functions mode toshiba_acpi: Add support for Panel Power ON toshiba_acpi: Add support to enable/disable USB 3 toshiba_acpi: Bump version number to 0.21 drivers/platform/x86/toshiba_acpi.c | 364 +++- 1 file changed, 360 insertions(+), 4 deletions(-) -- 2.2.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 resend 1/6] toshiba_acpi: Add version entry to sysfs
This patch adds a new entry to the sysfs, showing the version of the
driver.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 4e8a8cf..334b65e 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1514,6 +1514,8 @@ static const struct backlight_ops toshiba_backlight_data
= {
/*
* Sysfs files
*/
+static ssize_t toshiba_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
@@ -1566,6 +1568,7 @@ static ssize_t toshiba_usb_sleep_music_store(struct
device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_type, S_IRUGO, toshiba_kbd_type_show, NULL);
@@ -1590,6 +1593,7 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
toshiba_usb_sleep_music_store);
static struct attribute *toshiba_attributes[] = {
+ _attr_version.attr,
_attr_kbd_backlight_mode.attr,
_attr_kbd_type.attr,
_attr_available_kbd_modes.attr,
@@ -1611,6 +1615,12 @@ static struct attribute_group toshiba_attr_group = {
.attrs = toshiba_attributes,
};
+static ssize_t toshiba_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
+}
+
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
--
2.2.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 resend 5/6] toshiba_acpi: Add support to enable/disable USB 3
Toshiba laptops that come with USB 3 ports have a feature that lets
them disable USB 3 functionality and act as a regular USB 2 port, and
thus, saving power.
This patch adds support to that feature, by creating a sysfs entry
named "usb_three", acceptig only two parameters, 0 to disable the
USB 3 (acting as a USB 2) and 1 to enable it.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 101
1 file changed, 101 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index baf3376..c5b1ab5 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -126,6 +126,7 @@ MODULE_LICENSE("GPL");
#define SCI_USB_SLEEP_CHARGE 0x0150
#define SCI_KBD_ILLUM_STATUS 0x015c
#define SCI_USB_SLEEP_MUSIC0x015e
+#define SCI_USB_THREE 0x0169
#define SCI_TOUCHPAD 0x050e
#define SCI_KBD_FUNCTION_KEYS 0x0522
@@ -196,6 +197,7 @@ struct toshiba_acpi_dev {
unsigned int usb_sleep_music_supported:1;
unsigned int kbd_function_keys_supported:1;
unsigned int panel_power_on_supported:1;
+ unsigned int usb_three_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -1078,6 +1080,51 @@ static int toshiba_panel_power_on_set(struct
toshiba_acpi_dev *dev, u32 state)
return 0;
}
+/* USB Three */
+static int toshiba_usb_three_get(struct toshiba_acpi_dev *dev, u32 *state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_read(dev, SCI_USB_THREE, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to get USB 3 failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("USB 3 not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int toshiba_usb_three_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_write(dev, SCI_USB_THREE, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to set USB 3 failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("USB 3 not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1674,6 +1721,12 @@ static ssize_t toshiba_panel_power_on_show(struct device
*dev,
static ssize_t toshiba_panel_power_on_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static ssize_t toshiba_usb_three_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static ssize_t toshiba_usb_three_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
@@ -1706,6 +1759,8 @@ static DEVICE_ATTR(kbd_function_keys, S_IRUGO | S_IWUSR,
static DEVICE_ATTR(panel_power_on, S_IRUGO | S_IWUSR,
toshiba_panel_power_on_show,
toshiba_panel_power_on_store);
+static DEVICE_ATTR(usb_three, S_IRUGO | S_IWUSR,
+ toshiba_usb_three_show, toshiba_usb_three_store);
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
@@ -1722,6 +1777,7 @@ static struct attribute *toshiba_attributes[] = {
_attr_usb_sleep_music.attr,
_attr_kbd_function_keys.attr,
_attr_panel_power_on.attr,
+ _attr_usb_three.attr,
NULL,
};
@@ -2243,6 +2299,46 @@ static ssize_t toshiba_panel_power_on_store(struct
device *dev,
return count;
}
+static ssize_t toshiba_usb_three_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 state;
+ int ret;
+
+ ret = toshiba_usb_three_get(toshiba, );
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%d\n", state);
+}
+
+static ssize_t toshiba_usb_three_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
Re: [trivial PATCH] mod_devicetable.h: Make the definition of struct of_device_id easier to find
On Mon, 2015-02-09 at 19:35 -0600, Rob Herring wrote: > On Mon, Feb 9, 2015 at 3:15 PM, Joe Perches wrote: > > Move the open brace so the definition matches the more > > common kernel style. This makes grep a bit easier. Hey Rob. > I've got the same fix in -next for 3.20 already: Then you should push that change to Stephen's -next 'cause it's not there. > commit 851c63e3b381fdbf5aca1a797f37d8606b5588d2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3 1/2] ARM: at91: sama5d4/dts: add #{address, size}_cell properties for macb0
macb0 DT node can have phy child nodes, so add the #{address, size}_cell
for macb0 node.
Signed-off-by: Josh Wu
---
Changes in v3:
- new added
Changes in v2: None
arch/arm/boot/dts/sama5d4.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index d986b41..07953f2 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -852,6 +852,8 @@
interrupts = <54 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
pinctrl-0 = <_macb0_rmii>;
+ #address-cells = <1>;
+ #size-cells = <0>;
clocks = <_clk>, <_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
--
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/
