mkdir: cannot create directory ‘/functional’: Permission denied
Replace $$OUTPUT with $(OUTPUT) when referring to the Makefile OUTPUT
variable. The above make command now completes successfully.
Fixes: a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT")
Signed-off-by: Darren Hart (VMwa
Fix Makefile for futex selftests that's been broken since November
(sad face)
Step 3: Pick this up in the morning...
--
Darren Hart
VMware Open Source Technology Center
On Wed, Mar 22, 2017 at 11:28:40PM -0700, Joe Perches wrote:
> On Wed, 2017-03-22 at 23:20 -0700, Darren Hart wrote:
> > I do have an open question regarding how we're going about testing for the
> > end
> > of the header lines. Since we're not just testing for
s checkpatch to erroniously think that it's
> in the content body, as opposed to headers and thus flag a mail header
> as an unwrapped long comment line.
>
> Reported-by: Darren Hart (VMware)
> Original-patch-by: John 'Warthog9' Hawley (VMware)
> Signed-off-by: Joe Perch
On Wed, Mar 22, 2017 at 11:17:33AM -0700, Joe Perches wrote:
> On Wed, 2017-03-22 at 08:25 -0700, Darren Hart wrote:
> > On Tue, Mar 21, 2017 at 11:31:08AM -0700, Joe Perches wrote:
> > > On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote:
> &
vices of that platform. Please apply.
>
> Tested-by: Jonathan Woithe
> Reviewed-by: Jonathan Woithe
Applied, thanks Jonathan.
--
Darren Hart
VMware Open Source Technology Center
ines that start with maybe a space followed by a : ... Why did you
introduce that part of the check?
Looking at this more closely, I was also not clear why the original test looked
for several spaces followed by non-space. What case is this for?
> $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) {
>
>
Thanks,
--
Darren Hart
VMware Open Source Technology Center
On Wed, Feb 22, 2017 at 03:03:16PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 04:50:45PM -0800, Darren Hart wrote:
> > On Tue, Dec 13, 2016 at 09:36:42AM +0100, Peter Zijlstra wrote:
> > > Since the futex_q can dissapear the instruction after assigning NULL,
> >
bug on hardware, I will presume the same approach was
taken here. I'm dropping this patch as "changes requested" because at the very
least this needs a commit log which documents the problem manifested and why the
behavioral change is appropriate.
--
Darren Hart
VMware Open Source Technology Center
tform device sysfs attributes we had
previously and all look good to me.
--
Darren Hart
VMware Open Source Technology Center
;
> > From input POV your patch makes sense.
>
> Could you give your tag?
Based on this discussion and no additional input from Dmitry or Corentin, and my
own review, I have queued this patch to testing. Thanks.
--
Darren Hart
VMware Open Source Technology Center
16:41:55 -0700)
Thanks,
Darren Hart
VMware Open Source Technology Center
platform-drivers-x86 for v4.11-2
Asus fixes for the airplane LED and a long awaited fujitsu cleanup.
asus-wmi:
- Remove quirk_no_rfkill
- Detect quirk_no_r
On Tue, Feb 28, 2017 at 03:01:52PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 28, 2017 at 02:24:40PM +0100, Michał Kępień wrote:
> > > On Tue, Feb 28, 2017 at 09:33:28AM +0100, Micha?? K??pie?? wrote:
> > > > GregKH wrote:
> > > > > On Mon, Feb 27, 2017
> > their consequential low rate of use in the wild, such a move might be
> > > > justifiable. However, the kernel tends to hold userspace interfaces to
> > > > be
> > > > perpetual so I can't see how such a change would get up in this case.
> > > > Darren may like to comment on this.
> > >
> > > Yes, this definitely needs input from subsystem maintainers.
> > >
> > > Let me just emphasize once again that I believe backlight-related sysfs
> > > attributes belonging to the platform driver are a misplaced feature.
> > > Backlight-related features belong in backlight devices. The only
> > > situation I can think of that someone will get hurt by these getting
> > > removed is that they have some custom script which uses the platform
> > > device instead of the backlight device to control LCD brightness.
> > > Removing these attributes has no effect on whether brightness-related
> > > keys on the keyboard work or not.
> > >
> > > Nevertheless, if the consensus is that these should stay where they are,
> > > they need to be added conditionally, only when acpi_backlight=vendor.
> > > Otherwise they simply do not work on modern hardware and cause
> > > confusion.
> >
> > In regard to the above, please let me know what you think about:
> >
> > - removing backlight-related attributes from the platform device,
> >
> > - removing the platform device altogether and attaching
> > laptop-specific attributes to the ACPI device instead.
Unless GregKH objects, I would prefer to see the second option.
>
> Darren, Andy,
>
> As six weeks have passed since I originally asked for your comments, I
> hope another gentle reminder is okay. Your advice is needed before I
> can post further cleanups for fujitsu-laptop.
My sincere apologies. Please always feel free to nag if more than 2 weeks go by.
6 weeks is totally unacceptable.
--
Darren Hart
Intel Open Source Technology Center
to af050abb5c2e5e7d3e1368475d63cbac597dc34f:
platform/x86: intel_turbo_max_3: make it explicitly non-modular (2017-02-24
23:48:54 -0800)
Thanks,
Darren Hart
Intel Open Source Technology Center
platform-drivers-x86 for v4.11-1
New
On Fri, Feb 17, 2017 at 08:14:51AM +0100, Michał Kępień wrote:
> > On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > > On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> > > > On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrot
On Mon, Feb 20, 2017 at 07:55:45AM -0800, Srinivas Pandruvada wrote:
> On Thu, 2017-02-16 at 19:37 -0800, Darren Hart wrote:
> > On Mon, Feb 13, 2017 at 07:37:00PM -0500, Paul Gortmaker wrote:
> > > The Kconfig currently controlling compilation of this code is:
> > >
On Fri, Feb 17, 2017 at 02:47:56PM +1030, Jonathan Woithe wrote:
> On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
> > On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > > Do you want me to continue to use Acked-by, or should I switch to
On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> > On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> > > On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe
> > > wrote:
>
n a lot of dependants.
>
Paul, this all looks so very familiar... have we been through this before? Maybe
for another driver...
> Cc: Darren Hart
> Cc: Andy Shevchenko
> Cc: Srinivas Pandruvada
Srinivas, any objections?
> Cc: platform-driver-...@vger.kernel.org
> Sig
);
> + if (ret < 0)
> + return -EIO;
> + return count;
> +}
> +
> +static DEVICE_ATTR(touchpad_mode, 0644, show_touchpad_mode,
> store_touchpad_mode);
Please use:
static DEVICE_ATTR_RW(touchpad_mode);
You'll need to move the show_ and store_ prefixes to be postfixes, see
toshiba-acpi.c for several examples.
> +
> static struct attribute *ideapad_attributes[] = {
> &dev_attr_camera_power.attr,
> &dev_attr_fan_mode.attr,
> + &dev_attr_touchpad_mode.attr,
> NULL
> };
>
> --
> 2.11.0
>
>
--
Darren Hart
Intel Open Source Technology Center
to mainline. If you are
not the author or committing it to a tree followed by a pull-request, the
correct tag is "Reviewed-by".
--
Darren Hart
Intel Open Source Technology Center
patches.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
cycle (which is my first as
In general, you should be able to use Linus' master as the base. Only if you
require patches already in for-next, should you use for-next.
--
Darren Hart
Intel Open Source Technology Center
On Tue, Jan 24, 2017 at 05:25:40PM +0200, Andy Shevchenko wrote:
> For last few months Darren and I are co-maintaining PDx86 subsystem.
> Make this fact official by updating MAINTAINERS database.
>
> Cc: Darren Hart
> Signed-off-by: Andy Shevchenko
Acked-by: Darren Hart
>
ule tasks.
>
> Signed-off-by: Srinivas Pandruvada
Queued to testing, thanks Srinivas.
--
Darren Hart
Intel Open Source Technology Center
too.
2) Since it is BDW specifc, how about:
intel_bdw_turbo.c
CONFIG_INTEL_BDW_TURBO
I don't think "max enumeration" conveys any meaning to most readers.
Thoughts?
Thanks,
--
Darren Hart
Intel Open Source Technology Center
on't know if they'll have any (public) comments they can add on the matter
> yet however.
Thanks Mario. Yes, there isn't much to say here in public other than to confirm
we are keenly aware of the problem and have been actively working on fixing it,
both for this instance, and th
now only printed upon a successful push due to the last patch).
>
> Thanks for clarifying. It may be worth adding a comment to the effect that
> the patches were tested on a Lifebook E744. That aside, I'm happy with
> these clean ups.
>
> Acked-by: Jonathan Woithe
Queued to testing, thanks!
--
Darren Hart
Intel Open Source Technology Center
nly printed upon a successful push due to the last patch).
>
> Thanks for clarifying. It may be worth adding a comment to the effect that
> the patches were tested on a Lifebook E744. That aside, I'm happy with
> these clean ups.
>
> Acked-by: Jonathan Woithe
>
> Darren: do you want me to explicitly ack all 4 parts, or the above
> sufficient for your processes?
The above is sufficient as far as I'm concerned.
--
Darren Hart
Intel Open Source Technology Center
.
If we create folder, I'd recommend by manufacturer as that is typically along
the lines that our contributors work. Someone with a Dell laptop tends to focus
on Dell. The Intel engineers will focus primarily on Intel SoCs, etc.
I'd like to avoid getting too granualar as it adds overhead with Makefiles,
file navigation, etc. Any thoughts on a minimum file count to justify a new
directory? Maybe 5?
--
Darren Hart
Intel Open Source Technology Center
On Wed, Jan 11, 2017 at 01:37:19PM +0900, Stafford Horne wrote:
> On Tue, Jan 10, 2017 at 02:17:18PM -0800, Darren Hart wrote:
> > On Tue, Jan 10, 2017 at 02:10:42PM -0800, Darren Hart wrote:
> > > On Fri, Jan 06, 2017 at 01:18:39PM +0900, Stafford Horne wrote:
> > &
On Tue, Jan 10, 2017 at 02:10:42PM -0800, Darren Hart wrote:
> On Fri, Jan 06, 2017 at 01:18:39PM +0900, Stafford Horne wrote:
> > I am working on doing selftests for openrisc and found issues with the
> > futex test is not building after changes to the tests source.
> >
&
h rebuild will not happen. Add headers
> to fix it up.
>
> Signed-off-by: Stafford Horne
Thanks for catching this and the fix.
+Shuah Khan
Note: This appears also to be a problem for intel_pstate/Makefile
Reviewed-by: Darren Hart
> ---
> tools/testing/selftests/futex/funct
state();
> return 0;
> }
> -#endif
> static SIMPLE_DEV_PM_OPS(s3_wmi_pm, NULL, s3_wmi_resume);
>
> static struct platform_driver s3_wmi_driver = {
> --
> 2.9.0
>
>
--
Darren Hart
Intel Open Source Technology Center
Hi Linus,
Just two small fixes for platform drivers x86.
Thanks,
Darren Hart
Intel Open Source Technology Center
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git
On Sat, Dec 17, 2016 at 02:54:11PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 04:06:39PM -0800, Darren Hart wrote:
> > On Tue, Dec 13, 2016 at 09:36:40AM +0100, Peter Zijlstra wrote:
> > > Thomas spotted that fixup_pi_state_owner() can return errors and we
> &
vhart/linux-platform-drivers-x86.git
tags/platform-drivers-x86-v4.10-2
for you to fetch changes up to 83da6b59919a71a1a97ce9863aa0267eaf6d496c:
platform/x86: surface3-wmi: Balance locking on error path (2016-12-18
14:56:43 -0800)
Thanks,
Darren Hart
Intel Open Source Technology C
On Sat, Dec 17, 2016 at 02:52:14PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:31:40PM -0800, Darren Hart wrote:
> > On Tue, Dec 13, 2016 at 09:36:38AM +0100, Peter Zijlstra wrote:
> > > That way, when we drop hb->lock to wait, futex and rt_mutex wait stat
r = NULL;
> + smp_store_release(&q->lock_ptr, NULL);
> }
>
> static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q
> *top_waiter,
>
>
>
--
Darren Hart
Intel Open Source Technology Center
is possible that the next waiter (that caused top_waiter to call
* into the kernel) has since timed out and is no longer waiting on the
* lock.
*/
Is that clearer?
--
Darren Hart
Intel Open Source Technology Center
t; current)
> + rt_mutex_unlock(&q.pi_state->pi_mutex);
> /*
>* Drop the reference to the pi state which
>* the requeue_pi() code acquired for us.
>
>
>
--
Darren Hart
Intel Open Source Technology Center
ng (selftests/futex/functional in CI with kvm on a
dual socket Xeon "cpus=20,sockets=2,cores=5,threads=2").
Reviewed-by: Darren Hart
--
Darren Hart
Intel Open Source Technology Center
;ll comment as I work
through them and ask questions - to keep the dialog going.
>
> That way, when we drop hb->lock to wait, futex and rt_mutex wait state is
> consistent.
>
>
> In any case, it passes our inadequate testing.
It passed my CI tools/testing/selftests/futex/functional/run.sh. Did you also
happen to run a fuzz tester?
--
Darren Hart
Intel Open Source Technology Center
On Sat, Dec 17, 2016 at 12:29:41AM +0200, Andy Shevchenko wrote:
> On Fri, Dec 16, 2016 at 9:19 PM, Darren Hart wrote:
> > On Fri, Dec 16, 2016 at 08:49:13PM +0200, Andy Shevchenko wrote:
> >> On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart wrote:
> >> > On Tue, De
On Fri, Dec 16, 2016 at 08:49:13PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart wrote:
> > On Tue, Dec 13, 2016 at 02:26:21AM +0200, Andy Shevchenko wrote:
> >> On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
> >> wrote:
>
Yes, but as I mentioned:
> 1) submitter goes last;
> 2) SoB lines and Author(s) should reflect actual state of the sources.
> If patch has 2 SoBs I'm expecting see different names of Authors in
> the source code. *Or* in some cases it's possible to explain in the
> commit
nstead? It needs a place to serve both acpi_lpss.c
and pmc_atom.c. The include/linux/platform_data/x86 location doesn't seem too
strange as it supports a "platform" driver in the sense that pmc_atom is a
platform driver.
--
Darren Hart
Intel Open Source Technology Center
.git
tags/platform-drivers-x86-v4.10-1
for you to fetch changes up to cb2bf25145e0d2abef20f47dd2ae55bff97fd9cb:
platform/x86: thinkpad_acpi: Initialize local in_tablet_mode and type
(2016-12-15 12:31:48 -0800)
Thanks,
Darren Hart
Intel Open Source Technol
On Thu, Dec 15, 2016 at 08:15:02PM +0200, Andy Shevchenko wrote:
> On Wed, 2016-12-14 at 20:14 -0800, Darren Hart wrote:
> > linux-next reported in_tablet_mode and type may be used uninitialized
> > after:
> >
> > b31800283868 ("platform/x86: thinkpad_acpi: Move ta
nko
> ---
> In v2:
> - address Darren's comments
> - update tags (in particular put proper email of reporter)
>
> I dare to push this to testing ahead. If anyone has objections, tell me asap.
Looks good, thanks.
Reviewed-by: Darren Hart
>
> drivers/platform/x86/su
lock:
Please lead labels with a space:
out_free_unlock:
This makes diffs a bit nicer as the label isn't used in lieu of the function
name. This is also consistent with the rest of the file.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
cope) is 0, and
in_tablet_mode and type are assigned in both places
tp_features.hotkey_tablet is assigned.
Regardless, to make it explicit and avoid further reports, initialize
in_tablet_mode to 0 and type to "".
Signed-off-by: Darren Hart
Cc: Lyude
Cc: Henrique de Moraes Holschuh
On Thu, Dec 15, 2016 at 11:02:19AM +1100, Stephen Rothwell wrote:
> Hi Darren,
>
> On Wed, 14 Dec 2016 14:59:14 -0800 Darren Hart wrote:
> >
> > On Wed, Dec 14, 2016 at 02:21:38PM -0800, Darren Hart wrote:
> > > On Wed, Dec 14, 2016 at 01:50:44PM
is 0, and
in_tablet_mode is assigned in both places tp_features.hotkey_tablet is
assigned.
Regardless, to make it explicit and avoid further reports, initialize
in_tablet_mode to 0.
Signed-off-by: Darren Hart
Cc: Lyude
Cc: Henrique de Moraes Holschuh
Cc: Andy Shevchenko
---
drivers/pl
On Wed, Dec 14, 2016 at 02:21:38PM -0800, Darren Hart wrote:
> On Wed, Dec 14, 2016 at 01:50:44PM +1100, Stephen Rothwell wrote:
> > Hi Darren,
> >
> > After merging the drivers-x86 tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning
et_mode, res;
> ^
>
> Introduced by commit
>
> b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into
> separate function")
>
> I can't tell if this is a false positive or not.
That's an uninitialized local variable. Not sure how I missed that. I'll
fix it up today. Thank you for the report.
--
Darren Hart
Intel Open Source Technology Center
e.
> Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode.
>
> Tested-by: Daniel Martin
> Signed-off-by: Lyude
Our apologies for the delay. Thank you for the updates.
Queued to testing.
--
Darren Hart
Intel Open Source Technology Center
s too narrow). I expect that to stay true
> as long as there are ARM Chromebooks, which is hopefully forever. :)
>
Yes, that makes sense.
--
Darren Hart
Intel Open Source Technology Center
ace.
> + */
> + if (ret && rt_mutex_owner(pi_mutex) == current)
> + rt_mutex_unlock(pi_mutex);
> +
> /* Unqueue and drop the lock. */
> unqueue_me_pi(&q);
> }
>
> - /*
> - * If fixup_pi_state_owner() faulted and was unable to handle the
> - * fault, unlock the rt_mutex and return the fault to userspace.
> - */
> - if (ret == -EFAULT) {
> - if (pi_mutex && rt_mutex_owner(pi_mutex) == current)
> - rt_mutex_unlock(pi_mutex);
> - } else if (ret == -EINTR) {
> + if (ret == -EINTR) {
> /*
>* We've already been requeued, but cannot restart by calling
>* futex_lock_pi() directly. We could restart this syscall, but
>
--
Darren Hart
Intel Open Source Technology Center
> > In this path the fixup can return -EFAIL as well, so it should drop rtmutex
> > too if it owns it. We should move the rtmutex drop into the fixup
> > functions...
>
> Urgh, so would really like to avoid doing that, I'll have to instantly
> drag it back out again :/
Why would you have to drag it back out again? Something else you're working on?
--
Darren Hart
Intel Open Source Technology Center
edical leave through Nov 28. In the meantime, Andy
Shevchenko (on Cc) will be taking the lead on drivers/platform/x86 patches.
Andy, please work with Tan Jui to update this change to apply to our tree.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
radead.org/users/dvhart/linux-platform-drivers-x86.git
tags/platform-drivers-x86-v4.9-3
for you to fetch changes up to 8ec4b736d709562193566156c0dd40e327df2cbb:
Documentation/ABI: ibm_rtl: The "What:" fields are incomplete (2016-11-01
09:27:33 -0700)
Thanks,
Darren Hart
Intel Op
On Sun, Nov 06, 2016 at 12:05:12AM -0200, Marcos Paulo de Souza wrote:
> Hi Darren,
>
> On Sat, Nov 05, 2016 at 11:24:04AM -0700, Darren Hart wrote:
> > On Mon, Oct 31, 2016 at 11:56:10PM -0200, Marcos Paulo de Souza wrote:
> > > Without this patch, the Asus X45U wirel
acement of "v2" in the subject [PATCH vX N/M] prefix.
Most all of my feedback here is minor, but there were enough little things that
added up and I'd like to see this resubmitted as a series with those addressed
that applies cleanly - largely to make sure I haven't missed context and somehow
merged the wrong bits.
Thanks Lyude,
--
Darren Hart
Intel Open Source Technology Center
) {
> + /* For X1 Yoga (2016) */
> + tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_CMMD;
> + type = "CMMD";
> }
>
> if (!tp_features.hotkey_tablet)
> @@ -3928,6 +3951,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
> *ignore_acpi_ev = true;
> return true;
>
> + case TP_HKEY_EV_TABLET_CHANGED:
> + tpacpi_input_send_tabletsw();
> + hotkey_tablet_mode_notify_change();
> + *send_acpi_ev = false;
> + break;
> +
> default:
> pr_warn("unknown possible thermal alarm or keyboard event
> received\n");
> known = false;
> --
> 2.7.4
>
>
--
Darren Hart
Intel Open Source Technology Center
let" : "laptop");
> - res = add_to_attr_set(hotkey_dev_attributes,
> - &dev_attr_hotkey_tablet_mode.attr);
> - }
> -
> if (!res)
> res = register_attr_set_with_sysfs(
> hotkey_
On Sat, Nov 05, 2016 at 11:45:22AM -0700, Darren Hart wrote:
> On Thu, Oct 27, 2016 at 03:46:44PM -0400, Lyude wrote:
> > For whatever reason, the X1 Yoga doesn't support the normal method of
> > querying for tablet mode. Instead of providing the MHKG method under the
>
tion/SubmittingPatches.
I've queued this to testing as it addresses Henrique's change request. Henrique,
I'll add your Reviewed-by if you send it along, or drop it if you have more
reservations.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
ad-laptop.
> >
> > So, This patch adds the logic to check the machine that has AMW0_GUID1
> > should be in Acer/Packard Bell/Gateway white list. But, it still keeps
> > the quirk list of those supported non-acer machines for backward
> > compatible.
> >
> >
d include:
Cc: # 4.4.x-
But this should mean that the patch is explicitly broken or otherwise
inappropriate for 4.3 and earlier.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
to see something more like:
if (we should setup the accelerometer)
reval = ah
return AE_OK
return AE_CTRL_TERMINATE
If I'm misunderstanding this, can you please try to explain - a comment in the
function would be useful.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
gned-off-by. I also ask that you
attempt to apply this yourself before sending it back to stable. Does it
apply to 4.8? 4.1? 3.18? How far back do you want to see this backported
to stable?
--
Darren Hart
Intel Open Source Technology Center
On Wed, Oct 26, 2016 at 11:43:24PM +0200, Thomas Gleixner wrote:
> On Wed, 26 Oct 2016, Darren Hart wrote:
> > On Mon, Oct 24, 2016 at 01:38:54PM +, Tirdea, Irina wrote:
> > > intel_pmc_* drivers or is it enough to move it as a standalone driver for
> > > now?
>
e
> > > files. It's pure peripheral driver enablement. So drivers/platform/x86 is
> > > the proper location for this. Please discuss this with Darren Hart
> > > (cc'ed).
> >
>
> Thanks for pointing me in the right direction, Thomas!
>
> > We
warning,
> >> something about
> >> HWMON having a dependency on HAS_IOMEM.
> >
> > Hi Randy,
> >
> > Yes,
> > I built tree with this fix with the attached .config file.
> > Didn't see kconfig warnings.
> > I can have a look again.
>
> No need. lib/Kconfig handles it:
>
> config HAS_IOMEM
> bool
> depends on !NO_IOMEM
> select GENERIC_IO
> default y
>
>
> thanks.
> --
> ~Randy
>
Thanks for the review all. I've merged this with the original commit, now in
next.
--
Darren Hart
Intel Open Source Technology Center
u64 *val)
This is using a minimal allnoconfig with the pdx86 configs enabled. Config
attached. Can you have a look please?
Thanks,
--
Darren Hart
Intel Open Source Technology Center
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.9.0-rc1 Kernel Configuration
#
CONFIG_64BIT
file *file, const char __user
> +*userbuf, size_t count, loff_t *ppos)
> +{
> + u32 val, buf_size, fd;
> + int err = 0;
> + struct pmc_dev *pmcdev = &pmc;
Nit for future reference, declare in order of line length when possible, longest
first. I corrected in the series I pushed to 'testing'. No need to resend.
--
Darren Hart
Intel Open Source Technology Center
@@ config MLX_CPLD_PLATFORM
> tristate "Mellanox platform hotplug driver support"
> default n
> depends on MLX_PLATFORM
> + select HWMON
> select I2C
> ---help---
> This driver handles hot-plug events for the power suppliers, power
> --
> 2.1.4
>
>
--
Darren Hart
Intel Open Source Technology Center
On Sun, Oct 23, 2016 at 10:23:53AM +0200, Jiri Pirko wrote:
> Sun, Oct 23, 2016 at 08:14:53AM CEST, vad...@mellanox.com wrote:
> >
> >
> >> -Original Message-
> >> From: Darren Hart [mailto:dvh...@infradead.org]
> >> Sent: Friday, October 21, 2016
to Documentation/kernel-documentation.rst
> guideline;
> Fix added by Vadim:
> Fix re-scheduling flow for possibly missed signals. By mistake it
> was coupled with FAN.
Thanks Vadim. Merged to for-next for 4.10.
Also for 4.10, it would be good to move mlx-platform out of arch/x86/platform to
drivers/platform/x86 as it isn't an architectural driver. Would you be able to
prepare the patch?
Thanks,
--
Darren Hart
Intel Open Source Technology Center
On Wed, Oct 19, 2016 at 05:27:49PM -0600, Azael Avalos wrote:
> Hi Darren,
>
> 2016-10-19 14:26 GMT-06:00 Darren Hart :
>
> >
> > Want to going to stable?
>
> If possible, yes, as this issue affects other laptop manufacturers,
> we may never know if someone
arch/x86/platform/atom/pmc_atom.c into
> drivers/platform/x86. There is nothing architecture specific in these
> files. It's pure peripheral driver enablement. So drivers/platform/x86 is
> the proper location for this. Please discuss this with Darren Hart (cc'ed).
We've been ad
gt; + *documentation and/or other materials provided with the distribution.
> + * 3. Neither the names of the copyright holders nor the names of its
> + *contributors may be used to endorse or promote products derived from
> + *this software without specific prior written permissio
On Wed, Oct 12, 2016 at 10:26:43AM -0600, Azael Avalos wrote:
> *ping*
>
> 2016-08-28 11:00 GMT-06:00 Darren Hart :
> > On Thu, Aug 25, 2016 at 12:50:55PM -0600, Azael Avalos wrote:
> >> Bug 150611 uncovered that the WMI ID used by the toshiba-wmi driver
> >> is
-drivers-x86.git
tags/platform-drivers-x86-v4.9-2
for you to fetch changes up to ea893695ec1131a5fed0523ff8094bc6e8723bbe:
platform/x86: asus-wmi: add SERIO_I8042 dependency (2016-10-12 22:59:33 +0200)
Thanks,
Darren Hart
Intel Open Source Technology Center
adds extra features
> like wireless radio and bluetooth control, leds, hotkeys, backlight...
> --
> 2.9.0
>
>
--
Darren Hart
Intel Open Source Technology Center
changes up to 127595ed21c1bb24e20d488914b70ca7a643f7a4:
platform/x86: intel_pmc_core: avoid boot time warning for !CONFIG_DEBUGFS_FS
(2016-10-12 01:12:28 -0700)
Thanks,
Darren Hart
Intel Open Source Technology Center
platform
10-13IKB to the no_hw_rfkill dmi list,
> fixing the WiFI breakage.
>
> Signed-off-by: Brian Masney
Thanks Brian,
Queued to testing.
--
Darren Hart
Intel Open Source Technology Center
("pmc_core", NULL);
> > - if (IS_ERR_OR_NULL(dir))
> > + if (!dir)
> > return -ENOMEM;
>
> Hah, no, you shouldn't ever care about any return value being "wrong"
> from debugfs, the code should just continue on as normal.
>
> And yes, you are correct, the IS_ERR_OR_NULL() is totally wrong.
>
> thanks,
>
> greg k-h
>
Thanks Arnd and Greg, appreciate the catch and the fix.
Applied.
--
Darren Hart
Intel Open Source Technology Center
; Signed-off-by: SeongJae Park
No objection. Terminfo slists these separately, and I don't see a way to handle
ANSI in a single command.
Acked-by: Darren Hart
> ---
> tools/testing/selftests/futex/functional/run.sh | 2 +-
> tools/testing/selftests/futex/run.sh
On Thu, Sep 29, 2016 at 07:19:21AM +0200, Julia Lawall wrote:
>
>
> On Wed, 28 Sep 2016, Darren Hart wrote:
>
> > On Sun, Sep 11, 2016 at 03:05:59PM +0200, Julia Lawall wrote:
> >
> > Hi Julia,
> >
> > > For structure types defined in the same fil
On Thu, Sep 29, 2016 at 09:29:09AM -0400, Thomas Gleixner wrote:
> On Wed, 28 Sep 2016, Darren Hart wrote:
> > This through me as I was trying to reconcile this series with another
> > mellanox
> > platform driver from Vadim to the drivers/platform/x86 tree as this one
On Thu, Sep 29, 2016 at 08:59:55AM +0800, Axel Lin wrote:
> 2016-09-29 7:36 GMT+08:00 Darren Hart :
> > +LKML
> >
> > Axel, please always include LKML on any patch.
>
> I thought +LKML is optional if you already have a dedicated
> platform-driver-x86 maillist.
Nop
telem_apl_pss_idle_data,
> .pcs_idle_blkd_data = telem_apl_pcs_idle_blkd_data,
> .pcs_s0ix_blkd_data = telem_apl_pcs_s0ix_blkd_data,
>
>
--
Darren Hart
Intel Open Source Technology Center
v.telem_pmc_ssram_size - 1;
>
> - ret = platform_device_add_resources(pdev, telemetry_res,
> - ARRAY_SIZE(telemetry_res));
> - if (ret) {
> - dev_err(ipcdev.dev,
> - "Failed to add telemetry platform resources\n");
or SoC specific) in the same way
most of the others in arch/x86/platform are, but instead is more akin to the
end-product laptop drivers and such in drivers/platform/x86 which build platform
data from DMI strings, ACPI HIDs, etc.
If this isn't the right distinction between the two similarly named trees ...
how would you like to distinguish them? I'll volunteer to get that documented
someplace convenient to make it easier to decide what goes where.
--
Darren Hart
Intel Open Source Technology Center
provided with the distribution.
> + * 3. Neither the names of the copyright holders nor the names of its
> + *contributors may be used to endorse or promote products derived from
> + *this software without specific prior written permission.
> + *
> + * Alternatively, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") version 2 as published by the Free
> + * Software Foundation.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef __LINUX_PLATFORM_DATA_MLXCPLD_HOTPLUG_H
> +#define __LINUX_PLATFORM_DATA_MLXCPLD_HOTPLUG_H
> +
> +/* mlxcpld_hotplug_device - I2C device data:
> + * @adapter - ;
> + * @client - ;
> + * @brdinfo - ;
> + * @bus - ;
This comment blocks adds no information as it stands, please fill it out, or
remove it.
> + */
> +struct mlxcpld_hotplug_device {
> + struct i2c_adapter *adapter;
> + struct i2c_client *client;
> + struct i2c_board_info brdinfo;
> + u16 bus;
> +};
> +
> +/* mlxcpld_hotplug_platform_data - device platform data:
> + * @top_aggr_offset - offset of top aggregation interrupt register;
> + * @top_aggr_mask - top aggregation interrupt common mask;
> + * @top_aggr_psu_mask - top aggregation interrupt PSU mask;
> + * @psu_reg_offset - offset of PSU interrupt register;
> + * @psu_mask - PSU interrupt mask;
> + * @psu_count - number of equipped replaceable PSUs;
> + * @psu - pointer to PSU devices data array;
> + * @top_aggr_pwr_mask - top aggregation interrupt power mask;
> + * @pwr_reg_offset - offset of power interrupt register
> + * @pwr_mask - power interrupt mask;
> + * @pwr_count - number of power sources;
> + * @pwr - pointer to power devices data array;
> + * @top_aggr_fan_mask - top aggregation interrupt FAN mask;
> + * @fan_reg_offset - offset of FAN interrupt register;
> + * @fan_mask - FAN interrupt mask;
> + * @fan_count - number of equipped replaceable FANs;
> + * @fan - pointer to FAN devices data array;
> + */
> +struct mlxcpld_hotplug_platform_data {
> + u16 top_aggr_offset;
> + u8 top_aggr_mask;
> + u8 top_aggr_psu_mask;
> + u16 psu_reg_offset;
> + u8 psu_mask;
> + u8 psu_count;
> + struct mlxcpld_hotplug_device *psu;
> + u8 top_aggr_pwr_mask;
> + u16 pwr_reg_offset;
> + u8 pwr_mask;
> + u8 pwr_count;
> + struct mlxcpld_hotplug_device *pwr;
> + u8 top_aggr_fan_mask;
> + u16 fan_reg_offset;
> + u8 fan_mask;
> + u8 fan_count;
> + struct mlxcpld_hotplug_device *fan;
> +};
> +
> +#endif /* __LINUX_PLATFORM_DATA_MLXCPLD_HOTPLUG_H */
> --
> 2.1.4
>
>
--
Darren Hart
Intel Open Source Technology Center
ing this all down.
A couple of minor nits below, which I've taken care of.
Queued to testing.
>
> Signed-off-by: Oleksij Rempel
> Cc: Alex Henrie
> Cc: Dmitry Torokhov
> Cc: Corentin Chary
> Cc: Darren Hart
> Cc: acpi4asus-u...@lists.sourceforge.net
> Cc: platform-d
On Wed, Sep 07, 2016 at 09:28:15AM -0600, Azael Avalos wrote:
> This patch simply decouples te error checking of the ACPI status and
> the actual BT status, as those two were nested in an if/else check,
> but are completely unrelated.
>
> Signed-off-by: Azael Avalos
Queued, than
601 - 700 of 1672 matches
Mail list logo
