* Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations
From: Huang, Ying @ 2017-01-03 5:43 UTC (permalink / raw)
To: Minchan Kim
Cc: Jan Kara, Tim Chen, Andrew Morton, Ying Huang, dave.hansen, ak,
aaron.lu, linux-mm, linux-kernel, Hugh Dickins, Shaohua Li,
Rik van Riel, Andrea Arcangeli, Kirill A . Shutemov,
Vladimir Davydov, Johannes Weiner, Michal Hocko, Hillf Danton,
Christian Borntraeger, Jonathan Corbet, Peter Zijlstra,
Nicholas Piggin
In-Reply-To: <20170103043411.GA15657@bbox>
Hi, Minchan,
Minchan Kim <minchan@kernel.org> writes:
> Hi Jan,
>
> On Mon, Jan 02, 2017 at 04:48:41PM +0100, Jan Kara wrote:
>> Hi,
>>
>> On Tue 27-12-16 16:45:03, Minchan Kim wrote:
>> > > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
>> > > the rate that we have to contende for the radix tree.
>> >
>> > To me, it's rather hacky. I think it might be common problem for page cache
>> > so can we think another generalized way like range_lock? Ccing Jan.
>>
>> I agree on the hackyness of the patch and that page cache would suffer with
>> the same contention (although the files are usually smaller than swap so it
>> would not be that visible I guess). But I don't see how range lock would
>> help here - we need to serialize modifications of the tree structure itself
>> and that is difficult to achieve with the range lock. So what you would
>> need is either a different data structure for tracking swap cache entries
>> or a finer grained locking of the radix tree.
>
> Thanks for the comment, Jan.
>
> I think there are more general options. One is to shrink batching pages like
> Mel and Tim had approached.
>
> https://patchwork.kernel.org/patch/9008421/
> https://patchwork.kernel.org/patch/9322793/
This helps to reduce the lock contention on radix tree of swap cache.
But splitting swap cache has much better performance. So we switched
from that solution to current solution.
> Or concurrent page cache by peter.
>
> https://www.kernel.org/doc/ols/2007/ols2007v2-pages-311-318.pdf
I think this is good, it helps swap and file cache. But I don't know
whether other people want to go this way and how much effort will be
needed.
In contrast, splitting swap cache is quite simple, for implementation
and review. And the effect is good.
Best Regards,
Huang, Ying
> Ccing Nick who might have an interest on lockless page cache.
>
> Thanks.
^ permalink raw reply
* [U-Boot] [PATCH v2 29/30] arm: socfpga: arria10: Added Arria10 critical HW initialization to spl
From: Chee, Tien Fong @ 2017-01-03 5:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <254867a0-3df5-6e1a-fb4a-9a89396b32b4@kernel.org>
On Jum, 2016-12-30 at 06:14 -0600, Dinh Nguyen wrote:
>
> On 12/28/2016 12:34 AM, Chee Tien Fong wrote:
> >
> > From: Tien Fong Chee <tien.fong.chee@intel.com>
> >
> > This patch adding the Arria10 critical hardware initialization
> > before
> > enabling console print out in spl.
> >
> > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > Cc: Marek Vasut <marex@denx.de>
> > Cc: Dinh Nguyen <dinguyen@kernel.org>
> > Cc: Chin Liang See <chin.liang.see@intel.com>
> > Cc: Tien Fong <skywindctf@gmail.com>
> > ---
> > Changes for V2
> > - Release UART from reset before enalbing console, and reverting
> > license
> > ? changes.
> > ---
> > ?arch/arm/mach-socfpga/spl.c | 84
> > +++++++++++++++++++++++++++++++++++++++++++--
> > ?1 file changed, 82 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-
> > socfpga/spl.c
> > index fec4c7a..9e27f82 100644
> > --- a/arch/arm/mach-socfpga/spl.c
> > +++ b/arch/arm/mach-socfpga/spl.c
> > @@ -1,5 +1,5 @@
> > ?/*
> > - *??Copyright (C) 2012 Altera Corporation <www.altera.com>
> > + *??Copyright (C) 2012-2016 Altera Corporation <www.altera.com>
> > ? *
> > ? * SPDX-License-Identifier: GPL-2.0+
> > ? */
> > @@ -19,22 +19,32 @@
> > ?#include <asm/arch/sdram.h>
> > ?#include <asm/arch/scu.h>
> > ?#include <asm/arch/nic301.h>
> > +#include <asm/sections.h>
> > +#include <watchdog.h>
> > +#include <fdtdec.h>
> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +#include <asm/arch/pinmux.h>
> > +#endif
> > ?
> > ?DECLARE_GLOBAL_DATA_PTR;
> > ?
> > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > ?static struct pl310_regs *const pl310 =
> > ? (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> > ?static struct scu_registers *scu_regs =
> > ? (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
> > ?static struct nic301_registers *nic301_regs =
> > ? (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
> > -static struct socfpga_system_manager *sysmgr_regs =
> > +#endif
> > +
> > +static const struct socfpga_system_manager *sysmgr_regs =
> > ? (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> > ?
> > ?u32 spl_boot_device(void)
> > ?{
> > ? const u32 bsel = readl(&sysmgr_regs->bootinfo);
> > ?
> > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > ? switch (bsel & 0x7) {
> > ? case 0x1: /* FPGA (HPS2FPGA Bridge) */
> > ? return BOOT_DEVICE_RAM;
> > @@ -55,6 +65,24 @@ u32 spl_boot_device(void)
> > ? printf("Invalid boot device (bsel=%08x)!\n",
> > bsel);
> > ? hang();
> > ? }
> > +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > + switch ((bsel>>12) & 0x7) {
> Spaces around the '>>'.
>
> >
> > + case 0x1: /* FPGA (HPS2FPGA Bridge) */
> > + return BOOT_DEVICE_RAM;
> > + case 0x2: /* NAND Flash (1.8V) */
> > + case 0x3: /* NAND Flash (3.0V) */
> > + return BOOT_DEVICE_NAND;
> > + case 0x4: /* SD/MMC External Transceiver (1.8V) */
> > + case 0x5: /* SD/MMC Internal Transceiver (3.0V) */
> > + return BOOT_DEVICE_MMC1;
> > + case 0x6: /* QSPI Flash (1.8V) */
> > + case 0x7: /* QSPI Flash (3.0V) */
> > + return BOOT_DEVICE_SPI;
> > + default:
> > + printf("Invalid boot device (bsel=%08x)!\n",
> > bsel);
> > + hang();
> > + }
> > +#endif
> > ?}
> You missed my comment from V1:
>
> You should just do a shift define??here, so you don't have to add
> all
> this extra code here. Something like
>
> switch ((bsel >> BOOTINFO_BSEL_SHIFT) & 0x7)
>
Okay, noted.
>
> Dinh
^ permalink raw reply
* Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations
From: Huang, Ying @ 2017-01-03 5:43 UTC (permalink / raw)
To: Minchan Kim
Cc: Jan Kara, Tim Chen, Andrew Morton, Ying Huang, dave.hansen, ak,
aaron.lu, linux-mm, linux-kernel, Hugh Dickins, Shaohua Li,
Rik van Riel, Andrea Arcangeli, Kirill A . Shutemov,
Vladimir Davydov, Johannes Weiner, Michal Hocko, Hillf Danton,
Christian Borntraeger, Jonathan Corbet, Peter Zijlstra,
Nicholas Piggin
In-Reply-To: <20170103043411.GA15657@bbox>
Hi, Minchan,
Minchan Kim <minchan@kernel.org> writes:
> Hi Jan,
>
> On Mon, Jan 02, 2017 at 04:48:41PM +0100, Jan Kara wrote:
>> Hi,
>>
>> On Tue 27-12-16 16:45:03, Minchan Kim wrote:
>> > > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
>> > > the rate that we have to contende for the radix tree.
>> >
>> > To me, it's rather hacky. I think it might be common problem for page cache
>> > so can we think another generalized way like range_lock? Ccing Jan.
>>
>> I agree on the hackyness of the patch and that page cache would suffer with
>> the same contention (although the files are usually smaller than swap so it
>> would not be that visible I guess). But I don't see how range lock would
>> help here - we need to serialize modifications of the tree structure itself
>> and that is difficult to achieve with the range lock. So what you would
>> need is either a different data structure for tracking swap cache entries
>> or a finer grained locking of the radix tree.
>
> Thanks for the comment, Jan.
>
> I think there are more general options. One is to shrink batching pages like
> Mel and Tim had approached.
>
> https://patchwork.kernel.org/patch/9008421/
> https://patchwork.kernel.org/patch/9322793/
This helps to reduce the lock contention on radix tree of swap cache.
But splitting swap cache has much better performance. So we switched
from that solution to current solution.
> Or concurrent page cache by peter.
>
> https://www.kernel.org/doc/ols/2007/ols2007v2-pages-311-318.pdf
I think this is good, it helps swap and file cache. But I don't know
whether other people want to go this way and how much effort will be
needed.
In contrast, splitting swap cache is quite simple, for implementation
and review. And the effect is good.
Best Regards,
Huang, Ying
> Ccing Nick who might have an interest on lockless page cache.
>
> Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-03 5:38 UTC (permalink / raw)
To: Archit Taneja, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <da6d299e-be36-7564-f57f-ba5e3601cafc@codeaurora.org>
On Tuesday 03 January 2017 10:56 AM, Archit Taneja wrote:
> Hi Sekhar,
>
> On 1/2/2017 4:38 PM, Sekhar Nori wrote:
>> Hi Archit,
>>
>> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>>
>>>
>>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>>> THS8135 is a configurable video DAC, but no configuration is actually
>>>> necessary to make it work.
>>>>
>>>> For now use the dumb-vga-dac driver to support it.
>>>
>>> Queued to drm-misc-next
>>
>> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
>> to v4.10?
>
> These missed out on 4.10 because the drm related pull requests were
> already sent by then. These 2 patches are queued for 4.11.
Alright, thanks for the update.
Regards,
Sekhar
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-03 5:38 UTC (permalink / raw)
To: Archit Taneja, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <da6d299e-be36-7564-f57f-ba5e3601cafc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tuesday 03 January 2017 10:56 AM, Archit Taneja wrote:
> Hi Sekhar,
>
> On 1/2/2017 4:38 PM, Sekhar Nori wrote:
>> Hi Archit,
>>
>> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>>
>>>
>>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>>> THS8135 is a configurable video DAC, but no configuration is actually
>>>> necessary to make it work.
>>>>
>>>> For now use the dumb-vga-dac driver to support it.
>>>
>>> Queued to drm-misc-next
>>
>> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
>> to v4.10?
>
> These missed out on 4.10 because the drm related pull requests were
> already sent by then. These 2 patches are queued for 4.11.
Alright, thanks for the update.
Regards,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-03 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da6d299e-be36-7564-f57f-ba5e3601cafc@codeaurora.org>
On Tuesday 03 January 2017 10:56 AM, Archit Taneja wrote:
> Hi Sekhar,
>
> On 1/2/2017 4:38 PM, Sekhar Nori wrote:
>> Hi Archit,
>>
>> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>>
>>>
>>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>>> THS8135 is a configurable video DAC, but no configuration is actually
>>>> necessary to make it work.
>>>>
>>>> For now use the dumb-vga-dac driver to support it.
>>>
>>> Queued to drm-misc-next
>>
>> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
>> to v4.10?
>
> These missed out on 4.10 because the drm related pull requests were
> already sent by then. These 2 patches are queued for 4.11.
Alright, thanks for the update.
Regards,
Sekhar
^ permalink raw reply
* [PATCH v3 2/2] ucm: Add command 'get _file' to get the config file name of the opened card
From: mengdong.lin @ 2017-01-03 5:41 UTC (permalink / raw)
To: alsa-devel, broonie
Cc: Mengdong Lin, tiwai, mengdong.lin, liam.r.girdwood, vinod.koul,
pierre-louis.bossart
In-Reply-To: <cover.1483421175.git.mengdong.lin@linux.intel.com>
From: Mengdong Lin <mengdong.lin@linux.intel.com>
After opening a card, this command can show the name of the actually
loaded configuration file, either matches the card name or card long name.
So developers can check if there is a device-sepcific configuration file
available for a given card.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
diff --git a/include/use-case.h b/include/use-case.h
index 8911645..ae22bde 100644
--- a/include/use-case.h
+++ b/include/use-case.h
@@ -230,6 +230,7 @@ int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,
* Known identifiers:
* - NULL - return current card
* - _verb - return current verb
+ * - _file - return configuration file loaded for current card
*
* - [=]{NAME}[/[{modifier}|{/device}][/{verb}]]
* - value identifier {NAME}
diff --git a/src/ucm/main.c b/src/ucm/main.c
index 38a5e81..2d33886 100644
--- a/src/ucm/main.c
+++ b/src/ucm/main.c
@@ -1528,6 +1528,20 @@ int snd_use_case_get(snd_use_case_mgr_t *uc_mgr,
goto __end;
}
err = 0;
+ } else if (strcmp(identifier, "_file") == 0) {
+ /* get the conf file name of the opened card */
+ if ((uc_mgr->card_name == NULL)
+ || (uc_mgr->conf_file_name[0] == '\0')) {
+ err = -ENOENT;
+ goto __end;
+ }
+ *value = strndup(uc_mgr->conf_file_name, MAX_FILE);
+ if (*value == NULL) {
+ err = -ENOMEM;
+ goto __end;
+ }
+ err = 0;
+
} else if (identifier[0] == '_') {
err = -ENOENT;
goto __end;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] ucm: Load device-specific configuration file based on the card long name
From: mengdong.lin @ 2017-01-03 5:41 UTC (permalink / raw)
To: alsa-devel, broonie
Cc: Mengdong Lin, tiwai, mengdong.lin, liam.r.girdwood, vinod.koul,
pierre-louis.bossart
In-Reply-To: <cover.1483421175.git.mengdong.lin@linux.intel.com>
From: Mengdong Lin <mengdong.lin@linux.intel.com>
Intel DSP platform drivers are used by many different devices. For user
space to differentiate them, ASoC machine drivers may use the DMI info
(vendor.product.board) as card long name. Possible card long names
are:
DellInc..XPS139343.0310JH
IntelCorp..BroadwellClientplatform.WilsonBeachSDS
ASUSTeKCOMPUTERINC..T100TA.T100TA
Circuitco.MinnowboardMaxD0PLATFORM.MinnowBoardMAX
...
And user space can define configuration files like longname\longname.conf
for a specific device.
When being asked to load configuration file of a card, UCM will try to
find the card in the local machine and get its long name. If the card
long name is available, try to load the file longname\longname.conf to
get the best device-specific configuration; if this file is not available,
fall back to load the default configuration file name\name.conf as
before.
This update is backward compatible, because if ASoC machine drivers don't
explicity use DMI or other means to set the card long name, ASoC core
will use the card name as the long name. So UCM will load the config
file that matches both the card name and the long name.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
diff --git a/src/ucm/parser.c b/src/ucm/parser.c
index c98373a..14ee33f 100644
--- a/src/ucm/parser.c
+++ b/src/ucm/parser.c
@@ -55,6 +55,9 @@ static const char * const component_dir[] = {
NULL, /* terminator */
};
+static int filename_filter(const struct dirent *dirent);
+static int is_component_directory(const char *dir);
+
static int parse_sequence(snd_use_case_mgr_t *uc_mgr,
struct list_head *base,
snd_config_t *cfg);
@@ -1328,6 +1331,66 @@ static int parse_master_file(snd_use_case_mgr_t *uc_mgr, snd_config_t *cfg)
return 0;
}
+/* find the card in the local machine and store the card long name */
+static int get_card_long_name(snd_use_case_mgr_t *mgr)
+{
+ const char *card_name = mgr->card_name;
+ snd_ctl_t *handle;
+ int card, err;
+ snd_ctl_card_info_t *info;
+ const char *_name, *_long_name;
+
+ snd_ctl_card_info_alloca(&info);
+
+ card = -1;
+ if (snd_card_next(&card) < 0 || card < 0) {
+ uc_error("no soundcards found...");
+ return -1;
+ }
+
+ while (card >= 0) {
+ char name[32];
+
+ sprintf(name, "hw:%d", card);
+ err = snd_ctl_open(&handle, name, 0);
+ if (err < 0) {
+ uc_error("control open (%i): %s", card,
+ snd_strerror(err));
+ goto next_card;
+ }
+
+ err = snd_ctl_card_info(handle, info);
+ if (err < 0) {
+ uc_error("control hardware info (%i): %s", card,
+ snd_strerror(err));
+ snd_ctl_close(handle);
+ goto next_card;
+ }
+
+ /* Find the local card by comparing the given name with the
+ * card name and long name. User may open a card by its long
+ * name, so the given card name may be a long name.
+ */
+ _name = snd_ctl_card_info_get_name(info);
+ _long_name = snd_ctl_card_info_get_longname(info);
+ if (!strncmp(card_name, _name, MAX_CARD_LONG_NAME)
+ || !strncmp(card_name, _long_name, MAX_CARD_LONG_NAME)) {
+ strncpy(mgr->card_long_name, _long_name,
+ MAX_CARD_LONG_NAME - 1);
+ snd_ctl_close(handle);
+ return 0;
+ }
+
+ snd_ctl_close(handle);
+next_card:
+ if (snd_card_next(&card) < 0) {
+ uc_error("snd_card_next");
+ break;
+ }
+ }
+
+ return -1;
+}
static int load_master_config(const char *card_name, snd_config_t **cfg)
{
char filename[MAX_FILE];
@@ -1349,15 +1412,45 @@ static int load_master_config(const char *card_name, snd_config_t **cfg)
return 0;
}
-/* load master use case file for sound card */
+/* load master use case file for sound card
+ *
+ * The same ASoC machine driver can be shared by many different devices.
+ * For user space to differentiate them and get the best device-specific
+ * configuration, ASoC machine drivers may use the DMI info
+ * (vendor.product.board) as the card long name. And user space can define
+ * configuration files like longname\longname.conf for a specific device.
+ *
+ * This function will try to find the card in the local machine and get its
+ * long name, then load the file longname\longname.conf to get the best
+ * device-specific configuration. If the card is not found in the local
+ * machine or the device-specific file is not available, fall back to load
+ * the default configuration file name\name.conf.
+ */
int uc_mgr_import_master_config(snd_use_case_mgr_t *uc_mgr)
{
snd_config_t *cfg;
int err;
- err = load_master_config(uc_mgr->card_name, &cfg);
- if (err < 0)
- return err;
+ err = get_card_long_name(uc_mgr);
+ if (err == 0) /* load file that maches the card long name */
+ err = load_master_config(uc_mgr->card_long_name, &cfg);
+
+ if (err == 0) {
+ /* got device-specific file that matches the card long name */
+ strncpy(uc_mgr->conf_file_name, uc_mgr->card_long_name,
+ MAX_CARD_LONG_NAME - 1);
+ } else {
+ /* Fall back to the file that maches the given card name,
+ * either short name or long name (users may open a card by
+ * its name or long name).
+ */
+ err = load_master_config(uc_mgr->card_name, &cfg);
+ if (err < 0)
+ return err;
+ strncpy(uc_mgr->conf_file_name, uc_mgr->card_name,
+ MAX_CARD_LONG_NAME - 1);
+ }
+
err = parse_master_file(uc_mgr, cfg);
snd_config_delete(cfg);
if (err < 0)
diff --git a/src/ucm/ucm_local.h b/src/ucm/ucm_local.h
index 6d3302f..299a5b9 100644
--- a/src/ucm/ucm_local.h
+++ b/src/ucm/ucm_local.h
@@ -41,6 +41,7 @@
#include "use-case.h"
#define MAX_FILE 256
+#define MAX_CARD_LONG_NAME 80
#define ALSA_USE_CASE_DIR ALSA_CONFIG_DIR "/ucm"
#define SEQUENCE_ELEMENT_TYPE_CDEV 1
@@ -190,6 +191,8 @@ struct use_case_verb {
*/
struct snd_use_case_mgr {
char *card_name;
+ char card_long_name[MAX_CARD_LONG_NAME];
+ char conf_file_name[MAX_CARD_LONG_NAME];
char *comment;
/* use case verb, devices and modifier configs parsed from files */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] ucm: Automatically load the best config file based on the card long name
From: mengdong.lin @ 2017-01-03 5:41 UTC (permalink / raw)
To: alsa-devel, broonie
Cc: Mengdong Lin, tiwai, mengdong.lin, liam.r.girdwood, vinod.koul,
pierre-louis.bossart
From: Mengdong Lin <mengdong.lin@linux.intel.com>
Intel DSP platform drivers are used by many different devices. For user
space to differentiate them, now ASoC provide API for machine drivers to
include the DMI info (vendor, product and board) in card long name. This
series will add UCM support for loading best device-specific configuration
based on the card long name.
For the ASoC kernel patch, please see
ASoC: core: Add API to use DMI name in sound card long name (v2)
Mengdong Lin (2):
ucm: Load device-specific configuration file based on the card long
name
ucm: Add command 'get _file' to get the config file name of the opened
card
History:
v2: Request the device-specific file name to match the card long name,
no long use automatic key word matching and scoring to avoid error
and uncertainty. And add command to check the name of actually loaded
configuration file.
v3: Fix num in strncpy of the long name, which should be
MAX_CARD_LONG_NAME - 1, not MAX_CARD_LONG_NAME (80).
Mengdong Lin (2):
ucm: Load device-specific configuration file based on the card long
name
ucm: Add command 'get _file' to get the config file name of the opened
card
include/use-case.h | 1 +
src/ucm/main.c | 14 ++++++++
src/ucm/parser.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++---
src/ucm/ucm_local.h | 3 ++
4 files changed, 115 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [U-Boot] [PATCH v2 21/30] arm: socfpga: arria10: Enhanced socfpga_arria10_defconfig to support SPL
From: Chee, Tien Fong @ 2017-01-03 5:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <e44bf887-69ca-4267-7fd9-e3133f5934cd@denx.de>
On Jum, 2016-12-30 at 20:04 +0100, Marek Vasut wrote:
> On 12/29/2016 05:54 AM, Chee, Tien Fong wrote:
> >
> > On Kha, 2016-12-29 at 00:51 +0100, Marek Vasut wrote:
> > >
> > > On 12/28/2016 07:34 AM, Chee Tien Fong wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > >
> > > > Enhanced defconfig file for Arria10 to enable SPL build and
> > > > supporting
> > > > device tree build for SDMMC.
> > > >
> > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > Cc: Marek Vasut <marex@denx.de>
> > > > Cc: Dinh Nguyen <dinguyen@kernel.org>
> > > > Cc: Chin Liang See <chin.liang.see@intel.com>
> > > > Cc: Tien Fong <skywindctf@gmail.com>
> > > > ---
> > > > Changes for V2
> > > > - Removed boot header info setup since it already fixed in
> > > > mainline
> > > > ---
> > > > ?configs/socfpga_arria10_defconfig | 18 +++++++++++++-----
> > > > ?1 file changed, 13 insertions(+), 5 deletions(-)
> > > There's no arria10 defconfig in mainline ?
> > > I only received patches 18/30 and on ?
> > >
> > patch1 to patch17 are 01-arria10 rebase on u-boot.git, i believe
> > those
> > patches not CC to you orginally. Could you get from U-Boot Digest,
> > Vol
> > 103, Issue 53, or you want me to edit those patches CC to you?
> No, you cannot get them from the digest, it's a digest after all.
> I can get them from the list, but please always CC maintainers on
> relevant patches.
>
Yeah, i think so. I re-send patch1 to patch17 last week, i believe you?
received all of them already.
^ permalink raw reply
* [PATCH v2.1 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Sekhar Nori @ 2017-01-03 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208001418.4469-1-khilman@baylibre.com>
Hi Kevin,
On Thursday 08 December 2016 05:44 AM, Kevin Hilman wrote:
> Add VPIF node an pins to da850 and enable on boards. VPIF has two input
> channels described using the standard DT ports and enpoints.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> v2 -> v2.1: moved ports from SoC .dtsi to board .dts files.
>
> arch/arm/boot/dts/da850-evm.dts | 20 ++++++++++++++++++++
> arch/arm/boot/dts/da850-lcdk.dts | 13 +++++++++++++
> arch/arm/boot/dts/da850.dtsi | 27 ++++++++++++++++++++++++++-
> 3 files changed, 59 insertions(+), 1 deletion(-)
Can you split this patch to keep the SoC addition separate from board
updates. Separating support addition for EVM and LCDK will be good also.
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b91c680..5f0b40510b2b 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -399,7 +410,21 @@
> <&edma0 0 1>;
> dma-names = "tx", "rx";
> };
> +
> + vpif: video at 217000 {
> + compatible = "ti,da850-vpif";
> + reg = <0x217000 0x1000>;
> + interrupts = <92>;
> + status = "disabled";
> +
> + /* VPIF capture port */
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
Can you add this node just above mmc1? I am trying to keep the nodes
sorted in the order of unit address instead of new ones getting added at
the end. Unfortunately, it was not strictly enforced and we have many
breakages. But lets add the new ones where they will eventually end up.
Thanks,
Sekhar
^ permalink raw reply
* [UPDATE PATCH 14/18] ACPICA: Fix for implicit result conversion for the ToXxx functions
From: Lv Zheng @ 2017-01-03 5:30 UTC (permalink / raw)
To: Rafael J . Wysocki, Rafael J . Wysocki, Len Brown
Cc: Lv Zheng, Lv Zheng, linux-acpi, Bob Moore
In-Reply-To: <cover.1482821486.git.lv.zheng@intel.com>
From: Bob Moore <robert.moore@intel.com>
ACPICA commit e1342c9f2dde37a67e916099658b65984ef8a434
Implicit result conversion was incorrectly disabled for the
following functions:
FromBCD
ToBCD
ToDecimalString
ToHexString
ToInteger
ToBuffer
Subject rephrased by Lv Zheng due to SMTP 550:
The capital Triple-X in subject is a way too often associated with junk
email.
Link: https://github.com/acpica/acpica/commit/e1342c9f
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
---
drivers/acpi/acpica/acopcode.h | 14 +++++++-------
drivers/acpi/acpica/amlcode.h | 20 +++++++++++++++++---
drivers/acpi/acpica/exconvrt.c | 1 -
drivers/acpi/acpica/exresop.c | 1 -
4 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/acpica/acopcode.h b/drivers/acpi/acpica/acopcode.h
index ca4bda1..84d611b 100644
--- a/drivers/acpi/acpica/acopcode.h
+++ b/drivers/acpi/acpica/acopcode.h
@@ -249,7 +249,7 @@
#define ARGI_FIELD_OP ARGI_INVALID_OPCODE
#define ARGI_FIND_SET_LEFT_BIT_OP ARGI_LIST2 (ARGI_INTEGER, ARGI_TARGETREF)
#define ARGI_FIND_SET_RIGHT_BIT_OP ARGI_LIST2 (ARGI_INTEGER, ARGI_TARGETREF)
-#define ARGI_FROM_BCD_OP ARGI_LIST2 (ARGI_INTEGER, ARGI_FIXED_TARGET)
+#define ARGI_FROM_BCD_OP ARGI_LIST2 (ARGI_INTEGER, ARGI_TARGETREF)
#define ARGI_IF_OP ARGI_INVALID_OPCODE
#define ARGI_INCREMENT_OP ARGI_LIST1 (ARGI_TARGETREF)
#define ARGI_INDEX_FIELD_OP ARGI_INVALID_OPCODE
@@ -313,12 +313,12 @@
#define ARGI_SUBTRACT_OP ARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF)
#define ARGI_THERMAL_ZONE_OP ARGI_INVALID_OPCODE
#define ARGI_TIMER_OP ARG_NONE
-#define ARGI_TO_BCD_OP ARGI_LIST2 (ARGI_INTEGER, ARGI_FIXED_TARGET)
-#define ARGI_TO_BUFFER_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_FIXED_TARGET)
-#define ARGI_TO_DEC_STR_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_FIXED_TARGET)
-#define ARGI_TO_HEX_STR_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_FIXED_TARGET)
-#define ARGI_TO_INTEGER_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_FIXED_TARGET)
-#define ARGI_TO_STRING_OP ARGI_LIST3 (ARGI_BUFFER, ARGI_INTEGER, ARGI_FIXED_TARGET)
+#define ARGI_TO_BCD_OP ARGI_LIST2 (ARGI_INTEGER, ARGI_TARGETREF)
+#define ARGI_TO_BUFFER_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_TARGETREF)
+#define ARGI_TO_DEC_STR_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_TARGETREF)
+#define ARGI_TO_HEX_STR_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_TARGETREF)
+#define ARGI_TO_INTEGER_OP ARGI_LIST2 (ARGI_COMPUTEDATA,ARGI_TARGETREF)
+#define ARGI_TO_STRING_OP ARGI_LIST3 (ARGI_BUFFER, ARGI_INTEGER, ARGI_TARGETREF)
#define ARGI_UNLOAD_OP ARGI_LIST1 (ARGI_DDBHANDLE)
#define ARGI_VAR_PACKAGE_OP ARGI_LIST1 (ARGI_INTEGER)
#define ARGI_WAIT_OP ARGI_LIST2 (ARGI_EVENT, ARGI_INTEGER)
diff --git a/drivers/acpi/acpica/amlcode.h b/drivers/acpi/acpica/amlcode.h
index 6bd8d4b..8a0f959 100644
--- a/drivers/acpi/acpica/amlcode.h
+++ b/drivers/acpi/acpica/amlcode.h
@@ -277,9 +277,23 @@
#define ARGI_DEVICE_REF 0x0D
#define ARGI_REFERENCE 0x0E
#define ARGI_TARGETREF 0x0F /* Target, subject to implicit conversion */
-#define ARGI_FIXED_TARGET 0x10 /* Target, no implicit conversion */
-#define ARGI_SIMPLE_TARGET 0x11 /* Name, Local, Arg -- no implicit conversion */
-#define ARGI_STORE_TARGET 0x12 /* Target for store is TARGETREF + package objects */
+#define ARGI_SIMPLE_TARGET 0x10 /* Name, Local, Arg -- no implicit conversion */
+#define ARGI_STORE_TARGET 0x11 /* Target for store is TARGETREF + package objects */
+/*
+ * #define ARGI_FIXED_TARGET 0x10 Target, no implicit conversion
+ *
+ * Removed 10/2016. ARGI_FIXED_TARGET was used for these operators:
+ * from_BCD
+ * to_BCD
+ * to_decimal_string
+ * to_hex_string
+ * to_integer
+ * to_buffer
+ * The purpose of this type was to disable "implicit result conversion",
+ * but this was incorrect per the ACPI spec and other ACPI implementations.
+ * These operators now have the target operand defined as a normal
+ * ARGI_TARGETREF.
+ */
/* Multiple/complex types */
diff --git a/drivers/acpi/acpica/exconvrt.c b/drivers/acpi/acpica/exconvrt.c
index 588ad14..83202db 100644
--- a/drivers/acpi/acpica/exconvrt.c
+++ b/drivers/acpi/acpica/exconvrt.c
@@ -592,7 +592,6 @@ acpi_ex_convert_to_target_type(acpi_object_type destination_type,
*/
switch (GET_CURRENT_ARG_TYPE(walk_state->op_info->runtime_args)) {
case ARGI_SIMPLE_TARGET:
- case ARGI_FIXED_TARGET:
case ARGI_INTEGER_REF: /* Handles Increment, Decrement cases */
switch (destination_type) {
diff --git a/drivers/acpi/acpica/exresop.c b/drivers/acpi/acpica/exresop.c
index f29eba1..d4c386d 100644
--- a/drivers/acpi/acpica/exresop.c
+++ b/drivers/acpi/acpica/exresop.c
@@ -305,7 +305,6 @@ acpi_ex_resolve_operands(u16 opcode,
case ARGI_OBJECT_REF:
case ARGI_DEVICE_REF:
case ARGI_TARGETREF: /* Allows implicit conversion rules before store */
- case ARGI_FIXED_TARGET: /* No implicit conversion before store to target */
case ARGI_SIMPLE_TARGET: /* Name, Local, or arg - no implicit conversion */
case ARGI_STORE_TARGET:
--
2.7.4
^ permalink raw reply related
* Re: [1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2017-01-03 5:28 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Kalle Valo, linux-wireless, ath10k
In-Reply-To: <CAAd0S9DcCM9XQOihZx1sVf_1=S3VvDye4k1gEMgWEmNWDaBk5Q@mail.gmail.com>
Hi Christian / Kalle,
On Fri, Dec 30, 2016 at 03:35:10PM +0100, Christian Lamparter wrote:
> On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> > Christian Lamparter <chunkeey@googlemail.com> wrote:
> >> The 10.4 firmware adds extended peer information to the
> >> firmware's statistics payload. This additional info is
> >> stored as a separate data field and the elements are
> >> stored in their own "peers_extd" list.
> >>
> >> These elements can pile up in the same way as the peer
> >> information elements. This is because the
> >> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> >> pull the same amount (num_peer_stats) for every statistic
> >> data unit.
> >>
> >> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> >> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> >
> > My understanding is that I should skip this patch 1. Please let me know if
> > I misunderstood. But I'm still plannning to apply patch 2.
>
> I added Mohammed (I hope, he can reply to the open question when he
> returns), Since I'm not sure what he wants or not.
>
> As far as I'm aware, the "extended" boolean serves no purpose
> because it was only used in once place in debugfs_sta which was
> removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
> and "ath10k_sta_update_extd_stats_rx_duration" have been unified).
[shafi] We will wait for Kalle to review from the de-ferred stage
and get his opinion as well(regarding the design change).
I have no concerns as long this does not changes the existing behaviour.
thank you !
regards,
shafi
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2017-01-03 5:28 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Kalle Valo, linux-wireless, ath10k
In-Reply-To: <CAAd0S9DcCM9XQOihZx1sVf_1=S3VvDye4k1gEMgWEmNWDaBk5Q@mail.gmail.com>
Hi Christian / Kalle,
On Fri, Dec 30, 2016 at 03:35:10PM +0100, Christian Lamparter wrote:
> On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> > Christian Lamparter <chunkeey@googlemail.com> wrote:
> >> The 10.4 firmware adds extended peer information to the
> >> firmware's statistics payload. This additional info is
> >> stored as a separate data field and the elements are
> >> stored in their own "peers_extd" list.
> >>
> >> These elements can pile up in the same way as the peer
> >> information elements. This is because the
> >> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> >> pull the same amount (num_peer_stats) for every statistic
> >> data unit.
> >>
> >> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> >> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> >
> > My understanding is that I should skip this patch 1. Please let me know if
> > I misunderstood. But I'm still plannning to apply patch 2.
>
> I added Mohammed (I hope, he can reply to the open question when he
> returns), Since I'm not sure what he wants or not.
>
> As far as I'm aware, the "extended" boolean serves no purpose
> because it was only used in once place in debugfs_sta which was
> removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
> and "ath10k_sta_update_extd_stats_rx_duration" have been unified).
[shafi] We will wait for Kalle to review from the de-ferred stage
and get his opinion as well(regarding the design change).
I have no concerns as long this does not changes the existing behaviour.
thank you !
regards,
shafi
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Archit Taneja @ 2017-01-03 5:26 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <0b47c27e-cda4-b5f6-ff3c-da74c40ed204@ti.com>
Hi Sekhar,
On 1/2/2017 4:38 PM, Sekhar Nori wrote:
> Hi Archit,
>
> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>
>>
>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>> THS8135 is a configurable video DAC, but no configuration is actually
>>> necessary to make it work.
>>>
>>> For now use the dumb-vga-dac driver to support it.
>>
>> Queued to drm-misc-next
>
> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
> to v4.10?
These missed out on 4.10 because the drm related pull requests were
already sent by then. These 2 patches are queued for 4.11.
Thanks,
Archit
>
> Thanks,
> Sekhar
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
From: James Bottomley @ 2017-01-03 5:26 UTC (permalink / raw)
To: Jarkko Sakkinen; +Cc: linux-security-module, tpmdd-devel, open list
In-Reply-To: <1483393248.2458.32.camel@HansenPartnership.com>
On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > This patch set adds support for TPM spaces that provide a
> > > > context for isolating and swapping transient objects. This
> > > > patch set does not yet include support for isolating policy and
> > > > HMAC sessions but it is trivial to add once the basic approach
> > > > is settled (and that's why I created an RFC patch set).
> > >
> > > The approach looks fine to me. The only basic query I have is
> > > about the default: shouldn't it be with resource manager on
> > > rather than off? I can't really think of a use case that wants
> > > the RM off (even if you're running your own, having another
> > > doesn't hurt anything, and it's still required to share with in
> > > -kernel uses).
> >
> > This is a valid question and here's a longish explanation.
> >
> > In TPM2_GetCapability and maybe couple of other commands you can
> > get handles in the response body. I do not want to have special
> > cases in the kernel for response bodies because there is no a
> > generic way to do the substitution. What's worse, new commands in
> > the standard future revisions could have such commands requiring
> > special cases. In addition, vendor specific commans could have
> > handles in the response bodies.
>
> OK, in general I buy this ... what you're effectively saying is that
> we need a non-RM interface for certain management type commands.
>
> However, let me expand a bit on why I'm fretting about the non-RM use
> case. Right at the moment, we have a single TPM device which you use
> for access to the kernel TPM. The current tss2 just makes direct use
> of this, meaning it has to have 0666 permissions. This means that
> any local user can simply DoS the TPM by running us out of transient
> resources if they don't activate the RM. If they get a connection
> always via the RM, this isn't a worry. Perhaps the best way of
> fixing this is to expose two separate device nodes: one raw to the
> TPM which we could keep at 0600 and one with an always RM connection
> which we can set to 0666. That would mean that access to the non-RM
> connection is either root only or governed by a system set ACL.
OK, so I put a patch together that does this (see below). It all works
nicely (with a udev script that sets the resource manager device to
0666):
jejb@jarvis:~> ls -l /dev/tpm*
crw------- 1 root root 10, 224 Jan 2 20:54 /dev/tpm0
crw-rw-rw- 1 root root 246, 65536 Jan 2 20:54 /dev/tpm0rm
I've modified the tss to connect to /dev/tpm0rm by default and it all
seems to work.
The patch applies on top of your tabrm branch, by the way.
James
---
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index ac4c05f..25b8d30 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -33,6 +33,7 @@ DEFINE_IDR(dev_nums_idr);
static DEFINE_MUTEX(idr_lock);
struct class *tpm_class;
+struct class *tpm_rm_class;
dev_t tpm_devt;
/**
@@ -169,27 +170,39 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
chip->dev_num = rc;
device_initialize(&chip->dev);
+ device_initialize(&chip->devrm);
chip->dev.class = tpm_class;
chip->dev.release = tpm_dev_release;
chip->dev.parent = pdev;
chip->dev.groups = chip->groups;
+ chip->devrm.parent = pdev;
+ chip->devrm.class = tpm_rm_class;
+
if (chip->dev_num == 0)
chip->dev.devt = MKDEV(MISC_MAJOR, TPM_MINOR);
else
chip->dev.devt = MKDEV(MAJOR(tpm_devt), chip->dev_num);
+ chip->devrm.devt = MKDEV(MAJOR(tpm_devt), chip->dev_num + TPM_NUM_DEVICES);
+
rc = dev_set_name(&chip->dev, "tpm%d", chip->dev_num);
if (rc)
goto out;
+ rc = dev_set_name(&chip->devrm, "tpm%drm", chip->dev_num);
+ if (rc)
+ goto out;
if (!pdev)
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
cdev_init(&chip->cdev, &tpm_fops);
+ cdev_init(&chip->cdevrm, &tpm_rm_fops);
chip->cdev.owner = THIS_MODULE;
+ chip->cdevrm.owner = THIS_MODULE;
chip->cdev.kobj.parent = &chip->dev.kobj;
+ chip->cdevrm.kobj.parent = &chip->devrm.kobj;
chip->tr_buf.data = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
if (!chip->tr_buf.data) {
@@ -208,6 +221,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
out:
put_device(&chip->dev);
+ put_device(&chip->devrm);
return ERR_PTR(rc);
}
EXPORT_SYMBOL_GPL(tpm_chip_alloc);
@@ -252,7 +266,7 @@ static int tpm_add_char_device(struct tpm_chip *chip)
dev_name(&chip->dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
- return rc;
+ goto err_1;
}
rc = device_add(&chip->dev);
@@ -262,16 +276,44 @@ static int tpm_add_char_device(struct tpm_chip *chip)
dev_name(&chip->dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
- cdev_del(&chip->cdev);
- return rc;
+ goto err_2;
+ }
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ rc = cdev_add(&chip->cdevrm, chip->devrm.devt, 1);
+ if (rc) {
+ dev_err(&chip->dev,
+ "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+ dev_name(&chip->devrm), MAJOR(chip->devrm.devt),
+ MINOR(chip->devrm.devt), rc);
+
+ goto err_3;
}
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ rc = device_add(&chip->devrm);
+ if (rc) {
+ dev_err(&chip->dev,
+ "unable to device_register() %s, major %d, minor %d, err=%d\n",
+ dev_name(&chip->devrm), MAJOR(chip->devrm.devt),
+ MINOR(chip->devrm.devt), rc);
+
+ goto err_4;
+ }
/* Make the chip available. */
mutex_lock(&idr_lock);
idr_replace(&dev_nums_idr, chip, chip->dev_num);
mutex_unlock(&idr_lock);
return rc;
+ err_4:
+ cdev_del(&chip->cdevrm);
+ err_3:
+ device_del(&chip->dev);
+ err_2:
+ cdev_del(&chip->cdev);
+ err_1:
+ return rc;
}
static void tpm_del_char_device(struct tpm_chip *chip)
@@ -279,6 +321,11 @@ static void tpm_del_char_device(struct tpm_chip *chip)
cdev_del(&chip->cdev);
device_del(&chip->dev);
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ cdev_del(&chip->cdevrm);
+ device_del(&chip->devrm);
+ }
+
/* Make the chip unavailable. */
mutex_lock(&idr_lock);
idr_replace(&dev_nums_idr, NULL, chip->dev_num);
diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
index 139638b..bed29f9 100644
--- a/drivers/char/tpm/tpm-dev.c
+++ b/drivers/char/tpm/tpm-dev.c
@@ -54,23 +54,28 @@ static void timeout_work(struct work_struct *work)
mutex_unlock(&priv->buffer_mutex);
}
-static int tpm_open(struct inode *inode, struct file *file)
+static int tpm_open_internal(struct inode *inode, struct file *file, bool is_rm)
{
- struct tpm_chip *chip =
- container_of(inode->i_cdev, struct tpm_chip, cdev);
+ struct tpm_chip *chip;
struct file_priv *priv;
+ if (is_rm)
+ chip = container_of(inode->i_cdev, struct tpm_chip, cdevrm);
+ else
+ chip = container_of(inode->i_cdev, struct tpm_chip, cdev);
+
/* It's assured that the chip will be opened just once,
* by the check of is_open variable, which is protected
* by driver_lock. */
- if (test_and_set_bit(0, &chip->is_open)) {
+ if (!is_rm && test_and_set_bit(0, &chip->is_open)) {
dev_dbg(&chip->dev, "Another process owns this TPM\n");
return -EBUSY;
}
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (priv == NULL) {
- clear_bit(0, &chip->is_open);
+ if (!is_rm)
+ clear_bit(0, &chip->is_open);
return -ENOMEM;
}
@@ -82,9 +87,27 @@ static int tpm_open(struct inode *inode, struct file *file)
INIT_WORK(&priv->work, timeout_work);
file->private_data = priv;
+
+ if (is_rm) {
+ priv->space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!priv->space.context_buf)
+ return -ENOMEM;
+ priv->has_space = true;
+ }
+
return 0;
}
+static int tpm_open(struct inode *inode, struct file *file)
+{
+ return tpm_open_internal(inode, file, false);
+}
+
+static int tpm_rm_open(struct inode *inode, struct file *file)
+{
+ return tpm_open_internal(inode, file, true);
+}
+
static ssize_t tpm_read(struct file *file, char __user *buf,
size_t size, loff_t *off)
{
@@ -169,65 +192,6 @@ static ssize_t tpm_write(struct file *file, const char __user *buf,
return in_size;
}
-/**
- * tpm_ioc_new_space - handler for %SGX_IOC_NEW_SPACE ioctl
- *
- * Creates a new TPM space that can hold a set of transient objects. The space
- * is isolated with virtual handles that are mapped into physical handles by the
- * driver.
- */
-static long tpm_ioc_new_space(struct file *file, unsigned int ioctl,
- unsigned long arg)
-{
- struct file_priv *priv = file->private_data;
- struct tpm_chip *chip = priv->chip;
- int rc = 0;
-
- if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
- return -EOPNOTSUPP;
-
- mutex_lock(&priv->buffer_mutex);
-
- if (priv->has_space) {
- rc = -EBUSY;
- goto out;
- }
-
- priv->space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
- if (!priv->space.context_buf) {
- rc = -ENOMEM;
- goto out;
- }
-
- /* The TPM device can be opened again as this file has been moved to a
- * TPM handle space.
- */
- priv->has_space = true;
- clear_bit(0, &chip->is_open);
-out:
- mutex_unlock(&priv->buffer_mutex);
- return rc;
-}
-
-static long tpm_ioctl(struct file *file, unsigned int ioctl,
- unsigned long arg)
-{
- switch (ioctl) {
- case TPM_IOC_NEW_SPACE:
- return tpm_ioc_new_space(file, ioctl, arg);
- default:
- return -ENOIOCTLCMD;
- }
-}
-
-#ifdef CONFIG_COMPAT
-static long tpm_compat_ioctl(struct file *file, unsigned int ioctl,
- unsigned long arg)
-{
- return tpm_ioctl(file, ioctl, arg);
-}
-#endif
-
/*
* Called on file close
*/
@@ -247,7 +211,8 @@ static int tpm_release(struct inode *inode, struct file *file)
flush_work(&priv->work);
file->private_data = NULL;
atomic_set(&priv->data_pending, 0);
- clear_bit(0, &priv->chip->is_open);
+ if (!priv->has_space)
+ clear_bit(0, &priv->chip->is_open);
kfree(priv);
return 0;
}
@@ -258,10 +223,15 @@ const struct file_operations tpm_fops = {
.open = tpm_open,
.read = tpm_read,
.write = tpm_write,
- .unlocked_ioctl = tpm_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = tpm_compat_ioctl,
-#endif
+ .release = tpm_release,
+};
+
+const struct file_operations tpm_rm_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .open = tpm_rm_open,
+ .read = tpm_read,
+ .write = tpm_write,
.release = tpm_release,
};
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a1ae57e..c1829de 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1194,9 +1194,17 @@ static int __init tpm_init(void)
return PTR_ERR(tpm_class);
}
- rc = alloc_chrdev_region(&tpm_devt, 0, TPM_NUM_DEVICES, "tpm");
+ tpm_rm_class = class_create(THIS_MODULE, "tpmrm");
+ if (IS_ERR(tpm_rm_class)) {
+ pr_err("couldn't create tpmrm class\n");
+ class_destroy(tpm_class);
+ return PTR_ERR(tpm_rm_class);
+ }
+
+ rc = alloc_chrdev_region(&tpm_devt, 0, 2*TPM_NUM_DEVICES, "tpm");
if (rc < 0) {
pr_err("tpm: failed to allocate char dev region\n");
+ class_destroy(tpm_rm_class);
class_destroy(tpm_class);
return rc;
}
@@ -1208,7 +1216,8 @@ static void __exit tpm_exit(void)
{
idr_destroy(&dev_nums_idr);
class_destroy(tpm_class);
- unregister_chrdev_region(tpm_devt, TPM_NUM_DEVICES);
+ class_destroy(tpm_rm_class);
+ unregister_chrdev_region(tpm_devt, 2*TPM_NUM_DEVICES);
}
subsys_initcall(tpm_init);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index c6171e5..890fb6b 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -186,8 +186,8 @@ struct tpm_buf {
};
struct tpm_chip {
- struct device dev;
- struct cdev cdev;
+ struct device dev, devrm;
+ struct cdev cdev, cdevrm;
/* A driver callback under ops cannot be run unless ops_sem is held
* (sometimes implicitly, eg for the sysfs code). ops becomes null
@@ -493,8 +493,10 @@ static inline void tpm_buf_append_u32(struct tpm_buf *buf, const u32 value)
}
extern struct class *tpm_class;
+extern struct class *tpm_rm_class;
extern dev_t tpm_devt;
extern const struct file_operations tpm_fops;
+extern const struct file_operations tpm_rm_fops;
extern struct idr dev_nums_idr;
enum tpm_transmit_flags {
^ permalink raw reply related
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Archit Taneja @ 2017-01-03 5:26 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc
In-Reply-To: <0b47c27e-cda4-b5f6-ff3c-da74c40ed204@ti.com>
Hi Sekhar,
On 1/2/2017 4:38 PM, Sekhar Nori wrote:
> Hi Archit,
>
> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>
>>
>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>> THS8135 is a configurable video DAC, but no configuration is actually
>>> necessary to make it work.
>>>
>>> For now use the dumb-vga-dac driver to support it.
>>
>> Queued to drm-misc-next
>
> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
> to v4.10?
These missed out on 4.10 because the drm related pull requests were
already sent by then. These 2 patches are queued for 4.11.
Thanks,
Archit
>
> Thanks,
> Sekhar
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Archit Taneja @ 2017-01-03 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b47c27e-cda4-b5f6-ff3c-da74c40ed204@ti.com>
Hi Sekhar,
On 1/2/2017 4:38 PM, Sekhar Nori wrote:
> Hi Archit,
>
> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>
>>
>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>> THS8135 is a configurable video DAC, but no configuration is actually
>>> necessary to make it work.
>>>
>>> For now use the dumb-vga-dac driver to support it.
>>
>> Queued to drm-misc-next
>
> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
> to v4.10?
These missed out on 4.10 because the drm related pull requests were
already sent by then. These 2 patches are queued for 4.11.
Thanks,
Archit
>
> Thanks,
> Sekhar
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 16/18] net/ixgbe: create consistent filter
From: Xing, Beilei @ 2017-01-03 5:24 UTC (permalink / raw)
To: Zhao1, Wei, dev@dpdk.org; +Cc: Zhao1, Wei, Lu, Wenzhuo
In-Reply-To: <1483084390-53159-17-git-send-email-wei.zhao1@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, December 30, 2016 3:53 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei <wei.zhao1@intel.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>
> Subject: [dpdk-dev] [PATCH v2 16/18] net/ixgbe: create consistent filter
>
> This patch adds a function to create the flow directory filter.
>
> Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
>
> ---
>
>
> +/**
> + * Create or destroy a flow rule.
> + * Theorically one rule can match more than one filters.
> + * We will let it use the filter which it hitt first.
> + * So, the sequence matters.
> + */
> +static struct rte_flow *
> +ixgbe_flow_create(struct rte_eth_dev *dev,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item pattern[],
> + const struct rte_flow_action actions[],
> + struct rte_flow_error *error)
> +{
> + int ret;
> + struct rte_eth_ntuple_filter ntuple_filter;
> + struct rte_eth_ethertype_filter ethertype_filter;
> + struct rte_eth_syn_filter syn_filter;
> + struct ixgbe_fdir_rule fdir_rule;
> + struct rte_eth_l2_tunnel_conf l2_tn_filter;
> + struct ixgbe_hw_fdir_info *fdir_info =
> + IXGBE_DEV_PRIVATE_TO_FDIR_INFO(dev->data-
> >dev_private);
> + struct ixgbe_flow *flow = NULL;
> + struct ixgbe_ntuple_filter_ele *ntuple_filter_ptr;
> + struct ixgbe_ethertype_filter_ele *ethertype_filter_ptr;
> + struct ixgbe_eth_syn_filter_ele *syn_filter_ptr;
> + struct ixgbe_eth_l2_tunnel_conf_ele *l2_tn_filter_ptr;
> + struct ixgbe_fdir_rule_ele *fdir_rule_ptr;
> + struct ixgbe_flow_mem *ixgbe_flow_mem_ptr;
> +
> + flow = rte_zmalloc("ixgbe_flow", sizeof(struct ixgbe_flow), 0);
> + if (!flow) {
> + PMD_DRV_LOG(ERR, "failed to allocate memory");
> + return (struct rte_flow *)flow;
> + }
> + ixgbe_flow_mem_ptr = rte_zmalloc("ixgbe_flow_mem",
> + sizeof(struct ixgbe_flow_mem), 0);
> + if (!ixgbe_flow_mem_ptr) {
> + PMD_DRV_LOG(ERR, "failed to allocate memory");
> + return NULL;
> + }
> + ixgbe_flow_mem_ptr->flow = flow;
> + TAILQ_INSERT_TAIL(&ixgbe_flow_list,
> + ixgbe_flow_mem_ptr, entries);
> +
> + memset(&ntuple_filter, 0, sizeof(struct rte_eth_ntuple_filter));
> + ret = ixgbe_parse_ntuple_filter(attr, pattern,
> + actions, &ntuple_filter, error);
> + if (!ret) {
> + ret = ixgbe_add_del_ntuple_filter(dev, &ntuple_filter, TRUE);
> + if (!ret) {
> + ntuple_filter_ptr = rte_zmalloc("ixgbe_ntuple_filter",
> + sizeof(struct ixgbe_ntuple_filter_ele), 0);
> + (void)rte_memcpy(&ntuple_filter_ptr->filter_info,
> + &ntuple_filter,
> + sizeof(struct rte_eth_ntuple_filter));
> + TAILQ_INSERT_TAIL(&filter_ntuple_list,
> + ntuple_filter_ptr, entries);
> + flow->rule = ntuple_filter_ptr;
> + flow->filter_type = RTE_ETH_FILTER_NTUPLE;
> + }
> + return (struct rte_flow *)flow;
Should the return statement be in the parantheses above?
And is there any process if (ret<0) ?
> + }
> +
> + memset(ðertype_filter, 0, sizeof(struct
> rte_eth_ethertype_filter));
> + ret = ixgbe_parse_ethertype_filter(attr, pattern,
> + actions, ðertype_filter, error);
> + if (!ret) {
> + ret = ixgbe_add_del_ethertype_filter(dev,
> + ðertype_filter, TRUE);
> + if (!ret) {
> + ethertype_filter_ptr = rte_zmalloc(
> + "ixgbe_ethertype_filter",
> + sizeof(struct ixgbe_ethertype_filter_ele), 0);
> + (void)rte_memcpy(ðertype_filter_ptr-
> >filter_info,
> + ðertype_filter,
> + sizeof(struct rte_eth_ethertype_filter));
> + TAILQ_INSERT_TAIL(&filter_ethertype_list,
> + ethertype_filter_ptr, entries);
> + flow->rule = ethertype_filter_ptr;
> + flow->filter_type = RTE_ETH_FILTER_ETHERTYPE;
> + }
> + return (struct rte_flow *)flow;
Same above.
> + }
> +
> + memset(&syn_filter, 0, sizeof(struct rte_eth_syn_filter));
> + ret = cons_parse_syn_filter(attr, pattern, actions, &syn_filter, error);
> + if (!ret) {
> + ret = ixgbe_syn_filter_set(dev, &syn_filter, TRUE);
> + if (!ret) {
> + syn_filter_ptr = rte_zmalloc("ixgbe_syn_filter",
> + sizeof(struct ixgbe_eth_syn_filter_ele), 0);
> + (void)rte_memcpy(&syn_filter_ptr->filter_info,
> + &syn_filter,
> + sizeof(struct rte_eth_syn_filter));
> + TAILQ_INSERT_TAIL(&filter_syn_list,
> + syn_filter_ptr,
> + entries);
> + flow->rule = syn_filter_ptr;
> + flow->filter_type = RTE_ETH_FILTER_SYN;
> + }
> + return (struct rte_flow *)flow;
Same above.
> + }
> +
> + memset(&fdir_rule, 0, sizeof(struct ixgbe_fdir_rule));
> + ret = ixgbe_parse_fdir_filter(attr, pattern,
> + actions, &fdir_rule, error);
> + if (!ret) {
> + /* A mask cannot be deleted. */
> + if (fdir_rule.b_mask) {
> + if (!fdir_info->mask_added) {
> + /* It's the first time the mask is set. */
> + rte_memcpy(&fdir_info->mask,
> + &fdir_rule.mask,
> + sizeof(struct ixgbe_hw_fdir_mask));
> + ret = ixgbe_fdir_set_input_mask(dev);
> + if (ret)
> + return NULL;
Before return NULL, ixgbe_flow_mem_ptr and flow should be freed, right?
And ixgbe_flow_mem_ptr should be removed from ixgbe_flow_list. Or you can move TAILQ_INSERT_TAIL(&ixgbe_flow_list, ixgbe_flow_mem_ptr, entries) after a flow is added successfully.
Same comments for "return NULL" below.
> +
> + fdir_info->mask_added = TRUE;
> + } else {
> + /**
> + * Only support one global mask,
> + * all the masks should be the same.
> + */
> + ret = memcmp(&fdir_info->mask,
> + &fdir_rule.mask,
> + sizeof(struct ixgbe_hw_fdir_mask));
> + if (ret)
> + return NULL;
> + }
> + }
> +
> + if (fdir_rule.b_spec) {
> + ret = ixgbe_fdir_filter_program(dev, &fdir_rule,
> + FALSE, FALSE);
> + if (!ret) {
> + fdir_rule_ptr =
> rte_zmalloc("ixgbe_fdir_filter",
> + sizeof(struct ixgbe_fdir_rule_ele), 0);
> + (void)rte_memcpy(&fdir_rule_ptr-
> >filter_info,
> + &fdir_rule,
> + sizeof(struct ixgbe_fdir_rule));
> + TAILQ_INSERT_TAIL(&filter_fdir_list,
> + fdir_rule_ptr, entries);
> + flow->rule = fdir_rule_ptr;
> + flow->filter_type = RTE_ETH_FILTER_FDIR;
> +
> + return (struct rte_flow *)flow;
> + }
> +
> + if (ret)
> + return NULL;
> + }
> +
> + return NULL;
Why to return NULL here?
> + }
> +
> + memset(&l2_tn_filter, 0, sizeof(struct rte_eth_l2_tunnel_conf));
> + ret = cons_parse_l2_tn_filter(attr, pattern,
> + actions, &l2_tn_filter, error);
> + if (!ret) {
> + ret = ixgbe_dev_l2_tunnel_filter_add(dev, &l2_tn_filter,
> FALSE);
> + if (!ret) {
> + l2_tn_filter_ptr = rte_zmalloc("ixgbe_l2_tn_filter",
> + sizeof(struct ixgbe_eth_l2_tunnel_conf_ele),
> 0);
> + (void)rte_memcpy(&l2_tn_filter_ptr->filter_info,
> + &l2_tn_filter,
> + sizeof(struct rte_eth_l2_tunnel_conf));
> + TAILQ_INSERT_TAIL(&filter_l2_tunnel_list,
> + l2_tn_filter_ptr, entries);
> + flow->rule = l2_tn_filter_ptr;
> + flow->filter_type = RTE_ETH_FILTER_L2_TUNNEL;
> +
> + return (struct rte_flow *)flow;
> + }
is there any process if (ret<0) ?
> + }
> +
> + rte_free(ixgbe_flow_mem_ptr);
> + rte_free(flow);
> + return NULL;
> +}
> +
^ permalink raw reply
* RE: [PATCH 00/18] ACPICA 20161222 Release
From: Zheng, Lv @ 2017-01-03 5:23 UTC (permalink / raw)
To: Rafael J. Wysocki, Brown, Len
Cc: Lv Zheng, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
In-Reply-To: <4861890.YlOS97DeY7@aspire.rjw.lan>
Hi, Rafael
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Subject: Re: [PATCH 00/18] ACPICA 20161222 Release
>
> On Wednesday, December 28, 2016 03:28:00 PM Lv Zheng wrote:
> > The 20161222 ACPICA kernel-resident subsystem updates are linuxized based
> > on the linux-pm/linux-next branch.
> >
> > The patchset has passed the following build/boot tests.
> > Build tests are performed as follows:
> > 1. i386 + allyes
> > 2. i386 + allno
> > 3. i386 + default + ACPI_DEBUGGER=y
> > 4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
> > 5. i386 + default + ACPI_DEBUG=n + ACPI=y
> > 6. i386 + default + ACPI=n
> > 7. x86_64 + allyes
> > 8. x86_64 + allno
> > 9. x86_64 + default + ACPI_DEBUGGER=y
> > 10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
> > 11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
> > 12.x86_64 + default + ACPI=n
> > Boot tests are performed as follows:
> > 1. x86_64 + default + ACPI_DEBUGGER=y
> > Where:
> > 1. i386: machine named as "Dell Inspiron Mini 1010"
> > 2. x86_64: machine named as "Microsoft Surface Pro 3"
> > 3. default: kernel configuration with following items enabled:
> > All hardware drivers related to the machines of i386/x86_64
> > All "drivers/acpi" configurations
> > All "drivers/platform" drivers
> > All other drivers that link the APIs provided by ACPICA subsystem
> >
> > The divergences checking result:
> > Before applying (20161117 Release):
> > 467 lines
> > After applying (20161222 Release):
> > 369 lines
> >
> > Bob Moore (8):
> > ACPICA: Macro header: Fix some typos in comments. No functional change
> > ACPICA: Utilities: Update debug output
> > ACPICA: Resources: Not a valid resource if buffer length too long
> > ACPICA: Fix for implicit result conversion for the ToXXXX functions
> > ACPICA: Parser: Allow method invocations as target operands
> > ACPICA: Fix a problem with recent extra support for control method
> > invocations
> > ACPICA: Parser: Update parse info table for some operators
> > ACPICA: Update version to 20161222
> >
> > Colin Ian King (1):
> > ACPICA: Linux-specific header: Add support for s390x compilation.
> >
> > David E. Box (1):
> > ACPICA: Disassembler: Add Switch/Case disassembly support
> >
> > Lv Zheng (8):
> > ACPICA: Debugger: Rename debugger OSL names
> > ACPICA: Hardware: Remove bit_offset masking support
> > ACPICA: Hardware: Add access_width/bit_offset support in
> > acpi_hw_write()
> > ACPICA: Utilities: Add power of two rounding support
> > ACPICA: Hardware: Sort access bit width algorithm
> > ACPICA: Hardware: Add sleep register hooks
> > ACPICA: MSVC: Fix MSVC6 build issues
> > ACPICA: EFI: Add efihello demo application
> >
> > drivers/acpi/acpica/aclocal.h | 7 +-
> > drivers/acpi/acpica/acmacros.h | 72 +++++++++-
> > drivers/acpi/acpica/acopcode.h | 22 +--
> > drivers/acpi/acpica/amlcode.h | 20 ++-
> > drivers/acpi/acpica/dbxface.c | 4 +-
> > drivers/acpi/acpica/exconvrt.c | 1 -
> > drivers/acpi/acpica/exresop.c | 1 -
> > drivers/acpi/acpica/hwesleep.c | 35 +++--
> > drivers/acpi/acpica/hwregs.c | 153 +++++++++++++++------
> > drivers/acpi/acpica/hwsleep.c | 11 +-
> > drivers/acpi/acpica/psargs.c | 97 +++++++++----
> > drivers/acpi/acpica/psloop.c | 4 +
> > drivers/acpi/acpica/psobject.c | 10 +-
> > drivers/acpi/acpica/pstree.c | 10 +-
> > drivers/acpi/acpica/utdecode.c | 4 +-
> > drivers/acpi/acpica/utdelete.c | 6 +-
> > drivers/acpi/acpica/utresrc.c | 17 ++-
> > drivers/acpi/osl.c | 27 +++-
> > include/acpi/acexcep.h | 9 +-
> > include/acpi/acpiosxf.h | 12 +-
> > include/acpi/acpixf.h | 2 +-
> > include/acpi/platform/acenv.h | 5 +-
> > include/acpi/platform/aclinux.h | 7 +-
> > include/acpi/platform/aclinuxex.h | 4 +-
> > .../acpi/os_specific/service_layers/osunixxf.c | 22 +++
> > 25 files changed, 405 insertions(+), 157 deletions(-)
>
> Any chance to make patch [14/18] go to any mailing lists or actually any
> outside addresses *at* *all* without being filtered out by spam filters or
> similar?
It seems the ToXXX in the subject "ACPICA: Fix for implicit result conversion for the ToXXXX functions" hit spam filters from 1 of the chained MDAs:
#5.0.0 smtp; 5.3.0 - Other mail system problem 550-'5.7.1 Content-Policy reject msg: The capital Triple-X in subject is way too often associated with junk email, please rephrase.
I'll re-phrase and re-send the PATCH 14/18.
Thanks
Lv
^ permalink raw reply
* Re: [PATCH v3 2/3] DT: bingdings: power: reset: add linkstation-reset doc
From: Florian Fainelli @ 2017-01-03 5:21 UTC (permalink / raw)
To: Roger Shimizu, Sebastian Reichel, Rob Herring, Mark Rutland
Cc: Andrew Lunn, Ryan Tandy, linux-pm, devicetree, linux-arm-kernel
In-Reply-To: <20161227070611.14852-3-rogershimizu@gmail.com>
On 12/26/2016 11:06 PM, Roger Shimizu wrote:
> Add linkstation-reset doc to describe the newly added
> POWER_RESET_LINKSTATION driver, which controls magic command
> sending to UART1 to power-off Buffalo Linkstation / KuroBox
> and their variants.
>
> To: Sebastian Reichel <sre@kernel.org>
> To: Rob Herring <robh+dt@kernel.org>
> To: Mark Rutland <mark.rutland@arm.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Ryan Tandy <ryan@nardis.ca>
> Cc: linux-pm@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
>
> Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
> ---
> .../bindings/power/reset/linkstation-reset.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt b/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
> new file mode 100644
> index 000000000000..815e340318f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
> @@ -0,0 +1,26 @@
> +* Buffalo Linkstation Reset Driver
> +
> +Power of some Buffalo Linkstation or KuroBox Pro is managed by
> +micro-controller, which connects to UART1. After being fed from UART1
> +by a few magic numbers, the so-called power-off command,
> +the micro-controller will turn power off the device.
> +
> +This is very similar to QNAP or Synology NAS devices, which is
> +described in qnap-poweroff.txt, however the command is much simpler,
> +only 1-byte long and without checksums.
> +
> +This driver adds a handler to pm_power_off which is called to turn the
> +power off.
This is a driver implementation detail, so does not really belong in the
DT here.
> +
> +Required Properties:
> +- compatible: Should be "linkstation,power-off"
> +- reg: Address and length of the register set for UART1
Humm, should we instead have a phandle to the uart1 node?
> +- clocks: tclk clock
> +
> +Example:
> +
> + reset {
> + compatible = "linkstation,power-off";
> + reg = <0x12100 0x100>;
> + clocks = <&core_clk 0>;
> + };
>
--
Florian
^ permalink raw reply
* [PATCH v3 2/3] DT: bingdings: power: reset: add linkstation-reset doc
From: Florian Fainelli @ 2017-01-03 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227070611.14852-3-rogershimizu@gmail.com>
On 12/26/2016 11:06 PM, Roger Shimizu wrote:
> Add linkstation-reset doc to describe the newly added
> POWER_RESET_LINKSTATION driver, which controls magic command
> sending to UART1 to power-off Buffalo Linkstation / KuroBox
> and their variants.
>
> To: Sebastian Reichel <sre@kernel.org>
> To: Rob Herring <robh+dt@kernel.org>
> To: Mark Rutland <mark.rutland@arm.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Ryan Tandy <ryan@nardis.ca>
> Cc: linux-pm at vger.kernel.org
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
>
> Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
> ---
> .../bindings/power/reset/linkstation-reset.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt b/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
> new file mode 100644
> index 000000000000..815e340318f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
> @@ -0,0 +1,26 @@
> +* Buffalo Linkstation Reset Driver
> +
> +Power of some Buffalo Linkstation or KuroBox Pro is managed by
> +micro-controller, which connects to UART1. After being fed from UART1
> +by a few magic numbers, the so-called power-off command,
> +the micro-controller will turn power off the device.
> +
> +This is very similar to QNAP or Synology NAS devices, which is
> +described in qnap-poweroff.txt, however the command is much simpler,
> +only 1-byte long and without checksums.
> +
> +This driver adds a handler to pm_power_off which is called to turn the
> +power off.
This is a driver implementation detail, so does not really belong in the
DT here.
> +
> +Required Properties:
> +- compatible: Should be "linkstation,power-off"
> +- reg: Address and length of the register set for UART1
Humm, should we instead have a phandle to the uart1 node?
> +- clocks: tclk clock
> +
> +Example:
> +
> + reset {
> + compatible = "linkstation,power-off";
> + reg = <0x12100 0x100>;
> + clocks = <&core_clk 0>;
> + };
>
--
Florian
^ permalink raw reply
* [PATCH v3 1/3] power: reset: add linkstation-reset driver
From: Florian Fainelli @ 2017-01-03 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227070611.14852-2-rogershimizu@gmail.com>
Hi Roger,
On 12/26/2016 11:06 PM, Roger Shimizu wrote:
> Buffalo Linkstation / KuroBox and their variants need magic command
> sending to UART1 to power-off.
>
> Power driver linkstation-reset implements the magic command and I/O
> routine, which come from files listed below:
> - arch/arm/mach-orion5x/kurobox_pro-setup.c
> - arch/arm/mach-orion5x/terastation_pro2-setup.c
Interestingly, I submitted a patch doing nearly the same thing recently
after hacking on a Buffalo Terastation Pro II two days after yours
without seeing yours:
https://lkml.org/lkml/2016/12/28/273
Some comments below.
> +
> +static void __iomem *base;
> +static unsigned long tclk;
> +static const struct reset_cfg *cfg;
How about avoiding the singletons here and pass this down from the
platform driver's private data after we (see below) also make use of a
reboot notifier?
> +
> +static void linkstation_reset(void)
> +{
> + const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
> + int i;
> +
> + pr_err("%s: triggering power-off...\n", __func__);
> +
> + /* hijack UART1 and reset into sane state */
> + writel(0x83, UART1_REG(LCR));
> + writel(divisor & 0xff, UART1_REG(DLL));
> + writel((divisor >> 8) & 0xff, UART1_REG(DLM));
> + writel(cfg->magic[0], UART1_REG(LCR));
> + writel(cfg->magic[1], UART1_REG(IER));
> + writel(cfg->magic[2], UART1_REG(FCR));
> + writel(cfg->magic[3], UART1_REG(MCR));
> +
> + /* send the power-off command to PIC */
> + for(i = 0; cfg->cmd[i][0] > 0; i ++) {
> + /* [0] is size of the command; command starts from [1] */
> + uart1_micon_send(base, &(cfg->cmd[i][1]), cfg->cmd[i][0]);
> + }
> +}
> +
> +static int linkstation_reset_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *res;
> + struct clk *clk;
> + char symname[KSYM_NAME_LEN];
> +
> + const struct of_device_id *match =
> + of_match_node(linkstation_reset_of_match_table, np);
> + cfg = match->data;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "Missing resource");
> + return -EINVAL;
> + }
> +
> + base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!base) {
> + dev_err(&pdev->dev, "Unable to map resource");
> + return -EINVAL;
> + }
> +
> + /* We need to know tclk in order to calculate the UART divisor */
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + dev_err(&pdev->dev, "Clk missing");
> + return PTR_ERR(clk);
> + }
> +
> + tclk = clk_get_rate(clk);
Does this work with the Terastation II which has not been converted to
DT yet? Is tclk available through the CLK API there?
> +
> + /* Check that nothing else has already setup a handler */
> + if (pm_power_off) {
> + lookup_symbol_name((ulong)pm_power_off, symname);
> + dev_err(&pdev->dev,
> + "pm_power_off already claimed %p %s",
> + pm_power_off, symname);
> + return -EBUSY;
> + }
> + pm_power_off = linkstation_reset;
That seems a bit complicated, why not just assume that there will be
either this driver used, or not at all?
Also, you are supposed to register a reboot notifier to which you can
pass private context:
https://lkml.org/lkml/2016/12/28/275
As indicated in my patch series, the UART1-attached micro controller
does a lot more things that just providing reboot, which is why I chose
to move this code to a MFD driver, as the starting point before adding
support for LEDs, FAN, PWM, beeper which would be other types of devices.
Is adding support for other peripherals on your TODO as well?
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v3 1/3] power: reset: add linkstation-reset driver
From: Florian Fainelli @ 2017-01-03 5:19 UTC (permalink / raw)
To: Roger Shimizu, Sebastian Reichel
Cc: Andrew Lunn, Martin Michlmayr, Sylver Bruneau,
Herbert Valerio Riedel, Ryan Tandy,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161227070611.14852-2-rogershimizu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Roger,
On 12/26/2016 11:06 PM, Roger Shimizu wrote:
> Buffalo Linkstation / KuroBox and their variants need magic command
> sending to UART1 to power-off.
>
> Power driver linkstation-reset implements the magic command and I/O
> routine, which come from files listed below:
> - arch/arm/mach-orion5x/kurobox_pro-setup.c
> - arch/arm/mach-orion5x/terastation_pro2-setup.c
Interestingly, I submitted a patch doing nearly the same thing recently
after hacking on a Buffalo Terastation Pro II two days after yours
without seeing yours:
https://lkml.org/lkml/2016/12/28/273
Some comments below.
> +
> +static void __iomem *base;
> +static unsigned long tclk;
> +static const struct reset_cfg *cfg;
How about avoiding the singletons here and pass this down from the
platform driver's private data after we (see below) also make use of a
reboot notifier?
> +
> +static void linkstation_reset(void)
> +{
> + const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
> + int i;
> +
> + pr_err("%s: triggering power-off...\n", __func__);
> +
> + /* hijack UART1 and reset into sane state */
> + writel(0x83, UART1_REG(LCR));
> + writel(divisor & 0xff, UART1_REG(DLL));
> + writel((divisor >> 8) & 0xff, UART1_REG(DLM));
> + writel(cfg->magic[0], UART1_REG(LCR));
> + writel(cfg->magic[1], UART1_REG(IER));
> + writel(cfg->magic[2], UART1_REG(FCR));
> + writel(cfg->magic[3], UART1_REG(MCR));
> +
> + /* send the power-off command to PIC */
> + for(i = 0; cfg->cmd[i][0] > 0; i ++) {
> + /* [0] is size of the command; command starts from [1] */
> + uart1_micon_send(base, &(cfg->cmd[i][1]), cfg->cmd[i][0]);
> + }
> +}
> +
> +static int linkstation_reset_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *res;
> + struct clk *clk;
> + char symname[KSYM_NAME_LEN];
> +
> + const struct of_device_id *match =
> + of_match_node(linkstation_reset_of_match_table, np);
> + cfg = match->data;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "Missing resource");
> + return -EINVAL;
> + }
> +
> + base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!base) {
> + dev_err(&pdev->dev, "Unable to map resource");
> + return -EINVAL;
> + }
> +
> + /* We need to know tclk in order to calculate the UART divisor */
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + dev_err(&pdev->dev, "Clk missing");
> + return PTR_ERR(clk);
> + }
> +
> + tclk = clk_get_rate(clk);
Does this work with the Terastation II which has not been converted to
DT yet? Is tclk available through the CLK API there?
> +
> + /* Check that nothing else has already setup a handler */
> + if (pm_power_off) {
> + lookup_symbol_name((ulong)pm_power_off, symname);
> + dev_err(&pdev->dev,
> + "pm_power_off already claimed %p %s",
> + pm_power_off, symname);
> + return -EBUSY;
> + }
> + pm_power_off = linkstation_reset;
That seems a bit complicated, why not just assume that there will be
either this driver used, or not at all?
Also, you are supposed to register a reboot notifier to which you can
pass private context:
https://lkml.org/lkml/2016/12/28/275
As indicated in my patch series, the UART1-attached micro controller
does a lot more things that just providing reboot, which is why I chose
to move this code to a MFD driver, as the starting point before adding
support for LEDs, FAN, PWM, beeper which would be other types of devices.
Is adding support for other peripherals on your TODO as well?
Thanks!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 02/10] efi: Constify GetVariable() / SetVariable() signatures
From: Juergen Gross @ 2017-01-03 5:17 UTC (permalink / raw)
To: Lukas Wunner, Matt Fleming, Ard Biesheuvel,
linux-efi-u79uwXL29TY76Z2rM5mHXA
Cc: Tony Luck, Fenghua Yu, Boris Ostrovsky, David Vrabel
In-Reply-To: <bd030e11cd114fb1d568b21eddfc1fa75cd42e5e.1483318593.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
On 02/01/17 11:24, Lukas Wunner wrote:
> GetVariable() / SetVariable() is typically called with immutable
> VendorGuid and VariableName arguments. SetVariable() is also often
> called with an immutable Data argument. However declaring these const
> in the caller results in a compiler warning since they're not marked
> const in the function signatures. Rectify that, in keeping with the EFI
> spec which marks these arguments "IN".
>
> Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
> Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Tony Luck <tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Fenghua Yu <fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Boris Ostrovsky <boris.ostrovsky-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Cc: David Vrabel <david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
> Cc: Juergen Gross <jgross-IBi9RG/b67k@public.gmane.org>
> Signed-off-by: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
Xen parts:
Acked-by: Juergen Gross <jgross-IBi9RG/b67k@public.gmane.org>
Juergen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.