> Why can't you just revert this in userspace? Isn't that easier than
> doing a kernel patch and providing an option that we need to now
> maintain for pretty much forever?
I could solve it in userspace, but that really feels like a hacky
workaround and not a long term solution. It would mean tha
> What drivers/devices don't work with persist? We need to know that now,
> otherwise all other distros and users have problems, right?
We have seen a problem with the LTE modem in the Chromebook Pixel
using the usb/serial/option.c driver, but we are not quite sure of the
root cause yet. It occas
> Yes, okay, that's true. If a new USB device is plugged in while the
> lid is shut, and then the lid is opened very briefly, it's possible
> that the system could suspend again before the new device's "persist"
> attribute is updated. Does that case really matter? The device isn't
> likely to b
h
the XHCI specification. Let's change this to display the endpoint number
and direction, which are much more commonly used concepts in USB (and
map to XHCI DCIs 1-to-1).
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --gi
>> Rafael, is possible to apply the patch [1/2] I previously sent ?
>>
>> https://patchwork.kernel.org/patch/1878691/
>
> I need to talk about this with Len. That should happen tomorrow if everything
> goes well.
Hi Rafael,
Have you made a decision on picking up Daniel's first change yet? I
thin
devices before it unfreezes userspace.
This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
which allows distributions to make this decision on their own without
the need to carry a custom patch or revert the kernel's setting in
userspace.
Signed-off-by: Julius Werner
---
dr
, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner
---
drivers/usb/host
>> Is it just
>> for (prev = *first; prev; prev = prev->next)
>>xhci_segment_free(xhci, prev);
>>
>> ?
>
> Yeah, that seems cleaner.
>
> Sarah Sharp
I can submit it that way if you want, but I would advise against it. This way
you access the prev pointer after it has been freed already… th
, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner
---
drivers/usb/host
>I have noticed that the patch description has DOS line endings as well.
Sorry about those, Gmail adds them automatically. According to RFC
2046 (section 4.1.1), text/plain content must use CRLFs to encode line
breaks, so I guess this is the right thing. Your MUA should be
responsible for conv
*Ping!*
Are there still unanswered concerns left with this patch? I hope my
prior mails could clear up why I think that the PMU register
description in the device tree for a specific PHY is represents the
hardware more accurately after my patch, and my analysis of the
Exynos4 situation currently n
I've tried to get the 3503 driver to work in my case for quite some
time, but ultimately gave up. For me, playing around with the load
order was not enough to solve all issues. When you try to build a
permanent, clean solution for this, you should definitely also test
the case where the hub has alr
> So the 2.41a has BESL support, but may not set the BLC flag. What
> happens if we use the HIRD encoding instead? Will things break? It
> seems like we would need to disable USB 2.0 LPM on that host all
> together, if it expects BESL encoding, but advertises HIRD encoding.
Wait a second, just
a mutex to allow sleeping in the
critical section.
Change-Id: Ieecac52c27daa7a17a7ed3b2863ddba3aeb8d16f
Signed-off-by: Julius Werner
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 10 ++
drivers/usb/phy/phy-samsung-usb.c | 17 ++
drivers/usb/phy/phy-sam
Hi Felipe,
This is intended to pull down a reset signal line, not to switch power
to the device. I could implement that with the regulator framework
too, but I think that would just be confusing and harder to understand
without providing any benefit. It's really just a plain old GPIO.
--
To unsubs
Hi Jingoo,
Yeah, I followed that discussion back then, but it seems to have
stalled a little (at least the HSIC patches haven't been picked up in
any kernel.org repo yet to my knowledge).
The problem is that I think these approaches cannot work reliably. I
agree that it would be nice to control t
> If you take a look at Table
> 13: BESL/HIRD Encoding from the xHCI spec version including errata to
> 08/14/2012
Could you please provide a link to that errata? I still cannot find
it... but from your explanation, that design decision sounds pretty
horrible. Why didn't they just choose not to se
> This is specific to the acpi and should be handled in the
> processor_idle.c file instead of the cpuidle core code.
>
> Could be the function 'acpi_processor_cst_has_changed' the right place
> to set a dummy power value for the power in the new C-state ?
Thanks for your feedback. I think it woul
to enter them.
This patch ensures that the ACPI cpuidle driver sets those dummy power
values itself whenever it (re-)initializes its idle states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.
Signed-off-by: Julius Werner
> Could we just say this is always true because state[i+1] consumes less
> than state[i] ?
>
> And then just remove the 'set_power_state' function, and the field
> 'driver->power_specified' ?
>
> That will cleanup the code and fix this problem, no ?
I totally agree with your analysis. Even if a dr
Hi,
What is the current status of this? Daniel, do you think you have got
enough feedback to submit a definitive patch for this? Rafael, would
you approve of such a change?
The bug with dynamically added C-states that is tied to this still
hurts the battery life for some users across all distros
handling.
I understand that not everyone here agrees on what the best solution
is, but I think both of them are far better than the inconsistent and
potentially hard-disk-filling way that the current kernel does it.
On Wed, 2012-11-07 at 11:33 -0800, Julius Werner wrote:
> tcp_recvmsg contains a san
Thanks for moving this along, Daniel. I think this is the right
approach... the cpuidle driver shouldn't be more complex than
necessary.
Note that you are starting your loop too high in cpuidle_play_dead...
states[state_count] is not an actual state anymore, it should start at
state_count - 1. Als
igned-off-by: Julius Werner
---
arch/powerpc/platforms/pseries/processor_idle.c |4 ++--
drivers/acpi/processor_idle.c | 12 ++--
drivers/cpuidle/cpuidle.c |3 +--
drivers/idle/intel_idle.c | 13 -
4
> Maybe you can remove all these computations and set the flag
> en_core_tk_irqen for the driver ? That will be handled by the cpuidle
> framework, no ?
>
> Same comment for the intel_idle driver.
Yeah, I thought about that, too. I was a little too afraid of touching
the sched_clock_idle_wakeup_ev
d
not appear anymore.
Signed-off-by: Julius Werner
---
arch/powerpc/platforms/pseries/processor_idle.c |4 +-
drivers/acpi/processor_idle.c | 57 +-
drivers/cpuidle/cpuidle.c |3 +-
drivers/idle/intel_i
e cause of the error can be identified right away and the
system's hard drive is not unnecessarily strained.
Signed-off-by: Julius Werner
---
net/ipv4/tcp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 197c000..fcb0927 100644
> We've had reports of this WARN against the Fedora kernel for a while.
> Had this been immediately followed by a BUG(), we'd have never seen those
> traces at all,
> and just got "my machine just locked up" reports instead.
>
> The proper fix here is to find out why we're getting into this state.
I tend to agree with Dave that it's not in the user's best interest to
have a full-on BUG() here, and that we can get our reports just as
well by fishing them from the log through abrt or something similar. I
will just submit my alternative patch too and let you decide which one
you prefer.
This v
EBADFD to userspace (which seems most appropriate to me at this
point). As the underlying bug condition is "impossible" and therefore by
definition unrecoverable, this is the only sensible action other than a
full panic.
Signed-off-by: Julius Werner
---
net/ipv4/tcp.c |7 ++-
1 files c
> What I find very sad in all this is that you didnt mention the driver
> that was triggering this bug.
Sorry, I was just trying to keep this thread focussed on one patch.
The bug report that led me to this is publicly accessible at
http://crosbug.com/35827. We have encountered the problem only on
> So you probably are fighting a bug we already fixed in upstream kernel.
>
> (commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
> played well with cloned skbs.)
>
> This issue was already discussed on netdev in the past.
Thanks for the hint. Unfortunately, we have not pulled c86
that node to also print said log message if that write fails, so
that we can figure out the offending wakeup source for both kinds of
suspend aborts.
Signed-off-by: Julius Werner
---
drivers/base/power/wakeup.c | 5 +++--
include/linux/suspend.h | 1 +
kernel/power/main.c | 2 ++
3
dev.read()") and kill -9 the
process. However, you will have to pull in my other patch first ("usb:
xhci: Fix Command Ring Stopped Event handling"), or you may run into a
follow-up problem with cancelled commands that kills your whole HCD.
> On Fri, May 24, 2013 at 06:39:37PM -0700,
that node to also print said log message if that write fails, so
that we can figure out the offending wakeup source for both kinds of
suspend aborts.
Signed-off-by: Julius Werner
---
drivers/base/power/wakeup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/power/wakeup.c b
contain this chip.
Julius Werner (3):
usb: misc: usb3503: Fix up whitespace
usb: misc: usb3503: Remove hardcoded disabling of ports 2 and 3
usb: misc: usb3503: Remove 100ms sleep on reset, conform to data
sheet
drivers/usb/misc/usb3503.c | 16 +++-
1 file changed, 3 insertions
es or a configurable mechanism (such as a device tree property).
Until then, let's keep all ports enabled.
Signed-off-by: Julius Werner
---
drivers/usb/misc/usb3503.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
ind
Remove an erroneous tab that should be a space.
Signed-off-by: Julius Werner
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index d3a1cce..73aeb87 100644
--- a/drivers/usb/misc/usb3503.c
actually requires (as per its data sheet). If certain boards
require more time to set up the reference clock, they should change this
through local patches or add a proper, configurable synchronization
mechanism.
Signed-off-by: Julius Werner
---
drivers/usb/misc/usb3503.c | 6 ++
1 file changed, 2
Resending as plain text... sorry for the spam, Gmail just likes to
silently mess up my settings every once in a while.
On Tue, Jun 11, 2013 at 4:17 PM, Julius Werner wrote:
>
>> This is going to be done in the autosleep case too, which I'm slightly
>> concerned about.
&g
>> I liked the ones where we had IS_ERR_OR_NULL() here (and in all the
>> ones below)... you sometimes have to handle PHYs in
>> platform-independent code where you don't want to worry about if this
>> platform actually has a PHY driver there or not. Any reason you
>> changed that?
>
> The **get_ph
same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung
>> - if (sphy->phy_type == USB_PHY_TYPE_DEVICE) {
>> - reg = sphy->pmuregs + sphy->drv_data->devphy_reg_offset;
>> - en_mask = sphy->drv_data->devphy_en_mask;
>> - } else if (sphy->phy_type == USB_PHY_TYPE_HOST) {
>> - reg = sphy->pmuregs + sphy
same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung
same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung-usb.c | 51
r messages.
This patch makes the choice of reset dependent on the port status that
has just been read from the hub, as opposed to any previous in-kernel
state, thus working around this problem.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 4 ++--
1 file changed, 2 insertions(+), 2
-andiry.xu... he wrote that section originally but it seems that his
address is no longer available.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pl
> Wait a moment. Why does each of these attempts lead to a 5-second
> timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question. The kernel
enqueues a control transfer to the now disconnected address because
it's internal bookkeeping is not yet updated, but I
ned-off-by: Julius Werner
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4a8a1d6..558313d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4798,7 +4798,8 @@ static void
> An odd sort of bug. You'd think that not getting a response back would
> be one of the first types of error the hardware designers would check
> for.
You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
hub_port_connect
distinction which was only needed for those removed parts.
Julius Werner (3):
usb: phy-samsung-usb: Simplify PMU register handling
usb: phy-samsung-usb: trivial: rename pmuregs variable
usb: phy-samsung-usb: Remove USB_PHY_TYPE from Samsung PHY driver
arch/arm/boot/dts/exynos5250.dtsi | 4
Now that the sphy->pmuregs variable always points to only a single
register, let's rename it to make that more clear.
Signed-off-by: Julius Werner
---
drivers/usb/phy/phy-samsung-usb.c | 14 +++---
drivers/usb/phy/phy-samsung-usb.h | 4 ++--
drivers/usb/phy/phy-samsung-usb
same register.
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung-usb.c | 18 --
drivers/usb/phy/phy-samsung-usb.h | 23 +--
drivers/usb/phy/phy-samsung-usb2.c | 11 ---
drivers/usb/phy/phy-samsung
-by: Julius Werner
---
drivers/usb/phy/phy-samsung-usb.c | 23 +++
drivers/usb/phy/phy-samsung-usb.h | 7 +--
drivers/usb/phy/phy-samsung-usb2.c | 19 +++
drivers/usb/phy/phy-samsung-usb3.c | 7 ---
4 files changed, 7 insertions(+), 49 deletions
Hi Sarah,
I know you are probably swamped with patches, but this
(https://patchwork.kernel.org/patch/2612831/) has been hanging a few
months and I just wanted to double-check if it slipped through
somewhere. I still think this is necessary (regardless of any command
queue reengineering in the futu
of an Exynos5420.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-plat.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 51e22bf..7f46b5d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@
> Thanks for the patch! Did you test with a USB analyzer to see if the
> device was actually going into USB 2.0 Link PM? I'd like to confirm we
> really aren't breaking anything for DW3 hosts by enabling this.
Yes, I did. The LPM transfers on the analyzer look good and the device
works as expect
> You need the USB 2.0 spec errata from 2011-11 that describes the changes
> made for BESL as well. It's in the USB2-LPM-Errata-final.pdf and
> USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
>
> http://www.usb.org/developers/docs/usb_20_070113.zip
>
> I agree though, it's all a con
On Fri, Aug 2, 2013 at 12:51 AM, Felipe Balbi wrote:
> Hi,
>
> I need an Acked-by for the dtsi part. Ideally from Exynos 5 maintainer
> and at least one of the DT maintainers.
>
> --
> balbi
Okay, I think I forgot to update the DT bindings documentation
anyway... so I will resubmit this and addre
same register.
Signed-off-by: Julius Werner
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 26 +-
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung-usb.c | 18 ---
drivers/usb/phy/phy-samsung-usb.h
> This breaks compatibility, both for an old kernel and a new dt and a new
> kernel with an old dt. Is anyone using these bindings?
They only affect Samsung SoCs and have only been upstream for half a
year, so I doubt it's heavily used.
> Why are we describing fewer registers now? Are they descri
> @@ -94,11 +94,11 @@ static int devm_usb_phy_match(struct device *dev, void
> *res, void *match_data)
> */
> struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
> {
> - struct usb_phy **ptr, *phy;
> + struct usb_phy *phy = ERR_PTR(-ENOMEM), **ptr;
This l
> I'm not sure I understand. The old documentation referred to the
> USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> your new version only refers to (usb device) PHY_CONTROL. Regardless of
> multiple phys, you're suggesting that we describe less of each phy.
> That seems li
> Sorry, I don't understand what is not implemented. Without your patch, the
> PHY driver handles both PMU registers of Exynos4.
I don't have an Exynos4 to actually test this, so please let me know
if I'm missing something here... but in order to hit the right HOST
PHY register in the current upst
> Does this patch fix the control transfer data stage issue? Please break
> this into a bug fix for that, with your refactoring on top of that. We
> need to backport the bug fix to the stable kernels, and queue the
> refactoring for 3.11.
I don't think there is really any practial adverse effect
pts in USB.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 5f3a7c
the callers.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 111 +++
1 file changed, 29 insertions(+), 82 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1969c00..32629b2 100644
--- a/drivers/usb
B 1.1 devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner
---
drivers/usb/host/ehci-hub.c | 21 +
1 file changed, 21 insertions(+)
diff --
B 1.1 devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host/ehci-hub.c
On Thu, Apr 25, 2013 at 7:38 AM, Alan Stern wrote:
> On Wed, 24 Apr 2013, Julius Werner wrote:
>
>> The current EHCI code sleeps a flat 110ms in the resume path if there
>> was a USB 1.1 device connected to its companion controller during
>> suspend, waiting for the devi
wraps
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner
Acked-by: Alan Stern
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host/ehci-hub.c
pts in USB.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 5f3a7c
wraps
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner
Acked-by: Alan Stern
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host/ehci-hub.c
h should be backported to kernels as far as 3.0 that contain
the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI: handle
command after aborting the command ring".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 85 +---
1 file chan
the commit 3ffbba9511b4148cbe1f6b6238686adaeaca8feb "USB: xhci: Allocate
and address USB devices".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-hub.c | 7 +++
drivers/usb/host/xhci.c | 26 +++---
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/u
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing)
generic USB_QUIR
it switches from AC to battery power.
Signed-off-by: Julius Werner
---
drivers/cpuidle/cpuidle.c | 24
drivers/cpuidle/driver.c | 25 -
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle
*Ping!*
Happy New Year everyone. Is there any update on this? I think Francesco already
pointed out how to solve the last remaining issue with this, so I hope we can
now resubmit these patches and finally get them merged. Daniel?--
To unsubscribe from this list: send the line "unsubscribe linux-
Thanks again for making this happen, Daniel. I like this version,
except for the small nitpick that I still think it would make sense to
also turn the loop in menu.c around. How about something like this:
for (i = drv->state_count - 1; i >= CPUIDLE_DRIVER_STATE_START; i++) {
Thanks for the quick fix!
Reviewed-by: Julius Werner
> +config GOOGLE_COREBOOT_TABLE_ACPI
> + tristate
> + default GOOGLE_COREBOOT_TABLE
I don't think this helps in upgrading (as your commit message says)
unless you also keep the 'select GOOGLE_COREBOOT_TABLE' here, right?
> -int coreboot_table_init(struct device *dev, void __iomem *ptr
> @@ -138,8 +136,10 @@ int coreboot_table_init(struct device *dev, void __iomem
> *ptr)
> ptr_entry += entry.size;
> }
>
> - if (ret)
> + if (ret) {
> + bus_unregister(&coreboot_bus_type);
> iounmap(ptr);
> + }
nit: maybe cle
s the sparse warnings in this code and reduces the need to copy
> anything around anymore.
>
> Cc: Wei-Ning Huang
> Cc: Julius Werner
> Cc: Brian Norris
> Cc: Samuel Holland
> Signed-off-by: Stephen Boyd
> ---
> drivers/firmware/google/coreboot_table.c | 42 ++
an be repurposed for pure device creation and registration. We
> can devm()ify the memory mapping at the same time to keep error paths
> simpler.
>
> Cc: Wei-Ning Huang
> Cc: Julius Werner
> Cc: Brian Norris
> Cc: Samuel Holland
> Suggested-by: Julius Werner
> Signed-
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> Call request_mem_region() on the entire coreboot table to make sure
> other devices don't attempt to map the coreboot table in their drivers.
> If drivers need that support, it would be better to provide bus APIs
> they can use to do that thr
> Furthermore, I see that my system RAM excludes this coreboot table so it
> doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find.
Yes, that is intentional. We don't want the kernel to try to use that
memory for anything else (since we want those tables to survive), so
we mark them as
y set when "Driver has marked this resource
busy".
So after you make the change to the other patch where we immediately
unmap the coreboot table again at the end of the probe() function,
shouldn't it become available to userspace again even with
IO_STRICT_DEVMEM set?
On Thu, Aug 9, 20
the x86_64 architecture it will then cause a panic
(from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()).
This patch adds an explicit check to make sure offset + size will not
wrap around in the physical address type.
Signed-off-by: Julius Werner
---
drivers/char/mem.c | 5 +
On Sat, Jun 16, 2018 at 3:05 PM Ben Hutchings wrote:
>
> The help text for GOOGLE_FIRMWARE states that it should only be
> enabled when building a kernel for Google's own servers. However, it
> is now also a dependency for various Chromebook firmware drivers.
>
> Update the help text to reflect t
LGTM
Reviewed-by: Julius Werner
On Mon, Jun 18, 2018 at 3:55 PM Ben Hutchings wrote:
>
> The help text for GOOGLE_FIRMWARE states that it should only be
> enabled when building a kernel for Google's own servers. However,
> many of the drivers dependent on it are also useful
Thanks for all the clean-up, looks great now!
For the whole series:
Reviewed-by: Julius Werner
impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/
> You should use a sleeping function call, not a delay.
Whoops... yes, of course. Guess too much firmware work made me forget
what multithreading is there for a moment. Will send a v2.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/
impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..26bdd96 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/
patch adds optional properties for this information to
the existing "jedec,lpddr3" device tree binding to be used for that
purpose.
Signed-off-by: Julius Werner
---
Documentation/devicetree/bindings/ddr/lpddr3.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/
Sieben (1):
Suspicious indentation detection after conditional statement
Julius Werner (2):
checkpatch: ctx_statement_block: Fix preprocessor guard tracking
checkpatch: Ignore labels when checking indentation
scripts/checkpatch.pl | 56 +++
1 file c
to not try to restore any
previous state (which we don't have) at all, so we should just keep our
current state if $#stack is already 0.
Signed-off-by: Julius Werner
---
scripts/checkpatch.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/sc
space. The SUSPICIOUS_CODE_INDENT test also needs
to explicitly ignore labels to make sure it doesn't get confused by
them.
Signed-off-by: Julius Werner
---
scripts/checkpatch.pl | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/chec
From: Ivo Sieben
Raise a SUSPICIOUS_CODE_INDENT warning when unexpected indentation is found
after a conditional statement. This can be used to find missing braces or
wrong indentation in/after a conditional statement.
For example the following error is caught;
if (foo)
1 - 100 of 217 matches
Mail list logo
