Re: [PATCH v2 1/5] staging: rtl8192e: Fix coding style issues
Hi Suniel, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.11-rc1 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/sunil-m-techveda-org/staging-rtl8192e-Fix-coding-style-warnings-and-checks/20170311-16 config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/staging/rtl8192e/rtl8192e/rtl_core.c: In function 'rtl92e_set_rf_state': >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:220:13: error: >> 'WLAN_REASON_DISASSOC_STA_' undeclared (first use in this function) WLAN_REASON_DISASSOC_STA_ ^ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:220:13: note: each undeclared identifier is reported only once for each function it appears in >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:221:9: error: expected ')' >> before 'HAS_LEFT' HAS_LEFT); ^~~~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c: In function '_rtl92e_if_silent_reset': drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1248:24: warning: missing terminating " character RT_TRACE(COMP_RESET, "%s():==>start to down the ^ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1249:13: warning: missing terminating " character driver\n", __func__); ^ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1252:5: warning: missing terminating " character "%s():==>start to down the ^ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1253:13: warning: missing terminating " character driver\n", __func__); ^ >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:2752:0: error: unterminated >> argument list invoking macro "RT_TRACE" MODULE_PARM_DESC(channels, " Channel bitmask for specific locales. NYI"); >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1248:3: error: 'RT_TRACE' >> undeclared (first use in this function) RT_TRACE(COMP_RESET, "%s():==>start to down the ^~~~ >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1248:3: error: expected ';' at >> end of input >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1248:3: error: expected >> declaration or statement at end of input >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1248:3: error: expected >> declaration or statement at end of input drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1233:1: warning: label 'RESET_START' defined but not used [-Wunused-label] RESET_START: ^~~ >> drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1227:4: error: label 'END' used >> but not defined goto END; ^~~~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1218:24: warning: unused variable 'ieee' [-Wunused-variable] struct rtllib_device *ieee = priv->rtllib; ^~~~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1217:6: warning: unused variable 'reset_status' [-Wunused-variable] int reset_status = 0; ^~~~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:1216:5: warning: unused variable 'reset_times' [-Wunused-variable] u8 reset_times = 0; ^~~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c: At top level: drivers/staging/rtl8192e/rtl8192e/rtl_core.c:71:12: warning: '_rtl92e_pci_probe' used but never defined static int _rtl92e_pci_probe(struct pci_dev *pdev, ^ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:73:13: warning: '_rtl92e_pci_disconnect' used but never defined static void _rtl92e_pci_disconnect(struct pci_dev *pdev); ^~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:74:20: warning: '_rtl92e_irq' used but never defined static irqreturn_t _rtl92e_irq(int irq, void *netdev); ^~~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:86:13: warning: '_rtl92e_watchdog_wq_cb' used but never defined static void _rtl92e_watchdog_wq_cb(void *data); ^~ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:87:13: warning: '_rtl92e_watchdog_timer_cb' used but never defined static void _rtl92e_watchdog_timer_cb(unsigned long data); ^ drivers/staging/rtl8192e/rtl8192e/rtl_core.c:88:13: warning: '_rtl92e_hard_d
Re: [PATCH] tpm_crb: request and relinquish locality 0
On Fri, Mar 10, 2017 at 05:27:09PM -0700, Jason Gunthorpe wrote: > On Sat, Mar 11, 2017 at 01:58:00AM +0200, Jarkko Sakkinen wrote: > > Added two new callbacks to struct tpm_class_ops: > > > > - request_locality > > - relinquish_locality > > > > These are called before sending and receiving data from the TPM. > > If we are going to add new ops, I think we should also adjust the > existing drivers to use this mechanism as well? > > eg tis just calls its request_locality as the first thing in send.. > > Jason Would it be sufficient to adjust tpm_tis in addition to tpm_crb? Those are the only once where I can edit edit-compile-run cycle. The original commit I did worked on SKL platform that I tested but fails on KBL but keeping the locality throughout the transmit makes it stable on every platform I've tested. /Jarkko
Re: [PATCH] tpm_crb: check for bad response size
On Fri, Mar 10, 2017 at 05:46:04PM -0700, Jerry Snitselaar wrote:
> Make sure size of response buffer is at least 6 bytes, or
> we will underflow and pass large size_t to memcpy_fromio().
> This was encountered while testing earlier version of
> locality patchset.
>
> Fixes: 30fc8d138e912 ("tpm: TPM 2.0 CRB Interface")
> Signed-off-by: Jerry Snitselaar
Reviewed-by: Jarkko Sakkinen
/Jarkko
> ---
> drivers/char/tpm/tpm_crb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 89dc8a176ff1..cda4f312d1c9 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -236,7 +236,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
>
> memcpy_fromio(buf, priv->rsp, 6);
> expected = be32_to_cpup((__be32 *) &buf[2]);
> - if (expected > count)
> + if (expected > count || expected < 6)
> return -EIO;
>
> memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
> --
> 2.11.0.258.ge05806da9
>
Re: [PATCH v3 0/7] in-kernel resource manager
On Fri, Mar 03, 2017 at 05:19:01PM +0200, Jarkko Sakkinen wrote: > This patch set adds support for TPM spaces that provide an isolated > execution context for transient objects and HMAC and policy sessions. A > space is swapped into TPM volatile memory only when it is used and > swapped out after the use. > > There's a test script for trying out TPM spaces in > > git://git.infradead.org/users/jjs/tpm2-scripts.git > > A simple smoke test suite can be run by > > sudo python -m unittest -v tpm2_smoke.SpaceTest > > v3: > * Reverted back to /dev/tpmrm0 that was actually James' original > proposal. It's the most pragmatic choice as it cannot be mixed > with other TPM 2.0 and kernel idioms easily. > > v2: > * Substitute virtual handle in ContextSave. > * Substitute virtual handles in GetCapability. > * Validate that the real response length and the one reported in the > header match in tpm_transmit(). > > > James Bottomley (3): > tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c > tpm: expose spaces via a device link /dev/tpmrm > tpm2: add session handle context saving and restoring to the space > code > > Jarkko Sakkinen (4): > tpm: move length validation to tpm_transmit() > tpm: validate TPM 2.0 commands > tpm: export tpm2_flush_context_cmd > tpm: infrastructure for TPM spaces > > drivers/char/tpm/Makefile | 3 +- > drivers/char/tpm/tpm-chip.c | 71 - > drivers/char/tpm/tpm-dev-common.c | 148 +++ > drivers/char/tpm/tpm-dev.c| 143 +- > drivers/char/tpm/tpm-dev.h| 27 ++ > drivers/char/tpm/tpm-interface.c | 131 +++--- > drivers/char/tpm/tpm-sysfs.c | 2 +- > drivers/char/tpm/tpm.h| 49 +++- > drivers/char/tpm/tpm2-cmd.c | 173 + > drivers/char/tpm/tpm2-space.c | 532 > ++ > drivers/char/tpm/tpmrm-dev.c | 65 + > 11 files changed, 1123 insertions(+), 221 deletions(-) > create mode 100644 drivers/char/tpm/tpm-dev-common.c > create mode 100644 drivers/char/tpm/tpm-dev.h > create mode 100644 drivers/char/tpm/tpm2-space.c > create mode 100644 drivers/char/tpm/tpmrm-dev.c > > -- > 2.9.3 > These commits are now in my master and next branches. Tested-by's are still most welcome! /Jarkko
Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT
On 2017/3/7 22:35, Lorenzo Pieralisi wrote:
> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
>> From: Hanjun Guo
>>
>> For devices connecting to ITS, the devices need to identify themself
>> through a dev id; this dev id is represented in the IORT table in named
>> component node [1] for platform devices, so this patch adds code that
>> scans the IORT table to retrieve the devices' dev id.
>>
>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
>> retrieving dev id in ACPI platforms.
>>
>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>
>> Signed-off-by: Hanjun Guo
>> [lorenzo.pieral...@arm.com: rewrote commit log]
>> Signed-off-by: Lorenzo Pieralisi
>> Tested-by: Ming Lei
>> Tested-by: Wei Xu
>> Tested-by: Sinan Kaya
>> Cc: Marc Zyngier
>> Cc: Lorenzo Pieralisi
>> Cc: Tomasz Nowicki
>> Cc: Thomas Gleixner
>> ---
>> drivers/acpi/arm64/iort.c | 24
>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>> include/linux/acpi_iort.h | 5 +
>> 3 files changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 83cd59d..fb95ceb 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>> }
>>
>> /**
>> + * iort_pmsi_get_dev_id() - Get the device id for a device
>> + * @dev: The device for which the mapping is to be done.
>> + * @dev_id: The device ID found.
>> + *
>> + * Returns: 0 for successful find a dev id, -ENODEV on error
>> + */
>> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>> +{
>> +int i;
>> +struct acpi_iort_node *node;
>> +
>> +node = iort_find_dev_node(dev);
>> +if (!node)
>> +return -ENODEV;
> I think that when specs are updated so that we can enable SMMU MSIs we
> shall have to find a way to get the acpi_iort_node for a device that is
> not a named component here (ie SMMU), I reckon we can use the
> fwnode_handle but I have to have a deeper look.
Seems we can do this as follows:
---
drivers/acpi/arm64/iort.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 22e08d2..c794219 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -121,6 +121,31 @@ static inline void iort_delete_fwnode(struct
acpi_iort_node *node)
spin_unlock(&iort_fwnode_lock);
}
+/**
+ * iort_get_iort_node() - Retrieve iort_node associated with an fwnode
+ *
+ * @fwnode: fwnode associated with device to be looked-up
+ *
+ * Returns: iort_node pointer on success, NULL on failure
+ */
+static inline
+struct acpi_iort_node *iort_get_iort_node(struct fwnode_handle *fwnode)
+{
+ struct iort_fwnode *curr;
+ struct acpi_iort_node *iort_node = NULL;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry(curr, &iort_fwnode_list, list) {
+ if (curr->fwnode == fwnode) {
+ iort_node = curr->iort_node;
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+
+ return iort_node;
+}
+
typedef acpi_status (*iort_find_node_callback)
(struct acpi_iort_node *node, void *context);
@@ -434,9 +459,25 @@ static struct acpi_iort_node *iort_find_dev_node(struct
device *dev)
{
struct pci_bus *pbus;
- if (!dev_is_pci(dev))
+ if (!dev_is_pci(dev)) {
+ struct acpi_iort_node *node;
+ /*
+ * scan iort_fwnode_list to see if it's an iort platform
+ * device (such as SMMU, PMCG),its iort node already cached
+ * and associated with fwnode when iort platform devices
+ * were initialized.
+ */
+ node = iort_get_iort_node(dev->fwnode);
+ if (node)
+ return node;
+
+ /*
+ * if not, then it should be a platform device defined in
+ * DSDT (with Named Component node in IORT)
+ */
return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
iort_match_node_callback, dev);
+ }
/* Find a PCI root bus */
pbus = to_pci_dev(dev)->bus;
>
> This does not affect the patchset in its current form, just scanning
> the code to make sure we will be able to support SMMU MSIs too when
> time comes.
Sure, thanks!
Hanjun
Re: [PATCH] netfilter: Force fake conntrack entry to be at least 8 bytes aligned
Steven Rostedt (VMware) wrote: > Since the nfct and nfctinfo have been combined, the nf_conn structure > must be at least 8 bytes aligned, as the 3 LSB bits are used for the > nfctinfo. But there's a fake nf_conn structure to denote untracked > connections, which is created by a PER_CPU construct. This does not > guarantee that it will be 8 bytes aligned and can break the logic in > determining the correct nfctinfo. > > I triggered this on a 32bit machine with the following error: [..] Ugh. Originally I had planned to also submit followup changes to get rid of the untracked objects but that part got delayed. > By using DEFINE/DECLARE_PER_CPU_ALIGNED we can enforce at least 8 byte > alignment as all cache line sizes are at least 8 bytes or more. Thanks for fixing this! Acked-by: Florian Westphal
Re: [Outreachy kernel] [PATCH 00/10] staging: iio: Remove exceptional & on functions name
On Sat, Mar 11, 2017 at 12:12 PM, Julia Lawall wrote: > > > On Sat, 11 Mar 2017, simran singhal wrote: > >> This patch-series removes exceptional & on functions name. > > The semantic patch shown does nothing to check that the use of & is > exception in the given file. It just removes all the & on function names. > yes, I used this semantic patch only for only finding the functions with & and then I find out this drivers and use semantic patch for removing &. > julia > >> >> simran singhal (10): >> staging: iio: ad7192: Remove exceptional & on function name >> staging: iio: ad7780: Remove exceptional & on function name >> staging: iio: cdc: ad7746: Remove exceptional & on function name >> staging: iio: cdc: ad7152: Remove exceptional & on function name >> staging: iio: adis16240: Remove exceptional & on function name >> staging: iio: adis16201: Remove exceptional & on function name >> staging: iio: adis16209: Remove exceptional & on function name >> staging: iio: adis16203: Remove exceptional & on function name >> staging: iio: resolver: Remove exceptional & on function name >> staging: iio: gyro: Remove exceptional & on function name >> >> drivers/staging/iio/accel/adis16201.c | 4 ++-- >> drivers/staging/iio/accel/adis16203.c | 4 ++-- >> drivers/staging/iio/accel/adis16209.c | 4 ++-- >> drivers/staging/iio/accel/adis16240.c | 4 ++-- >> drivers/staging/iio/adc/ad7192.c | 12 ++-- >> drivers/staging/iio/adc/ad7780.c | 2 +- >> drivers/staging/iio/cdc/ad7152.c | 6 +++--- >> drivers/staging/iio/cdc/ad7746.c | 4 ++-- >> drivers/staging/iio/gyro/adis16060_core.c | 2 +- >> drivers/staging/iio/resolver/ad2s1200.c | 2 +- >> drivers/staging/iio/resolver/ad2s90.c | 2 +- >> 11 files changed, 23 insertions(+), 23 deletions(-) >> >> -- >> 2.7.4 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "outreachy-kernel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to outreachy-kernel+unsubscr...@googlegroups.com. >> To post to this group, send email to outreachy-ker...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/outreachy-kernel/1489203401-17518-1-git-send-email-singhalsimran0%40gmail.com. >> For more options, visit https://groups.google.com/d/optout. >>
Re: [Outreachy kernel] [PATCH] staging: sm750fb: function prototype argument should have an identifier name
This is the patch that I previously commented on. Thus the subject line
should contain v2. Please try to remember to do this every time. It is
very confusing to see something one thinks one has already seen with no
version information. There should also be a description of the change
since the previous version under the ---.
julia
On Sat, 11 Mar 2017, Arushi Singhal wrote:
>
> function prototype arguments like 'struct vb_device_info *','unsigned
> long' etc. should have an identifier name.
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/sm750fb/ddk750_display.h | 2 +-
> drivers/staging/sm750fb/ddk750_mode.h| 2 +-
> drivers/staging/sm750fb/ddk750_power.h | 2 +-
> drivers/staging/sm750fb/sm750.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_display.h
> b/drivers/staging/sm750fb/ddk750_display.h
> index e2a3f84ca4c5..609bf742efff 100644
> --- a/drivers/staging/sm750fb/ddk750_display.h
> +++ b/drivers/staging/sm750fb/ddk750_display.h
> @@ -102,6 +102,6 @@ typedef enum _disp_output_t {
> }
> disp_output_t;
>
> -void ddk750_setLogicalDispOut(disp_output_t);
> +void ddk750_setLogicalDispOut(disp_output_t output);
>
> #endif
> diff --git a/drivers/staging/sm750fb/ddk750_mode.h
> b/drivers/staging/sm750fb/ddk750_mode.h
> index 2183e664cf4b..6d204b8b4a01 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.h
> +++ b/drivers/staging/sm750fb/ddk750_mode.h
> @@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
> }
> mode_parameter_t;
>
> -int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
> +int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
>
> #endif
> diff --git a/drivers/staging/sm750fb/ddk750_power.h
> b/drivers/staging/sm750fb/ddk750_power.h
> index ec0b99d6a7ad..44c4fc587e96 100644
> --- a/drivers/staging/sm750fb/ddk750_power.h
> +++ b/drivers/staging/sm750fb/ddk750_power.h
> @@ -14,7 +14,7 @@ DPMS_t;
> (peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
> }
>
> -void ddk750_set_dpms(DPMS_t);
> +void ddk750_set_dpms(DPMS_t state);
> void sm750_set_power_mode(unsigned int powerMode);
> void sm750_set_current_gate(unsigned int gate);
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index 306711ed55f9..5ea455dee949 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -184,7 +184,7 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
> }
>
> int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> -int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
> +int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> -void hw_sm750_initAccel(struct sm750_dev *);
> +void hw_sm750_initAccel(struct sm750_dev *hw_sm750_initAccel);
> int hw_sm750_deWait(void);
> int hw_sm750le_deWait(void);
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF_k%2BMyLno8O%3DoX2mB808uPz5SBmuFsgEu3jM%2B2Qo8RUMw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
Re: [Outreachy kernel] [PATCH 00/10] staging: iio: Remove exceptional & on functions name
On Sat, 11 Mar 2017, SIMRAN SINGHAL wrote: > On Sat, Mar 11, 2017 at 12:12 PM, Julia Lawall wrote: > > > > > > On Sat, 11 Mar 2017, simran singhal wrote: > > > >> This patch-series removes exceptional & on functions name. > > > > The semantic patch shown does nothing to check that the use of & is > > exception in the given file. It just removes all the & on function names. > > > yes, I used this semantic patch only for only finding the functions with & > and then I find out this drivers and use semantic patch for removing &. The commit message should be written with respect to what was actually done, and not copied from a patch that actually did something else. The original semantic patch, that was probably only put in the cover letter, actually checked if the file mostly used function pointers in a particular way. julia > > > julia > > > >> > >> simran singhal (10): > >> staging: iio: ad7192: Remove exceptional & on function name > >> staging: iio: ad7780: Remove exceptional & on function name > >> staging: iio: cdc: ad7746: Remove exceptional & on function name > >> staging: iio: cdc: ad7152: Remove exceptional & on function name > >> staging: iio: adis16240: Remove exceptional & on function name > >> staging: iio: adis16201: Remove exceptional & on function name > >> staging: iio: adis16209: Remove exceptional & on function name > >> staging: iio: adis16203: Remove exceptional & on function name > >> staging: iio: resolver: Remove exceptional & on function name > >> staging: iio: gyro: Remove exceptional & on function name > >> > >> drivers/staging/iio/accel/adis16201.c | 4 ++-- > >> drivers/staging/iio/accel/adis16203.c | 4 ++-- > >> drivers/staging/iio/accel/adis16209.c | 4 ++-- > >> drivers/staging/iio/accel/adis16240.c | 4 ++-- > >> drivers/staging/iio/adc/ad7192.c | 12 ++-- > >> drivers/staging/iio/adc/ad7780.c | 2 +- > >> drivers/staging/iio/cdc/ad7152.c | 6 +++--- > >> drivers/staging/iio/cdc/ad7746.c | 4 ++-- > >> drivers/staging/iio/gyro/adis16060_core.c | 2 +- > >> drivers/staging/iio/resolver/ad2s1200.c | 2 +- > >> drivers/staging/iio/resolver/ad2s90.c | 2 +- > >> 11 files changed, 23 insertions(+), 23 deletions(-) > >> > >> -- > >> 2.7.4 > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "outreachy-kernel" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to outreachy-kernel+unsubscr...@googlegroups.com. > >> To post to this group, send email to outreachy-ker...@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/outreachy-kernel/1489203401-17518-1-git-send-email-singhalsimran0%40gmail.com. > >> For more options, visit https://groups.google.com/d/optout. > >> > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyODTiF%2BgdwwYnmL1W1oi-R0u2rM4c40jb5iWXFxJpfdJw%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. >
[PATCH v2] staging: sm750fb: function prototype argument should have an identifier name
function prototype arguments like 'struct vb_device_info *','unsigned
long' etc. should have an identifier name.
Signed-off-by: Arushi Singhal
---
changes in v2
-Add the identifier name of one more function prototype
drivers/staging/sm750fb/ddk750_display.h | 2 +-
drivers/staging/sm750fb/ddk750_mode.h| 2 +-
drivers/staging/sm750fb/ddk750_power.h | 2 +-
drivers/staging/sm750fb/sm750.h | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_display.h
b/drivers/staging/sm750fb/ddk750_display.h
index e2a3f84ca4c5..609bf742efff 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -102,6 +102,6 @@ typedef enum _disp_output_t {
}
disp_output_t;
-void ddk750_setLogicalDispOut(disp_output_t);
+void ddk750_setLogicalDispOut(disp_output_t output);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_mode.h
b/drivers/staging/sm750fb/ddk750_mode.h
index 2183e664cf4b..6d204b8b4a01 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
}
mode_parameter_t;
-int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
+int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h
b/drivers/staging/sm750fb/ddk750_power.h
index ec0b99d6a7ad..44c4fc587e96 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -14,7 +14,7 @@ DPMS_t;
(peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
}
-void ddk750_set_dpms(DPMS_t);
+void ddk750_set_dpms(DPMS_t state);
void sm750_set_power_mode(unsigned int powerMode);
void sm750_set_current_gate(unsigned int gate);
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 306711ed55f9..f60565cae80c 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -184,8 +184,8 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
}
int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
-int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
-void hw_sm750_initAccel(struct sm750_dev *);
+int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
+void hw_sm750_initAccel(struct sm750_dev *hw_sm750_initAccel);
int hw_sm750_deWait(void);
int hw_sm750le_deWait(void);
--
2.11.0
Re: [PATCH RFC] mm/vmscan: donot retry shrink zones when memcg is disabled
Hi Shakeel,
Thanks for reviewing.
On 03/11/2017 11:40 AM, Shakeel Butt wrote:
> On Fri, Mar 10, 2017 at 6:19 PM, Yisheng Xie wrote:
>> From: Yisheng Xie
>>
>> When we enter do_try_to_free_pages, the may_thrash is always clear, and
>> it will retry shrink zones to tap cgroup's reserves memory by setting
>> may_thrash when the former shrink_zones reclaim nothing.
>>
>> However, if CONFIG_MEMCG=n, it should not do this useless retry at all,
>> for we do not have any cgroup's reserves memory to tap, and we have
>> already done hard work and made no progress.
>>
>> Signed-off-by: Yisheng Xie
>> ---
>> mm/vmscan.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index bc8031e..b03ccc1 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -2808,7 +2808,7 @@ static unsigned long do_try_to_free_pages(struct
>> zonelist *zonelist,
>> return 1;
>>
>> /* Untapped cgroup reserves? Don't OOM, retry. */
>> - if (!sc->may_thrash) {
>> + if (!sc->may_thrash && IS_ENABLED(CONFIG_MEMCG)) {
> In my opinion it should be even more restrictive (restricting
> cgroup_disabled=memory boot option and cgroup legacy hierarchy). So,
> instead of IS_ENABLED(CONFIG_MEMCG), the check should be something
> like (cgroup_subsys_enabled(memory_cgrp_subsys) &&
> cgroup_subsys_on_dfl(memory_cgrp_subsys)).
Right， I will send another version soon.
Thanks
Yisheng Xie.
>> sc->priority = initial_priority;
>> sc->may_thrash = 1;
>> goto retry;
>> --
>> 1.9.1
>>
>>
>>
[tip:x86/urgent] x86/tlb: Fix tlb flushing when lguest clears PGE
Commit-ID: 9b3e557f1238135f6ff405e760001a8a40139214
Gitweb: http://git.kernel.org/tip/9b3e557f1238135f6ff405e760001a8a40139214
Author: Daniel Borkmann
AuthorDate: Sat, 11 Mar 2017 01:31:19 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 11:10:02 +0100
x86/tlb: Fix tlb flushing when lguest clears PGE
Fengguang reported random corruptions from various locations on x86-32
after commits d2852a224050 ("arch: add ARCH_HAS_SET_MEMORY config") and
9d876e79df6a ("bpf: fix unlocking of jited image when module ronx not set")
that uses the former. While x86-32 doesn't have a JIT like x86_64, the
bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to
ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module
support built in and therefore never had the DEBUG_SET_MODULE_RONX setting
enabled.
After investigating the crashes further, it turned out that using
set_memory_ro() and set_memory_rw() didn't have the desired effect, for
example, setting the pages as read-only on x86-32 would still let
probe_kernel_write() succeed without error. This behavior would manifest
itself in situations where the vmalloc'ed buffer was accessed prior to
set_memory_*() such as in case of bpf_prog_alloc(). In cases where it
wasn't, the page attribute changes seemed to have taken effect, leading to
the conclusion that a TLB invalidate didn't happen. Moreover, it turned out
that this issue reproduced with qemu in "-cpu kvm64" mode, but not for
"-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger
a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(),
though.
There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends
on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush
(depends on X86_FEATURE_PGE), and cr3 based flush. For "-cpu host" case in
my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu
kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually
worked fine, and further investigating the cr4 one turned out that
X86_CR4_PGE bit was not set in cr4 register, meaning the
__native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same
value instead of clearing X86_CR4_PGE in the first write to trigger the
flush.
It turned out that X86_CR4_PGE was cleared from cr4 during init from
lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also
cleared from there due to concerns of using PGE in guest kernel that can
lead to hard to trace bugs (see bff672e630a0 ("lguest: documentation V:
Host") in init()). The CPU feature bits are cleared in dynamic
boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses
static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB
flushing to use, meaning they still used the old setting of the host
kernel.
Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate
to static_cpu_has() checks is too late at this point as sections have been
patched already, so for now, it seems reasonable to switch back to
boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95992b
("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via
cr3 as originally intended, properly makes the new page attributes visible
and thus fixes the crashes seen by Fengguang.
Fixes: c109bf95992b ("x86/cpufeature: Remove cpu_has_pge")
Reported-by: Fengguang Wu
Signed-off-by: Daniel Borkmann
Cc: b...@suse.de
Cc: Kees Cook
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: Rusty Russell
Cc: Alexei Starovoitov
Cc: Linus Torvalds
Cc: l...@01.org
Cc: Laura Abbott
Link:
http://lkml.kernrl.org/r/20170301125426.l4nf65rx4waho...@wfg-t540p.sh.intel.com
Link:
http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.dan...@iogearbox.net
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 6fa8594..fc5abff 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -188,7 +188,7 @@ static inline void __native_flush_tlb_single(unsigned long
addr)
static inline void __flush_tlb_all(void)
{
- if (static_cpu_has(X86_FEATURE_PGE))
+ if (boot_cpu_has(X86_FEATURE_PGE))
__flush_tlb_global();
else
__flush_tlb();
[PATCH] statx: remove incorrect part of vfs_statx() comment
From: Eric Biggers request_mask and query_flags are function arguments, not passed in struct kstat. So remove the part of the comment which claims otherwise. This was apparently left over from an earlier version of the statx patch. Signed-off-by: Eric Biggers --- fs/stat.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/stat.c b/fs/stat.c index df484a60846d..b792dd201c31 100644 --- a/fs/stat.c +++ b/fs/stat.c @@ -159,9 +159,6 @@ EXPORT_SYMBOL(vfs_statx_fd); * Additionally, the use of AT_SYMLINK_NOFOLLOW in flags will prevent a symlink * at the given name from being referenced. * - * The caller must have preset stat->request_mask as for vfs_getattr(). The - * flags are also used to load up stat->query_flags. - * * 0 will be returned on success, and a -ve error code if unsuccessful. */ int vfs_statx(int dfd, const char __user *filename, int flags, -- 2.12.0
[PATCH] statx: optimize copy of struct statx to userspace
From: Eric Biggers
I found that statx() was significantly slower than stat(). As a
microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
file to the same with statx() passed a NULL path:
$ time ./stat_benchmark
real0m1.464s
user0m0.275s
sys 0m1.187s
$ time ./statx_benchmark
real0m5.530s
user0m0.281s
sys 0m5.247s
statx is expected to be a little slower than stat because struct statx
is larger than struct stat, but not by *that* much. It turns out that
most of the overhead was in copying struct statx to userspace,
apparently mostly in all the stac/clac instructions that got generated
for each __put_user() call. (This was on x86_64, but some other
architectures, e.g. arm64, have something similar now too.)
stat() instead initializes its struct on the stack and copies it to
userspace with a single call to copy_to_user(). This turns out to be
much faster, and changing statx to do this makes it almost as fast as
stat:
$ time ./statx_benchmark
real0m1.573s
user0m0.229s
sys 0m1.344s
Signed-off-by: Eric Biggers
---
fs/stat.c | 70 ++-
1 file changed, 33 insertions(+), 37 deletions(-)
diff --git a/fs/stat.c b/fs/stat.c
index b792dd201c31..2cb3d0229232 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -510,46 +510,41 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *,
filename,
}
#endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */
-static inline int __put_timestamp(struct timespec *kts,
- struct statx_timestamp __user *uts)
+static inline void init_statx_timestamp(struct statx_timestamp *uts,
+ const struct timespec *kts)
{
- return (__put_user(kts->tv_sec, &uts->tv_sec) ||
- __put_user(kts->tv_nsec,&uts->tv_nsec ) ||
- __put_user(0, &uts->__reserved));
+ uts->tv_sec = kts->tv_sec;
+ uts->tv_nsec = kts->tv_nsec;
+ uts->__reserved = 0;
}
-/*
- * Set the statx results.
- */
-static long statx_set_result(struct kstat *stat, struct statx __user *buffer)
+static int cp_statx(const struct kstat *stat, struct statx __user *buffer)
{
- uid_t uid = from_kuid_munged(current_user_ns(), stat->uid);
- gid_t gid = from_kgid_munged(current_user_ns(), stat->gid);
-
- if (__put_user(stat->result_mask, &buffer->stx_mask ) ||
- __put_user(stat->mode, &buffer->stx_mode ) ||
- __clear_user(&buffer->__spare0, sizeof(buffer->__spare0)) ||
- __put_user(stat->nlink, &buffer->stx_nlink ) ||
- __put_user(uid, &buffer->stx_uid) ||
- __put_user(gid, &buffer->stx_gid) ||
- __put_user(stat->attributes,&buffer->stx_attributes ) ||
- __put_user(stat->blksize, &buffer->stx_blksize) ||
- __put_user(MAJOR(stat->rdev), &buffer->stx_rdev_major ) ||
- __put_user(MINOR(stat->rdev), &buffer->stx_rdev_minor ) ||
- __put_user(MAJOR(stat->dev),&buffer->stx_dev_major ) ||
- __put_user(MINOR(stat->dev),&buffer->stx_dev_minor ) ||
- __put_timestamp(&stat->atime, &buffer->stx_atime ) ||
- __put_timestamp(&stat->btime, &buffer->stx_btime ) ||
- __put_timestamp(&stat->ctime, &buffer->stx_ctime ) ||
- __put_timestamp(&stat->mtime, &buffer->stx_mtime ) ||
- __put_user(stat->ino, &buffer->stx_ino) ||
- __put_user(stat->size, &buffer->stx_size ) ||
- __put_user(stat->blocks,&buffer->stx_blocks ) ||
- __clear_user(&buffer->__spare1, sizeof(buffer->__spare1)) ||
- __clear_user(&buffer->__spare2, sizeof(buffer->__spare2)))
- return -EFAULT;
-
- return 0;
+ struct statx tmp;
+
+ tmp.stx_mask = stat->result_mask;
+ tmp.stx_blksize = stat->blksize;
+ tmp.stx_attributes = stat->attributes;
+ tmp.stx_nlink = stat->nlink;
+ tmp.stx_uid = from_kuid_munged(current_user_ns(), stat->uid);
+ tmp.stx_gid = from_kgid_munged(current_user_ns(), stat->gid);
+ tmp.stx_mode = stat->mode;
+ memset(tmp.__spare0, 0, sizeof(tmp.__spare0));
+ tmp.stx_ino = stat->ino;
+ tmp.stx_size = stat->size;
+ tmp.stx_blocks = stat->blocks;
+ memset(tmp.__spare1, 0, sizeof(tmp.__spare1));
+ init_statx_timestamp(&tmp.stx_atime, &stat->atime);
+ init_statx_timestamp(&tmp.stx_btime, &stat->btime);
+ init_statx_timestamp(&tmp.stx_ctime, &stat->ctime);
+ init_statx_timestamp(&tmp.stx_mtime, &st
Re: [PATCH v2] staging: sm750fb: function prototype argument should have an identifier name
On Sat, Mar 11, 2017 at 10:53 AM, Arushi Singhal
wrote:
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -184,8 +184,8 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
> }
>
> int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> -int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
> -void hw_sm750_initAccel(struct sm750_dev *);
> +int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> +void hw_sm750_initAccel(struct sm750_dev *hw_sm750_initAccel);
"sm750_dev", like the implementation uses.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] x86/fpu: Support disabling AVX and AVX512
On Fri, 10 Mar 2017, Andi Kleen wrote:
> From: Andi Kleen
>
> For performance testing it is useful to be able to disable AVX
> and AVX512. User programs check in XGETBV if AVX is supported
> by the OS. If we don't initialize the XSAVE state for AVX it will
> appear as if the OS is not supporting AVX. For kernel users we
> can also clear the internal cpu feature bits.
>
> This patch implements disable options for AVX and AVX512 for
> the XSAVE code.
>
> I originally considered a generic argument that would disable
> any XSAVE feature, but it turns out you need special code
> to also disable all the CPUID bits, because otherwise
> kernel code may assume it exists, when it doesn't. MPX
> already has an own disable flag. Not clear it is useful
> for the others. So we only do it for AVX/AVX512 for now.
Please read and follow Documentation/process/submitting-patches.rst.
Especially this paragraph:
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour.
> + disable_avx [X86] Disable support for AVX on Intel CPUs.
So that command line option fails on AMD CPUs, right?
> + disable_avx512 [X86] Disable support for AVX512 on Intel CPUs.
Please drop the Intel stuff here as well. It's just a question of time
until AMD gets that as well.
> disable_1tb_segments [PPC]
> Disables the use of 1TB hash page table segments. This
> causes the kernel to fall back to 256MB segments which
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index c24ac1efb12d..cf75638ec657 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -16,6 +16,20 @@
>
> #include
>
> +enum xsave_features {
> + XSAVE_X87,
> + XSAVE_SSE,
> + XSAVE_AVX,
> + XSAVE_MPX_BOUNDS,
> + XSAVE_MPX_CSR,
> + XSAVE_AVX512_OPMASK,
> + XSAVE_AVX512_HI256,
> + XSAVE_AVX512_ZMM_HI256,
> + XSAVE_PT,
> + XSAVE_PKU,
> + XSAVE_UNKNOWN
> +};
What's that enum for? It's unused
> /*
> * Although we spell it out in here, the Processor Trace
> * xfeature is completely unused. We use other mechanisms
> @@ -41,6 +55,8 @@ static const char *xfeature_names[] =
> */
> u64 xfeatures_mask __read_mostly;
>
> +u64 xfeatures_disabled __initdata;
Why is this global?
> + xfeatures_mask &= ~xfeatures_disabled;
> xfeatures_mask &= fpu__get_supported_xfeatures_mask();
Thanks,
tglx
[PATCH RFC,v2] tpm_crb: request and relinquish locality 0
Added two new callbacks to struct tpm_class_ops:
- request_locality
- relinquish_locality
These are called before sending and receiving data from the TPM.
Signed-off-by: Jarkko Sakkinen
---
This not yet v2 of this patch. I'm checking that this is what needs to be done
for tpm_tis_core before I go through testing etc. Thank you.
drivers/char/tpm/tpm-interface.c | 9 +
drivers/char/tpm/tpm_crb.c | 41 +++-
drivers/char/tpm/tpm_tis_core.c | 10 +++---
include/linux/tpm.h | 3 ++-
4 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index e38c792..036843e 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -407,6 +407,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
if (chip->dev.parent)
pm_runtime_get_sync(chip->dev.parent);
+ if (chip->ops->request_locality) {
+ rc = chip->ops->request_locality(chip);
+ if (rc)
+ goto out;
+ }
+
rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
goto out;
@@ -466,6 +472,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
rc = tpm2_commit_space(chip, space, ordinal, buf, &len);
out:
+ if (chip->ops->relinquish_locality)
+ chip->ops->relinquish_locality(chip);
+
if (chip->dev.parent)
pm_runtime_put_sync(chip->dev.parent);
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 3245618..15b22a0 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -34,6 +34,15 @@ enum crb_defaults {
CRB_ACPI_START_INDEX = 1,
};
+enum crb_loc_ctrl {
+ CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
+ CRB_LOC_CTRL_RELINQUISH = BIT(1),
+};
+
+enum crb_loc_state {
+ CRB_LOC_STATE_LOC_ASSIGNED = BIT(1),
+};
+
enum crb_ctrl_req {
CRB_CTRL_REQ_CMD_READY = BIT(0),
CRB_CTRL_REQ_GO_IDLE= BIT(1),
@@ -172,6 +181,35 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
return 0;
}
+static int crb_request_locality(struct tpm_chip *chip, int loc)
+{
+ struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+
+ if (!priv->regs_h)
+ return 0;
+
+ iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, &priv->regs_h->loc_ctrl);
+ if (!crb_wait_for_reg_32(&priv->regs_h->loc_state,
+CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
+CRB_LOC_STATE_LOC_ASSIGNED, /* value */
+TPM2_TIMEOUT_C)) {
+ dev_warn(&chip->dev, "TPM_LOC_STATE_x.requestAccess timed
out\n");
+ return -ETIME;
+ }
+
+ return 0;
+}
+
+static void crb_relinquish_locality(struct tpm_chip *chip, int loc, bool force)
+{
+ struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+
+ if (!priv->regs_h)
+ return;
+
+ iowrite32(CRB_LOC_CTRL_RELINQUISH, &priv->regs_h->loc_ctrl);
+}
+
static u8 crb_status(struct tpm_chip *chip)
{
struct crb_priv *priv = dev_get_drvdata(&chip->dev);
@@ -198,7 +236,6 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t
count)
memcpy_fromio(buf, priv->rsp, 6);
expected = be32_to_cpup((__be32 *) &buf[2]);
-
if (expected > count)
return -EIO;
@@ -279,6 +316,8 @@ static const struct tpm_class_ops tpm_crb = {
.send = crb_send,
.cancel = crb_cancel,
.req_canceled = crb_req_canceled,
+ .request_locality = crb_request_locality,
+ .relinquish_locality = crb_relinquish_locality,
.req_complete_mask = CRB_DRV_STS_COMPLETE,
.req_complete_val = CRB_DRV_STS_COMPLETE,
};
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index fc0e9a2..505e9c5 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -73,7 +73,7 @@ static int check_locality(struct tpm_chip *chip, int l)
return -1;
}
-static void release_locality(struct tpm_chip *chip, int l, int force)
+static void release_locality(struct tpm_chip *chip, int l, bool force)
{
struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
int rc;
@@ -252,7 +252,6 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf,
size_t count)
out:
tpm_tis_ready(chip);
- release_locality(chip, priv->locality, 0);
return size;
}
@@ -268,9 +267,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8
*buf, size_t len)
size_t count = 0;
bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
- if (request_locality(chip, 0) < 0)
- return -EBUSY;
-
status = tpm_tis_status(chip);
if ((status & TPM_STS_COMMAND_READY) == 0) {
Re: [PATCH RFC,v2] tpm_crb: request and relinquish locality 0
On Sat, Mar 11, 2017 at 12:53:36PM +0200, Jarkko Sakkinen wrote:
> Added two new callbacks to struct tpm_class_ops:
>
> - request_locality
> - relinquish_locality
>
> These are called before sending and receiving data from the TPM.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> This not yet v2 of this patch. I'm checking that this is what needs to be done
> for tpm_tis_core before I go through testing etc. Thank you.
And apparently I did not amend tpm-interface.c change :( Anyway, I'm
merely sanity checking that I'm doing the right thing.
/Jarkko
> drivers/char/tpm/tpm-interface.c | 9 +
> drivers/char/tpm/tpm_crb.c | 41
> +++-
> drivers/char/tpm/tpm_tis_core.c | 10 +++---
> include/linux/tpm.h | 3 ++-
> 4 files changed, 54 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index e38c792..036843e 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -407,6 +407,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
> tpm_space *space,
> if (chip->dev.parent)
> pm_runtime_get_sync(chip->dev.parent);
>
> + if (chip->ops->request_locality) {
> + rc = chip->ops->request_locality(chip);
> + if (rc)
> + goto out;
> + }
> +
> rc = tpm2_prepare_space(chip, space, ordinal, buf);
> if (rc)
> goto out;
> @@ -466,6 +472,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
> tpm_space *space,
> rc = tpm2_commit_space(chip, space, ordinal, buf, &len);
>
> out:
> + if (chip->ops->relinquish_locality)
> + chip->ops->relinquish_locality(chip);
> +
> if (chip->dev.parent)
> pm_runtime_put_sync(chip->dev.parent);
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 3245618..15b22a0 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -34,6 +34,15 @@ enum crb_defaults {
> CRB_ACPI_START_INDEX = 1,
> };
>
> +enum crb_loc_ctrl {
> + CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
> + CRB_LOC_CTRL_RELINQUISH = BIT(1),
> +};
> +
> +enum crb_loc_state {
> + CRB_LOC_STATE_LOC_ASSIGNED = BIT(1),
> +};
> +
> enum crb_ctrl_req {
> CRB_CTRL_REQ_CMD_READY = BIT(0),
> CRB_CTRL_REQ_GO_IDLE= BIT(1),
> @@ -172,6 +181,35 @@ static int __maybe_unused crb_cmd_ready(struct device
> *dev,
> return 0;
> }
>
> +static int crb_request_locality(struct tpm_chip *chip, int loc)
> +{
> + struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> +
> + if (!priv->regs_h)
> + return 0;
> +
> + iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, &priv->regs_h->loc_ctrl);
> + if (!crb_wait_for_reg_32(&priv->regs_h->loc_state,
> + CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
> + CRB_LOC_STATE_LOC_ASSIGNED, /* value */
> + TPM2_TIMEOUT_C)) {
> + dev_warn(&chip->dev, "TPM_LOC_STATE_x.requestAccess timed
> out\n");
> + return -ETIME;
> + }
> +
> + return 0;
> +}
> +
> +static void crb_relinquish_locality(struct tpm_chip *chip, int loc, bool
> force)
> +{
> + struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> +
> + if (!priv->regs_h)
> + return;
> +
> + iowrite32(CRB_LOC_CTRL_RELINQUISH, &priv->regs_h->loc_ctrl);
> +}
> +
> static u8 crb_status(struct tpm_chip *chip)
> {
> struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> @@ -198,7 +236,6 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
>
> memcpy_fromio(buf, priv->rsp, 6);
> expected = be32_to_cpup((__be32 *) &buf[2]);
> -
> if (expected > count)
> return -EIO;
>
> @@ -279,6 +316,8 @@ static const struct tpm_class_ops tpm_crb = {
> .send = crb_send,
> .cancel = crb_cancel,
> .req_canceled = crb_req_canceled,
> + .request_locality = crb_request_locality,
> + .relinquish_locality = crb_relinquish_locality,
> .req_complete_mask = CRB_DRV_STS_COMPLETE,
> .req_complete_val = CRB_DRV_STS_COMPLETE,
> };
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index fc0e9a2..505e9c5 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -73,7 +73,7 @@ static int check_locality(struct tpm_chip *chip, int l)
> return -1;
> }
>
> -static void release_locality(struct tpm_chip *chip, int l, int force)
> +static void release_locality(struct tpm_chip *chip, int l, bool force)
> {
> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
> int rc;
> @@ -252,7 +252,6 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
>
> out:
> tpm_tis_ready(chip);
> - release_locality(chip, priv->locality, 0);
>
Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
Em Sat, 11 Mar 2017 00:37:14 +0200 Sakari Ailus escreveu: > Hi Mauro (and others), > > On Fri, Mar 10, 2017 at 12:53:42PM -0300, Mauro Carvalho Chehab wrote: > > Em Fri, 10 Mar 2017 15:20:48 +0100 > > Hans Verkuil escreveu: > > > > > > > > > As I've already mentioned, from talking about this with Mauro, it seems > > > > Mauro is in agreement with permitting the control inheritence... I wish > > > > Mauro would comment for himself, as I can't quote our private discussion > > > > on the subject. > > > > > > I can't comment either, not having seen his mail and reasoning. > > > > The rationale is that we should support the simplest use cases first. > > > > In the case of the first MC-based driver (and several subsequent > > ones), the simplest use case required MC, as it was meant to suport > > a custom-made sophisticated application that required fine control > > on each component of the pipeline and to allow their advanced > > proprietary AAA userspace-based algorithms to work. > > The first MC based driver (omap3isp) supports what the hardware can do, it > does not support applications as such. All media drivers support a subset of what the hardware can do. The question is if such subset covers the use cases or not. The current MC-based drivers (except for uvc) took a patch to offer a more advanced API, to allow direct control to each IP module, as it was said, by the time we merged the OMAP3 driver, that, for the N9/N900 camera to work, it was mandatory to access the pipeline's individual components. Such approach require that some userspace software will have knowledge about some hardware details, in order to setup pipelines and send controls to the right components. That makes really hard to have a generic user friendly application to use such devices. Non-MC based drivers control the hardware via a portable interface with doesn't require any knowledge about the hardware specifics, as either the Kernel or some firmware at the device will set any needed pipelines. In the case of V4L2 controls, when there's no subdev API, the main driver (e. g. the driver that creates the /dev/video nodes) sends a multicast message to all bound I2C drivers. The driver(s) that need them handle it. When the same control may be implemented on different drivers, the main driver sends a unicast message to just one driver[1]. [1] There are several non-MC drivers that have multiple ways to control some things, like doing scaling or adjust volume levels at either the bridge driver or at a subdriver. There's nothing wrong with this approach: it works, it is simpler, it is generic. So, if it covers most use cases, why not allowing it for usecases where a finer control is not a requirement? > Adding support to drivers for different "operation modes" --- this is > essentially what is being asked for --- is not an approach which could serve > either purpose (some functionality with simple interface vs. fully support > what the hardware can do, with interfaces allowing that) adequately in the > short or the long run. Why not? > If we are missing pieces in the puzzle --- in this case the missing pieces > in the puzzle are a generic pipeline configuration library and another > library that, with the help of pipeline autoconfiguration would implement > "best effort" service for regular V4L2 on top of the MC + V4L2 subdev + V4L2 > --- then these pieces need to be impelemented. The solution is > *not* to attempt to support different types of applications in each driver > separately. That will make writing drivers painful, error prone and is > unlikely ever deliver what either purpose requires. > > So let's continue to implement the functionality that the hardware supports. > Making a different choice here is bound to create a lasting conflict between > having to change kernel interface behaviour and the requirement of > supporting new functionality that hasn't been previously thought of, pushing > away SoC vendors from V4L2 ecosystem. This is what we all do want to avoid. This situation is there since 2009. If I remember well, you tried to write such generic plugin in the past, but never finished it, apparently because it is too complex. Others tried too over the years. The last trial was done by Jacek, trying to cover just the exynos4 driver. Yet, even such limited scope plugin was not good enough, as it was never merged upstream. Currently, there's no such plugins upstream. If we can't even merge a plugin that solves it for just *one* driver, I have no hope that we'll be able to do it for the generic case. That's why I'm saying that I'm OK on merging any patch that would allow setting controls via the /dev/video interface on MC-based drivers when compiled without subdev API. I may also consider merging patches allowing to change the behavior on runtime, when compiled with subdev API. > As far as i.MX6 driver goes, it is always possible to implement i.MX6 plugin > for libv4l to perform this. This sho
Re: [Outreachy kernel] [PATCH 00/10] staging: iio: Remove exceptional & on functions name
On Sat, Mar 11, 2017 at 2:57 PM, Julia Lawall wrote: > > > On Sat, 11 Mar 2017, SIMRAN SINGHAL wrote: > >> On Sat, Mar 11, 2017 at 12:12 PM, Julia Lawall wrote: >> > >> > >> > On Sat, 11 Mar 2017, simran singhal wrote: >> > >> >> This patch-series removes exceptional & on functions name. >> > >> > The semantic patch shown does nothing to check that the use of & is >> > exception in the given file. It just removes all the & on function names. >> > >> yes, I used this semantic patch only for only finding the functions with & >> and then I find out this drivers and use semantic patch for removing &. > > The commit message should be written with respect to what was actually > done, and not copied from a patch that actually did something else. The > original semantic patch, that was probably only put in the cover letter, > actually checked if the file mostly used function pointers in a particular > way. > Julia, so what should I do? I should not include this semantic patch as it does not check that that the use of & is exception in the given file. OR As I did it manually so I should mention this. > julia > >> >> > julia >> > >> >> >> >> simran singhal (10): >> >> staging: iio: ad7192: Remove exceptional & on function name >> >> staging: iio: ad7780: Remove exceptional & on function name >> >> staging: iio: cdc: ad7746: Remove exceptional & on function name >> >> staging: iio: cdc: ad7152: Remove exceptional & on function name >> >> staging: iio: adis16240: Remove exceptional & on function name >> >> staging: iio: adis16201: Remove exceptional & on function name >> >> staging: iio: adis16209: Remove exceptional & on function name >> >> staging: iio: adis16203: Remove exceptional & on function name >> >> staging: iio: resolver: Remove exceptional & on function name >> >> staging: iio: gyro: Remove exceptional & on function name >> >> >> >> drivers/staging/iio/accel/adis16201.c | 4 ++-- >> >> drivers/staging/iio/accel/adis16203.c | 4 ++-- >> >> drivers/staging/iio/accel/adis16209.c | 4 ++-- >> >> drivers/staging/iio/accel/adis16240.c | 4 ++-- >> >> drivers/staging/iio/adc/ad7192.c | 12 ++-- >> >> drivers/staging/iio/adc/ad7780.c | 2 +- >> >> drivers/staging/iio/cdc/ad7152.c | 6 +++--- >> >> drivers/staging/iio/cdc/ad7746.c | 4 ++-- >> >> drivers/staging/iio/gyro/adis16060_core.c | 2 +- >> >> drivers/staging/iio/resolver/ad2s1200.c | 2 +- >> >> drivers/staging/iio/resolver/ad2s90.c | 2 +- >> >> 11 files changed, 23 insertions(+), 23 deletions(-) >> >> >> >> -- >> >> 2.7.4 >> >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "outreachy-kernel" group. >> >> To unsubscribe from this group and stop receiving emails from it, send an >> >> email to outreachy-kernel+unsubscr...@googlegroups.com. >> >> To post to this group, send email to outreachy-ker...@googlegroups.com. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/outreachy-kernel/1489203401-17518-1-git-send-email-singhalsimran0%40gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "outreachy-kernel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to outreachy-kernel+unsubscr...@googlegroups.com. >> To post to this group, send email to outreachy-ker...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyODTiF%2BgdwwYnmL1W1oi-R0u2rM4c40jb5iWXFxJpfdJw%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. >>
Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
On 10/03/17 16:09, Mauro Carvalho Chehab wrote: > Em Fri, 10 Mar 2017 13:54:28 +0100 > Hans Verkuil escreveu: > >>> Devices that have complex pipeline that do essentially require using the >>> Media controller interface to configure them are out of that scope. >>> >> >> Way too much of how the MC devices should be used is in the minds of >> developers. >> There is a major lack for good detailed documentation, utilities, compliance >> test (really needed!) and libv4l plugins. > > Unfortunately, we merged an incomplete MC support at the Kernel. We knew > all the problems with MC-based drivers and V4L2 applications by the time > it was developed, and we requested Nokia developers (with was sponsoring MC > develoment, on that time) to work on a solution to allow standard V4L2 > applications to work with MC based boards. > > Unfortunately, we took the decision to merge MC without that, because > Nokia was giving up on Linux development, and we didn't want to lose the > 2 years of discussions and work around it, as Nokia employers were leaving > the company. Also, on that time, there was already some patches floating > around adding backward support via libv4l. Unfortunately, those patches > were never finished. > > The net result is that MC was merged with some huge gaps, including > the lack of a proper solution for a generic V4L2 program to work > with V4L2 devices that use the subdev API. > > That was not that bad by then, as MC was used only on cell phones > that run custom-made applications. > > The reallity changed, as now, we have lots of low cost SoC based > boards, used for all sort of purposes. So, we need a quick solution > for it. > > In other words, while that would be acceptable support special apps > on really embedded systems, it is *not OK* for general purpose SoC > harware[1]. > > [1] I'm calling "general purpose SoC harware" those ARM boards > like Raspberry Pi that are shipped to the mass and used by a wide > range of hobbyists and other people that just wants to run Linux on > ARM. It is possible to buy such boards for a very cheap price, > making them to be used not only on special projects, where a custom > made application could be interesting, but also for a lot of > users that just want to run Linux on a low cost ARM board, while > keeping using standard V4L2 apps, like "camorama". > > That's perhaps one of the reasons why it took a long time for us to > start receiving drivers upstream for such hardware: it is quite > intimidating and not logical to require developers to implement > on their drivers 2 complex APIs (MC, subdev) for those > hardware that most users won't care. From user's perspective, > being able to support generic applications like "camorama" and > "zbar" is all they want. > > In summary, I'm pretty sure we need to support standard V4L2 > applications on boards like Raspberry Pi and those low-cost > SoC-based boards that are shipped to end users. > >> Anyway, regarding this specific patch and for this MC-aware driver: no, you >> shouldn't inherit controls from subdevs. It defeats the purpose. > > Sorry, but I don't agree with that. The subdev API is an optional API > (and even the MC API can be optional). > > I see the rationale for using MC and subdev APIs on cell phones, > ISV and other embedded hardware, as it will allow fine-tuning > the driver's support to allow providing the required quality for > certain custom-made applications. but on general SoC hardware, > supporting standard V4L2 applications is a need. > > Ok, perhaps supporting both subdev API and V4L2 API at the same > time doesn't make much sense. We could disable one in favor of the > other, either at compilation time or at runtime. Right. If the subdev API is disabled, then you have to inherit the subdev controls in the bridge driver (how else would you be able to access them?). And that's the usual case. If you do have the subdev API enabled, AND you use the MC, then the intention clearly is to give userspace full control and inheriting controls no longer makes any sense (and is highly confusing IMHO). > > This way, if the subdev API is disabled, the driver will be > functional for V4L2-based applications that don't support neither > MC or subdev APIs. I'm not sure if it makes sense for the i.MX driver to behave differently depending on whether the subdev API is enabled or disabled. I don't know enough of the hardware to tell if it would ever make sense to disable the subdev API. Regards, Hans > >> As mentioned, I will attempt to try and get some time to work on this >> later this year. Fingers crossed. > > That will be good, and, once we have a solution that works, we can > work on cleanup the code, but, until then, drivers for arm-based boards > sold to end consumers should work out of the box with standard V4L2 apps. > > While we don't have that, I'm OK to merge patches adding such support > upstream. > > Thanks, > Mauro >
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event
On 10/03/17 19:37, Steve Longerbeam wrote:
> Hi Hans,
>
> On 03/10/2017 04:03 AM, Hans Verkuil wrote:
>> On 10/03/17 05:52, Steve Longerbeam wrote:
>>> Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
>>> output device has measured an interval between the reception or transmit
>>> completion of two consecutive frames of video that is outside the nominal
>>> frame interval by some tolerance value.
>>
>> Reading back what was said on this I agree with Sakari that this doesn't
>> belong here.
>>
>> Userspace can detect this just as easily (if not easier) with a timeout.
>>
>
>
> Unfortunately measuring frame intervals from userland is not accurate
> enough for i.MX6.
>
> The issue here is that the IPUv3, specifically the CSI unit, can
> permanently lose vertical sync if there are truncated frames sent
> on the bt.656 bus. We have seen a single missing line of video cause
> loss of vertical sync. The only way to correct this is to shutdown
> the IPU capture hardware and restart, which can be accomplished
> simply by restarting streaming from userland.
>
> There are no other indicators from the sensor about these short
> frame events (believe me, we've exhausted all avenues with the ADV718x).
> And the IPUv3 DMA engine has no status indicators for short frames
> either. So the only way to detect them is by measuring frame intervals.
>
> The intervals have to be able to resolve a single line of missing video.
> With a PAL video source that requires better than 58 usec accuracy.
>
> There is too much uncertainty to resolve this at user level. The
> driver is able to resolve this by measuring intervals between hardware
> interrupts as long as interrupt latency is reasonably low, and we
> have another method using the i.MX6 hardware input capture support
> that can measure these intervals very accurately with no errors
> introduced by interrupt latency.
>
> I made this event a private event to imx-media driver in a previous
> iteration, so I can return it to a private event, but this can't be
> done at user level.
It's fine to use an internal event as long as the end-user doesn't
see it. But if you lose vsyncs, then you never capture another frame,
right? So userspace can detect that (i.e. no new frames arrive) and
it can timeout on that. Or you detect it in the driver and restart there,
or call vb2_queue_error().
Anything really as long as this event isn't user-visible :-)
Regards,
Hans
>
> Steve
>
>
>>
>>>
>>> Signed-off-by: Steve Longerbeam
>>> ---
>>> Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++
>>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>>> include/uapi/linux/videodev2.h | 1 +
>>> 3 files changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> index 8d663a7..dc77363 100644
>>> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> @@ -197,6 +197,12 @@ call.
>>> the regions changes. This event has a struct
>>> :c:type:`v4l2_event_motion_det`
>>> associated with it.
>>> +* - ``V4L2_EVENT_FRAME_INTERVAL_ERROR``
>>> + - 7
>>> + - This event is triggered when the video capture or output device
>>> +has measured an interval between the reception or transmit
>>> +completion of two consecutive frames of video that is outside
>>> +the nominal frame interval by some tolerance value.
>>> * - ``V4L2_EVENT_PRIVATE_START``
>>>- 0x0800
>>>- Base event number for driver-private events.
>>> diff --git a/Documentation/media/videodev2.h.rst.exceptions
>>> b/Documentation/media/videodev2.h.rst.exceptions
>>> index e11a0d0..c7d8fad 100644
>>> --- a/Documentation/media/videodev2.h.rst.exceptions
>>> +++ b/Documentation/media/videodev2.h.rst.exceptions
>>> @@ -459,6 +459,7 @@ replace define V4L2_EVENT_CTRL event-type
>>> replace define V4L2_EVENT_FRAME_SYNC event-type
>>> replace define V4L2_EVENT_SOURCE_CHANGE event-type
>>> replace define V4L2_EVENT_MOTION_DET event-type
>>> +replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
>>> replace define V4L2_EVENT_PRIVATE_START event-type
>>>
>>> replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
>>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>> index 45184a2..cf5a0d0 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -2131,6 +2131,7 @@ struct v4l2_streamparm {
>>> #define V4L2_EVENT_FRAME_SYNC4
>>> #define V4L2_EVENT_SOURCE_CHANGE5
>>> #define V4L2_EVENT_MOTION_DET6
>>> +#define V4L2_EVENT_FRAME_INTERVAL_ERROR7
>>> #define V4L2_EVENT_PRIVATE_START0x0800
>>>
>>> /* Payload for V4L2_EVENT_VSYNC */
>>>
>>
>
Re: [Outreachy kernel] [PATCH 00/10] staging: iio: Remove exceptional & on functions name
On Sat, 11 Mar 2017, SIMRAN SINGHAL wrote: > On Sat, Mar 11, 2017 at 2:57 PM, Julia Lawall wrote: > > > > > > On Sat, 11 Mar 2017, SIMRAN SINGHAL wrote: > > > >> On Sat, Mar 11, 2017 at 12:12 PM, Julia Lawall > >> wrote: > >> > > >> > > >> > On Sat, 11 Mar 2017, simran singhal wrote: > >> > > >> >> This patch-series removes exceptional & on functions name. > >> > > >> > The semantic patch shown does nothing to check that the use of & is > >> > exception in the given file. It just removes all the & on function > >> > names. > >> > > >> yes, I used this semantic patch only for only finding the functions with & > >> and then I find out this drivers and use semantic patch for removing &. > > > > The commit message should be written with respect to what was actually > > done, and not copied from a patch that actually did something else. The > > original semantic patch, that was probably only put in the cover letter, > > actually checked if the file mostly used function pointers in a particular > > way. > > > Julia, so what should I do? > I should not include this semantic patch as it does not check that that the > use > of & is exception in the given file. > OR > As I did it manually so I should mention this. If you checked it manually, just mention that. I don't have the actual patches handy any more, but you could also say something like: Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch. This would be ok if the included semantic patch makes the change. It doesn't suggest that the semantic patch checkked for the excpeptionality. julia > > > julia > > > >> > >> > julia > >> > > >> >> > >> >> simran singhal (10): > >> >> staging: iio: ad7192: Remove exceptional & on function name > >> >> staging: iio: ad7780: Remove exceptional & on function name > >> >> staging: iio: cdc: ad7746: Remove exceptional & on function name > >> >> staging: iio: cdc: ad7152: Remove exceptional & on function name > >> >> staging: iio: adis16240: Remove exceptional & on function name > >> >> staging: iio: adis16201: Remove exceptional & on function name > >> >> staging: iio: adis16209: Remove exceptional & on function name > >> >> staging: iio: adis16203: Remove exceptional & on function name > >> >> staging: iio: resolver: Remove exceptional & on function name > >> >> staging: iio: gyro: Remove exceptional & on function name > >> >> > >> >> drivers/staging/iio/accel/adis16201.c | 4 ++-- > >> >> drivers/staging/iio/accel/adis16203.c | 4 ++-- > >> >> drivers/staging/iio/accel/adis16209.c | 4 ++-- > >> >> drivers/staging/iio/accel/adis16240.c | 4 ++-- > >> >> drivers/staging/iio/adc/ad7192.c | 12 ++-- > >> >> drivers/staging/iio/adc/ad7780.c | 2 +- > >> >> drivers/staging/iio/cdc/ad7152.c | 6 +++--- > >> >> drivers/staging/iio/cdc/ad7746.c | 4 ++-- > >> >> drivers/staging/iio/gyro/adis16060_core.c | 2 +- > >> >> drivers/staging/iio/resolver/ad2s1200.c | 2 +- > >> >> drivers/staging/iio/resolver/ad2s90.c | 2 +- > >> >> 11 files changed, 23 insertions(+), 23 deletions(-) > >> >> > >> >> -- > >> >> 2.7.4 > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups "outreachy-kernel" group. > >> >> To unsubscribe from this group and stop receiving emails from it, send > >> >> an email to outreachy-kernel+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to outreachy-ker...@googlegroups.com. > >> >> To view this discussion on the web visit > >> >> https://groups.google.com/d/msgid/outreachy-kernel/1489203401-17518-1-git-send-email-singhalsimran0%40gmail.com. > >> >> For more options, visit https://groups.google.com/d/optout. > >> >> > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "outreachy-kernel" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to outreachy-kernel+unsubscr...@googlegroups.com. > >> To post to this group, send email to outreachy-ker...@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyODTiF%2BgdwwYnmL1W1oi-R0u2rM4c40jb5iWXFxJpfdJw%40mail.gmail.com. > >> For more options, visit https://groups.google.com/d/optout. > >> >
[tip:x86/process] x86/process: Optimize TIF checks in __switch_to_xtra()
Commit-ID: af8b3cd3934ec60f4c2a420d19a9d416554f140b
Gitweb: http://git.kernel.org/tip/af8b3cd3934ec60f4c2a420d19a9d416554f140b
Author: Kyle Huey
AuthorDate: Tue, 14 Feb 2017 00:11:02 -0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 12:45:17 +0100
x86/process: Optimize TIF checks in __switch_to_xtra()
Help the compiler to avoid reevaluating the thread flags for each checked
bit by reordering the bit checks and providing an explicit xor for
evaluation.
With default defconfigs for each arch,
x86_64: arch/x86/kernel/process.o
text data bss dec hex
3056 8577 16 116492d81 Before
3024 8577 16 116172d61 After
i386: arch/x86/kernel/process.o
text data bss dec hex
2957 8673 8 116382d76 Before
2925 8673 8 116062d56 After
Originally-by: Thomas Gleixner
Signed-off-by: Kyle Huey
Cc: Peter Zijlstra
Cc: Andy Lutomirski
Link: http://lkml.kernel.org/r/20170214081104.9244-2-kh...@kylehuey.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/process.c | 65 ++-
1 file changed, 36 insertions(+), 29 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index f675915..ea9ea25 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -182,54 +182,61 @@ int set_tsc_mode(unsigned int val)
return 0;
}
+static inline void switch_to_bitmap(struct tss_struct *tss,
+ struct thread_struct *prev,
+ struct thread_struct *next,
+ unsigned long tifp, unsigned long tifn)
+{
+ if (tifn & _TIF_IO_BITMAP) {
+ /*
+* Copy the relevant range of the IO bitmap.
+* Normally this is 128 bytes or less:
+*/
+ memcpy(tss->io_bitmap, next->io_bitmap_ptr,
+ max(prev->io_bitmap_max, next->io_bitmap_max));
+ /*
+* Make sure that the TSS limit is correct for the CPU
+* to notice the IO bitmap.
+*/
+ refresh_tss_limit();
+ } else if (tifp & _TIF_IO_BITMAP) {
+ /*
+* Clear any possible leftover bits:
+*/
+ memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
+ }
+}
+
void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
struct tss_struct *tss)
{
struct thread_struct *prev, *next;
+ unsigned long tifp, tifn;
prev = &prev_p->thread;
next = &next_p->thread;
- if (test_tsk_thread_flag(prev_p, TIF_BLOCKSTEP) ^
- test_tsk_thread_flag(next_p, TIF_BLOCKSTEP)) {
+ tifn = READ_ONCE(task_thread_info(next_p)->flags);
+ tifp = READ_ONCE(task_thread_info(prev_p)->flags);
+ switch_to_bitmap(tss, prev, next, tifp, tifn);
+
+ propagate_user_return_notify(prev_p, next_p);
+
+ if ((tifp ^ tifn) & _TIF_BLOCKSTEP) {
unsigned long debugctl = get_debugctlmsr();
debugctl &= ~DEBUGCTLMSR_BTF;
- if (test_tsk_thread_flag(next_p, TIF_BLOCKSTEP))
+ if (tifn & _TIF_BLOCKSTEP)
debugctl |= DEBUGCTLMSR_BTF;
-
update_debugctlmsr(debugctl);
}
- if (test_tsk_thread_flag(prev_p, TIF_NOTSC) ^
- test_tsk_thread_flag(next_p, TIF_NOTSC)) {
- /* prev and next are different */
- if (test_tsk_thread_flag(next_p, TIF_NOTSC))
+ if ((tifp ^ tifn) & _TIF_NOTSC) {
+ if (tifn & _TIF_NOTSC)
hard_disable_TSC();
else
hard_enable_TSC();
}
-
- if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
- /*
-* Copy the relevant range of the IO bitmap.
-* Normally this is 128 bytes or less:
-*/
- memcpy(tss->io_bitmap, next->io_bitmap_ptr,
- max(prev->io_bitmap_max, next->io_bitmap_max));
-
- /*
-* Make sure that the TSS limit is correct for the CPU
-* to notice the IO bitmap.
-*/
- refresh_tss_limit();
- } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) {
- /*
-* Clear any possible leftover bits:
-*/
- memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
- }
- propagate_user_return_notify(prev_p, next_p);
}
/*
[tip:x86/process] x86/process: Optimize TIF_NOTSC switch
Commit-ID: 5a920155e388ec22a22e0532fb695b9215c9b34d
Gitweb: http://git.kernel.org/tip/5a920155e388ec22a22e0532fb695b9215c9b34d
Author: Thomas Gleixner
AuthorDate: Tue, 14 Feb 2017 00:11:04 -0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 12:45:18 +0100
x86/process: Optimize TIF_NOTSC switch
Provide and use a toggle helper instead of doing it with a branch.
x86_64: arch/x86/kernel/process.o
text data bss dec hex
3008 8577 16 116012d51 Before
2976 8577 16 115692d31 After
i386: arch/x86/kernel/process.o
text data bss dec hex
2925 8673 8 116062d56 Before
2893 8673 8 115742d36 After
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Andy Lutomirski
Link: http://lkml.kernel.org/r/20170214081104.9244-4-kh...@kylehuey.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/tlbflush.h | 10 ++
arch/x86/kernel/process.c | 22 --
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 6fa8594..ff4923a 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -110,6 +110,16 @@ static inline void cr4_clear_bits(unsigned long mask)
}
}
+static inline void cr4_toggle_bits(unsigned long mask)
+{
+ unsigned long cr4;
+
+ cr4 = this_cpu_read(cpu_tlbstate.cr4);
+ cr4 ^= mask;
+ this_cpu_write(cpu_tlbstate.cr4, cr4);
+ __write_cr4(cr4);
+}
+
/* Read the CR4 shadow. */
static inline unsigned long cr4_read_shadow(void)
{
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 83fa3cb..366db77 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -124,11 +124,6 @@ void flush_thread(void)
fpu__clear(&tsk->thread.fpu);
}
-static void hard_disable_TSC(void)
-{
- cr4_set_bits(X86_CR4_TSD);
-}
-
void disable_TSC(void)
{
preempt_disable();
@@ -137,15 +132,10 @@ void disable_TSC(void)
* Must flip the CPU state synchronously with
* TIF_NOTSC in the current running context.
*/
- hard_disable_TSC();
+ cr4_set_bits(X86_CR4_TSD);
preempt_enable();
}
-static void hard_enable_TSC(void)
-{
- cr4_clear_bits(X86_CR4_TSD);
-}
-
static void enable_TSC(void)
{
preempt_disable();
@@ -154,7 +144,7 @@ static void enable_TSC(void)
* Must flip the CPU state synchronously with
* TIF_NOTSC in the current running context.
*/
- hard_enable_TSC();
+ cr4_clear_bits(X86_CR4_TSD);
preempt_enable();
}
@@ -233,12 +223,8 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
task_struct *next_p,
wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
}
- if ((tifp ^ tifn) & _TIF_NOTSC) {
- if (tifn & _TIF_NOTSC)
- hard_disable_TSC();
- else
- hard_enable_TSC();
- }
+ if ((tifp ^ tifn) & _TIF_NOTSC)
+ cr4_toggle_bits(X86_CR4_TSD);
}
/*
[tip:x86/process] x86/process: Correct and optimize TIF_BLOCKSTEP switch
Commit-ID: b9894a2f5bd18b1691cb6872c9afe32b148d0132
Gitweb: http://git.kernel.org/tip/b9894a2f5bd18b1691cb6872c9afe32b148d0132
Author: Kyle Huey
AuthorDate: Tue, 14 Feb 2017 00:11:03 -0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 12:45:18 +0100
x86/process: Correct and optimize TIF_BLOCKSTEP switch
The debug control MSR is "highly magical" as the blockstep bit can be
cleared by hardware under not well documented circumstances.
So a task switch relying on the bit set by the previous task (according to
the previous tasks thread flags) can trip over this and not update the flag
for the next task.
To fix this its required to handle DEBUGCTLMSR_BTF when either the previous
or the next or both tasks have the TIF_BLOCKSTEP flag set.
While at it avoid branching within the TIF_BLOCKSTEP case and evaluating
boot_cpu_data twice in kernels without CONFIG_X86_DEBUGCTLMSR.
x86_64: arch/x86/kernel/process.o
textdatabss dec hex
3024857716 116172d61 Before
3008857716 116012d51 After
i386: No change
[ tglx: Made the shift value explicit, use a local variable to make the
code readable and massaged changelog]
Originally-by: Thomas Gleixner
Signed-off-by: Kyle Huey
Cc: Peter Zijlstra
Cc: Andy Lutomirski
Link: http://lkml.kernel.org/r/20170214081104.9244-3-kh...@kylehuey.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/process.c| 12 +++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index d8b5f8a..4c928f3 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -127,6 +127,7 @@
/* DEBUGCTLMSR bits (others vary by model): */
#define DEBUGCTLMSR_LBR(1UL << 0) /* last branch
recording */
+#define DEBUGCTLMSR_BTF_SHIFT 1
#define DEBUGCTLMSR_BTF(1UL << 1) /* single-step on
branches */
#define DEBUGCTLMSR_TR (1UL << 6)
#define DEBUGCTLMSR_BTS(1UL << 7)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index ea9ea25..83fa3cb 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -222,13 +222,15 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
task_struct *next_p,
propagate_user_return_notify(prev_p, next_p);
- if ((tifp ^ tifn) & _TIF_BLOCKSTEP) {
- unsigned long debugctl = get_debugctlmsr();
+ if ((tifp & _TIF_BLOCKSTEP || tifn & _TIF_BLOCKSTEP) &&
+ arch_has_block_step()) {
+ unsigned long debugctl, msk;
+ rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
debugctl &= ~DEBUGCTLMSR_BTF;
- if (tifn & _TIF_BLOCKSTEP)
- debugctl |= DEBUGCTLMSR_BTF;
- update_debugctlmsr(debugctl);
+ msk = tifn & _TIF_BLOCKSTEP;
+ debugctl |= (msk >> TIF_BLOCKSTEP) << DEBUGCTLMSR_BTF_SHIFT;
+ wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
}
if ((tifp ^ tifn) & _TIF_NOTSC) {
Re: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
On 03/11/2017 01:11 AM, Matthew Wilcox wrote:
On Fri, Mar 10, 2017 at 05:58:28PM +0200, Michael S. Tsirkin wrote:
One of the issues of current balloon is the 4k page size
assumption. For example if you free a huge page you
have to split it up and pass 4k chunks to host.
Quite often host can't free these 4k chunks at all (e.g.
when it's using huge tlb fs).
It's even sillier for architectures with base page size >4k.
I completely agree with you that we should be able to pass a hugepage
as a single chunk. Also we shouldn't assume that host and guest have
the same page size. I think we can come up with a scheme that actually
lets us encode that into a 64-bit word, something like this:
bit 0 clear => bits 1-11 encode a page count, bits 12-63 encode a PFN, page
size 4k.
bit 0 set, bit 1 clear => bits 2-12 encode a page count, bits 13-63 encode a
PFN, page size 8k
bits 0+1 set, bit 2 clear => bits 3-13 for page count, bits 14-63 for PFN, page
size 16k.
bits 0-2 set, bit 3 clear => bits 4-14 for page count, bits 15-63 for PFN, page
size 32k
bits 0-3 set, bit 4 clear => bits 5-15 for page count, bits 16-63 for PFN, page
size 64k
That means we can always pass 2048 pages (of whatever page size) in a single
chunk. And
we support arbitrary power of two page sizes. I suggest something like this:
u64 page_to_chunk(struct page *page)
{
u64 chunk = page_to_pfn(page) << PAGE_SHIFT;
chunk |= (1UL << compound_order(page)) - 1;
}
(note this is a single page of order N, so we leave the page count bits
set to 0, meaning one page).
I'm thinking what if the guest needs to transfer these much physically
continuous
memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
Is it going to use Six 64-bit chunks? Would it be simpler if we just
use the 128-bit chunk format (we can drop the previous normal 64-bit
format)?
Best,
Wei
[tip:irq/core] genirq: Add support for nested shared IRQs
Commit-ID: 45e5202213ae6541f7916bb3c64fbcd3019ec473 Gitweb: http://git.kernel.org/tip/45e5202213ae6541f7916bb3c64fbcd3019ec473 Author: Charles Keepax AuthorDate: Tue, 7 Mar 2017 16:28:18 + Committer: Thomas Gleixner CommitDate: Sat, 11 Mar 2017 12:57:03 +0100 genirq: Add support for nested shared IRQs On a specific audio system an interrupt input of an audio CODEC is used as a shared interrupt. That interrupt input is handled by a CODEC specific irq chip driver and triggers a CPU interrupt via the CODEC irq output line. The CODEC interrupt handler demultiplexes the CODEC interrupt inputs and the interrupt handlers for these demultiplexed inputs run nested in the context of the CODEC interrupt handler. The demultiplexed interrupts use handle_nested_irq() as their interrupt handler, which unfortunately has no support for shared interrupts. So the above hardware cannot be supported. Add shared interrupt support to handle_nested_irq() by iterating over the interrupt action chain. [ tglx: Massaged changelog ] Signed-off-by: Charles Keepax Cc: patc...@opensource.wolfsonmicro.com Link: http://lkml.kernel.org/r/1488904098-5350-1-git-send-email-ckee...@opensource.wolfsonmicro.com Signed-off-by: Thomas Gleixner --- kernel/irq/chip.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index be3c34e..686be4b 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -348,7 +348,10 @@ void handle_nested_irq(unsigned int irq) irqd_set(&desc->irq_data, IRQD_IRQ_INPROGRESS); raw_spin_unlock_irq(&desc->lock); - action_ret = action->thread_fn(action->irq, action->dev_id); + action_ret = IRQ_NONE; + for_each_action_of_desc(desc, action) + action_ret |= action->thread_fn(action->irq, action->dev_id); + if (!noirqdebug) note_interrupt(desc, action_ret);
Re: [PATCH v1] soc: rockchip: power-domain: Fix clang warning about negative shift count
Hi Matthias,
Am Freitag, 10. März 2017, 18:21:53 CET schrieb Matthias Kaehlcke:
> The following warning is generated when building with clang:
>
> drivers/soc/rockchip/pm_domains.c:726:22: error: shift count is negative
> [-Werror,-Wshift-count-negative] [RK3399_PD_TCPD0] = DOMAIN_RK3399(8,
> 8, -1, false),
> ^~
> drivers/soc/rockchip/pm_domains.c:101:2: note: expanded from macro
> 'DOMAIN_RK3399' DOMAIN(pwr, status, req, req, req, wakeup)
> ^~
> drivers/soc/rockchip/pm_domains.c:88:27: note: expanded from macro 'DOMAIN'
> .req_mask = (req >= 0) ? BIT(req) : 0, \
> ^~~~
> include/linux/bitops.h:6:24: note: expanded from macro 'BIT'
>
> The BIT macro is evaluated with the negative value -1, even though the
> resulting value would not be assigned. To fix this we only pass values
> between 0 and 63 to BIT(). Unfortunately this means that we lose the
> benefit of the compiler checking for out of bounds errors.
I tend to disagree here. This looks more like a case of "fix your compiler".
That conditional seems perfectly valid as the BIT(req) will never be reached
if req < 0 - your clang simply doesn't recognize the pattern somehow, while
for example gcc does.
Catering to specific whims of specific compilers feels somehow wrong, as what
will happen if some imaginary third compiler requires another different hack
to be satisfied?
Heiko
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/soc/rockchip/pm_domains.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/soc/rockchip/pm_domains.c
> b/drivers/soc/rockchip/pm_domains.c index 1c78c42416c6..6f2bb1222992 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -77,13 +77,15 @@ struct rockchip_pmu {
>
> #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain,
> genpd)
>
> +#define RK_MASK(bit) ((bit >= 0) ? BIT(bit & 0x3f) : 0)
> +
> #define DOMAIN(pwr, status, req, idle, ack, wakeup) \
> -{\
> - .pwr_mask = (pwr >= 0) ? BIT(pwr) : 0, \
> - .status_mask = (status >= 0) ? BIT(status) : 0, \
> - .req_mask = (req >= 0) ? BIT(req) : 0, \
> - .idle_mask = (idle >= 0) ? BIT(idle) : 0, \
> - .ack_mask = (ack >= 0) ? BIT(ack) : 0, \
> +{\
> + .pwr_mask = RK_MASK(pwr), \
> + .status_mask = RK_MASK(status), \
> + .req_mask = RK_MASK(req), \
> + .idle_mask = RK_MASK(idle), \
> + .ack_mask = RK_MASK(ack), \
> .active_wakeup = wakeup,\
> }
Re: [PATCH RFC,v2] tpm_crb: request and relinquish locality 0
On Sat, Mar 11, 2017 at 12:55:43PM +0200, Jarkko Sakkinen wrote: > On Sat, Mar 11, 2017 at 12:53:36PM +0200, Jarkko Sakkinen wrote: > > Added two new callbacks to struct tpm_class_ops: > > > > - request_locality > > - relinquish_locality > > > > These are called before sending and receiving data from the TPM. > > > > Signed-off-by: Jarkko Sakkinen > > --- > > This not yet v2 of this patch. I'm checking that this is what needs to be > > done > > for tpm_tis_core before I go through testing etc. Thank you. > > And apparently I did not amend tpm-interface.c change :( Anyway, I'm > merely sanity checking that I'm doing the right thing. If check_locality fails request_locality returns locality number but it's not used for anything. Would it be OK to change it to just return -EBUSY in this case? /Jarkko
[PATCH v2] tpm_crb: request and relinquish locality 0
Added two new callbacks to struct tpm_class_ops:
- request_locality
- relinquish_locality
These are called before sending and receiving data from the TPM. We
update also tpm_tis_core to use these callbacks. Small modification to
request_locality() is done so that it returns -EBUSY instead of locality
number when check_locality() fails.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 9 +
drivers/char/tpm/tpm_crb.c | 41 +++-
drivers/char/tpm/tpm_tis_core.c | 12
include/linux/tpm.h | 3 ++-
4 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index e38c792..9c56581 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -407,6 +407,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
if (chip->dev.parent)
pm_runtime_get_sync(chip->dev.parent);
+ if (chip->ops->request_locality) {
+ rc = chip->ops->request_locality(chip, 0);
+ if (rc)
+ goto out;
+ }
+
rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
goto out;
@@ -466,6 +472,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
rc = tpm2_commit_space(chip, space, ordinal, buf, &len);
out:
+ if (chip->ops->relinquish_locality)
+ chip->ops->relinquish_locality(chip, 0, false);
+
if (chip->dev.parent)
pm_runtime_put_sync(chip->dev.parent);
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 3245618..15b22a0 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -34,6 +34,15 @@ enum crb_defaults {
CRB_ACPI_START_INDEX = 1,
};
+enum crb_loc_ctrl {
+ CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
+ CRB_LOC_CTRL_RELINQUISH = BIT(1),
+};
+
+enum crb_loc_state {
+ CRB_LOC_STATE_LOC_ASSIGNED = BIT(1),
+};
+
enum crb_ctrl_req {
CRB_CTRL_REQ_CMD_READY = BIT(0),
CRB_CTRL_REQ_GO_IDLE= BIT(1),
@@ -172,6 +181,35 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
return 0;
}
+static int crb_request_locality(struct tpm_chip *chip, int loc)
+{
+ struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+
+ if (!priv->regs_h)
+ return 0;
+
+ iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, &priv->regs_h->loc_ctrl);
+ if (!crb_wait_for_reg_32(&priv->regs_h->loc_state,
+CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
+CRB_LOC_STATE_LOC_ASSIGNED, /* value */
+TPM2_TIMEOUT_C)) {
+ dev_warn(&chip->dev, "TPM_LOC_STATE_x.requestAccess timed
out\n");
+ return -ETIME;
+ }
+
+ return 0;
+}
+
+static void crb_relinquish_locality(struct tpm_chip *chip, int loc, bool force)
+{
+ struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+
+ if (!priv->regs_h)
+ return;
+
+ iowrite32(CRB_LOC_CTRL_RELINQUISH, &priv->regs_h->loc_ctrl);
+}
+
static u8 crb_status(struct tpm_chip *chip)
{
struct crb_priv *priv = dev_get_drvdata(&chip->dev);
@@ -198,7 +236,6 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t
count)
memcpy_fromio(buf, priv->rsp, 6);
expected = be32_to_cpup((__be32 *) &buf[2]);
-
if (expected > count)
return -EIO;
@@ -279,6 +316,8 @@ static const struct tpm_class_ops tpm_crb = {
.send = crb_send,
.cancel = crb_cancel,
.req_canceled = crb_req_canceled,
+ .request_locality = crb_request_locality,
+ .relinquish_locality = crb_relinquish_locality,
.req_complete_mask = CRB_DRV_STS_COMPLETE,
.req_complete_val = CRB_DRV_STS_COMPLETE,
};
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index fc0e9a2..c3cbe24 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -73,7 +73,7 @@ static int check_locality(struct tpm_chip *chip, int l)
return -1;
}
-static void release_locality(struct tpm_chip *chip, int l, int force)
+static void release_locality(struct tpm_chip *chip, int l, bool force)
{
struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
int rc;
@@ -97,7 +97,7 @@ static int request_locality(struct tpm_chip *chip, int l)
long rc;
if (check_locality(chip, l) >= 0)
- return l;
+ return -EBUSY;
rc = tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_REQUEST_USE);
if (rc < 0)
@@ -252,7 +252,6 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf,
size_t count)
out:
tpm_tis_ready(chip);
- release_locality(chip, priv->locality, 0);
return size;
}
@@ -268,9
Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
Em Sat, 11 Mar 2017 12:32:43 +0100 Hans Verkuil escreveu: > On 10/03/17 16:09, Mauro Carvalho Chehab wrote: > > Em Fri, 10 Mar 2017 13:54:28 +0100 > > Hans Verkuil escreveu: > > > >>> Devices that have complex pipeline that do essentially require using the > >>> Media controller interface to configure them are out of that scope. > >>> > >> > >> Way too much of how the MC devices should be used is in the minds of > >> developers. > >> There is a major lack for good detailed documentation, utilities, > >> compliance > >> test (really needed!) and libv4l plugins. > > > > Unfortunately, we merged an incomplete MC support at the Kernel. We knew > > all the problems with MC-based drivers and V4L2 applications by the time > > it was developed, and we requested Nokia developers (with was sponsoring MC > > develoment, on that time) to work on a solution to allow standard V4L2 > > applications to work with MC based boards. > > > > Unfortunately, we took the decision to merge MC without that, because > > Nokia was giving up on Linux development, and we didn't want to lose the > > 2 years of discussions and work around it, as Nokia employers were leaving > > the company. Also, on that time, there was already some patches floating > > around adding backward support via libv4l. Unfortunately, those patches > > were never finished. > > > > The net result is that MC was merged with some huge gaps, including > > the lack of a proper solution for a generic V4L2 program to work > > with V4L2 devices that use the subdev API. > > > > That was not that bad by then, as MC was used only on cell phones > > that run custom-made applications. > > > > The reallity changed, as now, we have lots of low cost SoC based > > boards, used for all sort of purposes. So, we need a quick solution > > for it. > > > > In other words, while that would be acceptable support special apps > > on really embedded systems, it is *not OK* for general purpose SoC > > harware[1]. > > > > [1] I'm calling "general purpose SoC harware" those ARM boards > > like Raspberry Pi that are shipped to the mass and used by a wide > > range of hobbyists and other people that just wants to run Linux on > > ARM. It is possible to buy such boards for a very cheap price, > > making them to be used not only on special projects, where a custom > > made application could be interesting, but also for a lot of > > users that just want to run Linux on a low cost ARM board, while > > keeping using standard V4L2 apps, like "camorama". > > > > That's perhaps one of the reasons why it took a long time for us to > > start receiving drivers upstream for such hardware: it is quite > > intimidating and not logical to require developers to implement > > on their drivers 2 complex APIs (MC, subdev) for those > > hardware that most users won't care. From user's perspective, > > being able to support generic applications like "camorama" and > > "zbar" is all they want. > > > > In summary, I'm pretty sure we need to support standard V4L2 > > applications on boards like Raspberry Pi and those low-cost > > SoC-based boards that are shipped to end users. > > > >> Anyway, regarding this specific patch and for this MC-aware driver: no, you > >> shouldn't inherit controls from subdevs. It defeats the purpose. > > > > Sorry, but I don't agree with that. The subdev API is an optional API > > (and even the MC API can be optional). > > > > I see the rationale for using MC and subdev APIs on cell phones, > > ISV and other embedded hardware, as it will allow fine-tuning > > the driver's support to allow providing the required quality for > > certain custom-made applications. but on general SoC hardware, > > supporting standard V4L2 applications is a need. > > > > Ok, perhaps supporting both subdev API and V4L2 API at the same > > time doesn't make much sense. We could disable one in favor of the > > other, either at compilation time or at runtime. > > Right. If the subdev API is disabled, then you have to inherit the subdev > controls in the bridge driver (how else would you be able to access them?). > And that's the usual case. > > If you do have the subdev API enabled, AND you use the MC, then the > intention clearly is to give userspace full control and inheriting controls > no longer makes any sense (and is highly confusing IMHO). I tend to agree with that. > > > > This way, if the subdev API is disabled, the driver will be > > functional for V4L2-based applications that don't support neither > > MC or subdev APIs. > > I'm not sure if it makes sense for the i.MX driver to behave differently > depending on whether the subdev API is enabled or disabled. I don't know > enough of the hardware to tell if it would ever make sense to disable the > subdev API. Yeah, I don't know enough about it either. The point is: this is something that the driver maintainer and driver users should decide if it either makes sense or not, based on the expected use cases. Tha
[PATCH] staging: lustre fix constant comparision style issue in lu_object.h
This patch resolves the "Comparisons should place the constant on
the right side of the test" found with checkpatch tool.
Signed-off-by: Craig Inches
---
drivers/staging/lustre/lustre/include/lu_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/include/lu_object.h
b/drivers/staging/lustre/lustre/include/lu_object.h
index 7a4f412..02be805 100644
--- a/drivers/staging/lustre/lustre/include/lu_object.h
+++ b/drivers/staging/lustre/lustre/include/lu_object.h
@@ -1130,7 +1130,7 @@ struct lu_context_key {
{\
type *value; \
\
- BUILD_BUG_ON(PAGE_SIZE < sizeof(*value));\
+ BUILD_BUG_ON(sizeof(*value) > PAGE_SIZE);\
\
value = kzalloc(sizeof(*value), GFP_NOFS); \
if (!value) \
--
2.10.2
[tip:x86/cpu] x86/cpu: Drop unneded members of struct cpuinfo_x86
Commit-ID: 04402116846f36adea9503d7cd5104a7ed27a1a6
Gitweb: http://git.kernel.org/tip/04402116846f36adea9503d7cd5104a7ed27a1a6
Author: Mathias Krause
AuthorDate: Sun, 12 Feb 2017 22:12:07 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:30:23 +0100
x86/cpu: Drop unneded members of struct cpuinfo_x86
Those member serve no purpose -- not even fill padding for alignment or
such. So just get rid of them.
Signed-off-by: Mathias Krause
Acked-by: Borislav Petkov
Cc: Jesper Nilsson
Cc: Mikael Starvik
Cc: Geert Uytterhoeven
Cc: Andrew Morton
Cc: "David S. Miller"
Link:
http://lkml.kernel.org/r/1486933932-585-2-git-send-email-mini...@googlemail.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index f385eca..893f80e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -80,7 +80,7 @@ extern u16 __read_mostly tlb_lld_1g[NR_INFO];
/*
* CPU type and hardware bug flags. Kept separately for each CPU.
- * Members of this structure are referenced in head.S, so think twice
+ * Members of this structure are referenced in head_32.S, so think twice
* before touching them. [mj]
*/
@@ -91,11 +91,6 @@ struct cpuinfo_x86 {
__u8x86_mask;
#ifdef CONFIG_X86_32
charwp_works_ok;/* It doesn't on 386's */
-
- /* Problems on some 486Dx4's and old 386's: */
- charrfu;
- charpad0;
- charpad1;
#else
/* Number of 4K pages in DTLB/ITLB combined(in pages): */
int x86_tlbsize;
Re: [PATCH] kbuild: strip the last slash in KBUILD_EXTMOD
Hi Wei,
2017-02-23 0:08 GMT+09:00 Wei Yang :
> Current kbuild will build the target again if we run "make M=dir" and "make
> M=dir/" by turns, since if_changed will see the prerequisite is changed.
> The behavior may confuse the user a little, since actually we are building
> the same target and no difference.
>
> According to current implementation in scripts/Makefile.build, the obj
> passed to next level is a directory name with last slash stripped. This
> patch strips the last slash in KBUILD_EXTMOD which is assigned from "M=".
>
> Signed-off-by: Wei Yang
> ---
> Makefile | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b1037774e8e8..db6ed60928ab 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -184,13 +184,15 @@ endif
> # Old syntax make ... SUBDIRS=$PWD is still supported
> # Setting the environment variable KBUILD_EXTMOD take precedence
> ifdef SUBDIRS
> - KBUILD_EXTMOD ?= $(SUBDIRS)
> + __KBUILD_EXTMOD ?= $(SUBDIRS)
> endif
>
> ifeq ("$(origin M)", "command line")
> - KBUILD_EXTMOD := $(M)
> + __KBUILD_EXTMOD := $(M)
> endif
>
> +KBUILD_EXTMOD = $(patsubst %/,%,$(__KBUILD_EXTMOD))
> +
> # If building an external module we do not care about the all: rule
> # but instead _all depend on modules
> PHONY += all
This patch would break a use-case
where KBUILD_EXTMOD is given as an environment.
Maybe adding the following should be enough?
KBUILD_EXTMOD := $(patsubst %/,%,$(KBUILD_EXTMOD))
--
Best Regards
Masahiro Yamada
[tip:x86/cpu] x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86
Commit-ID: 6415813bae75feba10b8ca3ed6634a72c2a4d313
Gitweb: http://git.kernel.org/tip/6415813bae75feba10b8ca3ed6634a72c2a4d313
Author: Mathias Krause
AuthorDate: Sun, 12 Feb 2017 22:12:08 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:30:24 +0100
x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86
Remove the wp_works_ok member of struct cpuinfo_x86. It's an
optimization back from Linux v0.99 times where we had no fixup support
yet and did the CR0.WP test via special code in the page fault handler.
The < 0 test was an optimization to not do the special casing for each
NULL ptr access violation but just for the first one doing the WP test.
Today it serves no real purpose as the test no longer needs special code
in the page fault handler and the only call side -- mem_init() -- calls
it just once, anyway. However, Xen pre-initializes it to 1, to skip the
test.
Doing the test again for Xen should be no issue at all, as even the
commit introducing skipping the test (commit d560bc61575e ("x86, xen:
Suppress WP test on Xen")) mentioned it being ban aid only. And, in
fact, testing the patch on Xen showed nothing breaks.
The pre-fixup times are long gone and with the removal of the fallback
handling code in commit a5c2a893dbd4 ("x86, 386 removal: Remove
CONFIG_X86_WP_WORKS_OK") the kernel requires a working CR0.WP anyway.
So just get rid of the "optimization" and do the test unconditionally.
Signed-off-by: Mathias Krause
Acked-by: Borislav Petkov
Cc: Jesper Nilsson
Cc: Jeremy Fitzhardinge
Cc: Arnd Hannemann
Cc: Mikael Starvik
Cc: Geert Uytterhoeven
Cc: Andrew Morton
Cc: "David S. Miller"
Link:
http://lkml.kernel.org/r/1486933932-585-3-git-send-email-mini...@googlemail.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h | 4 +---
arch/x86/kernel/cpu/proc.c | 5 ++---
arch/x86/kernel/setup.c | 11 ---
arch/x86/mm/init_32.c| 9 +
arch/x86/xen/enlighten.c | 1 -
5 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 893f80e..4aa93b5 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -89,9 +89,7 @@ struct cpuinfo_x86 {
__u8x86_vendor; /* CPU vendor */
__u8x86_model;
__u8x86_mask;
-#ifdef CONFIG_X86_32
- charwp_works_ok;/* It doesn't on 386's */
-#else
+#ifdef CONFIG_X86_64
/* Number of 4K pages in DTLB/ITLB combined(in pages): */
int x86_tlbsize;
#endif
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 18ca99f..6df621a 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -31,14 +31,13 @@ static void show_cpuinfo_misc(struct seq_file *m, struct
cpuinfo_x86 *c)
"fpu\t\t: %s\n"
"fpu_exception\t: %s\n"
"cpuid level\t: %d\n"
- "wp\t\t: %s\n",
+ "wp\t\t: yes\n",
static_cpu_has_bug(X86_BUG_FDIV) ? "yes" : "no",
static_cpu_has_bug(X86_BUG_F00F) ? "yes" : "no",
static_cpu_has_bug(X86_BUG_COMA) ? "yes" : "no",
static_cpu_has(X86_FEATURE_FPU) ? "yes" : "no",
static_cpu_has(X86_FEATURE_FPU) ? "yes" : "no",
- c->cpuid_level,
- c->wp_works_ok ? "yes" : "no");
+ c->cpuid_level);
}
#else
static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..7cd7bbe 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -173,14 +173,11 @@ static struct resource bss_resource = {
#ifdef CONFIG_X86_32
-/* cpu data as detected by the assembly code in head.S */
-struct cpuinfo_x86 new_cpu_data = {
- .wp_works_ok = -1,
-};
+/* cpu data as detected by the assembly code in head_32.S */
+struct cpuinfo_x86 new_cpu_data;
+
/* common cpu data for all cpus */
-struct cpuinfo_x86 boot_cpu_data __read_mostly = {
- .wp_works_ok = -1,
-};
+struct cpuinfo_x86 boot_cpu_data __read_mostly;
EXPORT_SYMBOL(boot_cpu_data);
unsigned int def_to_bigsmp;
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 2b4b53e..4dddfaf 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -716,15 +716,17 @@ void __init paging_init(void)
*/
static void __init test_wp_bit(void)
{
+ int wp_works_ok;
+
printk(KERN_INFO
"Checking if this processor honours the WP bit even in supervisor mode...");
/* Any page-aligned address will do, the test is non-destructive */
__set_fixmap(FIX_WP_TEST, __pa(&swapper_pg_dir), PAGE_KERNEL_RO);
- boot_cpu_data.wp_works_ok = do_test_wp_bit();
+ wp_works_ok = do_test_wp_bit();
Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval
Hi Steve, On Thu, Mar 09, 2017 at 08:52:58PM -0800, Steve Longerbeam wrote: > If the pads on both sides of a link specify a frame interval, then > those frame intervals should match. Create the exported function > v4l2_subdev_link_validate_frame_interval() to verify this. This > function can be called in a subdevice's media_entity_operations > or v4l2_subdev_pad_ops link_validate callbacks. > > Signed-off-by: Steve Longerbeam If your only goal is to configure frame dropping on a sub-device, I suggest to implement s_frame_interval() on the pads of that sub-device only. The frames are then dropped according to the configured frame rates between the sink and source pads. Say, configuring sink for 1/30 s and source 1/15 would drop half of the incoming frames. Considering that supporting specific frame interval on most sub-devices adds no value or is not the interface through which it the frame rate configured, I think it is overkill to change the link validation to expect otherwise. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[tip:x86/acpi] Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"
Commit-ID: c962cff17dfa11f4a8227ac16de2b28aea3312e4
Gitweb: http://git.kernel.org/tip/c962cff17dfa11f4a8227ac16de2b28aea3312e4
Author: Dou Liyang
AuthorDate: Fri, 3 Mar 2017 16:02:23 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:41:18 +0100
Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"
Revert: dc6db24d2476 ("x86/acpi: Set persistent cpuid <-> nodeid mapping when
booting")
The mapping of "cpuid <-> nodeid" is established at boot time via ACPI
tables to keep associations of workqueues and other node related items
consistent across cpu hotplug.
But, ACPI tables are unreliable and failures with that boot time mapping
have been reported on machines where the ACPI table and the physical
information which is retrieved at actual hotplug is inconsistent.
Revert the mapping implementation so it can be replaced with a less error
prone approach.
Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: r...@rjwysocki.net
Cc: linux-a...@vger.kernel.org
Cc: guzhe...@huawei.com
Cc: izumi.t...@jp.fujitsu.com
Cc: l...@kernel.org
Link:
http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/acpi/boot.c | 2 +-
drivers/acpi/acpi_processor.c | 5 ---
drivers/acpi/bus.c| 1 -
drivers/acpi/processor_core.c | 73 ---
include/linux/acpi.h | 3 --
5 files changed, 1 insertion(+), 83 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index ae32838..f6b0e87 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -710,7 +710,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 4467a80..5d208a9 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -182,11 +182,6 @@ int __weak arch_register_cpu(int cpu)
void __weak arch_unregister_cpu(int cpu) {}
-int __weak acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
-{
- return -ENODEV;
-}
-
static int acpi_processor_hotadd_init(struct acpi_processor *pr)
{
unsigned long long sta;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 80cb5eb..34fbe02 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1249,7 +1249,6 @@ static int __init acpi_init(void)
acpi_wakeup_device_init();
acpi_debugger_init();
acpi_setup_sb_notify_handler();
- acpi_set_processor_mapping();
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 611a558..a843862 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -278,79 +278,6 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static bool __init
-map_processor(acpi_handle handle, phys_cpuid_t *phys_id, int *cpuid)
-{
- int type, id;
- u32 acpi_id;
- acpi_status status;
- acpi_object_type acpi_type;
- unsigned long long tmp;
- union acpi_object object = { 0 };
- struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
-
- status = acpi_get_type(handle, &acpi_type);
- if (ACPI_FAILURE(status))
- return false;
-
- switch (acpi_type) {
- case ACPI_TYPE_PROCESSOR:
- status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
- if (ACPI_FAILURE(status))
- return false;
- acpi_id = object.processor.proc_id;
-
- /* validate the acpi_id */
- if(acpi_processor_validate_proc_id(acpi_id))
- return false;
- break;
- case ACPI_TYPE_DEVICE:
- status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
- if (ACPI_FAILURE(status))
- return false;
- acpi_id = tmp;
- break;
- default:
- return false;
- }
-
- type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
-
- *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
- id = acpi_map_cpuid(*phys_id, acpi_id);
-
- if (id < 0)
- return false;
- *cpuid = id;
- return true;
-}
-
-static acpi_status __init
-set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
- void **rv)
-{
- phys_cpuid_t phys_id;
- int cpu_id;
-
- if (!map_processor(handle, &phys_id, &cpu_id))
- return AE_ERROR;
-
- acpi_map_cpu2node(handle, cpu_id, phys_id);
- return AE_OK;
-}
-
-void __i
[tip:x86/acpi] x86/acpi: Restore the order of CPU IDs
Commit-ID: 2b85b3d22920db7473e5fed5719e7955c0ec323e
Gitweb: http://git.kernel.org/tip/2b85b3d22920db7473e5fed5719e7955c0ec323e
Author: Dou Liyang
AuthorDate: Fri, 3 Mar 2017 16:02:25 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:41:19 +0100
x86/acpi: Restore the order of CPU IDs
The following commits:
f7c28833c2 ("x86/acpi: Enable acpi to register all possible cpus at
boot time") and 8f54969dc8 ("x86/acpi: Introduce persistent storage
for cpuid <-> apicid mapping")
... registered all the possible CPUs at boot time via ACPI tables to
make the mapping of cpuid <-> apicid fixed. Both enabled and disabled
CPUs could have a logical CPU ID after boot time.
But, ACPI tables are unreliable. the number amd order of Local APIC
entries which depends on the firmware is often inconsistent with the
physical devices. Even if they are consistent, The disabled CPUs which
take up some logical CPU IDs will also make the order discontinuous.
Revert the part of disabled CPUs registration, keep the allocation
logic of logical CPU IDs and also keep some code location changes.
Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: r...@rjwysocki.net
Cc: linux-a...@vger.kernel.org
Cc: guzhe...@huawei.com
Cc: izumi.t...@jp.fujitsu.com
Cc: l...@kernel.org
Link:
http://lkml.kernel.org/r/1488528147-2279-4-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/acpi/boot.c | 7 ++-
arch/x86/kernel/apic/apic.c | 26 +++---
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index f6b0e87..b2879cc23 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -179,10 +179,15 @@ static int acpi_register_lapic(int id, u32 acpiid, u8
enabled)
return -EINVAL;
}
+ if (!enabled) {
+ ++disabled_cpus;
+ return -EINVAL;
+ }
+
if (boot_cpu_physical_apicid != -1U)
ver = boot_cpu_apic_version;
- cpu = __generic_processor_info(id, ver, enabled);
+ cpu = generic_processor_info(id, ver);
if (cpu >= 0)
early_per_cpu(x86_cpu_to_acpiid, cpu) = acpiid;
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index aee7ded..8ccb7ef 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2063,7 +2063,7 @@ static int allocate_logical_cpuid(int apicid)
return nr_logical_cpuids++;
}
-int __generic_processor_info(int apicid, int version, bool enabled)
+int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
@@ -2121,11 +2121,9 @@ int __generic_processor_info(int apicid, int version,
bool enabled)
if (num_processors >= nr_cpu_ids) {
int thiscpu = max + disabled_cpus;
- if (enabled) {
- pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
- "reached. Processor %d/0x%x ignored.\n",
- max, thiscpu, apicid);
- }
+ pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
+ "reached. Processor %d/0x%x ignored.\n",
+ max, thiscpu, apicid);
disabled_cpus++;
return -EINVAL;
@@ -2177,23 +2175,13 @@ int __generic_processor_info(int apicid, int version,
bool enabled)
apic->x86_32_early_logical_apicid(cpu);
#endif
set_cpu_possible(cpu, true);
-
- if (enabled) {
- num_processors++;
- physid_set(apicid, phys_cpu_present_map);
- set_cpu_present(cpu, true);
- } else {
- disabled_cpus++;
- }
+ physid_set(apicid, phys_cpu_present_map);
+ set_cpu_present(cpu, true);
+ num_processors++;
return cpu;
}
-int generic_processor_info(int apicid, int version)
-{
- return __generic_processor_info(apicid, version, true);
-}
-
int hard_smp_processor_id(void)
{
return read_apic_id();
[tip:x86/acpi] Revert"x86/acpi: Enable MADT APIs to return disabled apicids"
Commit-ID: 09c3f2bd5c7e5f18687663acb6adc6b167484ca5
Gitweb: http://git.kernel.org/tip/09c3f2bd5c7e5f18687663acb6adc6b167484ca5
Author: Dou Liyang
AuthorDate: Fri, 3 Mar 2017 16:02:24 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:41:18 +0100
Revert"x86/acpi: Enable MADT APIs to return disabled apicids"
Revert: 8ad893faf2ea ("x86/acpi: Enable MADT APIs to return disabled apicids")
Remove the leftovers of the boot time 'cpuid <-> nodeid' mapping approach.
Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: r...@rjwysocki.net
Cc: linux-a...@vger.kernel.org
Cc: guzhe...@huawei.com
Cc: izumi.t...@jp.fujitsu.com
Cc: l...@kernel.org
Link:
http://lkml.kernel.org/r/1488528147-2279-3-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
---
drivers/acpi/processor_core.c | 60 ---
1 file changed, 22 insertions(+), 38 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index a843862..b933061 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -32,12 +32,12 @@ static struct acpi_table_madt *get_madt_table(void)
}
static int map_lapic_id(struct acpi_subtable_header *entry,
-u32 acpi_id, phys_cpuid_t *apic_id, bool ignore_disabled)
+u32 acpi_id, phys_cpuid_t *apic_id)
{
struct acpi_madt_local_apic *lapic =
container_of(entry, struct acpi_madt_local_apic, header);
- if (ignore_disabled && !(lapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (lapic->processor_id != acpi_id)
@@ -48,13 +48,12 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
}
static int map_x2apic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
- bool ignore_disabled)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
{
struct acpi_madt_local_x2apic *apic =
container_of(entry, struct acpi_madt_local_x2apic, header);
- if (ignore_disabled && !(apic->lapic_flags & ACPI_MADT_ENABLED))
+ if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration && (apic->uid == acpi_id)) {
@@ -66,13 +65,12 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
}
static int map_lsapic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
- bool ignore_disabled)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
{
struct acpi_madt_local_sapic *lsapic =
container_of(entry, struct acpi_madt_local_sapic, header);
- if (ignore_disabled && !(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration) {
@@ -89,13 +87,12 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
* Retrieve the ARM CPU physical identifier (MPIDR)
*/
static int map_gicc_mpidr(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *mpidr,
- bool ignore_disabled)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *mpidr)
{
struct acpi_madt_generic_interrupt *gicc =
container_of(entry, struct acpi_madt_generic_interrupt, header);
- if (ignore_disabled && !(gicc->flags & ACPI_MADT_ENABLED))
+ if (!(gicc->flags & ACPI_MADT_ENABLED))
return -ENODEV;
/* device_declaration means Device object in DSDT, in the
@@ -112,7 +109,7 @@ static int map_gicc_mpidr(struct acpi_subtable_header
*entry,
}
static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
- int type, u32 acpi_id, bool ignore_disabled)
+ int type, u32 acpi_id)
{
unsigned long madt_end, entry;
phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
@@ -130,20 +127,16 @@ static phys_cpuid_t map_madt_entry(struct acpi_table_madt
*madt,
struct acpi_subtable_header *header =
(struct acpi_subtable_header *)entry;
if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
- if (!map_lapic_id(header, acpi_id, &phys_id,
- ignore_disabled))
+ if (!map_lapic_id(header, acpi_id, &phys_id))
break;
} else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
- if (!map_x2apic_id(header, type, acpi_id, &phys_id,
- ignore_disabled))
+ if (!map_x2apic_id(header, type, acpi_id, &phys_id))
[tip:x86/acpi] acpi/processor: Implement DEVICE operator for processor enumeration
Commit-ID: 8c8cb30f49b86333d8e036e1945cf1a78c03577e
Gitweb: http://git.kernel.org/tip/8c8cb30f49b86333d8e036e1945cf1a78c03577e
Author: Dou Liyang
AuthorDate: Fri, 3 Mar 2017 16:02:26 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:41:20 +0100
acpi/processor: Implement DEVICE operator for processor enumeration
ACPI allows to declare processors either with the PROCESSOR or with the
DEVICE operator. The current implementation handles only the PROCESSOR
operator.
On a system which uses the DEVICE operator for processor enumeration the
evaluation fails.
Check for the ACPI type of the ACPI handle and evaluate PROCESSOR and
DEVICE types separately.
Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: r...@rjwysocki.net
Cc: linux-a...@vger.kernel.org
Cc: guzhe...@huawei.com
Cc: izumi.t...@jp.fujitsu.com
Cc: l...@kernel.org
Link:
http://lkml.kernel.org/r/1488528147-2279-5-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
---
drivers/acpi/acpi_processor.c | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 5d208a9..9a98d7e 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -633,25 +633,50 @@ static acpi_status __init
acpi_processor_ids_walk(acpi_handle handle,
void **rv)
{
acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long uid;
union acpi_object object = { 0 };
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
- status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+ status = acpi_get_type(handle, &acpi_type);
if (ACPI_FAILURE(status))
- acpi_handle_info(handle, "Not get the processor object\n");
- else
- processor_validated_ids_update(object.processor.proc_id);
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ goto err;
+ uid = object.processor.proc_id;
+ break;
+
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
+ if (ACPI_FAILURE(status))
+ goto err;
+ break;
+ default:
+ goto err;
+ }
+
+ processor_validated_ids_update(uid);
+ return true;
+
+err:
+ acpi_handle_info(handle, "Invalid processor object\n");
+ return false;
- return AE_OK;
}
-static void __init acpi_processor_check_duplicates(void)
+void __init acpi_processor_check_duplicates(void)
{
- /* Search all processor nodes in ACPI namespace */
+ /* check the correctness for all processors in ACPI namespace */
acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX,
acpi_processor_ids_walk,
NULL, NULL, NULL);
+ acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, acpi_processor_ids_walk,
+ NULL, NULL);
}
bool __init acpi_processor_validate_proc_id(int proc_id)
[tip:x86/acpi] acpi/processor: Check for duplicate processor ids at hotplug time
Commit-ID: a77d6cd968497792e072b74dff45b891ba778ddb
Gitweb: http://git.kernel.org/tip/a77d6cd968497792e072b74dff45b891ba778ddb
Author: Dou Liyang
AuthorDate: Fri, 3 Mar 2017 16:02:27 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:41:20 +0100
acpi/processor: Check for duplicate processor ids at hotplug time
The check for duplicate processor ids happens at boot time based on the
ACPI table contents, but the final sanity checks for a processor happen
at hotplug time.
At hotplug time, where the physical information is available, which might
differ from the ACPI table information, a check for duplicate processor
ids is missing.
Add it to the hotplug checks and rename the function so it better
reflects its purpose.
Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: r...@rjwysocki.net
Cc: linux-a...@vger.kernel.org
Cc: guzhe...@huawei.com
Cc: izumi.t...@jp.fujitsu.com
Cc: l...@kernel.org
Link:
http://lkml.kernel.org/r/1488528147-2279-6-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
---
drivers/acpi/acpi_processor.c | 13 ++---
include/linux/acpi.h | 2 +-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 9a98d7e..0143135 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -280,6 +280,13 @@ static int acpi_processor_get_info(struct acpi_device
*device)
pr->acpi_id = value;
}
+ if (acpi_duplicate_processor_id(pr->acpi_id)) {
+ dev_err(&device->dev,
+ "Failed to get unique processor _UID (0x%x)\n",
+ pr->acpi_id);
+ return -ENODEV;
+ }
+
pr->phys_id = acpi_get_phys_id(pr->handle, device_declaration,
pr->acpi_id);
if (invalid_phys_cpuid(pr->phys_id))
@@ -580,7 +587,7 @@ static struct acpi_scan_handler processor_container_handler
= {
static int nr_unique_ids __initdata;
/* The number of the duplicate processor IDs */
-static int nr_duplicate_ids __initdata;
+static int nr_duplicate_ids;
/* Used to store the unique processor IDs */
static int unique_processor_ids[] __initdata = {
@@ -588,7 +595,7 @@ static int unique_processor_ids[] __initdata = {
};
/* Used to store the duplicate processor IDs */
-static int duplicate_processor_ids[] __initdata = {
+static int duplicate_processor_ids[] = {
[0 ... NR_CPUS - 1] = -1,
};
@@ -679,7 +686,7 @@ void __init acpi_processor_check_duplicates(void)
NULL, NULL);
}
-bool __init acpi_processor_validate_proc_id(int proc_id)
+bool acpi_duplicate_processor_id(int proc_id)
{
int i;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 63a7519..9b05886 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -287,7 +287,7 @@ static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
}
/* Validate the processor object's proc_id */
-bool acpi_processor_validate_proc_id(int proc_id);
+bool acpi_duplicate_processor_id(int proc_id);
#ifdef CONFIG_ACPI_HOTPLUG_CPU
/* Arch dependent functions for cpu hotplug support */
Re: [PATCH v5 21/39] UAPI: Add media UAPI Kbuild file
Hi Steve, On Thu, Mar 09, 2017 at 08:53:01PM -0800, Steve Longerbeam wrote: > Add an empty UAPI Kbuild file for media UAPI headers. > > Signed-off-by: Steve Longerbeam The existing V4L2 UAPI headers are under include/uapi/linux. Could you use that directory instead? I actually wouldn't really object doing this but it should have been done in 2002 or so when the first V4L2 header was added. Now the benefit is questionable. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[PATCH v2 RFC] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages
From: Yisheng Xie
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, when memcg is disabled or on legacy hierarchy, it should not do
this useless retry at all, for we do not have any cgroup's reserves
memory to tap, and we have already done hard work but made no progress.
To avoid this time costly and useless retrying, add a stub function
may_thrash and return true when memcg is disabled or on legacy
hierarchy.
Signed-off-by: Yisheng Xie
Suggested-by: Shakeel Butt
---
v2:
- more restrictive condition for retry of shrink_zones (restricting
cgroup_disabled=memory boot option and cgroup legacy hierarchy) - Shakeel
- add a stub function may_thrash() to avoid compile error or warning.
- rename subject from "donot retry shrink zones when memcg is disable"
to "more restrictive condition for retry in do_try_to_free_pages"
Any comment is more than welcome!
Thanks
Yisheng Xie
mm/vmscan.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bc8031e..415f800 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -184,6 +184,19 @@ static bool sane_reclaim(struct scan_control *sc)
#endif
return false;
}
+
+static bool may_thrash(struct scan_control *sc)
+{
+ /*
+* When memcg is disabled or on legacy hierarchy, there is no cgroup
+* reserves memory to tap.
+*/
+ if (!cgroup_subsys_enabled(memory_cgrp_subsys) ||
+ !cgroup_subsys_on_dfl(memory_cgrp_subsys))
+ return true;
+
+ return sc->may_thrash;
+}
#else
static bool global_reclaim(struct scan_control *sc)
{
@@ -194,6 +207,11 @@ static bool sane_reclaim(struct scan_control *sc)
{
return true;
}
+
+static bool may_thrash(struct scan_control *sc)
+{
+ return true;
+}
#endif
/*
@@ -2808,7 +2826,7 @@ static unsigned long do_try_to_free_pages(struct zonelist
*zonelist,
return 1;
/* Untapped cgroup reserves? Don't OOM, retry. */
- if (!sc->may_thrash) {
+ if (!may_thrash(sc)) {
sc->priority = initial_priority;
sc->may_thrash = 1;
goto retry;
--
1.9.1
[tip:x86/vdso] x86/hyperv: Implement hv_get_tsc_page()
Commit-ID: bd2a9adaadb8defcaf6c284bca7ff41634105f51
Gitweb: http://git.kernel.org/tip/bd2a9adaadb8defcaf6c284bca7ff41634105f51
Author: Vitaly Kuznetsov
AuthorDate: Fri, 3 Mar 2017 14:21:40 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:47:28 +0100
x86/hyperv: Implement hv_get_tsc_page()
To use Hyper-V TSC page clocksource from vDSO we need to make tsc_pg
available. Implement hv_get_tsc_page() and add CONFIG_HYPERV_TSCPAGE to
make #ifdef-s simple.
Signed-off-by: Vitaly Kuznetsov
Cc: Stephen Hemminger
Cc: Haiyang Zhang
Cc: Dexuan Cui
Cc: Andy Lutomirski
Cc: de...@linuxdriverproject.org
Cc: "K. Y. Srinivasan"
Cc: virtualizat...@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20170303132142.25595-2-vkuzn...@redhat.com
Signed-off-by: Thomas Gleixner
---
arch/x86/hyperv/hv_init.c | 9 +++--
arch/x86/include/asm/mshyperv.h | 8
drivers/hv/Kconfig | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 8bef70e..bb1ea58 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -27,10 +27,15 @@
#include
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
static struct ms_hyperv_tsc_page *tsc_pg;
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
+{
+ return tsc_pg;
+}
+
static u64 read_hv_clock_tsc(struct clocksource *arg)
{
u64 current_tick;
@@ -139,7 +144,7 @@ void hyperv_init(void)
/*
* Register Hyper-V specific clocksource.
*/
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
if (ms_hyperv.features & HV_X64_MSR_REFERENCE_TSC_AVAILABLE) {
union hv_x64_msr_hypercall_contents tsc_msr;
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 7c9c895..d324dce 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -176,4 +176,12 @@ void hyperv_report_panic(struct pt_regs *regs);
bool hv_is_hypercall_page_setup(void);
void hyperv_cleanup(void);
#endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
+#else
+static inline struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
+{
+ return NULL;
+}
+#endif
#endif
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 0403b51..c29cd53 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -7,6 +7,9 @@ config HYPERV
Select this option to run Linux as a Hyper-V client operating
system.
+config HYPERV_TSCPAGE
+ def_bool HYPERV && X86_64
+
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
depends on HYPERV && CONNECTOR && NLS
[tip:x86/vdso] x86/hyperv: Move TSC reading method to asm/mshyperv.h
Commit-ID: 0733379b512ce36ba0b10942f9597b74f579f063
Gitweb: http://git.kernel.org/tip/0733379b512ce36ba0b10942f9597b74f579f063
Author: Vitaly Kuznetsov
AuthorDate: Fri, 3 Mar 2017 14:21:41 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:47:28 +0100
x86/hyperv: Move TSC reading method to asm/mshyperv.h
As a preparation to making Hyper-V TSC page suitable for vDSO move
the TSC page reading logic to asm/mshyperv.h. While on it, do the
following:
- Document the reading algorithm.
- Simplify the code a bit.
- Add explicit READ_ONCE() to not rely on 'volatile'.
- Add explicit barriers to prevent re-ordering (we need to read sequence
strictly before and after)
- Use mul_u64_u64_shr() instead of assembly, gcc generates a single 'mul'
instruction on x86_64 anyway.
[ tglx: Simplified the loop ]
Signed-off-by: Vitaly Kuznetsov
Cc: Stephen Hemminger
Cc: Haiyang Zhang
Cc: Dexuan Cui
Cc: Andy Lutomirski
Cc: de...@linuxdriverproject.org
Cc: "K. Y. Srinivasan"
Cc: virtualizat...@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20170303132142.25595-3-vkuzn...@redhat.com
Signed-off-by: Thomas Gleixner
---
arch/x86/hyperv/hv_init.c | 36
arch/x86/include/asm/mshyperv.h | 46 +
2 files changed, 50 insertions(+), 32 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index bb1ea58..7f51523 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -38,39 +38,11 @@ struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
static u64 read_hv_clock_tsc(struct clocksource *arg)
{
- u64 current_tick;
+ u64 current_tick = hv_read_tsc_page(tsc_pg);
+
+ if (current_tick == U64_MAX)
+ rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
- if (tsc_pg->tsc_sequence != 0) {
- /*
-* Use the tsc page to compute the value.
-*/
-
- while (1) {
- u64 tmp;
- u32 sequence = tsc_pg->tsc_sequence;
- u64 cur_tsc;
- u64 scale = tsc_pg->tsc_scale;
- s64 offset = tsc_pg->tsc_offset;
-
- rdtscll(cur_tsc);
- /* current_tick = ((cur_tsc *scale) >> 64) + offset */
- asm("mulq %3"
- : "=d" (current_tick), "=a" (tmp)
- : "a" (cur_tsc), "r" (scale));
-
- current_tick += offset;
- if (tsc_pg->tsc_sequence == sequence)
- return current_tick;
-
- if (tsc_pg->tsc_sequence != 0)
- continue;
- /*
-* Fallback using MSR method.
-*/
- break;
- }
- }
- rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
return current_tick;
}
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index d324dce..fba1007 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -178,6 +178,52 @@ void hyperv_cleanup(void);
#endif
#ifdef CONFIG_HYPERV_TSCPAGE
struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
+static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
+{
+ u64 scale, offset, cur_tsc;
+ u32 sequence;
+
+ /*
+* The protocol for reading Hyper-V TSC page is specified in Hypervisor
+* Top-Level Functional Specification ver. 3.0 and above. To get the
+* reference time we must do the following:
+* - READ ReferenceTscSequence
+* A special '0' value indicates the time source is unreliable and we
+* need to use something else. The currently published specification
+* versions (up to 4.0b) contain a mistake and wrongly claim '-1'
+* instead of '0' as the special value, see commit c35b82ef0294.
+* - ReferenceTime =
+*((RDTSC() * ReferenceTscScale) >> 64) + ReferenceTscOffset
+* - READ ReferenceTscSequence again. In case its value has changed
+* since our first reading we need to discard ReferenceTime and repeat
+* the whole sequence as the hypervisor was updating the page in
+* between.
+*/
+ do {
+ sequence = READ_ONCE(tsc_pg->tsc_sequence);
+ if (!sequence)
+ return U64_MAX;
+ /*
+* Make sure we read sequence before we read other values from
+* TSC page.
+*/
+ smp_rmb();
+
+ scale = READ_ONCE(tsc_pg->tsc_scale);
+ offset = READ_ONCE(tsc_pg->tsc_offset);
+ cur_tsc = rdtsc_ordered();
+
+ /*
+* Make sure we read se
[tip:x86/vdso] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method
Commit-ID: 90b20432aeb850ef84086a72893cd9411479d896
Gitweb: http://git.kernel.org/tip/90b20432aeb850ef84086a72893cd9411479d896
Author: Vitaly Kuznetsov
AuthorDate: Fri, 3 Mar 2017 14:21:42 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:47:28 +0100
x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method
Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol
defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the
required support by adding hvclock_page VVAR.
Signed-off-by: Vitaly Kuznetsov
Cc: Stephen Hemminger
Cc: Haiyang Zhang
Cc: Dexuan Cui
Cc: Andy Lutomirski
Cc: de...@linuxdriverproject.org
Cc: "K. Y. Srinivasan"
Cc: virtualizat...@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20170303132142.25595-4-vkuzn...@redhat.com
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 24
arch/x86/entry/vdso/vdso-layout.lds.S | 3 ++-
arch/x86/entry/vdso/vdso2c.c | 3 +++
arch/x86/entry/vdso/vma.c | 7 +++
arch/x86/hyperv/hv_init.c | 3 +++
arch/x86/include/asm/clocksource.h| 3 ++-
arch/x86/include/asm/vdso.h | 1 +
7 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/vclock_gettime.c
b/arch/x86/entry/vdso/vclock_gettime.c
index 9d4d6e1..fa8dbfc 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,11 @@ extern u8 pvclock_page
__attribute__((visibility("hidden")));
#endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+extern u8 hvclock_page
+ __attribute__((visibility("hidden")));
+#endif
+
#ifndef BUILD_VDSO32
notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
@@ -141,6 +147,20 @@ static notrace u64 vread_pvclock(int *mode)
return last;
}
#endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+static notrace u64 vread_hvclock(int *mode)
+{
+ const struct ms_hyperv_tsc_page *tsc_pg =
+ (const struct ms_hyperv_tsc_page *)&hvclock_page;
+ u64 current_tick = hv_read_tsc_page(tsc_pg);
+
+ if (current_tick != U64_MAX)
+ return current_tick;
+
+ *mode = VCLOCK_NONE;
+ return 0;
+}
+#endif
notrace static u64 vread_tsc(void)
{
@@ -173,6 +193,10 @@ notrace static inline u64 vgetsns(int *mode)
else if (gtod->vclock_mode == VCLOCK_PVCLOCK)
cycles = vread_pvclock(mode);
#endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+ else if (gtod->vclock_mode == VCLOCK_HVCLOCK)
+ cycles = vread_hvclock(mode);
+#endif
else
return 0;
v = (cycles - gtod->cycle_last) & gtod->mask;
diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S
b/arch/x86/entry/vdso/vdso-layout.lds.S
index a708aa9..8ebb4b6 100644
--- a/arch/x86/entry/vdso/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/vdso-layout.lds.S
@@ -25,7 +25,7 @@ SECTIONS
* segment.
*/
- vvar_start = . - 2 * PAGE_SIZE;
+ vvar_start = . - 3 * PAGE_SIZE;
vvar_page = vvar_start;
/* Place all vvars at the offsets in asm/vvar.h. */
@@ -36,6 +36,7 @@ SECTIONS
#undef EMIT_VVAR
pvclock_page = vvar_start + PAGE_SIZE;
+ hvclock_page = vvar_start + 2 * PAGE_SIZE;
. = SIZEOF_HEADERS;
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 491020b..0780a44 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -74,6 +74,7 @@ enum {
sym_vvar_page,
sym_hpet_page,
sym_pvclock_page,
+ sym_hvclock_page,
sym_VDSO_FAKE_SECTION_TABLE_START,
sym_VDSO_FAKE_SECTION_TABLE_END,
};
@@ -82,6 +83,7 @@ const int special_pages[] = {
sym_vvar_page,
sym_hpet_page,
sym_pvclock_page,
+ sym_hvclock_page,
};
struct vdso_sym {
@@ -94,6 +96,7 @@ struct vdso_sym required_syms[] = {
[sym_vvar_page] = {"vvar_page", true},
[sym_hpet_page] = {"hpet_page", true},
[sym_pvclock_page] = {"pvclock_page", true},
+ [sym_hvclock_page] = {"hvclock_page", true},
[sym_VDSO_FAKE_SECTION_TABLE_START] = {
"VDSO_FAKE_SECTION_TABLE_START", false
},
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 226ca70..faf80fd 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_X86_64)
unsigned int __read_mostly vdso64_enabled = 1;
@@ -121,6 +122,12 @@ static int vvar_fault(const struct vm_special_mapping *sm,
vmf->address,
__pa(pvti) >> PAGE_SHIFT);
}
+ } else if (sym_offset == image->sym_hvclock_page) {
+ struct ms_hyperv_tsc_page *tsc_pg = hv_get_tsc_page();
+
+ i
[PATCH v2 RFC] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages
From: Yisheng Xie
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, when memcg is disabled or on legacy hierarchy, it should not do
this useless retry at all, for we do not have any cgroup's reserves
memory to tap, and we have already done hard work but made no progress.
To avoid this time costly and useless retrying, add a stub function
may_thrash and return true when memcg is disabled or on legacy
hierarchy.
Signed-off-by: Yisheng Xie
Suggested-by: Shakeel Butt
---
v2:
- more restrictive condition for retry of shrink_zones (restricting
cgroup_disabled=memory boot option and cgroup legacy hierarchy) - Shakeel
- add a stub function may_thrash() to avoid compile error or warning.
- rename subject from "donot retry shrink zones when memcg is disable"
to "more restrictive condition for retry in do_try_to_free_pages"
Any comment is more than welcome!
Thanks
Yisheng Xie
mm/vmscan.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bc8031e..415f800 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -184,6 +184,19 @@ static bool sane_reclaim(struct scan_control *sc)
#endif
return false;
}
+
+static bool may_thrash(struct scan_control *sc)
+{
+ /*
+* When memcg is disabled or on legacy hierarchy, there is no cgroup
+* reserves memory to tap.
+*/
+ if (!cgroup_subsys_enabled(memory_cgrp_subsys) ||
+ !cgroup_subsys_on_dfl(memory_cgrp_subsys))
+ return true;
+
+ return sc->may_thrash;
+}
#else
static bool global_reclaim(struct scan_control *sc)
{
@@ -194,6 +207,11 @@ static bool sane_reclaim(struct scan_control *sc)
{
return true;
}
+
+static bool may_thrash(struct scan_control *sc)
+{
+ return true;
+}
#endif
/*
@@ -2808,7 +2826,7 @@ static unsigned long do_try_to_free_pages(struct zonelist
*zonelist,
return 1;
/* Untapped cgroup reserves? Don't OOM, retry. */
- if (!sc->may_thrash) {
+ if (!may_thrash(sc)) {
sc->priority = initial_priority;
sc->may_thrash = 1;
goto retry;
--
1.9.1
Re: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote: > I'm thinking what if the guest needs to transfer these much physically > continuous > memory to host: 1GB+2MB+64KB+32KB+16KB+4KB. > Is it going to use Six 64-bit chunks? Would it be simpler if we just > use the 128-bit chunk format (we can drop the previous normal 64-bit > format)? Is that a likely thing for the guest to need to do though? Freeing a 1GB page is much more liikely, IMO.
Re: [PATCH v2 07/11] iio: adc: sun4i-gpadc-iio: move code used in MFD probing to new function
Hi Icenowy,
On 10/03/2017 20:36, Icenowy Zheng wrote:
>
>
> 10.03.2017, 18:56, "Quentin Schulz" :
>> This moves code used in MFD probing to a new sun4i_gpadc_probe_mfd
>> function.
>>
>> Signed-off-by: Quentin Schulz
>> ---
>>
>> added in v2
>>
>> drivers/iio/adc/sun4i-gpadc-iio.c | 78
>> ++-
>
> I cannot find this source file even in linux-next.
>
>From the cover letter:
This series of patch is based on this[1] series of patch.
[1] https://lkml.org/lkml/2016/12/13/298 : "[PATCH v9] add support for
Allwinner SoCs ADC"
Quentin
>> 1 file changed, 45 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
>> b/drivers/iio/adc/sun4i-gpadc-iio.c
>> index a8e134f..7cb997a 100644
>> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
>> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
>> @@ -454,31 +454,16 @@ static int sun4i_irq_init(struct platform_device
>> *pdev, const char *name,
>> return 0;
>> }
>>
>> -static int sun4i_gpadc_probe(struct platform_device *pdev)
>> +static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
>> + struct iio_dev *indio_dev)
>> {
>> - struct sun4i_gpadc_iio *info;
>> - struct iio_dev *indio_dev;
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> + struct sun4i_gpadc_dev *sun4i_gpadc_dev =
>> + dev_get_drvdata(pdev->dev.parent);
>> int ret;
>> - struct sun4i_gpadc_dev *sun4i_gpadc_dev;
>> -
>> - sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
>> -
>> - indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> - if (!indio_dev)
>> - return -ENOMEM;
>>
>> - info = iio_priv(indio_dev);
>> - platform_set_drvdata(pdev, indio_dev);
>> -
>> - mutex_init(&info->mutex);
>> info->regmap = sun4i_gpadc_dev->regmap;
>> - info->indio_dev = indio_dev;
>> - init_completion(&info->completion);
>> - indio_dev->name = dev_name(&pdev->dev);
>> - indio_dev->dev.parent = &pdev->dev;
>> - indio_dev->dev.of_node = pdev->dev.of_node;
>> - indio_dev->info = &sun4i_gpadc_iio_info;
>> - indio_dev->modes = INDIO_DIRECT_MODE;
>> +
>> indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
>> indio_dev->channels = sun4i_gpadc_channels;
>>
>> @@ -519,8 +504,7 @@ static int sun4i_gpadc_probe(struct platform_device
>> *pdev)
>> dev_err(&pdev->dev,
>> "could not register thermal sensor: %ld\n",
>> PTR_ERR(tzd));
>> - ret = PTR_ERR(tzd);
>> - goto err;
>> + return PTR_ERR(tzd);
>> }
>> } else {
>> indio_dev->num_channels =
>> @@ -528,36 +512,65 @@ static int sun4i_gpadc_probe(struct platform_device
>> *pdev)
>> indio_dev->channels = sun4i_gpadc_channels_no_temp;
>> }
>>
>> - pm_runtime_set_autosuspend_delay(&pdev->dev,
>> - SUN4I_GPADC_AUTOSUSPEND_DELAY);
>> - pm_runtime_use_autosuspend(&pdev->dev);
>> - pm_runtime_set_suspended(&pdev->dev);
>> - pm_runtime_enable(&pdev->dev);
>> -
>> if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
>> sun4i_gpadc_temp_data_irq_handler,
>> "temp_data", &info->temp_data_irq,
>> &info->ignore_temp_data_irq);
>> if (ret < 0)
>> - goto err;
>> + return ret;
>> }
>>
>> ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
>> sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
>> &info->fifo_data_irq,
>> &info->ignore_fifo_data_irq);
>> if (ret < 0)
>> - goto err;
>> + return ret;
>>
>> if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> ret = iio_map_array_register(indio_dev,
>> sun4i_gpadc_hwmon_maps);
>> if (ret < 0) {
>> dev_err(&pdev->dev,
>> "failed to register iio map array\n");
>> - goto err;
>> + return ret;
>> }
>> }
>>
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_probe(struct platform_device *pdev)
>> +{
>> + struct sun4i_gpadc_iio *info;
>> + struct iio_dev *indio_dev;
>> + int ret;
>> +
>> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + info = iio_priv(indio_dev);
>> + platform_set_drvdata(pdev, indio_dev);
>> +
>> + mutex_init(&info->mutex);
>> + info->indio_dev = indio_dev;
>> + init_completion(&info->completion);
>> + indio_dev->name = dev_name(&pdev->dev);
>> + indio_dev->dev.parent = &pdev->dev;
>> + indio_dev->dev.of_node = pdev->dev.of_node;
>> + indio_dev->info = &sun4i_gpadc_iio_info;
>> + indio_dev->modes = INDIO_DIRECT_MODE;
>> +
>> + ret = sun4i_gpadc_probe_mfd(pdev, indio_dev);
>> + if (ret)
>> + return ret;
>> +
>> + pm_runtime_set_autosuspend_delay(&pdev->dev,
>> + SUN4I_GPADC_AUTOSUSPEND_DELAY);
>> + pm_runtime
Re: [PATCH v2 05/11] Documentation: DT: bindings: mfd: add A33 GPADC binding
Hi Icenowy,
On 10/03/2017 20:25, Icenowy Zheng wrote:
>
>
> 10.03.2017, 18:56, "Quentin Schulz" :
>> This patch adds documentation for the A33 GPADC binding.
>>
>> Signed-off-by: Quentin Schulz
>> ---
>>
>> added in v2
>>
>> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 59 ++
>> 1 file changed, 59 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> new file mode 100644
>> index 000..17242c8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> @@ -0,0 +1,59 @@
>> +Allwinner SoCs' GPADC Device Tree bindings
>> +--
>> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor
>> +and sometimes as a touchscreen controller.
>> +
>> +Required properties:
>> + - compatible: "sun8i-a33-gpadc-iio",
>> + - reg: mmio address range of the chip,
>> + - #thermal-sensor-cells: shall be 0,
>> + - #io-channel-cells: shall be 0,
>> +
>> +Example:
>> + rtp: rtp@01c25000 {
>
> I think we'd better call it ths.
>
To match the datasheet, I agree.
> And can you make thermal-sensor-cells become 1?
>
> Maxime Ripard wants to base H3/H5/A64 thermal driver on this patchset, and
> for H5/A64 there's 2/3 thermal sensors.
>
Yes, that'll require a specific DT node for those thermal sensors. Then
since we would update the possible compatibles in the documentation
anyway, that would be a good idea to update to say that
thermal-sensor-cells could be different from 0 too.
That was my mindset to set thermal-sensor-cells to 0, since we only
support SoC which has only one thermal sensor at the moment.
> Thus for A33/H3 we will have thermal-sensor-cells to 1, but only have
> <&ths 0>.
>
That's non-sense. There is one thermal sensor for the A33,
thermal-sensor-cells has to be 0.
I don't mind to remove the requirement for thermal-sensor-cells to be 0
but I won't put a requirement for it to be 1 as it isn't true.
Thanks,
Quentin
>> + compatible = "allwinner,sun8i-a33-gpadc-iio";
>> + reg = <0x01c25000 0x100>;
>> + #thermal-sensor-cells = <0>;
>> + #io-channel-cells = <0>;
>> + };
>> +
>> +sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>> +
>> +sun4i resistive touchscreen controller
>> +--
>> +
>> +Required properties:
>> + - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
>> + "allwinner,sun6i-a31-ts"
>> + - reg: mmio address range of the chip
>> + - interrupts: interrupt to which the chip is connected
>> + - #thermal-sensor-cells: shall be 0
>> +
>> +Optional properties:
>> + - allwinner,ts-attached : boolean indicating that an actual touchscreen
>> + is attached to the controller
>> + - allwinner,tp-sensitive-adjust : integer (4 bits)
>> + adjust sensitivity of pen down detection
>> + between 0 (least sensitive) and 15
>> + (defaults to 15)
>> + - allwinner,filter-type : integer (2 bits)
>> + select median and averaging filter
>> + samples used for median / averaging filter
>> + 0: 4/2
>> + 1: 5/3
>> + 2: 8/4
>> + 3: 16/8
>> + (defaults to 1)
>> +
>> +Example:
>> +
>> + rtp: rtp@01c25000 {
>> + compatible = "allwinner,sun4i-a10-ts";
>> + reg = <0x01c25000 0x100>;
>> + interrupts = <29>;
>> + allwinner,ts-attached;
>> + #thermal-sensor-cells = <0>;
>> + /* sensitive/noisy touch panel */
>> + allwinner,tp-sensitive-adjust = <0>;
>> + allwinner,filter-type = <3>;
>> + };
>> --
>> 2.9.3
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: srcu: BUG in __synchronize_srcu
- On Mar 10, 2017, at 5:26 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Fri, Mar 10, 2017 at 08:29:55PM +0100, Andrey Konovalov wrote: >> On Fri, Mar 10, 2017 at 8:28 PM, Andrey Konovalov >> wrote: >> > Hi, >> > >> > I've got the following error report while fuzzing the kernel with >> > syzkaller on an arm64 board. >> >> This also happened on x86 a few times during fuzzing, however it >> wasn't reproducible. >> >> > >> > On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8). >> > >> > A reproducer and .config are attached. >> > >> > The bug happens while executing the following syzkaller program in a loop. >> > While it looks kvm-related, it might be that kvm just stresses the >> > srcu subsystem. >> > >> > mmap(&(0x7f00/0xfff000)=nil, (0xfff000), 0x3, 0x32, >> > 0x, 0x0) >> > r0 = openat$kvm(0xff9c, >> > &(0x7fa05000)="2f6465762f6b766d00", 0x0, 0x0) >> > ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) >> > >> > [ cut here ] >> > kernel BUG at kernel/rcu/srcu.c:436! > > This is on v4.10, correct? No, as stated above, this is on linux-next as of March 8, 2017. I'm currently looking at the diff of kernel/rcu/srcu.c between v4.10 and next-20170310. There are a few changes there. One of them is the introduction of the new srcu algorithm with separate lock vs unlock counters, which simplifies read lock/unlock by removing the sequence counter. Another change that directly impacts __synchronize_rcu() (near the BUG()) is bc138e7a "srcu: Allow mid-boot use of synchronize_srcu()". Odds are that this change introduce an unforeseen scenario that skips awaiting for completion later after boot than expected. It might be worthwhile to review it closely once more. Thoughts ? Thanks, Mathieu > >> > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP >> > Modules linked in: meson_drm drm_kms_helper drm dwmac_generic realtek >> > dwmac_meson8b stmmac_platform stmmac meson_rng rng_core meson_gxbb_wdt >> > ipv6 >> > CPU: 3 PID: 4250 Comm: a.out Not tainted >> > 4.11.0-rc1-next-20170308-xc2-dirty #3 >> > Hardware name: Hardkernel ODROID-C2 (DT) >> > task: 800063699700 task.stack: 800063cfc000 >> > PC is at[] __synchronize_srcu+0x3d0/0x470 >> > kernel/rcu/srcu.c:412 >> > LR is at[ ] __synchronize_srcu+0x130/0x470 >> > kernel/rcu/srcu.c:434 >> > pc : [] lr : [] pstate: 8145 >> > sp : 800063cffb00 >> > x29: 800063cffb00 x28: 80005b1d6e00 >> > x27: 1fffe4000156b242 x26: 800063cffb70 >> > x25: 1fffe4000156b23b x24: 2ab591d8 >> > x23: 29dbf000 x22: 2ab591a0 >> > x21: 2ab59210 x20: 800063cffb70 >> > x19: 2ab59190 x18: 0a03 >> > x17: 944f3950 x16: 2811f818 >> > x15: x14: 0007 >> > x13: 0002 x12: >> > x11: 0040 x10: 1fffe400014b568c >> > x9 : 2ab29000 x8 : 0007 >> > x7 : 0001 x6 : >> > x5 : 0040 x4 : 0003 >> > x3 : 2ab59208 x2 : 1fffe4000156b243 >> > x1 : x0 : 80005e71fb70 >> > >> > Process a.out (pid: 4250, stack limit = 0x800063cfc000) >> > Stack: (0x800063cffb00 to 0x800063d0) >> > fb00: 800063cffbd0 2821a480 2ab59190 1b63adc0 >> > fb20: dfff2000 2ab59190 80004b9a8a00 197351bc >> > fb40: 80004b9a8de0 800060cad328 80005b1d6e00 >> > fb60: 80004b9a8a00 197351bc 80004f5e7b70 28217968 >> > fb80: 8001 dead4ead00010001 dfff2000 >> > fba0: 2ab4c4b0 29b0b358 >> > fbc0: 800063cffbc0 800063cffbc0 800063cffbf0 283ffd20 >> > fbe0: 80005b1d6e00 0140 800063cffc50 283aedfc >> > fc00: 80004b9a8a00 80004b9a8a00 80004b9a8d78 0001 >> > fc20: 02a6 80004f406780 80004b9a8aa0 800063699ac8 >> > fc40: 1c6d3359 800063699700 800063cffd20 2810caec >> > fc60: 80004b9a8a00 80004b9a8b20 80004b9a8d78 0001 >> > fc80: 80005ebae2d8 800063699ac8 800063cffca0 2840fc08 >> > fca0: 800063cffce0 2843327c 80005ebae2d8 80004b9a8a00 >> > fcc0: 80005ebae0f0 29de8000 800063cffce0 284332c4 >> > fce0: 800063cffd20 2810cc64 80004b9a8a00 80004b9a8a48 >> > fd00: 80004b9a8d78 0001 800063cffd20 2810cae0 >> > fd20: 800063cffd60 2811db88 800063699700 800063699700 >> > fd40: 80004b9a8a00 0001 02a6 80004f406780 >> > fd60: 800063cffe40 2811f694 80004f406780 >> > fd80: 80004f40681c 0004 19e80d03 19e80d02 >> > f
[PATCH v1 05/10] staging: iio: adis16240: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16240.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16240.c
b/drivers/staging/iio/accel/adis16240.c
index 27d7f6a..37a29dc 100644
--- a/drivers/staging/iio/accel/adis16240.c
+++ b/drivers/staging/iio/accel/adis16240.c
@@ -373,8 +373,8 @@ static const struct attribute_group
adis16240_attribute_group = {
static const struct iio_info adis16240_info = {
.attrs = &adis16240_attribute_group,
- .read_raw = &adis16240_read_raw,
- .write_raw = &adis16240_write_raw,
+ .read_raw = adis16240_read_raw,
+ .write_raw = adis16240_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 06/10] staging: iio: adis16201: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16201.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16201.c
b/drivers/staging/iio/accel/adis16201.c
index d6c8658..7565268 100644
--- a/drivers/staging/iio/accel/adis16201.c
+++ b/drivers/staging/iio/accel/adis16201.c
@@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16201_channels[] = {
};
static const struct iio_info adis16201_info = {
- .read_raw = &adis16201_read_raw,
- .write_raw = &adis16201_write_raw,
+ .read_raw = adis16201_read_raw,
+ .write_raw = adis16201_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 08/10] staging: iio: adis16203: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16203.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16203.c
b/drivers/staging/iio/accel/adis16203.c
index 68189ad..b59755a 100644
--- a/drivers/staging/iio/accel/adis16203.c
+++ b/drivers/staging/iio/accel/adis16203.c
@@ -233,8 +233,8 @@ static const struct iio_chan_spec adis16203_channels[] = {
};
static const struct iio_info adis16203_info = {
- .read_raw = &adis16203_read_raw,
- .write_raw = &adis16203_write_raw,
+ .read_raw = adis16203_read_raw,
+ .write_raw = adis16203_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 10/10] staging: iio: gyro: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/gyro/adis16060_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/gyro/adis16060_core.c
b/drivers/staging/iio/gyro/adis16060_core.c
index ab816a2..c9d46e7 100644
--- a/drivers/staging/iio/gyro/adis16060_core.c
+++ b/drivers/staging/iio/gyro/adis16060_core.c
@@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
}
static const struct iio_info adis16060_info = {
- .read_raw = &adis16060_read_raw,
+ .read_raw = adis16060_read_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 03/10] staging: iio: cdc: ad7746: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/cdc/ad7746.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 81f8b9e..6294de7 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -664,8 +664,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
static const struct iio_info ad7746_info = {
.attrs = &ad7746_attribute_group,
- .read_raw = &ad7746_read_raw,
- .write_raw = &ad7746_write_raw,
+ .read_raw = ad7746_read_raw,
+ .write_raw = ad7746_write_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 04/10] staging: iio: cdc: ad7152: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/cdc/ad7152.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7152.c b/drivers/staging/iio/cdc/ad7152.c
index e8609b8..59ef93c 100644
--- a/drivers/staging/iio/cdc/ad7152.c
+++ b/drivers/staging/iio/cdc/ad7152.c
@@ -441,9 +441,9 @@ static int ad7152_write_raw_get_fmt(struct iio_dev
*indio_dev,
static const struct iio_info ad7152_info = {
.attrs = &ad7152_attribute_group,
- .read_raw = &ad7152_read_raw,
- .write_raw = &ad7152_write_raw,
- .write_raw_get_fmt = &ad7152_write_raw_get_fmt,
+ .read_raw = ad7152_read_raw,
+ .write_raw = ad7152_write_raw,
+ .write_raw_get_fmt = ad7152_write_raw_get_fmt,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 00/10] staging: iio: Remove exceptional & on functions name
This patch-series removes exceptional & on functions name. v1: -Change the commit message of all the patches of the patch-series simran singhal (10): staging: iio: ad7192: Remove exceptional & on function name staging: iio: ad7780: Remove exceptional & on function name staging: iio: cdc: ad7746: Remove exceptional & on function name staging: iio: cdc: ad7152: Remove exceptional & on function name staging: iio: adis16240: Remove exceptional & on function name staging: iio: adis16201: Remove exceptional & on function name staging: iio: adis16209: Remove exceptional & on function name staging: iio: adis16203: Remove exceptional & on function name staging: iio: resolver: Remove exceptional & on function name staging: iio: gyro: Remove exceptional & on function name drivers/staging/iio/accel/adis16201.c | 4 ++-- drivers/staging/iio/accel/adis16203.c | 4 ++-- drivers/staging/iio/accel/adis16209.c | 4 ++-- drivers/staging/iio/accel/adis16240.c | 4 ++-- drivers/staging/iio/adc/ad7192.c | 12 ++-- drivers/staging/iio/adc/ad7780.c | 2 +- drivers/staging/iio/cdc/ad7152.c | 6 +++--- drivers/staging/iio/cdc/ad7746.c | 4 ++-- drivers/staging/iio/gyro/adis16060_core.c | 2 +- drivers/staging/iio/resolver/ad2s1200.c | 2 +- drivers/staging/iio/resolver/ad2s90.c | 2 +- 11 files changed, 23 insertions(+), 23 deletions(-) -- 2.7.4
[PATCH v1 02/10] staging: iio: ad7780: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/adc/ad7780.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index e149600..dec3ba6 100644
--- a/drivers/staging/iio/adc/ad7780.c
+++ b/drivers/staging/iio/adc/ad7780.c
@@ -154,7 +154,7 @@ static const struct ad7780_chip_info ad7780_chip_info_tbl[]
= {
};
static const struct iio_info ad7780_info = {
- .read_raw = &ad7780_read_raw,
+ .read_raw = ad7780_read_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 01/10] staging: iio: ad7192: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/adc/ad7192.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index 4fc8588..d11c6de 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -564,18 +564,18 @@ static int ad7192_write_raw_get_fmt(struct iio_dev
*indio_dev,
}
static const struct iio_info ad7192_info = {
- .read_raw = &ad7192_read_raw,
- .write_raw = &ad7192_write_raw,
- .write_raw_get_fmt = &ad7192_write_raw_get_fmt,
+ .read_raw = ad7192_read_raw,
+ .write_raw = ad7192_write_raw,
+ .write_raw_get_fmt = ad7192_write_raw_get_fmt,
.attrs = &ad7192_attribute_group,
.validate_trigger = ad_sd_validate_trigger,
.driver_module = THIS_MODULE,
};
static const struct iio_info ad7195_info = {
- .read_raw = &ad7192_read_raw,
- .write_raw = &ad7192_write_raw,
- .write_raw_get_fmt = &ad7192_write_raw_get_fmt,
+ .read_raw = ad7192_read_raw,
+ .write_raw = ad7192_write_raw,
+ .write_raw_get_fmt = ad7192_write_raw_get_fmt,
.attrs = &ad7195_attribute_group,
.validate_trigger = ad_sd_validate_trigger,
.driver_module = THIS_MODULE,
--
2.7.4
[PATCH v1 09/10] staging: iio: resolver: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/resolver/ad2s1200.c | 2 +-
drivers/staging/iio/resolver/ad2s90.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/resolver/ad2s1200.c
b/drivers/staging/iio/resolver/ad2s1200.c
index 82b2d88..a37e199 100644
--- a/drivers/staging/iio/resolver/ad2s1200.c
+++ b/drivers/staging/iio/resolver/ad2s1200.c
@@ -97,7 +97,7 @@ static const struct iio_chan_spec ad2s1200_channels[] = {
};
static const struct iio_info ad2s1200_info = {
- .read_raw = &ad2s1200_read_raw,
+ .read_raw = ad2s1200_read_raw,
.driver_module = THIS_MODULE,
};
diff --git a/drivers/staging/iio/resolver/ad2s90.c
b/drivers/staging/iio/resolver/ad2s90.c
index 5b1c0db..b227090 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -47,7 +47,7 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
}
static const struct iio_info ad2s90_info = {
- .read_raw = &ad2s90_read_raw,
+ .read_raw = ad2s90_read_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH v1 07/10] staging: iio: adis16209: Remove exceptional & on function name
Remove & from function pointers to conform to the style found elsewhere
in the file. Done using the following semantic patch
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16209.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16209.c
b/drivers/staging/iio/accel/adis16209.c
index 8ff537f..56bc2ac 100644
--- a/drivers/staging/iio/accel/adis16209.c
+++ b/drivers/staging/iio/accel/adis16209.c
@@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16209_channels[] = {
};
static const struct iio_info adis16209_info = {
- .read_raw = &adis16209_read_raw,
- .write_raw = &adis16209_write_raw,
+ .read_raw = adis16209_read_raw,
+ .write_raw = adis16209_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
Re: [PATCH v3 0/3] Bind RMI4 over SMBus from PS/2
Hi, On Wed, 2017-03-08 at 16:24 +0100, Benjamin Tissoires wrote: > Hi Dmitry, > > This is mostly a resend of the PS/2-SMBus binding (last 3 patches of > now 3 years > of trial and errors). > I integrated both warnings raised by Coccinelle, and squashed 4/3 > into 3/3. Just want to provide you some quick feedback from the user's perspective... I tested this patch set on my somewhat hacked together laptop - I have a Lenovo T440p with the touchpad replaced with a "top button pad" from a T450 or similar. With this patch set (and using the psmouse.synaptics_intertouch=1 option), the touchpad is found and used via RMI4/SMBUS, and the PS2 passthrough to the trackpoint does work. Passing the buttons presses from the top buttons to the trackpoint device doesn't work - my understanding is the code for this isn't included here? The touchpad cursor movement (and scrolling, etc.) is so much smoother than with the PS2 interface of this touchpad model... I'm glad these patches are getting closer to complete! Calvin. [ 17.665070] psmouse serio1: synaptics: queried max coordinates: x [..5676], y [..4758] [ 17.698107] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1096..] [ 17.760612] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x1, board id: 3053, fw id: 2560 [ 17.763619] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 [ 17.766577] psmouse serio1: synaptics: device also supported by an other bus. [ 17.807548] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input9 [ 18.435205] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 18.630809] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input18 [ 19.064659] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM3053-003, fw id: 1741108 [ 19.131839] input: Synaptics TM3053-003 as /devices/rmi4-00/input/input19 [ 19.152671] rmi4_smbus 9-002c: registered rmi smb driver at 0x2c. [ 20.425233] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 20.482937] input: TPPS/2 IBM TrackPoint as /devices/rmi4-00/rmi4-00.fn03/serio3/input/input21 -- Calvin Walton
memfill v2 now with ARM and x86 implementations
On Mon, Feb 06, 2017 at 12:16:44AM +0900, Minchan Kim wrote:
> +static inline void zram_fill_page(char *ptr, unsigned long len,
> + unsigned long value)
> +{
> + int i;
> + unsigned long *page = (unsigned long *)ptr;
> +
> + WARN_ON_ONCE(!IS_ALIGNED(len, sizeof(unsigned long)));
> +
> + if (likely(value == 0)) {
> + memset(ptr, 0, len);
> + } else {
> + for (i = 0; i < len / sizeof(*page); i++)
> + page[i] = value;
> + }
> +}
I've hacked up memset32/memset64 for both ARM and x86 here:
http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/memfill
Can you do some performance testing and see if it makes a difference?
At this point, I'd probably ask for the first 5 patches in that git
branch to be included, and leave out memfill and the shoddy testsuite.
I haven't actually tested either asm implementation ... only the
C fallback.
Re: [PATCH 6/8] Input: psmouse - add support for SMBus companions
Hi Benjamin, [auto build test ERROR on input/next] [also build test ERROR on v4.11-rc1 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/PS/20170311-222141 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: x86_64-randconfig-x004-201710 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 Note: the linux-review/Dmitry-Torokhov/PS/20170311-222141 HEAD b84adc980e4fc51bf4be2aac8853afcc68ceb13b builds fine. It only hurts bisectibility. All error/warnings (new ones prefixed by >>): In file included from drivers/input/mouse/psmouse-base.c:27:0: >> drivers/input/mouse/psmouse.h:234:56: warning: 'struct i2c_board_info' >> declared inside parameter list will not be visible outside of this >> definition or declaration int psmouse_smbus_init(struct psmouse *psmouse, struct i2c_board_info *board, ^~ -- drivers/input/mouse/synaptics.o: In function `psmouse_smbus_init': >> synaptics.c:(.text+0x0): multiple definition of `psmouse_smbus_init' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11c4): first defined here drivers/input/mouse/synaptics.o: In function `psmouse_smbus_cleanup': >> synaptics.c:(.text+0x10): multiple definition of `psmouse_smbus_cleanup' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11d4): first defined here drivers/input/mouse/focaltech.o: In function `psmouse_smbus_init': focaltech.c:(.text+0x0): multiple definition of `psmouse_smbus_init' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11c4): first defined here drivers/input/mouse/focaltech.o: In function `psmouse_smbus_cleanup': focaltech.c:(.text+0x10): multiple definition of `psmouse_smbus_cleanup' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11d4): first defined here drivers/input/mouse/byd.o: In function `psmouse_smbus_init': byd.c:(.text+0x3e8): multiple definition of `psmouse_smbus_init' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11c4): first defined here drivers/input/mouse/byd.o: In function `psmouse_smbus_cleanup': byd.c:(.text+0x3f8): multiple definition of `psmouse_smbus_cleanup' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11d4): first defined here drivers/input/mouse/elantech.o: In function `psmouse_smbus_init': elantech.c:(.text+0x1cc6): multiple definition of `psmouse_smbus_init' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11c4): first defined here drivers/input/mouse/elantech.o: In function `psmouse_smbus_cleanup': elantech.c:(.text+0x1cd6): multiple definition of `psmouse_smbus_cleanup' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11d4): first defined here drivers/input/mouse/sentelic.o: In function `psmouse_smbus_init': sentelic.c:(.text+0x14f1): multiple definition of `psmouse_smbus_init' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11c4): first defined here drivers/input/mouse/sentelic.o: In function `psmouse_smbus_cleanup': sentelic.c:(.text+0x1501): multiple definition of `psmouse_smbus_cleanup' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11d4): first defined here drivers/input/mouse/trackpoint.o: In function `psmouse_smbus_init': trackpoint.c:(.text+0xb2b): multiple definition of `psmouse_smbus_init' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11c4): first defined here drivers/input/mouse/trackpoint.o: In function `psmouse_smbus_cleanup': trackpoint.c:(.text+0xb3b): multiple definition of `psmouse_smbus_cleanup' drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x11d4): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 3.16 000/372] 3.16.42-rc2 review
I've added two more patches to the queue for this release, which will be sent as replies to this message. Responses should be made by Wed Mar 15 00:00:00 UTC 2017. Anything received after that time might be too late. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do.
[PATCH 3.16 372/372] tty: n_hdlc: get rid of racy n_hdlc.tbuf
3.16.42-rc2 review patch. If anyone has any objections, please let me know.
--
From: Alexander Popov
commit 82f2341c94d270421f383641b7cd670e474db56b upstream.
Currently N_HDLC line discipline uses a self-made singly linked list for
data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
an error.
The commit be10eb7589337e5defbe214dae038a53dd21add8
("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
one data buffer to tx_free_buf_list twice. That causes double free in
n_hdlc_release().
Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
in case of tx error put current data buffer after the head of tx_buf_list.
Signed-off-by: Alexander Popov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/n_hdlc.c | 132 +++
1 file changed, 69 insertions(+), 63 deletions(-)
diff --git a/drivers/tty/n_hdlc.c b/drivers/tty/n_hdlc.c
index 1bacbc3b19a0..e94aea8c0d05 100644
--- a/drivers/tty/n_hdlc.c
+++ b/drivers/tty/n_hdlc.c
@@ -114,7 +114,7 @@
#define DEFAULT_TX_BUF_COUNT 3
struct n_hdlc_buf {
- struct n_hdlc_buf *link;
+ struct list_head list_item;
int count;
char buf[1];
};
@@ -122,8 +122,7 @@ struct n_hdlc_buf {
#defineN_HDLC_BUF_SIZE (sizeof(struct n_hdlc_buf) + maxframe)
struct n_hdlc_buf_list {
- struct n_hdlc_buf *head;
- struct n_hdlc_buf *tail;
+ struct list_head list;
int count;
spinlock_tspinlock;
};
@@ -136,7 +135,6 @@ struct n_hdlc_buf_list {
* @backup_tty - TTY to use if tty gets closed
* @tbusy - reentrancy flag for tx wakeup code
* @woke_up - FIXME: describe this field
- * @tbuf - currently transmitting tx buffer
* @tx_buf_list - list of pending transmit frame buffers
* @rx_buf_list - list of received frame buffers
* @tx_free_buf_list - list unused transmit frame buffers
@@ -149,7 +147,6 @@ struct n_hdlc {
struct tty_struct *backup_tty;
int tbusy;
int woke_up;
- struct n_hdlc_buf *tbuf;
struct n_hdlc_buf_list tx_buf_list;
struct n_hdlc_buf_list rx_buf_list;
struct n_hdlc_buf_list tx_free_buf_list;
@@ -159,6 +156,8 @@ struct n_hdlc {
/*
* HDLC buffer list manipulation functions
*/
+static void n_hdlc_buf_return(struct n_hdlc_buf_list *buf_list,
+ struct n_hdlc_buf *buf);
static void n_hdlc_buf_put(struct n_hdlc_buf_list *list,
struct n_hdlc_buf *buf);
static struct n_hdlc_buf *n_hdlc_buf_get(struct n_hdlc_buf_list *list);
@@ -208,16 +207,9 @@ static void flush_tx_queue(struct tty_struct *tty)
{
struct n_hdlc *n_hdlc = tty2n_hdlc(tty);
struct n_hdlc_buf *buf;
- unsigned long flags;
while ((buf = n_hdlc_buf_get(&n_hdlc->tx_buf_list)))
n_hdlc_buf_put(&n_hdlc->tx_free_buf_list, buf);
- spin_lock_irqsave(&n_hdlc->tx_buf_list.spinlock, flags);
- if (n_hdlc->tbuf) {
- n_hdlc_buf_put(&n_hdlc->tx_free_buf_list, n_hdlc->tbuf);
- n_hdlc->tbuf = NULL;
- }
- spin_unlock_irqrestore(&n_hdlc->tx_buf_list.spinlock, flags);
}
static struct tty_ldisc_ops n_hdlc_ldisc = {
@@ -283,7 +275,6 @@ static void n_hdlc_release(struct n_hdlc *n_hdlc)
} else
break;
}
- kfree(n_hdlc->tbuf);
kfree(n_hdlc);
} /* end of n_hdlc_release() */
@@ -402,13 +393,7 @@ static void n_hdlc_send_frames(struct n_hdlc *n_hdlc,
struct tty_struct *tty)
n_hdlc->woke_up = 0;
spin_unlock_irqrestore(&n_hdlc->tx_buf_list.spinlock, flags);
- /* get current transmit buffer or get new transmit */
- /* buffer from list of pending transmit buffers */
-
- tbuf = n_hdlc->tbuf;
- if (!tbuf)
- tbuf = n_hdlc_buf_get(&n_hdlc->tx_buf_list);
-
+ tbuf = n_hdlc_buf_get(&n_hdlc->tx_buf_list);
while (tbuf) {
if (debuglevel >= DEBUG_LEVEL_INFO)
printk("%s(%d)sending frame %p, count=%d\n",
@@ -420,7 +405,7 @@ static void n_hdlc_send_frames(struct n_hdlc *n_hdlc,
struct tty_struct *tty)
/* rollback was possible and has been done */
if (actual == -ERESTARTSYS) {
- n_hdlc->tbuf = tbuf;
+ n_hdlc_buf_return(&n_hdlc->tx_buf_list, tbuf);
break;
}
/* if transmit error, throw frame away by */
@@ -435,10 +420,7 @@ static void n_hdlc_send_frames(struct n_hdlc *n_hdlc,
struct tty_struct *tty)
/* free current transmit b
[PATCH 3.16 371/372] TTY: n_hdlc, fix lockdep false positive
3.16.42-rc2 review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby
commit e9b736d88af1a143530565929390cadf036dc799 upstream.
The class of 4 n_hdls buf locks is the same because a single function
n_hdlc_buf_list_init is used to init all the locks. But since
flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls
n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep
emits a warning:
=
[ INFO: possible recursive locking detected ]
4.3.0-25.g91e30a7-default #1 Not tainted
-
a.out/1248 is trying to acquire lock:
(&(&list->spinlock)->rlock){..}, at: []
n_hdlc_buf_put+0x20/0x60 [n_hdlc]
but task is already holding lock:
(&(&list->spinlock)->rlock){..}, at: []
n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&list->spinlock)->rlock);
lock(&(&list->spinlock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by a.out/1248:
#0: (&tty->ldisc_sem){++}, at: []
tty_ldisc_ref_wait+0x20/0x50
#1: (&(&list->spinlock)->rlock){..}, at: []
n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
...
Call Trace:
...
[] _raw_spin_lock_irqsave+0x50/0x70
[] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
[] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc]
[] tty_ioctl+0x3f1/0xe40
...
Fix it by initializing the spin_locks separately. This removes also
reduntand memset of a freshly kzallocated space.
Signed-off-by: Jiri Slaby
Reported-by: Dmitry Vyukov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/n_hdlc.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/n_hdlc.c b/drivers/tty/n_hdlc.c
index bbc4ce66c2c1..bcaba17688f6 100644
--- a/drivers/tty/n_hdlc.c
+++ b/drivers/tty/n_hdlc.c
@@ -159,7 +159,6 @@ struct n_hdlc {
/*
* HDLC buffer list manipulation functions
*/
-static void n_hdlc_buf_list_init(struct n_hdlc_buf_list *list);
static void n_hdlc_buf_put(struct n_hdlc_buf_list *list,
struct n_hdlc_buf *buf);
static struct n_hdlc_buf *n_hdlc_buf_get(struct n_hdlc_buf_list *list);
@@ -853,10 +852,10 @@ static struct n_hdlc *n_hdlc_alloc(void)
if (!n_hdlc)
return NULL;
- n_hdlc_buf_list_init(&n_hdlc->rx_free_buf_list);
- n_hdlc_buf_list_init(&n_hdlc->tx_free_buf_list);
- n_hdlc_buf_list_init(&n_hdlc->rx_buf_list);
- n_hdlc_buf_list_init(&n_hdlc->tx_buf_list);
+ spin_lock_init(&n_hdlc->rx_free_buf_list.spinlock);
+ spin_lock_init(&n_hdlc->tx_free_buf_list.spinlock);
+ spin_lock_init(&n_hdlc->rx_buf_list.spinlock);
+ spin_lock_init(&n_hdlc->tx_buf_list.spinlock);
/* allocate free rx buffer list */
for(i=0;ispinlock);
-} /* end of n_hdlc_buf_list_init() */
-
-/**
* n_hdlc_buf_put - add specified HDLC buffer to tail of specified list
* @list - pointer to buffer list
* @buf- pointer to buffer
[PATCH 3.2 201/202] list: introduce list_first_entry_or_null
3.2.87-rc2 review patch. If anyone has any objections, please let me know. -- From: Jiri Pirko commit 6d7581e62f8be462440d7b22c6361f7c9fa4902b upstream. non-rcu variant of list_first_or_null_rcu Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- include/linux/list.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/linux/list.h b/include/linux/list.h index 6a1f8df9144b..b83e5657365a 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -362,6 +362,17 @@ static inline void list_splice_tail_init(struct list_head *list, list_entry((ptr)->next, type, member) /** + * list_first_entry_or_null - get the first element from a list + * @ptr: the list head to take the element from. + * @type: the type of the struct this is embedded in. + * @member:the name of the list_struct within the struct. + * + * Note that if the list is empty, it returns NULL. + */ +#define list_first_entry_or_null(ptr, type, member) \ + (!list_empty(ptr) ? list_first_entry(ptr, type, member) : NULL) + +/** * list_for_each - iterate over a list * @pos: the &struct list_head to use as a loop cursor. * @head: the head for your list.
[PATCH 3.2 202/202] tty: n_hdlc: get rid of racy n_hdlc.tbuf
3.2.87-rc2 review patch. If anyone has any objections, please let me know.
--
From: Alexander Popov
commit 82f2341c94d270421f383641b7cd670e474db56b upstream.
Currently N_HDLC line discipline uses a self-made singly linked list for
data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
an error.
The commit be10eb7589337e5defbe214dae038a53dd21add8
("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
one data buffer to tx_free_buf_list twice. That causes double free in
n_hdlc_release().
Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
in case of tx error put current data buffer after the head of tx_buf_list.
Signed-off-by: Alexander Popov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/n_hdlc.c | 132 +++
1 file changed, 69 insertions(+), 63 deletions(-)
--- a/drivers/tty/n_hdlc.c
+++ b/drivers/tty/n_hdlc.c
@@ -115,7 +115,7 @@
#define DEFAULT_TX_BUF_COUNT 3
struct n_hdlc_buf {
- struct n_hdlc_buf *link;
+ struct list_head list_item;
int count;
char buf[1];
};
@@ -123,8 +123,7 @@ struct n_hdlc_buf {
#defineN_HDLC_BUF_SIZE (sizeof(struct n_hdlc_buf) + maxframe)
struct n_hdlc_buf_list {
- struct n_hdlc_buf *head;
- struct n_hdlc_buf *tail;
+ struct list_head list;
int count;
spinlock_tspinlock;
};
@@ -137,7 +136,6 @@ struct n_hdlc_buf_list {
* @backup_tty - TTY to use if tty gets closed
* @tbusy - reentrancy flag for tx wakeup code
* @woke_up - FIXME: describe this field
- * @tbuf - currently transmitting tx buffer
* @tx_buf_list - list of pending transmit frame buffers
* @rx_buf_list - list of received frame buffers
* @tx_free_buf_list - list unused transmit frame buffers
@@ -150,7 +148,6 @@ struct n_hdlc {
struct tty_struct *backup_tty;
int tbusy;
int woke_up;
- struct n_hdlc_buf *tbuf;
struct n_hdlc_buf_list tx_buf_list;
struct n_hdlc_buf_list rx_buf_list;
struct n_hdlc_buf_list tx_free_buf_list;
@@ -160,6 +157,8 @@ struct n_hdlc {
/*
* HDLC buffer list manipulation functions
*/
+static void n_hdlc_buf_return(struct n_hdlc_buf_list *buf_list,
+ struct n_hdlc_buf *buf);
static void n_hdlc_buf_put(struct n_hdlc_buf_list *list,
struct n_hdlc_buf *buf);
static struct n_hdlc_buf *n_hdlc_buf_get(struct n_hdlc_buf_list *list);
@@ -209,16 +208,9 @@ static void flush_tx_queue(struct tty_st
{
struct n_hdlc *n_hdlc = tty2n_hdlc(tty);
struct n_hdlc_buf *buf;
- unsigned long flags;
while ((buf = n_hdlc_buf_get(&n_hdlc->tx_buf_list)))
n_hdlc_buf_put(&n_hdlc->tx_free_buf_list, buf);
- spin_lock_irqsave(&n_hdlc->tx_buf_list.spinlock, flags);
- if (n_hdlc->tbuf) {
- n_hdlc_buf_put(&n_hdlc->tx_free_buf_list, n_hdlc->tbuf);
- n_hdlc->tbuf = NULL;
- }
- spin_unlock_irqrestore(&n_hdlc->tx_buf_list.spinlock, flags);
}
static struct tty_ldisc_ops n_hdlc_ldisc = {
@@ -284,7 +276,6 @@ static void n_hdlc_release(struct n_hdlc
} else
break;
}
- kfree(n_hdlc->tbuf);
kfree(n_hdlc);
} /* end of n_hdlc_release() */
@@ -403,13 +394,7 @@ static void n_hdlc_send_frames(struct n_
n_hdlc->woke_up = 0;
spin_unlock_irqrestore(&n_hdlc->tx_buf_list.spinlock, flags);
- /* get current transmit buffer or get new transmit */
- /* buffer from list of pending transmit buffers */
-
- tbuf = n_hdlc->tbuf;
- if (!tbuf)
- tbuf = n_hdlc_buf_get(&n_hdlc->tx_buf_list);
-
+ tbuf = n_hdlc_buf_get(&n_hdlc->tx_buf_list);
while (tbuf) {
if (debuglevel >= DEBUG_LEVEL_INFO)
printk("%s(%d)sending frame %p, count=%d\n",
@@ -421,7 +406,7 @@ static void n_hdlc_send_frames(struct n_
/* rollback was possible and has been done */
if (actual == -ERESTARTSYS) {
- n_hdlc->tbuf = tbuf;
+ n_hdlc_buf_return(&n_hdlc->tx_buf_list, tbuf);
break;
}
/* if transmit error, throw frame away by */
@@ -436,10 +421,7 @@ static void n_hdlc_send_frames(struct n_
/* free current transmit buffer */
n_hdlc_buf_put(&n_hdlc->tx_free_buf_list, tbuf);
-
- /* this tx buffer is done */
- n_hdlc->tbuf = NULL;
-
+
[PATCH 3.2 000/202] 3.2.87-rc2 review
I've added three more patches to the queue for this release, which will be sent as replies to this message. Responses should be made by Wed Mar 15 00:00:00 UTC 2017. Anything received after that time might be too late. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do.
[PATCH 3.2 200/202] TTY: n_hdlc, fix lockdep false positive
3.2.87-rc2 review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby
commit e9b736d88af1a143530565929390cadf036dc799 upstream.
The class of 4 n_hdls buf locks is the same because a single function
n_hdlc_buf_list_init is used to init all the locks. But since
flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls
n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep
emits a warning:
=
[ INFO: possible recursive locking detected ]
4.3.0-25.g91e30a7-default #1 Not tainted
-
a.out/1248 is trying to acquire lock:
(&(&list->spinlock)->rlock){..}, at: []
n_hdlc_buf_put+0x20/0x60 [n_hdlc]
but task is already holding lock:
(&(&list->spinlock)->rlock){..}, at: []
n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&list->spinlock)->rlock);
lock(&(&list->spinlock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by a.out/1248:
#0: (&tty->ldisc_sem){++}, at: []
tty_ldisc_ref_wait+0x20/0x50
#1: (&(&list->spinlock)->rlock){..}, at: []
n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
...
Call Trace:
...
[] _raw_spin_lock_irqsave+0x50/0x70
[] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
[] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc]
[] tty_ioctl+0x3f1/0xe40
...
Fix it by initializing the spin_locks separately. This removes also
reduntand memset of a freshly kzallocated space.
Signed-off-by: Jiri Slaby
Reported-by: Dmitry Vyukov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/n_hdlc.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
--- a/drivers/tty/n_hdlc.c
+++ b/drivers/tty/n_hdlc.c
@@ -160,7 +160,6 @@ struct n_hdlc {
/*
* HDLC buffer list manipulation functions
*/
-static void n_hdlc_buf_list_init(struct n_hdlc_buf_list *list);
static void n_hdlc_buf_put(struct n_hdlc_buf_list *list,
struct n_hdlc_buf *buf);
static struct n_hdlc_buf *n_hdlc_buf_get(struct n_hdlc_buf_list *list);
@@ -856,10 +855,10 @@ static struct n_hdlc *n_hdlc_alloc(void)
memset(n_hdlc, 0, sizeof(*n_hdlc));
- n_hdlc_buf_list_init(&n_hdlc->rx_free_buf_list);
- n_hdlc_buf_list_init(&n_hdlc->tx_free_buf_list);
- n_hdlc_buf_list_init(&n_hdlc->rx_buf_list);
- n_hdlc_buf_list_init(&n_hdlc->tx_buf_list);
+ spin_lock_init(&n_hdlc->rx_free_buf_list.spinlock);
+ spin_lock_init(&n_hdlc->tx_free_buf_list.spinlock);
+ spin_lock_init(&n_hdlc->rx_buf_list.spinlock);
+ spin_lock_init(&n_hdlc->tx_buf_list.spinlock);
/* allocate free rx buffer list */
for(i=0;ispinlock);
-} /* end of n_hdlc_buf_list_init() */
-
-/**
* n_hdlc_buf_put - add specified HDLC buffer to tail of specified list
* @list - pointer to buffer list
* @buf- pointer to buffer
Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
Hi Mauro and Hans, On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote: > Em Sat, 11 Mar 2017 12:32:43 +0100 > Hans Verkuil escreveu: > > > On 10/03/17 16:09, Mauro Carvalho Chehab wrote: > > > Em Fri, 10 Mar 2017 13:54:28 +0100 > > > Hans Verkuil escreveu: > > > > > >>> Devices that have complex pipeline that do essentially require using the > > >>> Media controller interface to configure them are out of that scope. > > >>> > > >> > > >> Way too much of how the MC devices should be used is in the minds of > > >> developers. > > >> There is a major lack for good detailed documentation, utilities, > > >> compliance > > >> test (really needed!) and libv4l plugins. > > > > > > Unfortunately, we merged an incomplete MC support at the Kernel. We knew > > > all the problems with MC-based drivers and V4L2 applications by the time > > > it was developed, and we requested Nokia developers (with was sponsoring > > > MC > > > develoment, on that time) to work on a solution to allow standard V4L2 > > > applications to work with MC based boards. > > > > > > Unfortunately, we took the decision to merge MC without that, because > > > Nokia was giving up on Linux development, and we didn't want to lose the > > > 2 years of discussions and work around it, as Nokia employers were leaving > > > the company. Also, on that time, there was already some patches floating > > > around adding backward support via libv4l. Unfortunately, those patches > > > were never finished. > > > > > > The net result is that MC was merged with some huge gaps, including > > > the lack of a proper solution for a generic V4L2 program to work > > > with V4L2 devices that use the subdev API. > > > > > > That was not that bad by then, as MC was used only on cell phones > > > that run custom-made applications. > > > > > > The reallity changed, as now, we have lots of low cost SoC based > > > boards, used for all sort of purposes. So, we need a quick solution > > > for it. > > > > > > In other words, while that would be acceptable support special apps > > > on really embedded systems, it is *not OK* for general purpose SoC > > > harware[1]. > > > > > > [1] I'm calling "general purpose SoC harware" those ARM boards > > > like Raspberry Pi that are shipped to the mass and used by a wide > > > range of hobbyists and other people that just wants to run Linux on > > > ARM. It is possible to buy such boards for a very cheap price, > > > making them to be used not only on special projects, where a custom > > > made application could be interesting, but also for a lot of > > > users that just want to run Linux on a low cost ARM board, while > > > keeping using standard V4L2 apps, like "camorama". > > > > > > That's perhaps one of the reasons why it took a long time for us to > > > start receiving drivers upstream for such hardware: it is quite > > > intimidating and not logical to require developers to implement > > > on their drivers 2 complex APIs (MC, subdev) for those > > > hardware that most users won't care. From user's perspective, > > > being able to support generic applications like "camorama" and > > > "zbar" is all they want. > > > > > > In summary, I'm pretty sure we need to support standard V4L2 > > > applications on boards like Raspberry Pi and those low-cost > > > SoC-based boards that are shipped to end users. > > > > > >> Anyway, regarding this specific patch and for this MC-aware driver: no, > > >> you > > >> shouldn't inherit controls from subdevs. It defeats the purpose. > > > > > > Sorry, but I don't agree with that. The subdev API is an optional API > > > (and even the MC API can be optional). > > > > > > I see the rationale for using MC and subdev APIs on cell phones, > > > ISV and other embedded hardware, as it will allow fine-tuning > > > the driver's support to allow providing the required quality for > > > certain custom-made applications. but on general SoC hardware, > > > supporting standard V4L2 applications is a need. > > > > > > Ok, perhaps supporting both subdev API and V4L2 API at the same > > > time doesn't make much sense. We could disable one in favor of the > > > other, either at compilation time or at runtime. > > > > Right. If the subdev API is disabled, then you have to inherit the subdev > > controls in the bridge driver (how else would you be able to access them?). > > And that's the usual case. > > > > If you do have the subdev API enabled, AND you use the MC, then the > > intention clearly is to give userspace full control and inheriting controls > > no longer makes any sense (and is highly confusing IMHO). > > I tend to agree with that. I agree as well. This is in line with how existing drivers behave, too. > > > > > > > This way, if the subdev API is disabled, the driver will be > > > functional for V4L2-based applications that don't support neither > > > MC or subdev APIs. > > > > I'm not sure if it makes sense for the i.MX driver to behave diff
[PATCH] ARM: dts: uniphier: fix pin groups of eMMC pin-mux node
The eMMC devices on UniPhier boards are generally used in the 8-bit
mode. So, DAT4-7 pins should be controlled.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
index 8ee79da..246f35f 100644
--- a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
@@ -45,7 +45,7 @@
&pinctrl {
pinctrl_emmc: emmc_grp {
- groups = "emmc";
+ groups = "emmc", "emmc_dat8";
function = "emmc";
};
--
2.7.4
[PATCH] arm64: dts: uniphier: add pinctrl property to eMMC node for LD11/LD20
Now everything is ready to enable this pinctrl. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 ++ arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi index 2ed35e3..4b54b56 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi @@ -304,6 +304,8 @@ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc"; reg = <0x5a00 0x400>; interrupts = <0 78 4>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_emmc>; clocks = <&sys_clk 4>; bus-width = <8>; mmc-ddr-1_8v; diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi index 96c053f..6193f11 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi @@ -378,6 +378,8 @@ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc"; reg = <0x5a00 0x400>; interrupts = <0 78 4>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_emmc>; clocks = <&sys_clk 4>; bus-width = <8>; mmc-ddr-1_8v; -- 2.7.4
Re: [PULL REQUEST] i2c for 4.11
Linus, > You added an extra revert, only to pull in the *exact* same patch. WTF? The patch I reverted had a broken, typoed Signed-off. My rationale was to have only a proper one, and not two different ones coming from different trees. Looks like I misjudged, sorry. > Please stop this kind of stupidity. Now I have that unnecessary revert > with a misleading commit log in my tree, in addition to that stupid > merge that has no explanation and just reinstates the exact same thing > you reverted. I see your point. > And talking about that merge I will repeat this one more time: merges > are commits too. You had damn well add explanations for what a merge > merges and why it is done. Understood. Peter joined as co-maintainer kind of recently, and I guess it shows that I didn't have to pass on merges a lot so far. It is not that I ignored your preferences for merges (which make total sense to me), I just missed to check how to properly do it. Will improve! Regards, Wolfram signature.asc Description: PGP signature
Re: UBSAN: Undefined behaviour in kernel/time/tick-sched.c:600:9
> > Cc'ing KASAN folks
> >
> >> (Retry with fixed address ox 86 list)
> >>
> >> This HP Netserver LT6000R, quad P3 Xeon. Trying
> >> 4.11.0-rc1-00088-gec3b93a, I got the following UBSAN warning that was
> >> not there in 4.10:
> >>
> >> [ 14.820437]
> >>
> >> [ 14.820534] UBSAN: Undefined behaviour in kernel/time/tick-sched.c:600:9
> >> [ 14.820594] signed integer overflow:
> >> [ 14.820645] 11567464533 + 3985952 cannot be represented in type 'long
> >> long int'
> >
> > This does not make any sense:
> >
> > 11567464533 + 3985952 = 0x2b1798055 + 0x3cd220 = 0x2b1b65275
> >
> > which definitely fits into a 'long long int' aka 64 bit
>
>
> Is there a reproducer? Or can you print the values right in
> tick-sched.c with pr_err?
No, it's not reproducible at will - subsequent reboots did not cause it,
only the KASAN warning from drivers/acpi/acpica/dsutils.c:640 and
arch/x86/events/intel/p6.c:115:29 are there as usual.
gcc version 6.2.0 20160927 (Debian 6.2.0-5)
>
> The code in ubsan.c looks more complex than I would expect from that
> code. There is probably some potential for truncation:
>
> static s_max get_signed_val(struct type_descriptor *type, unsigned long val)
> {
> if (is_inline_int(type)) {
> unsigned extra_bits = sizeof(s_max)*8 - type_bit_width(type);
> return ((s_max)val) << extra_bits >> extra_bits;
> }
> if (type_bit_width(type) == 64)
> return *(s64 *)val;
> return *(s_max *)val;
> }
>
>
>
> >> [ 14.820722] CPU: 3 PID: 135 Comm: startpar Not tainted
> >> 4.11.0-rc1-00088-gec3b93a #61
> >> [ 14.820793] Hardware name: Hewlett Packard HP NetServer/HP System
> >> Board, BIOS 4.06.46 PW 06/25/2003
> >> [ 14.820863] Call Trace:
> >> [ 14.820950] ? dump_stack+0x45/0x6e
> >> [ 14.821022] ? ubsan_epilogue+0xb/0x40
> >> [ 14.821081] ? handle_overflow+0xb6/0xe0
> >> [ 14.821146] ? smp_trace_apic_timer_interrupt+0x85/0x100
> >> [ 14.821208] ? __ubsan_handle_add_overflow+0xf/0x20
> >> [ 14.821281] ? get_cpu_idle_time_us+0x204/0x2b0
> >> [ 14.821350] ? get_idle_time+0x57/0xb0
> >> [ 14.821405] ? show_stat+0x217/0x10c0
> >> [ 14.821463] ? seq_open+0x33/0xb0
> >> [ 14.821519] ? __d_alloc+0x149/0x2c0
> >> [ 14.821574] ? get_iowait_time+0xb0/0xb0
> >> [ 14.821628] ? single_open+0x4d/0xb0
> >> [ 14.821685] ? single_open_size+0x37/0xc0
> >> [ 14.821748] ? path_openat+0x7d5/0x1bd0
> >> [ 14.821804] ? seq_read+0xca/0x6f0
> >> [ 14.821872] ? _copy_to_user+0x5e/0x90
> >> [ 14.821937] ? cp_new_stat64+0x108/0x130
> >> [ 14.821991] ? __seq_open_private+0x80/0x80
> >> [ 14.822062] ? proc_reg_read+0x7c/0x120
> >> [ 14.822117] ? proc_reg_write+0x120/0x120
> >> [ 14.822172] ? __vfs_read+0x3e/0x240
> >> [ 14.88] ? vfs_read+0x92/0x1b0
> >> [ 14.822282] ? SyS_read+0x45/0xa0
> >> [ 14.822338] ? do_fast_syscall_32+0xb9/0x220
> >> [ 14.822395] ? entry_SYSENTER_32+0x47/0x71
> >> [ 14.822447]
> >>
>
--
Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/
[PATCH] staging: rtl8192u: Remove typedef phy_ofdm_rx_status_rxsc_sgien_exintfflag
Remove typdef phy_ofdm_rx_status_rxsc_sgien_exintfflag and replace its uses
in the code.
Signed-off-by: simran singhal
---
drivers/staging/rtl8192u/r8192U.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index a7ba8f3..cd3e922 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -793,12 +793,12 @@ typedef struct _phy_cck_rx_status_report_819xusb {
} phy_sts_cck_819xusb_t;
-typedef struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
+struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
u8 reserved:4;
u8 rxsc:2;
u8 sgi_en:1;
u8 ex_intf_flag:1;
-} phy_ofdm_rx_status_rxsc_sgien_exintfflag;
+};
typedef enum _RT_CUSTOMER_ID {
RT_CID_DEFAULT = 0,
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 13239f4..0d830f6 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4242,7 +4242,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
*priv,
{
phy_sts_ofdm_819xusb_t *pofdm_buf;
phy_sts_cck_819xusb_t *pcck_buf;
- phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
+ struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
s8 rx_pwr[4], rx_pwr_all = 0;
@@ -4432,7 +4432,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
*priv,
/* record rx statistics for debug */
rxsc_sgien_exflg = pofdm_buf->rxsc_sgien_exflg;
- prxsc = (phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
+ prxsc = (struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
&rxsc_sgien_exflg;
if (pdrvinfo->BW) /* 40M channel */
priv->stats.received_bwtype[1 + prxsc->rxsc]++;
--
2.7.4
[PATCH] drm/radeon: Fix GPU lockups for the R7 M270
Commit 3a69adfe5617 ("drm/radeon: drop oland quirks") removed
quirks for Oland but also caused a regression where M270 GPUs
would go into a lock-up when OpenGL intensive applications were used.
This reverts the change only for the M270 and fixes the lock-ups.
Signed-off-by: Umang Raghuvanshi
---
drivers/gpu/drm/radeon/si_dpm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d12b8978142f..c2c129eef3c4 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2984,6 +2984,11 @@ static void si_apply_state_adjust_rules(struct
radeon_device *rdev,
(rdev->pdev->device == 0x6667)) {
max_sclk = 75000;
}
+ } else if (rdev->family == CHIP_OLAND && rdev->pdev->device == 0x6604 &&
+ rdev->pdev->revision == 0) {
+ // Fix max_sclk and max_mclk for the Radeon R7 M270
+ max_sclk = 75000;
+ max_mclk = 8;
}
if (rps->vce_active) {
--
2.12.0
Re: [Outreachy kernel] [PATCH] staging: rtl8192u: Remove typedef phy_ofdm_rx_status_rxsc_sgien_exintfflag
On Sat, 11 Mar 2017, simran singhal wrote:
> Remove typdef phy_ofdm_rx_status_rxsc_sgien_exintfflag and replace its uses
> in the code.
>
> Signed-off-by: simran singhal
> ---
> drivers/staging/rtl8192u/r8192U.h | 4 ++--
> drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U.h
> b/drivers/staging/rtl8192u/r8192U.h
> index a7ba8f3..cd3e922 100644
> --- a/drivers/staging/rtl8192u/r8192U.h
> +++ b/drivers/staging/rtl8192u/r8192U.h
> @@ -793,12 +793,12 @@ typedef struct _phy_cck_rx_status_report_819xusb {
> } phy_sts_cck_819xusb_t;
>
>
> -typedef struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
> +struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
You should drop the _ at the beginning of the name. The _ suggests that
he name is a hidden thing, because one was intended to use the typedef.
The is not the case any more, so it would be better to drop the _.
The name of the structure seems to be sort of a concatenation of the names
of the fields. If you can think of a better name based on how the
structure is used, that could be good to.
julia
> u8 reserved:4;
> u8 rxsc:2;
> u8 sgi_en:1;
> u8 ex_intf_flag:1;
> -} phy_ofdm_rx_status_rxsc_sgien_exintfflag;
> +};
>
> typedef enum _RT_CUSTOMER_ID {
> RT_CID_DEFAULT = 0,
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 13239f4..0d830f6 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -4242,7 +4242,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
> *priv,
> {
> phy_sts_ofdm_819xusb_t *pofdm_buf;
> phy_sts_cck_819xusb_t *pcck_buf;
> - phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
> + struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
> u8 *prxpkt;
> u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
> s8 rx_pwr[4], rx_pwr_all = 0;
> @@ -4432,7 +4432,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
> *priv,
>
> /* record rx statistics for debug */
> rxsc_sgien_exflg = pofdm_buf->rxsc_sgien_exflg;
> - prxsc = (phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
> + prxsc = (struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
> &rxsc_sgien_exflg;
> if (pdrvinfo->BW) /* 40M channel */
> priv->stats.received_bwtype[1 + prxsc->rxsc]++;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170311162045.GA21103%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.
>
Re: nvme, allocation failures, and aborted commands
On Thursday, March 9, 2017 6:03:34 PM MST Keith Busch wrote: > On Thu, Mar 09, 2017 at 03:01:27PM -0700, Thomas Fjellstrom wrote: > > On Monday, March 6, 2017 5:46:33 PM MST Keith Busch wrote: > > > > > > echo 128 > /sys/block/nvme0n1/queue/max_hw_sectors_kb > > > echo 128 > /sys/block/nvme0n1/queue/max_nr_requests > > > > > > > First off, theres no max_nr_requests, and echoing into max_hw_sectors_kb gets > > me a permission denied even as root no matter the value I tried. > > What I meant to say was "max_sectors_kb" and "nr_request". > That seems to have quieted any errors. Performance hasn't suffered any. I had also tried a test with the mq-deadline scheduler instead of none, and it helped as well but did eventually show some command aborted errors. I'm just wondering why this is something that can happen. Shouldn't the default be "just work"? Is there no way to query the device for some sane defaults? I understand the Samsung 960 Evo m.2 (I have the 256GB model) isn't the highest end device out there, but it should be quite popular and should "just work" or a lot of people will complain or decide linux is broken. -- Thomas Fjellstrom tho...@fjellstrom.ca
Re: [Outreachy kernel] [PATCH] staging: rtl8192u: Remove typedef phy_ofdm_rx_status_rxsc_sgien_exintfflag
On Sat, Mar 11, 2017 at 9:56 PM, Julia Lawall wrote:
>
>
> On Sat, 11 Mar 2017, simran singhal wrote:
>
>> Remove typdef phy_ofdm_rx_status_rxsc_sgien_exintfflag and replace its uses
>> in the code.
>>
>> Signed-off-by: simran singhal
>> ---
>> drivers/staging/rtl8192u/r8192U.h | 4 ++--
>> drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8192u/r8192U.h
>> b/drivers/staging/rtl8192u/r8192U.h
>> index a7ba8f3..cd3e922 100644
>> --- a/drivers/staging/rtl8192u/r8192U.h
>> +++ b/drivers/staging/rtl8192u/r8192U.h
>> @@ -793,12 +793,12 @@ typedef struct _phy_cck_rx_status_report_819xusb {
>> } phy_sts_cck_819xusb_t;
>>
>>
>> -typedef struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
>> +struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
>
> You should drop the _ at the beginning of the name. The _ suggests that
> he name is a hidden thing, because one was intended to use the typedef.
> The is not the case any more, so it would be better to drop the _.
>
> The name of the structure seems to be sort of a concatenation of the names
> of the fields. If you can think of a better name based on how the
> structure is used, that could be good to.
>
Juila, I think changing the name of the structure is not a good idea as other
structures are also given on the basis of concatenation of the names
of the fields.
So, it will break the consistency.
And I will resend this patch with droping "_" at the beginning.
> julia
>
>> u8 reserved:4;
>> u8 rxsc:2;
>> u8 sgi_en:1;
>> u8 ex_intf_flag:1;
>> -} phy_ofdm_rx_status_rxsc_sgien_exintfflag;
>> +};
>>
>> typedef enum _RT_CUSTOMER_ID {
>> RT_CID_DEFAULT = 0,
>> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
>> b/drivers/staging/rtl8192u/r8192U_core.c
>> index 13239f4..0d830f6 100644
>> --- a/drivers/staging/rtl8192u/r8192U_core.c
>> +++ b/drivers/staging/rtl8192u/r8192U_core.c
>> @@ -4242,7 +4242,7 @@ static void rtl8192_query_rxphystatus(struct
>> r8192_priv *priv,
>> {
>> phy_sts_ofdm_819xusb_t *pofdm_buf;
>> phy_sts_cck_819xusb_t *pcck_buf;
>> - phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
>> + struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
>> u8 *prxpkt;
>> u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
>> s8 rx_pwr[4], rx_pwr_all = 0;
>> @@ -4432,7 +4432,7 @@ static void rtl8192_query_rxphystatus(struct
>> r8192_priv *priv,
>>
>> /* record rx statistics for debug */
>> rxsc_sgien_exflg = pofdm_buf->rxsc_sgien_exflg;
>> - prxsc = (phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
>> + prxsc = (struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
>> &rxsc_sgien_exflg;
>> if (pdrvinfo->BW) /* 40M channel */
>> priv->stats.received_bwtype[1 + prxsc->rxsc]++;
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/outreachy-kernel/20170311162045.GA21103%40singhal-Inspiron-5558.
>> For more options, visit https://groups.google.com/d/optout.
>>
Re: [Outreachy kernel] [PATCH] staging: rtl8192u: Remove typedef phy_ofdm_rx_status_rxsc_sgien_exintfflag
On Sat, 11 Mar 2017, SIMRAN SINGHAL wrote:
> On Sat, Mar 11, 2017 at 9:56 PM, Julia Lawall wrote:
> >
> >
> > On Sat, 11 Mar 2017, simran singhal wrote:
> >
> >> Remove typdef phy_ofdm_rx_status_rxsc_sgien_exintfflag and replace its uses
> >> in the code.
> >>
> >> Signed-off-by: simran singhal
> >> ---
> >> drivers/staging/rtl8192u/r8192U.h | 4 ++--
> >> drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/staging/rtl8192u/r8192U.h
> >> b/drivers/staging/rtl8192u/r8192U.h
> >> index a7ba8f3..cd3e922 100644
> >> --- a/drivers/staging/rtl8192u/r8192U.h
> >> +++ b/drivers/staging/rtl8192u/r8192U.h
> >> @@ -793,12 +793,12 @@ typedef struct _phy_cck_rx_status_report_819xusb {
> >> } phy_sts_cck_819xusb_t;
> >>
> >>
> >> -typedef struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
> >> +struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
> >
> > You should drop the _ at the beginning of the name. The _ suggests that
> > he name is a hidden thing, because one was intended to use the typedef.
> > The is not the case any more, so it would be better to drop the _.
> >
> > The name of the structure seems to be sort of a concatenation of the names
> > of the fields. If you can think of a better name based on how the
> > structure is used, that could be good to.
> >
> Juila, I think changing the name of the structure is not a good idea as other
> structures are also given on the basis of concatenation of the names
> of the fields.
> So, it will break the consistency.
I think that the name (or rather all the names) will have to be changed
eventually. It's impractical and unmeaningful. But perhaps it woud be
too much for this patch, so it's fine to just drop the _.
julia
>
> And I will resend this patch with droping "_" at the beginning.
>
>
> > julia
> >
> >> u8 reserved:4;
> >> u8 rxsc:2;
> >> u8 sgi_en:1;
> >> u8 ex_intf_flag:1;
> >> -} phy_ofdm_rx_status_rxsc_sgien_exintfflag;
> >> +};
> >>
> >> typedef enum _RT_CUSTOMER_ID {
> >> RT_CID_DEFAULT = 0,
> >> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> >> b/drivers/staging/rtl8192u/r8192U_core.c
> >> index 13239f4..0d830f6 100644
> >> --- a/drivers/staging/rtl8192u/r8192U_core.c
> >> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> >> @@ -4242,7 +4242,7 @@ static void rtl8192_query_rxphystatus(struct
> >> r8192_priv *priv,
> >> {
> >> phy_sts_ofdm_819xusb_t *pofdm_buf;
> >> phy_sts_cck_819xusb_t *pcck_buf;
> >> - phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
> >> + struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
> >> u8 *prxpkt;
> >> u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm,
> >> rxsc_sgien_exflg;
> >> s8 rx_pwr[4], rx_pwr_all = 0;
> >> @@ -4432,7 +4432,7 @@ static void rtl8192_query_rxphystatus(struct
> >> r8192_priv *priv,
> >>
> >> /* record rx statistics for debug */
> >> rxsc_sgien_exflg = pofdm_buf->rxsc_sgien_exflg;
> >> - prxsc = (phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
> >> + prxsc = (struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
> >> &rxsc_sgien_exflg;
> >> if (pdrvinfo->BW) /* 40M channel */
> >> priv->stats.received_bwtype[1 + prxsc->rxsc]++;
> >> --
> >> 2.7.4
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "outreachy-kernel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to outreachy-kernel+unsubscr...@googlegroups.com.
> >> To post to this group, send email to outreachy-ker...@googlegroups.com.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/outreachy-kernel/20170311162045.GA21103%40singhal-Inspiron-5558.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyMFOVzDNWABBP2oTN5q7_H7vABWFb5LBt96teurvNQVVg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
Re: [PATCH] powerpc: Fix crash introduced with commit 5657933dbb6e
On Thu, Mar 9, 2017 at 6:33 PM, Larry Finger wrote:
>
> The problem was bisected to commit 5657933dbb6e ("treewide: Move dma_ops
> from struct dev_archdata into struct device"). The problem was a missing
> copy of critical information from struct dev_archdata into struct device,
> leading to the dereference of a null pointer.
>
> This fix was suggested by Benjamin Herrenschmidt.
I'm assuming I'll be getting this through the powerpc tree. Holler if
that isn't the case.
Linus
[PATCH] staging: rtl8188eu: Fix redundant space coding style issue
Signed-off-by: Alex Yashchenko
---
drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
index 201c15b..81bf494 100644
--- a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
+++ b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
@@ -733,7 +733,7 @@ void ODM_RA_TxRPT2Handle_8188E(struct odm_dm_struct
*dm_odm, u8 *TxRPT_Buf, u16
pRAInfo->RTY[0], pRAInfo->RTY[1],
pRAInfo->RTY[2], pRAInfo->RTY[3],
pRAInfo->RTY[4], pRAInfo->DROP,
-macid_entry0 , macid_entry1));
+macid_entry0, macid_entry1));
if (pRAInfo->PTActive) {
if (pRAInfo->RAstage < 5)
odm_RateDecision_8188E(dm_odm,
pRAInfo);
--
1.9.1
Re: [PATCH 2/2] x86/fpu: Support disabling AVX and AVX512
On Sat, Mar 11, 2017 at 11:46:37AM +0100, Thomas Gleixner wrote:
> > +enum xsave_features {
> > + XSAVE_X87,
> > + XSAVE_SSE,
> > + XSAVE_AVX,
> > + XSAVE_MPX_BOUNDS,
> > + XSAVE_MPX_CSR,
> > + XSAVE_AVX512_OPMASK,
> > + XSAVE_AVX512_HI256,
> > + XSAVE_AVX512_ZMM_HI256,
> > + XSAVE_PT,
> > + XSAVE_PKU,
> > + XSAVE_UNKNOWN
> > +};
>
> What's that enum for? It's unused
It's not. The disable functions use it (although only the AVX parts)
-Andi
[PATCH v2] staging: rtl8192u: Remove typedef phy_ofdm_rx_status_rxsc_sgien_exintfflag
Remove typdef phy_ofdm_rx_status_rxsc_sgien_exintfflag and replace its uses
in the code.
Signed-off-by: simran singhal
---
v2:
-Drop the "_" at the beginning of the name of the structure
drivers/staging/rtl8192u/r8192U.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index a7ba8f3..524c1c9 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -793,12 +793,12 @@ typedef struct _phy_cck_rx_status_report_819xusb {
} phy_sts_cck_819xusb_t;
-typedef struct _phy_ofdm_rx_status_rxsc_sgien_exintfflag {
+struct phy_ofdm_rx_status_rxsc_sgien_exintfflag {
u8 reserved:4;
u8 rxsc:2;
u8 sgi_en:1;
u8 ex_intf_flag:1;
-} phy_ofdm_rx_status_rxsc_sgien_exintfflag;
+};
typedef enum _RT_CUSTOMER_ID {
RT_CID_DEFAULT = 0,
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 13239f4..8448e83 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4242,7 +4242,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
*priv,
{
phy_sts_ofdm_819xusb_t *pofdm_buf;
phy_sts_cck_819xusb_t *pcck_buf;
- phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
+ struct phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
s8 rx_pwr[4], rx_pwr_all = 0;
@@ -4432,7 +4432,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
*priv,
/* record rx statistics for debug */
rxsc_sgien_exflg = pofdm_buf->rxsc_sgien_exflg;
- prxsc = (phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
+ prxsc = (struct phy_ofdm_rx_status_rxsc_sgien_exintfflag *)
&rxsc_sgien_exflg;
if (pdrvinfo->BW) /* 40M channel */
priv->stats.received_bwtype[1 + prxsc->rxsc]++;
--
2.7.4
[PATCH v2 0/8] watchdog: s3c2410: Fixes and improvements
Hi, Minor cleanup and some fixes for the watchdog used on all Samsung SoCs. The DTS patches should through samsung-soc tree but they depend on introducing new compatible. The patches waiting for new compatible will be deferred to next release. Changes since v1: = 1. Add Guenter's review and Rob's ack. 2. Change compatible in patch 6/8 instead 3/8. Best regards, Krzysztof Krzysztof Kozlowski (8): watchdog: s3c2410: Remove confusing CONFIG prefix from local defines watchdog: s3c2410: Fix infinite interrupt in soft mode ARM: dts: exynos: Fix watchdog reset on Exynos4412 ARM: dts: s3c64xx: Enable watchdog on all S3C64xx boards ARM: dts: exynos: Enable watchdog on all Exynos4 boards ARM: dts: exynos: Fix infinite interrupt in soft mode on Exynos4210 and Exynos5440 ARM: dts: s3c64xx: Fix infinite interrupt in soft mode ARM: dts: s5pv210: Fix infinite interrupt in soft mode .../devicetree/bindings/watchdog/samsung-wdt.txt | 9 +++--- arch/arm/boot/dts/exynos4.dtsi | 9 -- arch/arm/boot/dts/exynos4210-origen.dts| 4 --- arch/arm/boot/dts/exynos4210.dtsi | 8 + arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi| 4 --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 4 --- arch/arm/boot/dts/exynos4412-origen.dts| 4 --- arch/arm/boot/dts/exynos4412.dtsi | 9 ++ arch/arm/boot/dts/exynos5440.dtsi | 2 +- arch/arm/boot/dts/s3c64xx.dtsi | 3 +- arch/arm/boot/dts/s5pv210.dtsi | 2 +- drivers/watchdog/s3c2410_wdt.c | 37 +++--- 12 files changed, 51 insertions(+), 44 deletions(-) -- 2.9.3
[PATCH v2 4/8] ARM: dts: s3c64xx: Enable watchdog on all S3C64xx boards
Watchdog module does not have external dependencies so it can be safely
enabled in s3c64xx.dtsi thus making it available for all S3C64xx-based
boards.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c64xx.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 0ccb414cd268..6caec5f27d38 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -100,7 +100,6 @@
interrupts = <26>;
clock-names = "watchdog";
clocks = <&clocks PCLK_WDT>;
- status = "disabled";
};
i2c0: i2c@7f004000 {
--
2.9.3
[PATCH v2 3/8] ARM: dts: exynos: Fix watchdog reset on Exynos4412
The Exynos4412 has the same watchdog as newer SoCs (e.g. Exynos5250).
Just like the others, for working it requires additional steps in Power
Management Unit: unmasking the reset request and enabling the system
reset. Without these additional steps in PMU, the watchdog will not be
able to reset the system on expiration event.
Change the compatible of Exynos4412 watchdog device node to
samsung,exynos5250-wdt which includes the additional PMU steps.
This will also fix infinite watchdog interrupt in soft mode (lack of
interrupt clear) because it is also included in samsung,exynos5250-wdt.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi| 9 -
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4412.dtsi | 10 ++
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 18def1c774d5..71e2cdae6068 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -283,15 +283,6 @@
};
};
- watchdog: watchdog@1006 {
- compatible = "samsung,s3c2410-wdt";
- reg = <0x1006 0x100>;
- interrupts = ;
- clocks = <&clock CLK_WDT>;
- clock-names = "watchdog";
- status = "disabled";
- };
-
rtc: rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index f9408188f97f..8bff2253acca 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -119,6 +119,15 @@
};
};
+ watchdog: watchdog@1006 {
+ compatible = "samsung,s3c2410-wdt";
+ reg = <0x1006 0x100>;
+ interrupts = ;
+ clocks = <&clock CLK_WDT>;
+ clock-names = "watchdog";
+ status = "disabled";
+ };
+
clock: clock-controller@1003 {
compatible = "samsung,exynos4210-clock";
reg = <0x1003 0x2>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 235bbb69ad7c..6f47988a1ab5 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -215,6 +215,16 @@
};
};
+ watchdog: watchdog@1006 {
+ compatible = "samsung,exynos5250-wdt";
+ reg = <0x1006 0x100>;
+ interrupts = ;
+ clocks = <&clock CLK_WDT>;
+ clock-names = "watchdog";
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ status = "disabled";
+ };
+
adc: adc@126C {
compatible = "samsung,exynos-adc-v1";
reg = <0x126C 0x100>;
--
2.9.3
[PATCH v2 5/8] ARM: dts: exynos: Enable watchdog on all Exynos4 boards
Watchdog module does not have external dependencies so it can be safely
enabled in exynos4.dtsi thus making it available for all Exynos4-based
boards.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-origen.dts | 4
arch/arm/boot/dts/exynos4210.dtsi | 1 -
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 4
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4
arch/arm/boot/dts/exynos4412-origen.dts | 4
arch/arm/boot/dts/exynos4412.dtsi | 1 -
6 files changed, 18 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index a2c6a13fe67b..312650e2450f 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -328,7 +328,3 @@
&tmu {
status = "okay";
};
-
-&watchdog {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 8bff2253acca..9d51d4d62d94 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -125,7 +125,6 @@
interrupts = ;
clocks = <&clock CLK_WDT>;
clock-names = "watchdog";
- status = "disabled";
};
clock: clock-controller@1003 {
diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
index a36cd36a26b8..4cd62487bb16 100644
--- a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
+++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
@@ -495,7 +495,3 @@
vtmu-supply = <&ldo16_reg>;
status = "okay";
};
-
-&watchdog {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 78f118cb73d4..0f1ff792fe44 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -555,7 +555,3 @@
vtmu-supply = <&ldo10_reg>;
status = "okay";
};
-
-&watchdog {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index a1ab6f94bb64..7a83e2df18a6 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -541,7 +541,3 @@
&serial_3 {
status = "okay";
};
-
-&watchdog {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 6f47988a1ab5..cc69466f17c0 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -222,7 +222,6 @@
clocks = <&clock CLK_WDT>;
clock-names = "watchdog";
samsung,syscon-phandle = <&pmu_system_controller>;
- status = "disabled";
};
adc: adc@126C {
--
2.9.3
[PATCH v2 1/8] watchdog: s3c2410: Remove confusing CONFIG prefix from local defines
The CONFIG prefix from defines in the s3c2410_wdt.c might suggest that
these constants come from Kconfig.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Guenter Roeck
---
drivers/watchdog/s3c2410_wdt.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 59e95762a6de..3e216f54cb6f 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -64,8 +64,8 @@
#define S3C2410_WTCON_PRESCALE_MASK(0xff << 8)
#define S3C2410_WTCON_PRESCALE_MAX 0xff
-#define CONFIG_S3C2410_WATCHDOG_ATBOOT (0)
-#define CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME (15)
+#define S3C2410_WATCHDOG_ATBOOT(0)
+#define S3C2410_WATCHDOG_DEFAULT_TIME (15)
#define EXYNOS5_RST_STAT_REG_OFFSET0x0404
#define EXYNOS5_WDT_DISABLE_REG_OFFSET 0x0408
@@ -79,7 +79,7 @@
static bool nowayout = WATCHDOG_NOWAYOUT;
static int tmr_margin;
-static int tmr_atboot = CONFIG_S3C2410_WATCHDOG_ATBOOT;
+static int tmr_atboot = S3C2410_WATCHDOG_ATBOOT;
static int soft_noboot;
static int debug;
@@ -90,10 +90,10 @@ module_param(soft_noboot, int, 0);
module_param(debug, int, 0);
MODULE_PARM_DESC(tmr_margin, "Watchdog tmr_margin in seconds. (default="
- __MODULE_STRING(CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME) ")");
+ __MODULE_STRING(S3C2410_WATCHDOG_DEFAULT_TIME) ")");
MODULE_PARM_DESC(tmr_atboot,
"Watchdog is started at boot time if set to 1, default="
- __MODULE_STRING(CONFIG_S3C2410_WATCHDOG_ATBOOT));
+ __MODULE_STRING(S3C2410_WATCHDOG_ATBOOT));
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
MODULE_PARM_DESC(soft_noboot, "Watchdog action, set to 1 to ignore reboots, "
@@ -406,7 +406,7 @@ static struct watchdog_ops s3c2410wdt_ops = {
static struct watchdog_device s3c2410_wdd = {
.info = &s3c2410_wdt_ident,
.ops = &s3c2410wdt_ops,
- .timeout = CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME,
+ .timeout = S3C2410_WATCHDOG_DEFAULT_TIME,
};
/* interrupt handler code */
@@ -600,12 +600,12 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
wdt->wdt_device.timeout);
if (ret) {
started = s3c2410wdt_set_heartbeat(&wdt->wdt_device,
- CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME);
+ S3C2410_WATCHDOG_DEFAULT_TIME);
if (started == 0)
dev_info(dev,
"tmr_margin value out of range, default %d used\n",
- CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME);
+ S3C2410_WATCHDOG_DEFAULT_TIME);
else
dev_info(dev, "default timer value is out of range, "
"cannot start\n");
--
2.9.3
[PATCH v2 2/8] watchdog: s3c2410: Fix infinite interrupt in soft mode
In soft (no-reboot) mode, the driver self-pings watchdog upon expiration
of an interrupt. However the interrupt itself was not cleared thus on
first hit, the system enters infinite interrupt handling loop.
On Odroid U3 (Exynos4412), when booted with s3c2410_wdt.soft_noboot=1
argument the console is flooded:
# killall -9 watchdog
[ 60.523760] s3c2410-wdt 1006.watchdog: watchdog timer expired
(irq)
[ 60.536744] s3c2410-wdt 1006.watchdog: watchdog timer expired
(irq)
Fix this by writing something to the WTCLRINT register to clear the
interrupt. The register WTCLRINT however appeared in S3C6410 so a new
watchdog quirk and flavor are needed.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Guenter Roeck
Acked-by: Rob Herring
---
.../devicetree/bindings/watchdog/samsung-wdt.txt| 9 +
drivers/watchdog/s3c2410_wdt.c | 21 ++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 8f3d96af81d7..1f6e101e299a 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -6,10 +6,11 @@ occurred.
Required properties:
- compatible : should be one among the following
- (a) "samsung,s3c2410-wdt" for Exynos4 and previous SoCs
- (b) "samsung,exynos5250-wdt" for Exynos5250
- (c) "samsung,exynos5420-wdt" for Exynos5420
- (c) "samsung,exynos7-wdt" for Exynos7
+ - "samsung,s3c2410-wdt" for S3C2410
+ - "samsung,s3c6410-wdt" for S3C6410, S5PV210 and Exynos4
+ - "samsung,exynos5250-wdt" for Exynos5250
+ - "samsung,exynos5420-wdt" for Exynos5420
+ - "samsung,exynos7-wdt" for Exynos7
- reg : base physical address of the controller and length of memory mapped
region.
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 3e216f54cb6f..7db7847a005c 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -46,6 +46,7 @@
#define S3C2410_WTCON 0x00
#define S3C2410_WTDAT 0x04
#define S3C2410_WTCNT 0x08
+#define S3C2410_WTCLRINT 0x0c
#define S3C2410_WTCNT_MAXCNT 0x
@@ -72,6 +73,7 @@
#define EXYNOS5_WDT_MASK_RESET_REG_OFFSET 0x040c
#define QUIRK_HAS_PMU_CONFIG (1 << 0)
#define QUIRK_HAS_RST_STAT (1 << 1)
+#define QUIRK_HAS_WTCLRINT_REG (1 << 2)
/* These quirks require that we have a PMU register map */
#define QUIRKS_HAVE_PMUREG (QUIRK_HAS_PMU_CONFIG | \
@@ -143,13 +145,18 @@ static const struct s3c2410_wdt_variant drv_data_s3c2410
= {
};
#ifdef CONFIG_OF
+static const struct s3c2410_wdt_variant drv_data_s3c6410 = {
+ .quirks = QUIRK_HAS_WTCLRINT_REG,
+};
+
static const struct s3c2410_wdt_variant drv_data_exynos5250 = {
.disable_reg = EXYNOS5_WDT_DISABLE_REG_OFFSET,
.mask_reset_reg = EXYNOS5_WDT_MASK_RESET_REG_OFFSET,
.mask_bit = 20,
.rst_stat_reg = EXYNOS5_RST_STAT_REG_OFFSET,
.rst_stat_bit = 20,
- .quirks = QUIRK_HAS_PMU_CONFIG | QUIRK_HAS_RST_STAT,
+ .quirks = QUIRK_HAS_PMU_CONFIG | QUIRK_HAS_RST_STAT \
+ | QUIRK_HAS_WTCLRINT_REG,
};
static const struct s3c2410_wdt_variant drv_data_exynos5420 = {
@@ -158,7 +165,8 @@ static const struct s3c2410_wdt_variant drv_data_exynos5420
= {
.mask_bit = 0,
.rst_stat_reg = EXYNOS5_RST_STAT_REG_OFFSET,
.rst_stat_bit = 9,
- .quirks = QUIRK_HAS_PMU_CONFIG | QUIRK_HAS_RST_STAT,
+ .quirks = QUIRK_HAS_PMU_CONFIG | QUIRK_HAS_RST_STAT \
+ | QUIRK_HAS_WTCLRINT_REG,
};
static const struct s3c2410_wdt_variant drv_data_exynos7 = {
@@ -167,12 +175,15 @@ static const struct s3c2410_wdt_variant drv_data_exynos7
= {
.mask_bit = 23,
.rst_stat_reg = EXYNOS5_RST_STAT_REG_OFFSET,
.rst_stat_bit = 23, /* A57 WDTRESET */
- .quirks = QUIRK_HAS_PMU_CONFIG | QUIRK_HAS_RST_STAT,
+ .quirks = QUIRK_HAS_PMU_CONFIG | QUIRK_HAS_RST_STAT \
+ | QUIRK_HAS_WTCLRINT_REG,
};
static const struct of_device_id s3c2410_wdt_match[] = {
{ .compatible = "samsung,s3c2410-wdt",
.data = &drv_data_s3c2410 },
+ { .compatible = "samsung,s3c6410-wdt",
+ .data = &drv_data_s3c6410 },
{ .compatible = "samsung,exynos5250-wdt",
.data = &drv_data_exynos5250 },
{ .compatible = "samsung,exynos5420-wdt",
@@ -418,6 +429,10 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
dev_info(wdt->dev, "watchdog timer expired (irq)\n");
s3c2410wdt_keepalive(&wdt->wdt_device);
+
+ if (wdt->drv_data->quirks & QUIRK_HAS_WTCLRINT_REG)
+ writel(0x1, wdt->reg_base + S3C2410_WTCLRINT);
+
return IRQ_HANDLED;
}
[PATCH v2 7/8] ARM: dts: s3c64xx: Fix infinite interrupt in soft mode
In soft (no-reboot) mode, the driver self-pings watchdog upon expiration
of an interrupt. The interrupt has to be cleared, because otherwise
system enters infinite interrupt handling loop.
Use a samsung,s3c6410-wdt compatible to select appropriate quirk for
clearing the watchdog interrupt.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c64xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 6caec5f27d38..c55cbb3af2c0 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -94,7 +94,7 @@
};
watchdog: watchdog@7e004000 {
- compatible = "samsung,s3c2410-wdt";
+ compatible = "samsung,s3c6410-wdt";
reg = <0x7e004000 0x1000>;
interrupt-parent = <&vic0>;
interrupts = <26>;
--
2.9.3
[PATCH v2 8/8] ARM: dts: s5pv210: Fix infinite interrupt in soft mode
In soft (no-reboot) mode, the driver self-pings watchdog upon expiration
of an interrupt. The interrupt has to be cleared, because otherwise
system enters infinite interrupt handling loop.
Use a samsung,s3c6410-wdt compatible to select appropriate quirk for
clearing the watchdog interrupt.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s5pv210.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index a853918be43f..726c5d0dbd5b 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -310,7 +310,7 @@
};
watchdog: watchdog@e270 {
- compatible = "samsung,s3c2410-wdt";
+ compatible = "samsung,s3c6410-wdt";
reg = <0xe270 0x1000>;
interrupt-parent = <&vic0>;
interrupts = <26>;
--
2.9.3
[PATCH v2 6/8] ARM: dts: exynos: Fix infinite interrupt in soft mode on Exynos4210 and Exynos5440
In soft (no-reboot) mode, the driver self-pings watchdog upon expiration
of an interrupt. The interrupt has to be cleared, because otherwise
system enters infinite interrupt handling loop.
Use a samsung,s3c6410-wdt compatible to select appropriate quirk for
clearing the watchdog interrupt.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 9d51d4d62d94..e6e62103a71f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -120,7 +120,7 @@
};
watchdog: watchdog@1006 {
- compatible = "samsung,s3c2410-wdt";
+ compatible = "samsung,s3c6410-wdt";
reg = <0x1006 0x100>;
interrupts = ;
clocks = <&clock CLK_WDT>;
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 77d35bb92950..abfe054b2187 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -189,7 +189,7 @@
};
watchdog@11 {
- compatible = "samsung,s3c2410-wdt";
+ compatible = "samsung,s3c6410-wdt";
reg = <0x11 0x1000>;
interrupts = ;
clocks = <&clock CLK_B_125>;
--
2.9.3
Re: [PATCH v2 1/8] watchdog: s3c2410: Remove confusing CONFIG prefix from local defines
On Sat, Mar 11, 2017 at 07:25:20PM +0200, Krzysztof Kozlowski wrote: > The CONFIG prefix from defines in the s3c2410_wdt.c might suggest that > these constants come from Kconfig. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Guenter Roeck > --- > drivers/watchdog/s3c2410_wdt.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > Ah, my mistake, I looked at watchdog-master but this is already in watchdog-next. Sorry for confusion. Best regards, Krzysztof
[PATCH 1/2] x86/xsave: Move xsave initialization to after parsing early parameters
From: Andi Kleen Move the XSAVE initialization code to be after parsing early parameters. I don't see any reason why the FPU code needs to be initialized that early, nothing else in the initialization phase uses XSAVE. This is useful to be able to handle command line parameters in the XSAVE initialization code. Signed-off-by: Andi Kleen --- arch/x86/kernel/cpu/common.c | 1 - arch/x86/kernel/setup.c | 3 +++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 58094a1f9e9d..db16a28d49a1 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -844,7 +844,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c) } setup_force_cpu_cap(X86_FEATURE_ALWAYS); - fpu__init_system(c); } void __init early_cpu_init(void) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 4bf0c8926a1c..2a85efc37e1f 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -90,6 +90,7 @@ #include #include #include +#include #include #include @@ -987,6 +988,8 @@ void __init setup_arch(char **cmdline_p) parse_early_param(); + fpu__init_system(&boot_cpu_data); + #ifdef CONFIG_MEMORY_HOTPLUG /* * Memory used by the kernel cannot be hot-removed because Linux -- 2.9.3
[PATCH 2/2] x86/fpu: Support disabling AVX and AVX512
From: Andi Kleen
For performance testing it is useful to be able to disable AVX
and AVX512. User programs check in XGETBV if AVX is supported
by the OS. If we don't initialize the XSAVE state for AVX it will
appear as if the OS is not supporting AVX.
Implement disable options for AVX and AVX512 code in the XSAVE code.
v2: Change description. Make variable static. Remove Intel reference.
Signed-off-by: Andi Kleen
---
Documentation/admin-guide/kernel-parameters.txt | 3 ++
arch/x86/kernel/fpu/xstate.c| 61 +
2 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45caabada..b94ff507a48f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -785,6 +785,9 @@
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
+ disable_avx [X86] Disable support for AVX
+ disable_avx512 [X86] Disable support for AVX512
+
disable_1tb_segments [PPC]
Disables the use of 1TB hash page table segments. This
causes the kernel to fall back to 256MB segments which
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index c24ac1efb12d..977ab03eacf7 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -16,6 +16,20 @@
#include
+enum xsave_features {
+ XSAVE_X87,
+ XSAVE_SSE,
+ XSAVE_AVX,
+ XSAVE_MPX_BOUNDS,
+ XSAVE_MPX_CSR,
+ XSAVE_AVX512_OPMASK,
+ XSAVE_AVX512_HI256,
+ XSAVE_AVX512_ZMM_HI256,
+ XSAVE_PT,
+ XSAVE_PKU,
+ XSAVE_UNKNOWN
+};
+
/*
* Although we spell it out in here, the Processor Trace
* xfeature is completely unused. We use other mechanisms
@@ -41,6 +55,8 @@ static const char *xfeature_names[] =
*/
u64 xfeatures_mask __read_mostly;
+static u64 xfeatures_disabled __initdata;
+
static unsigned int xstate_offsets[XFEATURE_MAX] = { [ 0 ... XFEATURE_MAX - 1]
= -1};
static unsigned int xstate_sizes[XFEATURE_MAX] = { [ 0 ... XFEATURE_MAX - 1]
= -1};
static unsigned int xstate_comp_offsets[sizeof(xfeatures_mask)*8];
@@ -52,6 +68,21 @@ static unsigned int
xstate_comp_offsets[sizeof(xfeatures_mask)*8];
*/
unsigned int fpu_user_xstate_size;
+static void clear_avx512(void)
+{
+ setup_clear_cpu_cap(X86_FEATURE_AVX512F);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512IFMA);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512PF);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512ER);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512CD);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512DQ);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512BW);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512VL);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512VBMI);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512_4VNNIW);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512_4FMAPS);
+}
+
/*
* Clear all of the X86_FEATURE_* bits that are unavailable
* when the CPU has no XSAVE support.
@@ -64,17 +95,9 @@ void fpu__xstate_clear_all_cpu_caps(void)
setup_clear_cpu_cap(X86_FEATURE_XSAVES);
setup_clear_cpu_cap(X86_FEATURE_AVX);
setup_clear_cpu_cap(X86_FEATURE_AVX2);
- setup_clear_cpu_cap(X86_FEATURE_AVX512F);
- setup_clear_cpu_cap(X86_FEATURE_AVX512IFMA);
- setup_clear_cpu_cap(X86_FEATURE_AVX512PF);
- setup_clear_cpu_cap(X86_FEATURE_AVX512ER);
- setup_clear_cpu_cap(X86_FEATURE_AVX512CD);
- setup_clear_cpu_cap(X86_FEATURE_AVX512DQ);
- setup_clear_cpu_cap(X86_FEATURE_AVX512BW);
- setup_clear_cpu_cap(X86_FEATURE_AVX512VL);
+ clear_avx512();
setup_clear_cpu_cap(X86_FEATURE_MPX);
setup_clear_cpu_cap(X86_FEATURE_XGETBV1);
- setup_clear_cpu_cap(X86_FEATURE_AVX512VBMI);
setup_clear_cpu_cap(X86_FEATURE_PKU);
setup_clear_cpu_cap(X86_FEATURE_AVX512_4VNNIW);
setup_clear_cpu_cap(X86_FEATURE_AVX512_4FMAPS);
@@ -735,6 +758,7 @@ void __init fpu__init_system_xstate(void)
goto out_disable;
}
+ xfeatures_mask &= ~xfeatures_disabled;
xfeatures_mask &= fpu__get_supported_xfeatures_mask();
/* Enable xstate instructions to be able to continue with
initialization: */
@@ -1080,3 +1104,22 @@ int copyin_to_xsaves(const void *kbuf, const void __user
*ubuf,
return 0;
}
+
+static int __init parse_disable_avx512(char *str)
+{
+ xfeatures_disabled |= BIT(XSAVE_AVX512_OPMASK) |
+ BIT(XSAVE_AVX512_HI256) |
+ BIT(XSAVE_AVX512_ZMM_HI256);
+ clear_avx512();
+ return 0;
+}
+early_param("disable_avx512", parse_disable_avx512);
+
+static int __init parse_disable_avx(char *str)
+{
+ xfeatures_disabled |= BIT(XSAVE_AVX);
+ setup_clear_cpu_cap(X86_FEATURE_AVX);
+ s
