On Mon, 2013-12-16 at 08:01 -0500, Prarit Bhargava wrote:
> Sorry everyone, I was out on PTO for the past few weeks.
>
>
> On 12/06/2013 07:30 AM, Matt Fleming wrote:
> > On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
> >> On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
> >>> On Wed,
Sorry everyone, I was out on PTO for the past few weeks.
On 12/06/2013 07:30 AM, Matt Fleming wrote:
> On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
>> On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
>>> On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
The other part I
Sorry everyone, I was out on PTO for the past few weeks.
On 12/06/2013 07:30 AM, Matt Fleming wrote:
On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
The other part I noticed about
On Mon, 2013-12-16 at 08:01 -0500, Prarit Bhargava wrote:
Sorry everyone, I was out on PTO for the past few weeks.
On 12/06/2013 07:30 AM, Matt Fleming wrote:
On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
On Wed, 04 Dec, at
On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
> On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
> > On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
> > > The other part I noticed about this particular patchset is that it's
> > > not really "firmware" as such, but specifically PC
On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
The other part I noticed about this particular patchset is that it's
not really firmware as such, but specifically PC wiht ACPI that
On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
> On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
> > The other part I noticed about this particular patchset is that it's
> > not really "firmware" as such, but specifically PC wiht ACPI that
> > gets covered here. So rather than
On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
> The other part I noticed about this particular patchset is that it's
> not really "firmware" as such, but specifically PC wiht ACPI that
> gets covered here. So rather than generalizing the code, another
> option would be to narrow down the
On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
The other part I noticed about this particular patchset is that it's
not really firmware as such, but specifically PC wiht ACPI that
gets covered here. So rather than generalizing the code, another
option would be to narrow down the scope and
On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
The other part I noticed about this particular patchset is that it's
not really firmware as such, but specifically PC wiht ACPI that
gets covered here. So rather than generalizing the
On Tuesday 03 December 2013, Andrew Morton wrote:
> I do wonder if it all should be generalised a bit - it creates a bunch
> of infrastructure which is specific to system firmware issues, but
> what's so special about firmware? Why can't I use this infrastructure
> to log netdev errors or acpi
On Wed, 2013-12-04 at 06:51 -0500, Prarit Bhargava wrote:
>
> On 12/03/2013 04:21 PM, Andrew Morton wrote:
> > On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava
> > wrote:
> > A slight simplification:
> >
> >> +static inline char *dump_hadware_arch_desc(void)
> >> +{
> >> + return NULL;
> >>
On 12/03/2013 04:21 PM, Andrew Morton wrote:
> On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava wrote:
> A slight simplification:
>
>> +static inline char *dump_hadware_arch_desc(void)
>> +{
>> +return NULL;
>> +}
>
> return "unavailable";
>
>> +void warn_slowpath_fmt_dev(const
On 12/03/2013 04:21 PM, Andrew Morton wrote:
On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava pra...@redhat.com wrote:
A slight simplification:
+static inline char *dump_hadware_arch_desc(void)
+{
+return NULL;
+}
return unavailable;
+void warn_slowpath_fmt_dev(const
On Wed, 2013-12-04 at 06:51 -0500, Prarit Bhargava wrote:
On 12/03/2013 04:21 PM, Andrew Morton wrote:
On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava pra...@redhat.com
wrote:
A slight simplification:
+static inline char *dump_hadware_arch_desc(void)
+{
+ return NULL;
+}
On Tuesday 03 December 2013, Andrew Morton wrote:
I do wonder if it all should be generalised a bit - it creates a bunch
of infrastructure which is specific to system firmware issues, but
what's so special about firmware? Why can't I use this infrastructure
to log netdev errors or acpi errors
On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava wrote:
> Logging and tracking firmware bugs in the kernel has long been an issue
> for system administrators. The current kernel does not have a good
> uniform method of reporting firmware bugs and the code in the kernel is a
> mix of printk's
On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava pra...@redhat.com wrote:
Logging and tracking firmware bugs in the kernel has long been an issue
for system administrators. The current kernel does not have a good
uniform method of reporting firmware bugs and the code in the kernel is a
mix
Logging and tracking firmware bugs in the kernel has long been an issue
for system administrators. The current kernel does not have a good
uniform method of reporting firmware bugs and the code in the kernel is a
mix of printk's and WARN_ONs. This causes problems for both system
administrators
Logging and tracking firmware bugs in the kernel has long been an issue
for system administrators. The current kernel does not have a good
uniform method of reporting firmware bugs and the code in the kernel is a
mix of printk's and WARN_ONs. This causes problems for both system
administrators
20 matches
Mail list logo
