>From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
From: Fei Yang
Date: Mon, 26 Aug 2013 11:21:48 -0700
Subject: [PATCH] FIXDEP: error opening depfile
Met a kernel build issue where fixdep fails to open a depfile,
fixdep: error opening depfile: drivers/driver-name/.driver-co
>> From: Fei Yang
>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>> Subject: [PATCH] FIXDEP: error opening depfile
>>
>> Met a kernel build issue where fixdep fails to open a depfile,
>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d:
>> No such file or directory
>> make[4]: ***
From: Fei Yang
Date: Mon, 26 Aug 2013 11:21:48 -0700
Subject: [PATCH] FIXDEP: error opening depfile
Met a kernel build issue where fixdep fails to open a depfile,
fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d:
No such file or directory
>>
>> I thought fixdep is about finding module dependency, and it isn't
>> needed for built-in drivers. Please correct me if I'm wrong.
>
>fixdep filters the *.d files generated by gcc. These files record source
>-> object file dependencies, to not miss rebuilds.
OK, then it's more likely to be a ti
>> static struct resource axp288_fuel_gauge_resources[] = {
>> {
>> .start = AXP288_IRQ_QWBTU,
>> @@ -572,6 +587,11 @@ static struct mfd_cell axp288_cells[] = {
>> .resources = axp288_fuel_gauge_resources,
>> },
>> {
>> +.name = "axp20x-pek", /*
> +/* Whiskey Cove PMIC share same ACPI ID between different platforms */
> +#define BROXTON_PMIC_WC_HRV 4
> +static int bxtwc_probe(struct platform_device *pdev) {
> + int ret;
> + struct resource *res;
> + struct intel_soc_pmic *pmic;
> + acpi_status status;
> + unsig
> > >Why is this being added to the regmap core rather than being
> > >implemented in using the reg_write() and reg_read() callbacks in the
> > >core driver for the PMIC?
> > Thanks. I don't receive this message before in eamil.
> > Current regmap only support register access using several bus:
+ if (intel_mid_identify_cpu() ==
+ INTEL_MID_CPU_CHIP_TANGIER) {
+ if (!strncmp(pentry->name,
+ "r69001-ts-i2c", 13))
+
>> The detail is
>> Beside pmic core driver itself, there are many pmic function device
>> dirvers, such as gpio, theremal, charger, bcu ..., will use this regmap api
>> to access registers.
> This sounds like this is a single device, not a generic bus.
Well, yes this is more like a bridge to th
Sorry, this one has wrong commit message, please comment on the other patch
with [PATCH 02/14] removed
> From: Fei Yang
>
> Some implementations may require an additional step for setting the FID bits
> to ensure correct transactions over the IOSF side band interface.
> Add the FID support acc
> In subject better to use x86/platform/iosf_mbi prefix.
Will update commit message.
>> Some implementations may require an additional step for setting the
>> FID
> What FID stands for?
Function ID defined in IOSF specification. Will add more detail in the updated
commit message.
>> Change-Id:
> Can only be true for last TRB
>
| if (event->status & DEPEVT_STATUS_IOC)
| return 1;
This is the problem. The whole USB request gets only one interrupt when the
last TRB completes, so dwc3_gadget_ep_reclaim_trb_sg()
gets called with event->status = 0x6 which has DEPEVT_STATU
>> One question that comes to my mind is this: Does the USB transmission
>> stall (e.g. endpoint stall) or not? In other words, is adb connection
>> broken because USB stops transmitting anything, or because the data is
>> transmitted but its integrity is broken during transmission and that
>>
One question that comes to my mind is this: Does the USB
transmission stall (e.g. endpoint stall) or not? In other words, is
adb connection broken because USB stops transmitting anything, or
because the data is transmitted but its integrity is broken during
transmission
> > Can only be true for last TRB
> >
| if (event->status & DEPEVT_STATUS_IOC)
| return 1;
>
> This is the problem. The whole USB request gets only one interrupt when the
> last TRB completes, so dwc3_gadget_ep_reclaim_trb_sg()
> gets called with event->status = 0x6 which has D
> On Tue, Mar 19, 2019 at 10:56 PM Josh Gao wrote:
> >
> > On Tue, Mar 19, 2019 at 10:32 PM wrote:
> > >
> > > From: Fei Yang
> > >
> > > The following kernel panic happens due to the io_data buffer gets
> > > deallocated before the async io is completed. Add a check for the
> > > case where i
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index
> 0e5cfeb..5e771a2 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -183,5 +183,6 @@ obj-$(CONFIG_MFD_RT5033) += rt5033.o
> obj-$(CONFIG_MFD_SKY81452) += sky81452.o
>
> intel-soc-pmic-objs := intel
>> The following line of code in function ffs_epfile_io is trying to set
>> flag io_data->use_sg in case buffer required is larger than one page.
>>
>> io_data->use_sg = gadget->sg_supported && data_len > PAGE_SIZE;
>>
>> However at this point of time the variable data_len has not been set
>>
18 matches
Mail list logo
